First, I want to say thanks for your help in this and the previous threads.
> The JNLP fragment in my first mail can be used to resolve java.xml.ws > for JNLP applications that depend on the JAX-WS version included in the > JRE. It's predicated on the version of the runtime so you should be able > to use the same JNLP for 6, 7, 8 and 9. > As regards strong encapsulation then Java Web Start has support for the > equivalent of `--add-exports` and `--add-opens`. I think we discussed > this in a previous thread (you mentioned you inherited code that hacks > String internals if I remember correctly). Yes we have added tons of --add-exports and --add-opens to our JNLP and just also a "--add-modules=java.xml.ws". That works great and testing with Java 9 are going well so far. The --add-exports, -add-opens and --add-modules entries is a good list to see what we need to fix. Of course it is our target to remove this list but this take some time. Our problem is that our "old" JNLP, which works with Java 6, 7 and 8 does no longer work with Java 9. This could be easily solved by the Webstart launcher in Java 9. Java 9 should just generate warnings in the Webstart Java console to inform which --add-exports/-add-opens or --add-modules is missing in the JNLP and that this JNLP will not work with Java 10. This will give us, and especially our customers, more time to migrate. To explain that a bit more: Our JNLP is not a static resource, it is generated server-side. So our customers need to update the server installations which is a big and costly task in our business field (ERP software). We have customers which hosts server installations which is used by hundreds and thousands of users in their daily work. Such big customers can not quickly install a new software update we have just released. They need weeks to plan and test an upcoming server-side software update before they can install it on the production system. Java 9 will be released on 2017/07/27, so we are under high business pressur. Furthermore we have no guarantee that the "new" JNLP, which works with 9-ea+169, will finally works with the final Java 9 release and none can guarantee that until the final Java 9 version is really released. This is also the reason we have improved the JNLP stuff: In further releases of our software, we allow to modify/change the server-side JNLP generation in a more flexible way via config files to defuse JNLP related issues. > I don't know when JDK 10 will be released and I also don't know for sure > if JRE 10 will continue to bundle JAX-WS or not. Assuming it is removed > then it will be a surprise as the JDK has never dropped APIs like this. > I don't think we should feel too bad about that because each of these > APIs are standalone technologies with their own download. BTW: We don't > maintain these APIs in OpenJDK, instead they are maintained in upstream > projects. I could imagine the migration guide for JDK 10 providing the > JNLP need to download the standalone versions as libraries. Yes and it is the right way to deprecate those modules in Java 9, as you have done. So we aware of the deprecation and we have time to prepare a solution for this. This is what is going wrong with Java 9 and the JNLP: Java 8 has give us no hint that this JNLP will no longer work with Java 9 and what we should do. Otherwise it would be enough time to prepare our software. The Webstart in Java 9 EA has started working just a few weeks/months ago (around EA 15x). So there was also no chance to test and prepare our software with Java 9 EA. That's why I propose to enable all modules and set --permit-illegal-access by default in case of the Webstart for (and only for) Java 9. BTW: I would also welcome if the Oracle Webstart would have a specification and been part of the OpenJDK or somewhere as open source project. Regards Reto
