JDK-8172147 : MR jar API validator doesn't detect changes in a return type of a method.
  • Type: Bug
  • Component: tools
  • Sub-Component: jar
  • Affected Version: 9
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2016-12-30
  • Updated: 2019-06-05
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.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8071566 - Improve testing for multi-version JAR file maker tool
Relates :  
JDK-8172148 - MR jar API validator doesn't detect new public/protected inner classes.
Description
Create two classes, compile and put them in base and v10 directories respectively 
public class C {
 public boolean m(){return true;}
}

public class C {
 public int m(){return 0;}
}

create MR jar
jar cf file.jar -C  base C.class,
                --release 10 -C  v10 C.class

jar tool exits successfully.
Comments
Uncomment test http://hg.openjdk.java.net/jdk9/dev/jdk/file/e15c8b97a107/test/tools/jar/multiRelease/ApiValidatorTest.java#l96 as soon as the issue is fixed
18-01-2017
The validator currently works on a best effort basis and should be good enough to catch basic changes in an API, such as the addition of new methods or fields. I expect there will be many cases that slip through, such as in this case, which is more complex since in general when there is a class hierarchy it is possible to change the return type of an overriding method to a subtype, a.k.a. covarient return types (e.g. see recent changes to nio buffers). So to do this properly, beyond checking simple cases with primitive return types, will require more work.
03-01-2017