JDK-8073962 : PIT testing: Multiversion jar tool works incorrectly with anonymous classes
  • Type: Bug
  • Component: tools
  • Sub-Component: jar
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2015-02-26
  • Updated: 2017-07-20
  • Resolved: 2015-04-29
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9Fixed
Related Reports
Relates :  
JDK-8047305 - JEP 238: Multi-Release JAR Files
Description
Multiversion jar tool works incorrectly with anonymous classes having public methods.

If a class for e.g. JDK 7 has one anonymous class that implements e.g. Runnable interface and the same named class for JDK 8 has one anonymous class implementing e.g. java.util.concurrent.Callable interface, then anonymous class for JDK 8 is not put to the multiversion jar file.

Example with the code is attached ("Test14.zip").
Comments
More than that, the work of the new JAR tool will depend on the order of the private methods with anonymous classes. Imagine that you have the following structure: private void privMethod1() { java.util.concurrent.Callable<Object> callable = new java.util.concurrent.Callable<Object>() { @Override public Object call() throws Exception { return new Object(); } }; } private void privMethod2() { Runnable runnable = new Runnable() { @Override public void run() { System.out.println("run"); } }; } If you change the order of these methods in the source file, their numbers will be swapped after JAVAC compiles them. But by convention, MV-JAR tool behavior should not depend on the order of private methods.
23-04-2015
I think, yes, it should be different for anonymous classes, because anonymous classes are kind of private members, not public (you can declare anonymous class inside a private method and assign an instance of this anon class to a local variable of a private method). By the convention that we have now about this feature (AFAIK), only public API should be checked, but not private.
23-04-2015
If the two classes were not anonymous classes, but were just two named classes with the same name and different public api���s, the correct thing to do is to accept the base class and ignore the versioned class (and print a warning message). That is what happens in this case. Should there be different behavior because the classes are not named classes, but anonymous classes?
22-04-2015