I think this is an error. It makes more sense to have the
javax.annotation package exist in its own module. If the long-idle JSR
250 and specifications like it are really a concern, then this module
should follow the pattern of all other such modules and be upgradeable.
Note that until #AvoidConcealedPackageConflicts is resolved, AFAICT the
suggestion of depending on the JSR 250 API can't work anyway if
java.xml.ws.annotations is used because there will be two sets of the
same package in the module system.
This once again shines a bright light on a few key Jigsaw defects, and
it's getting a bit frustrating watching requirements get reconned to
compensate for implementation problems. This is purely a hack to make
up for an implementation difficulty and makes no sense when framed from
the perspective of the end user. Let's try to do better.
On 02/13/2017 08:08 AM, Claes Redestad wrote:
Hi Guillaume,
On 02/13/2017 02:34 PM, Guillaume Smet wrote:
At the end, I'm wondering if these classes shouldn't be part of the
default
set of classes exposed without requiring an --add-modules option.
one of the main reasons why java.xml.ws.annotations is not resolved
by default is that there are many projects out there with dependencies
on various JSR 305 implementations[1], which is a non-final and dormant
JSR which happen to clash with JSR 250 by adding more annotations to
the same packages... thus if java.xml.ws.annotations is resolved at
boot time using --add-modules then any project with a dependency on
one of the rogue JSR 305 implementations is likely to break[2].
A perhaps less fragile alternative here is to not depend on the
JDK-bundled java.xml.ws.annotations at all but instead depend directly
on the JSR 250 API as published by the JCP[3] as an explicit dependency.
Hope this helps!
/Claes
[1] https://jcp.org/en/jsr/detail?id=305
[2] See http://openjdk.java.net/jeps/261#EE-modules for more info
[3] E.g.:
https://mvnrepository.com/artifact/javax.annotation/jsr250-api/1.0
--
- DML
