EJB Timer vs Jakarta Scheduler
Zastąp ciężkie timery EJB prostszym harmonogramowaniem przez ManagedScheduledExecutorService z Jakarta Concurrency.
Porównanie kodu
✕ Java EE
@Stateless
public class ReportGenerator {
@Resource
TimerService timerService;
@PostConstruct
public void init() {
timerService.createCalendarTimer(
new ScheduleExpression()
.hour("2").minute("0"));
}
@Timeout
public void generateReport(Timer timer) {
// runs every day at 02:00
buildDailyReport();
}
}
✓ Jakarta EE 10+
@ApplicationScoped
public class ReportGenerator {
@Resource
ManagedScheduledExecutorService scheduler;
@PostConstruct
public void init() {
scheduler.scheduleAtFixedRate(
this::generateReport,
0, 24, TimeUnit.HOURS);
}
public void generateReport() {
buildDailyReport();
}
}
Widzisz problem z tym kodem? Daj nam znać.
Dlaczego nowoczesne podejście wygrywa
Mniej boilerplate
Bez callbacku @Timeout i ScheduleExpression, używasz standardowego API ScheduledExecutorService.
Lepsza testowalność
Zwykłe metody i mocki executora upraszczają testy bez kontenera EJB.
Podejście cloud-native
Managed executory integrują się z cyklem życia kontenera i działają w lekkich runtime'ach.
Stare podejście
EJB TimerService
Nowoczesne podejście
ManagedScheduledExecutorService
Od JDK
11
Poziom trudności
Średniozaawansowany
Wsparcie JDK
EJB Timer vs Jakarta Scheduler
Dostępne
Dostępne od Jakarta EE 10 / Concurrency 3.0
Jak to działa
Timery EJB wymagają beana @Stateless lub @Singleton, callbacku @Timeout i wyrażeń harmonogramu w adnotacjach albo XML. Jakarta Concurrency udostępnia ManagedScheduledExecutorService z dobrze znanym API java.util.concurrent. To mniej boilerplate, łatwiejsze testy jednostkowe i brak zależności od kontenera EJB.
Powiązana dokumentacja