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; - 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. - 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. -- Guillaume
