On 23/05/2016 15:52, Andrew Dinn wrote:
:
Thanks to you and Sanders for the advice. The relevant packages now appear.
Could you explain how the disabled status of this module is arrived at
in the final build? Is it excluded from the standard visible set by
virtue of being listed in UPGRADEABLE_MODULES? I couldn't find anywhere
else where any different treatment might be applied.
The section entitled "Root modules" in JEP 261 is the section to read.
It's essentially that the java.se rather than java.se.ee is resolved by
default when compiling code in the unnamed module or running and the
initial class is loaded from the class path.
:
Hmm, perhaps -XaddExports requires a check to see that it does not add
any exports unless the module has also been added.
javac and java behave slightly differently for this case, it's something
we need to fix.
:
However, we do interoperate with 2 other orbs and in those cases we
currently provide the relevant CORBA classes via the classpath using
-Xbootclasspath:p (which I have explained is no longer going to work).
I think that this command line option was adopted merely in order to
pre-empt the SE Corba classes in rt.jar. So, I am hoping that if we
omit -addmod java.corba and add the alternatrive ORB jar to the system
classpath then we will actually be safe. If you have reason to believe
otherwise please let me know. Meanwhile, I'll get back to you if and
when this turns into a packed lunch problem. Thanks for the help.
If you have complete replacement/upgrade for the java.corba module then
you can deploy on it on the class path and it should work. Alternatively
you can deploy it on the upgrade module path to upgrade/override the
module in the JDK (`-upgrademodulepath mycorba.jar -addmods java.corba`).
On the other hand, if you adding to the JDK java.corba module then
you'll need to use -Xpatch to augment or override what is in the JDK
(`-Xpatch:java.corba=mycorbapatch.jar -addmods java.corba`).
-Alan.
