Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
spring-projects-issues opened this issue May 28, 2013 · 5 comments

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented May 28, 2013

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented May 31, 2013

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented May 31, 2013

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented May 31, 2013

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented May 31, 2013

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jan 12, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants