CODEWITHSUNDEEP
javaguavatype-erasuretype-parameter
Ray
Ray

Reputation: 4869

Implementing ListeningExecutorService in Java 5

In Java 5, the ExecutorService interface declares the method:

<T> List<Future<T>> invokeAll(Collection<Callable<T>> tasks)
    throws InterruptedException;

whereas Guava 11.0.2, written in Java 6 but supposedly compatible with Java 5, overrides it in ListeningExecutorService as:

 <T> List<Future<T>> invokeAll(Collection<? extends Callable<T>> tasks)
     throws InterruptedException;

If I want to implement my own ListeningExecutorService, I would need to implement both of these methods, but I am also not able to have two methods the same erasure, so it's a bit of a Catch 22.

Is there any way around this problem? More specifically, is there any way to implement a ListeningExecutorService in Java 5?

As a side note to any Guava folks--is it actually necessary for Guava to re-declare this method since it's already inherited from ExecutorService?

Upvotes: 2

Views: 577

Answers (3)

Chris Povirk
Chris Povirk

Reputation: 3962

The way that we made this work was to override the JDK's ExecutorService interface in our bootclasspath. You could do something similar during your project's compilation. The easiest way to see our setup is probably the change that removed it for release 12 (since that release will require JDK6).

Upvotes: 2

trutheality
trutheality

Reputation: 23465

The only way I can think of implementing both interfaces, scary as it is, is

List invokeAll(Collection tasks)

drop the generic types, document why you are doing it, and be very careful.

Upvotes: 3

Natix
Natix

Reputation: 14257

The original method signature has been reported as a bug and fixed for JDK 6: https://bugs.java.com/bugdatabase/view_bug?bug_id=6267833

To quote the resolution message:

  • is binary compatible.
  • is source compatible for users of an ExecutorService
  • requires minor source code changes for the small set of developers who have implemented ExecutorService without inheriting the default implementations in AbstractExecutorService. The set of affected developers are developers creating sophisticated thread pool applications, putting them into the "concurrency rocket scientist" category. They will generally appreciate this change. The possible compiler error is trivial to fix in the source code.

Upvotes: 4

Related Questions