Spring's TaskSchedulers should expose ScheduledExecutorService interface like TaskExecutors expose Executor [SPR-10599]

[spring-projects-issues]

Nick Williams opened SPR-10599 and commented

In Spring, TaskExecutor beans expose the java.util.concurrent.Executor interface. The advantage of this is that developers can program against an interface native to the Java SE API and then fulfill the dependency with any TaskExecutor.

Unfortunately, no such support exists for java.util.concurrent.ScheduledExecutorService. As a developer who prefers to program against Executor, my code would be cleaner and more portable if Spring's TaskScheduler beans exposed the ScheduledExecutorService interface so that I could program against that as well. If y'all do not want to make TaskScheduler extend ScheduledExecutorService (which would cause custom TaskScheduler implementations to have to change), consider instead just making ThreadPoolTaskScheduler implement ScheduledExecutorService.

(Note: I'm still not quite sure what Spring 4.0's required runtime Java version will be. If Spring 4.0 will REQUIRE Java 8 to run, you could make TaskScheduler extend ScheduledExecutorService without breaking existing implementations by using default methods.)

---

Affects: 4.0 M1

[spring-projects-issues]

Juergen Hoeller commented

The reason why we are not doing this already is that ScheduledExecutorService is a pretty extensive interface, even including lifecycle methods. The standard Executor interface is quite a different story; note that we're not implementing ExecutorService there either, just the minimal Executor.

[spring-projects-issues]

Juergen Hoeller commented

Oh, and Spring Framework 4.0 won't require Java 8 by any means. It is being built against OpenJDK 8 and has dedicated Java 8 support but remains compatible with Java 6 and 7.

[spring-projects-issues]

Nick Williams commented

Interesting. How does that work? I understand -target and -source (are you using -source 1.8 -target 1.6???), but what about classes that don't exist in the Java SE 6 API, etc.?

[spring-projects-issues]

Juergen Hoeller commented

We're building against OpenJDK 8 using -source 1.6 -target 1.6 and are calling into Java 8 specific APIs in several optional places (such as the entire org.springframework.format.datetime.standard package for JSR-310 support, the StandardReflectionParameterNameDiscoverer adapter, etc). Compatibility with Java 8 lambda expressions and method references is being achieved through compliance with their applicability rules (the target parameter needs to be a single-method interface); we don't need to compile with -target 1.8 for that purpose. We'll even be able to apply Java 8 specific annotations such as @Repeatable in a few places; on earlier JDKs where those annotations cannot be loaded, they'll silently get dropped by the JVM's annotation discovery mechanism. All in all, it's a quite straightforward arrangement.

FWIW, we've been using similar arrangements before: for example, with Spring Framework 3.2 where we support Java 5 to Java 7 while compiling against OpenJDK 7 - same approach towards optional API usage as outlined above. Even worse, with Spring 2.5, we've been supporting JDK 1.4 next to Java 5 and 6, with many parts of the framework having Java 5 specific support, plenty of specific annotations, etc while the core framework remained -target 1.4 based. Back at that time, we used separate source tress for JDK 1.4 based sources versus Java 5 based sources, compiling them independently and then merging them into the same module jars so that it all appeared as a unified whole. Fortunately we don't need to go that far anymore. We still do need to test on JDK 6 and 7 of course, catching accidental use of Java 8 APIs as far as possible.

Juergen

[spring-projects-issues]

Bulk closing outdated, unresolved issues. Please, reopen if still relevant.