Java SE JSR 250 annotations module renamed to

David M. Lloyd david.lloyd at
Mon Feb 13 14:32:40 UTC 2017

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 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 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 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 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]
> [2] See for more info
> [3] E.g.:


More information about the jigsaw-dev mailing list