Java SE JSR 250 annotations module renamed to java.xml.ws.annotation?

[David M. Lloyd]

On 02/13/2017 08:58 AM, David M. Lloyd wrote:
> On 02/13/2017 08:49 AM, Alan Bateman wrote:
>> On 13/02/2017 14:32, David M. Lloyd wrote:
>>
>>> 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.
>> It is its own module and it is upgradable.
>>
>>>
>>> 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.
>> The technical debt here that a handful of APIs are "shared" between Java
>> SE and Java EE. The first steps to addressing that technical debt are in
>> the JSR 379 EDR.
>
> I would agree but for the problem of @Generated.  Would that it had been
> put into java.lang.annotation to begin with!  But the reality is that
> there has been a long-standing assumption that is broken with Java 9
> that this class would be in the JDK, thus code generators have been free
> to include this annotation (which, on the surface, seems like a useful
> thing to do) without fear of introducing additional dependencies.  Now
> it's a compilation error unless you either include a very non-intuitive
> module name, or else an external dependency.  The authors of such code
> generators can likely figure this out, but users will almost certainly
> run into trouble.  It's yet another bump without a very good reason.

Here is what I said to Andrew Haley (our JSR 379 rep):

> I think that if this module is to be present in the JDK, it should retain its previous name ("java.annotations.common").  If the module is to be deprecated for removal from the platform (i.e. permanently replaced with an external dependency), then the @Generated annotation should be deprecated from JSR-250 and its related specifications, and also (ideally) moved into java.lang.annotation if it is deemed still useful, because such an annotation should always be present in the JDK.





-- 
- DML