This type of report is a good idea though because it's always going to e more thorough than the TCK signature tests will be.
The hard part though is eliminating all of the false alarms so that it's useful.
Cases that can trip it up:
- Public classes which are not directly exposed by the API but simply used to by the API (Util classes, factory impls etc)
- Java SE classes which likely trip up the report because the Java EE version is more recent and therefore requires endorsed or special class loading
- Vendor Implementation Hooks. These are allowed to exist and in some cases are even required. This is why one should always prefer the API shipped by the container they are using.
- Bug Fixes / MR releases might report slight changes to method signatures or additional methods.
Per Tomaz's point, a focus on EE7 is better but if someone wants to volunteer time on discovering EE6 compliance issues we would certainly address any issues discovered. Of course patches would be even better :)
-Jason
Sent from my iPhone
Agreed, that is why I am saying that javaee6 jar is not really representative, what was done with javaee7 one is completely different story.