> De: "Guillaume Smet" <guilla...@hibernate.org> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: jigsaw-dev@openjdk.java.net > Envoyé: Lundi 13 Février 2017 16:43:36 > Objet: Re: Java SE JSR 250 annotations module renamed to > java.xml.ws.annotation?
> Hi Rémi, > (replied to you but it's more of a general answer to the consensus) > On Mon, Feb 13, 2017 at 3:59 PM, Remi Forax < fo...@univ-mlv.fr > wrote: >> so there are 3 cases: >> - your application is modular, in that case one module defines a dependency >> (with requires) on a module* containing the JSR 250 annotation and you have >> nothing to do. >> - your application uses a container that provides a jar containing the JSR >> 250 >> annotations in the classpath, you still have nothing to do. >> - your application uses the classpath and do not provide any jars containing >> the >> JSR 250 annotations, you can use --add-modules but be aware after some point >> the JDK will stop to provide this jar (the module is marked deprecated). >> perhaps another way to see this is to think that we made a mistake to include >> parts of the Java EE modules inside the JDK when releasing Java 6, and we are >> trying to fix that mistake now, which means removing those packages but >> because >> we are Java instead of removing them now, we made them accessible under a >> flag >> and we will remove them in Java 10. > I can understand this point of view but...: > - if we are willing to deprecate this, maybe it would be better not to let the > --add-modules <your-common-annotations-module-name-here> fix spread in all the > projects everywhere and maybe a clear statement about the future of it would > be > nice - I may have missed it though - see what they did for pax-exam for > instance: > https://github.com/ops4j/org.ops4j.pax.exam2/blob/master/containers/pax-exam-container-karaf/src/main/java/org/ops4j/pax/exam/karaf/container/internal/runner/KarafJavaRunner.java#L63 > for instance; i agree, > - from what I understand, there are 2 types of annotations in this module: > @Generated and annotations related to injection/lifecycle. While I would agree > to add a dependency for the latter, I find it pretty weird to add a dependency > for @Generated. Or maybe, we should just say to the Java world "don't use the > @Generated annotation when you generate code and please upgrade all the > tooling > out there to not depend on it". > - fixing a mistake is always a good thing but as stated by Andrew, they were > advertised as common annotations and part of the JDK so it's definitely a big > change if they get deprecated and removed > - even as a temporary workaround, it's really weird to have to require a > module > named java.xml.ws.annotation for that. It does not really make sense from an > end user perspective. the module name reflect the fact that it's a part of jax-ws and not annotations that you can use for other things. > - as I understand it, the idea is that the new java.xml.ws.annotation module > should basically be considered a private one and should not really be used > anywhere thus its name? > - the only future-proof solution proposed is to depend on the JSR 250 API jar > - > which doesn't look very cool just for @Generated - or get all the Java tooling > out there to remove the usage of the @Generated annotation? > Creating a new @Generated annotation will take years to be used in the real > world, considering everyone will want to keep the backwards compatibility with > Java 8 for a while. > Not sure there's an easy way out but I think these are real concerns that > should > be addressed somehow. I'm not sure we have to introduce a replacement for @Generated, i maybe wrong but the retention of this annotation is the source, so it's an indication for the developer more than anything else, so each framework can come with its own annotation and in my opinion, it will make the dependencies more clear. That's said i'm not a big fan of generated source codes, asking users to provide interfaces and implements the corresponding classes at runtime like by example spring boot does is more convenient IMO. > -- > Guillaume Rémi
