April 2016 - jpms-spec-comments

Привeт
by Катя1922 27 Apr '16

27 Apr '16

1 0

Привeтик
by Тихоновский Нина 26 Apr '16

26 Apr '16

1 0

Cannot find class javax.xml.bind.annotation.adapters.XmlAdapters
by thchuong＠gmail 18 Apr '16

18 Apr '16

Hi, I am testing the compatibility of my project to the jdk 9. I use i18nlog library (version 1.0.10) to maintain the internationalization feature of the project. When building my application, I received this error on jdk 9b113 Caused by: java.lang.NoClassDefFoundError: javax/xml/bind/annotation/adapters/XmlAdapter at java.lang.ClassLoader.defineClass1(java.base@9-ea/Native Method) at java.lang.ClassLoader.defineClass(java.base@9-ea/ClassLoader.java:939) at org.apache.tools.ant.AntClassLoader.defineClassFromData(AntClassLoader.java:1124) at org.apache.tools.ant.AntClassLoader.getClassFromStream(AntClassLoader.java:1295) at org.apache.tools.ant.AntClassLoader.findClassInComponents(AntClassLoader.java:1351) at org.apache.tools.ant.AntClassLoader.findClass(AntClassLoader.java:1311) at org.apache.tools.ant.AntClassLoader.loadClass(AntClassLoader.java:1064) at java.lang.ClassLoader.loadClass(java.base@9-ea/ClassLoader.java:419) at org.apache.tools.ant.AntClassLoader.findBaseClass(AntClassLoader.java:1383) at org.apache.tools.ant.AntClassLoader.loadClass(AntClassLoader.java:1060) at java.lang.ClassLoader.loadClass(java.base@9-ea/ClassLoader.java:419) at mazz.i18n.ant.I18NAntTask.execute(I18NAntTask.java:537) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) ... 27 more Caused by: java.lang.ClassNotFoundException: javax.xml.bind.annotation.adapters.XmlAdapter at org.apache.tools.ant.AntClassLoader.findClassInComponents(AntClassLoader.java:1361) at org.apache.tools.ant.AntClassLoader.findClass(AntClassLoader.java:1311) at org.apache.tools.ant.AntClassLoader.loadClass(AntClassLoader.java:1064) at java.lang.ClassLoader.loadClass(java.base@9-ea/ClassLoader.java:419) ... 45 more I also tried to add "-XaddExporst:java.xml.bind/javax.xml.bing.annotation.adapters=ALL-UNNAMED" but the module was not recognized Error occurred during initialization of VM java.lang.RuntimeException: Unknown module: java.xml.bind at jdk.internal.module.ModuleBootstrap.fail(java.base@9-ea/ModuleBootstrap.java:526) at jdk.internal.module.ModuleBootstrap.addExtraExports(java.base@9-ea/ModuleBootstrap.java:447) at jdk.internal.module.ModuleBootstrap.boot(java.base@9-ea/ModuleBootstrap.java:308) at java.lang.System.initPhase2(java.base@9-ea/System.java:1916) However, the issue didn't happen when building with the build 112 of the jdk. Would you please give me a workaround for this? Chuong

1 0

Привет
by Facebook 14 Apr '16

14 Apr '16

1 0

Приветик!
by Жанна 07 Apr '16

07 Apr '16

1 0

Combining a custom modular run-time image with a third party plugin system
by Stefan Dollase 04 Apr '16

04 Apr '16

Hello EG, I posted this question to StackOverflow [1], however this mailinglist might be the more appropriate place for it: Based on this [2] twitter post, I am going to assume that Jigsaw will be a > part of Java 9. > > When reading about Jigsaw, I asked myself a question: What happens when I > release my application with a custom modular run-time image, but a third > party module requires additional JRE modules which were not released with > the application, because they were not required by the application? > > Imagine an application that wants to benefit from the modularization. It > provides a service interface that can be implemented by a third party > module. The application loads all the third party modules which provide an > implementation of the service interface when the application is starting. > In my opinion, this is a great and easy way to provide a public API for > third party plugins and I can imagine using this by myself quite frequently. > > Now, there is also a tool called jlink which allows one to create a > release of an application which does not only contain the application > modules but also the requires JRE modules. This is called a custom modular > run-time image. The great thing is, that the release only contains the JRE > modules which are actually used by the application, which prevents the > release from growing very big in size. Currently, jlink will figure out > which modules have to be included by itself. However, service > implementation providing modules have to be included explicitly by the > developer, see [3]. I think this is also great for many applications where > the developer does not want to require the user to install a JRE. > > The problem arises when we try to use both in a single application: The > custom modular run-time image only contains the JRE modules which are used > by the application. However, a plugin might use JRE modules which have not > been used by the application and thus these modules are not available at > run-time. Thus, the plugin will not work. > > Here is the only solution that I can think of, however it is far from > perfect: > > Include the missing JRE modules into the third party plugin. While this > might seem to be a simple solution at first, it actually come with quite > some issues. > > First, this requires the plugin developer to know which JRE modules are > included in the application. If this is unknown they might include a JRE > module which is already available in the application itself, which might > cause problems. Thus, it becomes a part of the public API which modules are > used by the application. I think this is not desirable, because it is an > implementation detail. Also, it might change quite frequently. > > Second, since the available JRE modules are a part of the public API, they > need to be specified somehow. While this might work via documentation, I > think it should be specified via formal code. For example, it might work to > use a requires public clause in the application module for all JRE modules > which should be available to the plugin module. This makes these JRE > modules available to the plugin, because the plugin will require the > application module. > > Third, the question arises whether it is desirable to allow the plugin to > use additional JRE modules. If it is not, there should probably an clause > for the module-info.java to specify that the current module is a plugin for > a given other module. For example, instead of using require for the > application module, one would use plugs in to or another notation for that. > This would prevent the module from requiring any JRE modules. However, this > is probably not gonna work, since other third party modules which are > required by the plugin module might require additional JRE modules. Thus, I > think it is tough to offer support for such a mechanism. > > Fourth, it is also tough to allow plugins to use additional JRE modules. > This would either require the different JRE modules to be compatible in > different versions or the plugin developer to always include the additional > JRE modules in a version that is compatible to the version of the JRE > modules in the application. I am not sure about whether the JRE modules are > supposed to be compatible in different versions, but my assumption is that > they are not supposed to be, because it would prevent many changes in the > future. > > Are some of my assumptions wrong? Maybe it works just fine to include a > JRE module in the application and the plugin? Maybe the additional JRE > modules in the plugin also don't have to be compatible with the JRE modules > in the application? After all, they might not interact with each other. > > How should we handle this architectural problem? Are there other languages > with a modular and partly releasable run-time? How did they solve the > problem? > > Please note that similar problems might arise with commonly used libraries > like Google guava or the Apache commons. However, this question should be > mostly about the problems which arise from using a custom modular run-time > image. > > [1]: > http://stackoverflow.com/questions/36388004/java-9-combining-a-custom-modul… > [2]: https://twitter.com/mreinhold/status/713384458452226048 > [3]: https://twitter.com/mreinhold/status/665122968851382273 > Has this already been discussed? Any feedback is appreciated. Kind regards Stefan Dollase

1 0

Add multiplicity declaration to use clause of service consuming module
by Stefan Dollase 04 Apr '16

04 Apr '16

Hello EG, the other day, I sent this message to jigsaw-dev. However, I was told to send it to this list, because it is more appropriate. Quoting my original message: Hello, > > I read the article in [1], which describes the problem that jlink cannot > figure out which service providing modules should be included into the > custom modular run-time image. In [2] there is a statement about this: > Previously, jlink included all service providing modules. Now, none of them > is included. Since I am not sure whether this was already discussed, I > would like to suggest a third approach: > > My suggestion is to add a multiplicity declaration to the module-info.java > file for each uses clause. Here is an example: > > module com.socket { > uses one com.socket.spi.NetworkSocketProvider; > } > > This declares that the module `com.socket` requires exactly one > implementation of the service `com.socket.spi.NetworkSocketProvider`. Here > are further suggestions for multiplicity keywords: > * optional - requires either zero or exactly one implementation > * one - requires exactly one implementation > * at least one - requires at least one implementation (this needs a better > keyword) > * any - any number of implementations is sufficient, even zero > > I suggest to require a multiplicity declaration, so the intent is always > clear. However, it will also work to choose a default when no explicit > declaration is given. Currently, any is the default. > > Adding a multiplicity declaration to the uses clause of the service > consuming module allows to nicely solve the problem that is described in > the article. Now, the jlink tool can check whether the multiplicity > declaration is fulfilled. Then, it can include only the required service > providing modules into the custom modular run-time image. > > Besides this declaration, one might add convenience methods to the > ServiceLoader class. Currently, there is only ServiceLoader::iterator. I > suggest to add the following methods: > * loadOptional() - checks that there is exactly zero or one > implementation and returns an Optional<> containing a new instance of the > implementation, if any, throws a RuntimeException or Error if there is not > exactly zero or one implementation > * loadOne() - checks that there is exactly one implementation > available and returns an instance of the implementation, throws a > RuntimeException or Error if there is not exactly one implementation > * loadAtLeastOne() - checks that there is at least one implementation > available and returns a Set of instances of the implementations, throws a > RuntimeException or Error if there is not at least one implementation > * loadAny() - returns a Set of instances of the available > implementations > > I think these methods should throw an Error, since the condition can and > should be checked at compile-time. Thus, it is a fatal error if the > constraint is not met at run-time. > > Finally, it might be helpful to be able to explicitly declare which > service implementations are provided to which service consumers. For > example, given a service `S` with the implementations `S1`, `S2` and `S3` > provided by the modules `M1`, `M2` and `M3`. `S` is used by the modules > `SC1` and `SC2`. `SC1` requires exactly one implementation of `S` while > `SC2` requires any number of implementations. Now, it is unclear which > implementation should be used by which service consuming module. Currently, > the service consuming module will decide this manually in the code by > iterating over all provided implementations. I think this should be > explicitly declared. For example, one might declare that for `SC1`, `S` is > provided with the implementation `S1`, but for `SC2`, `S` is provided with > the implementations `S2` and `S3`. The great thing about this explicit > declaration is, that tools like jlink can use this information, so it > becomes even more clear which modules are required at run-time. Provided > that `SC1` and `SC2` are included in the custom modular run-time image, the > service configuration given above implies that also `M1`, `M2` and `M3` > have to be included in the custom modular run-time image. If the service > configuration is changed so for `SC2`, `S` is only provided with the > implementation `S1`, then only `M1` has to be included into the custom > modular run-time image, but `M2` and `M3` can be omitted. > > Also, my suggestion is that this is an interpreted document instead of a > compiled one, so it can easily be changed after a release. For example, if > an application uses a logging service it would be helpful to be able to add > a custom logging service implementation to the module path and simply > change the implementation which is used by the application by changing the > service configuration file. This also implies that there should be a tool > to validate the service configuration via the command line. > > Here is a summary of the proposed changes: > * add a multiplicity declaration to the uses clause > * use the multiplicity declaration to validate the current configuration > of service consumers and service providers > * include all required service provider modules when executing jlink > * add convenience methods to the ServiceLoader class which match the > introduced multiplicity declarations > * add an (interpreted) document to explicitly declare the service > configuration > * add a command-line tool to validate the service configuration > > I am happy to hear any feedback. If you have trouble understanding my > suggestions, please don't hesitate to ask for clarification. > > Again, I am not sure whether this topic was already discussed. I was > unable to find it. If it was, please feel free to ignore this mail and send > me a link to the discussion. > > [1]: https://blog.codecentric.de/en/2016/01/java9-jigsaw-missing-piece/ > [2]: https://twitter.com/mreinhold/status/665122968851382273 > > Regards Quoting the answer by Alan Bateman: On 26/03/2016 02:45, Stefan Dollase wrote: > >> Hello, >> >> I read the article in [1], which describes the problem that jlink cannot >> figure out which service providing modules should be included into the >> custom modular run-time image. In [2] there is a statement about this: >> Previously, jlink included all service providing modules. Now, none of >> them >> is included. Since I am not sure whether this was already discussed, I >> would like to suggest a third approach: >> > JEP 282 [1] lists services as an open issue. > > Yes, it was the case, at least for a brief period, that service providers > were linked in automatically. It immediately leads to calls for ways to > keep providers out and it gets very complicated once you have a > command-line that it try to add and exclude modules at the same time. > > So as things stand, jlink is an advanced tool and you do need to know > about service providers when creating a custom runtime image. If you want > specific crypto support or a specific dynamic language then you need > specify the names of the modules to -addmods when creating the runtime > image. > > On extending the `uses` clause then this may be something to send to > jpms-spec-comments for consideration if you feel it is important. One thing > to be aware of is that the early exploratory phase of Project Jigsaw had > `requires service S` and `requires optional service S`. The former could > cause resolution to fail if there weren't any modules providing > implementations of S. The latter is more like what we have today with > `uses`. > > At least for usages in the JDK, then we almost always used the latter in > the prototypes at the time. One reason is the consumer modules often have a > default implementation to use when there aren't any implementations > deployed. The java.xml module has a default implementation of each of the > XML parser types for example. There are a few cases, like the > java.scripting or java.naming modules where there isn't any notion of the > default implementation but it's not an error in either case to link or run > without any service providers. The reason is that service provider modules > may be loaded at runtime, maybe into module layers that a container creates. > > -Alan > > [1] http://openjdk.java.net/jeps/282 As I said before, I am happy to hear any feedback and provide clarifications. Also, if there was already a discussion about the topic, please point me in the right direction. Thanks. Regards Stefan Dollase

1 0

Приветик
by Facebook 03 Apr '16

03 Apr '16

1 0