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

Reply via email to