TLDR; we can't. In Java 6, we made the mistake to create what you can call twin packages, a package with few classes in the JDK and the same package with more classes including the classes already present in the JDK. The idea was that you can run an application using the JDK, in that case you have access the the small subset and you can also use the full packages in a container env.
This approach fails once you have to update such kind of packages because the classes that can from the JDK (from the bootclasspath) can have a different versions from the classes that comes from the container (from the classpath). Note that this problem is just a variation of the problem of having two different versions of the same jars in the classpath. In the java module world, a package can comes from only one module (i.e. one modular jar). So with java 9, if you have different versions of the same jars, from the VM point of view different modular jars containing the same package, the VM fails when trying to resolve the module graph at startup. So with Java 9 you can only have one jar containing a package in the module graph. With Java 9, the JDK is modularized otherwise it will not be able to run modules from the module path, it also has to provide a way for classes on the classpath to see modules of the JDK otherwise your application will not be able to find java.lang.Object. For that, classes from classpath are put in a fake module named the unamed module. Now if the module containing the JSR 250 annotations is included by default in the module graph of the JDK, every projects using a container that will also use the JSR 250 (so the JSR 250 jars is in the classpath) will fail because the module of the JDK and unamed module will both have the same package. To solve that issue, the idea is that the JDK is released with a module containing the JSR 250 annotations but this module is not included in the root modules and you have to use --add-modules to add it in the root modules. 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. cheers, Rémi ----- Mail original ----- > De: "Guillaume Smet" <guilla...@hibernate.org> > À: jigsaw-dev@openjdk.java.net > Envoyé: Lundi 13 Février 2017 14:34:28 > Objet: Java SE JSR 250 annotations module renamed to java.xml.ws.annotation? > Hi, > > (Posting this on the list at the request of Rory O'Donnell) > > This morning I tried to upgrade our Hibernate Validator build and came > across this issue: > https://bugs.openjdk.java.net/browse/JDK-8173604 . > > As a lot of projects experimenting with the Early access builds of the JDK > 9, we added --add-modules java.annotations.common to our build options. > > This doesn't work anymore as the Java SE JSR 250 annotations (@Generated, > @PreDestroy, @PostConstruct, @Resource...) that were previously in a module > called java.annotations.common were moved to a module called > java.xml.ws.annotation as part of the aforementioned issue. > > The fix is easy, I just have to change my --add-modules directive but I > started to wonder if there's some sort of misunderstanding here. > > As far as I understand it, these annotations are supposed to be common > annotations available in the JDK (see JSR 250: Common Annotations for the > JavaTM Platform). Some are used by a lot of projects out there: nearly > every project based on generated code requires the @Generated annotation to > be present as most tools generating code use it. > > I don't know why these annotations were hosted in the jaxws part of the > source code to begin with but I don't think we can limit them to this usage. > > 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. > > Thanks for your feedback. > > -- > Guillaume
