Just over six months after the release of JobRunr 4.0, Ronald Dehuysser, Founder and Lead Developer of JobRunr, introduced JobRunr 5.0 to provide improved support for Spring, Quarkus and Micronaut by providing a Spring Native implementation, configuration for the number default retries, database type selection, and transaction support. Now tasks can be scheduled based on an interval and cron expressions support the last day of the week and the last day of the month.

JobRunr, a free open-source JVM job scheduling tool for commercial use, enables background processing in Java using persistent storage and supports distributed solutions. The paid professional version additionally offers job queues, batches, and chaining. A generic Java library is available as well as specific solutions for Spring Boot, Micronaut and Quarkus.

An SQL, NoSQL, or InMemory data source must be configured to use JobRunr. Various options are available after configuration to run background tasks:

BackgroundJob.enqueue(() -> 
    System.out.println("Fire and forget, executed once."));
BackgroundJob.schedule(now().plusMinutes(1), () -> 
    System.out.println("Scheduled job, executed once"));
BackgroundJob.scheduleRecurrently(Cron.every30seconds(), () -> 
    System.out.println("Recurring job, executed every 30 seconds"));
BackgroundJob.enqueue(() -> jobRunrService.annotatedJob("retry"));

The last statement uses a method with the @Job annotation to retry the job on exception:

@Job(name = "Example retry job", retries = 1)
public void annotatedJob(String variable) throws Exception {
	System.out.println("Annotated job " + variable);
	throw new Exception("Trigger retry");
}

The example produces the following output, where the last line is repeated indefinitely:

Recurring job, executed every 30 seconds
Fire and forget, executed once.
Annotated job retry
java.lang.Exception: Trigger retry
…
Annotated job retry
java.lang.Exception: Trigger retry
…
Recurring job, executed every 30 seconds
Scheduled job, executed once
Recurring job, executed every 30 seconds

This new version supports Spring Native with the jobrunr-spring-boot-native dependency in order to build and run applications with GraalVM.

Task scheduling is now also possible using an instance of Duration class as a repeating interval:

BackgroundJob.scheduleRecurrently("recurring-job", Duration.ofSeconds(10), 
    () -> System.out.println("Recurring job"));

Changing recurring tasks to support intervals is a drastic change; all recurring and scheduled jobs should be deleted before upgrading to JobRunr 5.0.

JobRunr has an optional web dashboard that, among other things, displays logging. SLF4J’s Mapped Diagnostic Context (MDC) allows the use of MDC variables in logging, such as using the request correlation ID:

@Job(name = "Example retry job %X{request.correlationId}", retries = 1)

Support for Cron expressions to schedule tasks on the last day of the week and the last day of the month is now possible by placing an “L” in the day of week or day of month fields.

It is now possible to specify the default number of retries for Spring Boot, Quarkus and Micronaut:

# Spring Boot
org.jobrunr.jobs.default-number-of-retries=42

# Quarkus
quarkus.jobs.default-number-of-retries=42

# Micronaut
jobrunr:
  jobs:
	default-number-of-retries:42

When multiple databases are available for Spring Boot, Micronaut or Quarkus, it is possible to configure the JobRunr database by specifying the database typefor example sql:

# Spring Boot
org.jobrunr.database.type=sql 

# Quarkus
quarkus.jobrunr.database.type=sql

# Micronaut:
jobrunr:
  database:
	type:sql

JobRunr’s smooth API now supports Micrometer metrics:

JobRunr.configure()
    .useMicroMeter(new JobRunrMicroMeterIntegration(meterRegistry));

With this version, the dashboard has noIndex and noFollow meta tags so that publicly available dashboards on the Internet are no longer indexed by Google.

Recurring tasks are now cached and reloaded once the number of tasks changes. This improves performance since jobs are no longer reloaded from the StorageProvider interface whenever JobRunr searches for new jobs.

Breaking changes in this release will require an update to ElasticSearch and all JobRunr-related project dependencies.

The following features are only available for JobRunr Pro edition.

• Transactions created by Spring Boot Starter or Micronaut integration are used by JobRunr Pro.
• Instant processing of jobs is now possible because the BackgroundJobServer no longer requires pollInterval at least 5 seconds. Implementation of Spring, Micronaut and Quarkus beans JobClientFilter or JobServerFilter are automatically registered in JobRunr as job filters, allowing developers to extend existing JobRunr functionality.
• With ServerTags, used to specify on which server a Job can run, it is now possible to schedule a Job only on the server that scheduled it: @Job(runOnServerWithTag = "%CURRENT_SERVER")
• The JobRunr Pro dashboard now allows requeuing or deleting all failed jobs at once.
• the JobScheduler the class can now query the results of the job from the database.

Asked, in September 2021, what the Java community should know about JobRunr, Dehuysser told InfoQ:

Dehuysser: I would like to emphasize three things:

1. JobRunr does magic with ASM (which is also used by Spring, Hibernate and many other frameworks) to analyze lambda job. By using ASM, I really learned a lot about JVM bytecode, which isn’t as difficult as I imagined.
2. As JobRunr performs bytecode analysis, it also participates in the Oracle Quality Outreach program. This means that JobRunr is tested against upcoming JVM versions. This helps me to ensure that he will continue to work on new versions of Java and also helps the Java community as bugs in the JVM itself are caught earlier.
3. For users who need support or additional features, there is also JobRunr Pro. It builds on JobRunr and adds additional features such as queues with different priorities (high priority jobs are processed before low priority jobs), job chaining, atomic batches and a better table panel that adds search capabilities.

And, for every license sold, new trees are expected since 5% of revenue goes to teamtrees.

Further details on the full list of changes can be found on the JobRunr 5.0 blog post.