[jacorb-developer] java 9

Thu Nov 2 21:47:07 CET 2017

With some help from people on the OpenJDK mailing list, I was able to successfully run our application, using the JacORB 3.9 release in Java 9.
http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-November/006040.html

I added the JacORB jars as library dependencies of my application, and added them to the Class-Path: statement of the application manifest file.
This alone was enough to run on JRE8, but not on JRE9.

Two problems are, the java.corba module is not included in JRE9 by default, and the JacORB jars are not a "complete" implementation, they use classes that are still located in the corba module of the JRE.
Thankfully, there are command line parameters to overcome these problems, it doesn't look pretty, but it works.  The JRE CORBA module is added to the JRE at startup by the --add-modules argument.  Then it's implementation is overridden by the --patch-module argument.  Since visibility of some of the packages in the java.corba module are now hidden, a few --add-exports arguments are also needed to re-expose those packages to the JacORB code, which is in the UNNAMED module along with the un-modularized application.

The command line ends up looking something like this:
javaw.exe --add-modules java.corba --patch-module java.corba=lib\jacorb-3.9.jar;lib\jacorb-omgapi-3.9.jar;lib\slf4j-api-1.7.14.jar;lib\slf4j-jdk14-1.7.14.jar --add-exports java.corba/org.jacorb.orb=ALL-UNNAMED --add-exports java.corba/org.jacorb.orb.listener=ALL-UNNAMED --add-exports java.corba/org.jacorb.orb.policies=ALL-UNNAMED --add-exports java.corba/org.omg.BiDirPolicy=ALL-UNNAMED --add-exports java.corba/org.omg.IIOP=ALL-UNNAMED -jar MyApplicationUsingJacORB.jar

This is likely only a temporary solution, since the proposal is to remove CORBA from Java SE and the JDK.
https://bugs.openjdk.java.net/browse/JDK-8189188

There is some talk of moving the OpenJDK source code for CORBA to a GitHub project.  I don't know if it could then be used to "fill out" the JacORB implementation, but still keep the LGPL licensing of JacORB?

-----Original Message-----
From: Pierskalla, Eric 
Sent: Tuesday, October 17, 2017 3:19 PM
To: Discussions concerning CORBA development with JacORB
Subject: RE: [jacorb-developer] java 9

Hello Jan, and anyone else with ideas on this issue,

The following is from the JDK 9 Migration Guide  https://docs.oracle.com/javase/9/migrate/toc.htm#JSMIG-GUID-7744EF96-5899-4FB2-B34E-86D49B2E89B6

Removed Endorsed Standards Override Mechanism

The java.endorsed.dirs system property and the lib/endorsed directory are no longer present. The javac compiler and java launcher will exit if either one is detected.
In JDK 9, you can use upgradeable modules or put the JAR files on the class path.
<deleted text>

Modules Shared with Java EE Not Resolved by Default

In JDK 9, the modules that contain CORBA or the APIs shared between Java SE and Java EE are not resolved by default when you compile or run code on the class path. These are:
    java.corba — CORBA
<deleted text>
Existing code with references to classes in these APIs will not compile without changes to the build. Similarly, code on the class path with references to classes in these APIs will fail with NoDefClassFoundError or ClassNotFoundException unless changes are made in how the application is deployed. 

The code for these APIs was not removed in JDK 9, although the modules are deprecated for removal. The policy of not resolving these modules is a first step toward removing these APIs from Java SE and the JDK in a future release.

The migration options for libraries or applications that use these APIs are:

    1. Use the --add-modules command-line option to ensure that the module with the API is resolved at startup. For example, specify --add-module java.xml.bind to ensure that the java.xml.bind module is resolved. This allows existing code that uses the JAXB API and implementation to work as it did in JDK 8.

    This is a temporary workaround because eventually these modules will be removed from the JDK.

    Using --add-modules java.se.ee or --add-modules ALL-SYSTEM as a workaround is not recommended. These options will resolve all Java EE modules, which is problematic in environments that are also using the standalone versions of APIs.

    2. Deploy the standalone version of the API (and implementation if needed) on the class path. Each of the Java EE APIs are standalone technologies with projects published in Maven Central.

    3. Deploy the standalone version of these modules on the upgrade module path. The standalone versions are provided by the Java EE project.

<end of text from Migration Guide>

After reading this, I decided that the best route for me was #2, to simply deploy JacORB on the classpath.  We have a "standard" Java desktop application.
I cloned the latest JacORB code from GitHub, and rebuilt it, using JDK8.  I did try setting my JAVA_HOME to JDK9, but the Maven build errored, and I don't know anything about Maven right now.
I removed the JacORB jars from the lib/endorsed folder of JRE 8, and put them on the classpath of the application.
The application along with JacORB works fine when run in JRE8.
But when run in JRE9, I get errors similar to those that Jan reported:

JacORB on classpath, without --add-modules java.corba:

Exception causes:
  java.lang.NoClassDefFoundError: javax/rmi/CORBA/Stub
  java.lang.ClassNotFoundException: javax.rmi.CORBA.Stub Stack trace:
  java.base/java.lang.ClassLoader.defineClass1(Native Method)
  java.base/java.lang.ClassLoader.defineClass(Unknown Source)
  java.base/java.security.SecureClassLoader.defineClass(Unknown Source)
  java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(Unknown Source)
  java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(Unknown Source)
  java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(Unknown Source)
  java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(Unknown Source)
  java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(Unknown Source)
  java.base/java.lang.ClassLoader.loadClass(Unknown Source)
  org.jacorb.orb.ORB._getDelegate(ORB.java:585)
  org.jacorb.orb.ORB.string_to_object(ORB.java:2466)
  vdcomm.LogonManager.init_(LogonManager.java:1824)  <----application code

JacORB on classpath, with --add-modules java.corba or --add-modules ALL_SYSTEM:

Exception causes:
  java.lang.NoClassDefFoundError: org/omg/CORBA/ORBSingleton
  java.lang.ClassNotFoundException: org.omg.CORBA.ORBSingleton Stack trace:
  org.jacorb.config.JdkLoggingInitializer.<clinit>(JdkLoggingInitializer.java:54)
  java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
  java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
  java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
  java.base/java.lang.reflect.Constructor.newInstance(Unknown Source)
  java.base/java.lang.Class.newInstance(Unknown Source)
  org.jacorb.config.JacORBConfiguration.newInstance(JacORBConfiguration.java:1047)
  org.jacorb.config.JacORBConfiguration.getAttributeAsObject(JacORBConfiguration.java:1099)
  org.jacorb.config.JacORBConfiguration.initLogging(JacORBConfiguration.java:688)
  org.jacorb.config.JacORBConfiguration.<init>(JacORBConfiguration.java:239)
  org.jacorb.config.JacORBConfiguration.getConfiguration(JacORBConfiguration.java:206)
  org.jacorb.orb.ORB.set_parameters(ORB.java:1884)
  java.corba at 9/org.omg.CORBA.ORB.init(Unknown Source)
  vdcomm.Orb.getOrb(Orb.java:323)   <---- application code

There is an ORBSingleton.java file in the JacORB project at ...\JacORB\omgapi\target\generated-sources\idl\org\omg\CORBA, and an ORBSingleton.class file at ...\JacORB\omgapi\target\classes\org\omg\CORBA.  I also see ORBSingleton.class in the jacorb-omgapi.jar file.

Is this some sort of classloader issue?
Or is it required that we build JacORB using JDK 9?
I would like to build using JDK 9, but as I said earlier, I am an absolute rookie when it comes to Maven.

Any ideas on this would be welcome.  Unlike earlier versions, Java 9 handles high-DPI displays correctly, so we need to be able to deploy on it.

Eric

-----Original Message-----
From: jacorb-developer-bounces~eric.pierskalla=datalogic.com at lists.spline.inf.fu-berlin.de [mailto:jacorb-developer-bounces~eric.pierskalla=datalogic.com at lists.spline.inf.fu-berlin.de] On Behalf Of Vomlel Jan
Sent: Monday, October 09, 2017 3:02 AM
To: Discussions concerning CORBA development with JacORB
Subject: Re: [jacorb-developer] java 9

Thank you Eric, I have read this article and I think it is way, how to run jacorb on java 9. 

But --upgrade-module-path is somethink like endorsed directory and I wanted to use java 9 because I wanted to remove endorsed mechanism from my applications. I would like to create standard wars without other instalations to tomcat, run unit tests quickly from ide, simplier application structure and building scripts (one lib folder), .... With --upgrade-module-path on Java 9 I am in the same situation as with  -Djava.endorsed.dirs on Java 8.

Jan Vomlel

-----Original Message-----
From: jacorb-developer-bounces~jan.vomlel=aipsafe.cz at lists.spline.inf.fu-berlin.de [mailto:jacorb-developer-bounces~jan.vomlel=aipsafe.cz at lists.spline.inf.fu-berlin.de] On Behalf Of Pierskalla, Eric
Sent: Friday, October 6, 2017 10:33 PM
To: Discussions concerning CORBA development with JacORB <jacorb-developer at lists.spline.inf.fu-berlin.de>
Subject: Re: [jacorb-developer] java 9

From what I have learned to date, in Java 9, the java.corba module in java.se.ee is "upgradeable".  In theory it can be upgraded/replaced by placing modules in the --upgrade-module-path.
Although there is a lot of information on the web about the module system in Java 9, there isn't much about upgradable modules.
There is some info here:
http://openjdk.java.net/jeps/261 

-----Original Message-----
From: jacorb-developer-bounces~eric.pierskalla=datalogic.com at lists.spline.inf.fu-berlin.de [mailto:jacorb-developer-bounces~eric.pierskalla=datalogic.com at lists.spline.inf.fu-berlin.de] On Behalf Of Nick Cross
Sent: Wednesday, October 04, 2017 3:41 AM
To: jacorb-developer at lists.spline.inf.fu-berlin.de
Subject: Re: [jacorb-developer] java 9

Hi,

We have not (as of yet) experimented with Java 9. However if you have patches they would be more than welcome.

Thanks

Nick

On 04/10/17 09:38, Vomlel Jan wrote:
> Hello,
> 
> I have tryed to use jacorb on java 9. But it is not working.
> 
> I think it is because jacorb-omgapi redefines some parts of java.corba module and uses other parts. Java 9 does not have endorsed mechanism, modules can be used or not used, but they cannot be partially changed.
> 
> Do you have any plan to support java 9?
> 
> Exception when java.corba module is used:
> java.lang.NoClassDefFoundError: org/omg/CORBA/ORBSingleton
>                at org.jacorb.orb.ORBSingleton.configure(ORBSingleton.java:155)
>                at org.jacorb.orb.ORB.configure(ORB.java:292)
>                at org.jacorb.orb.ORB.set_parameters(ORB.java:1884)
>                at
> java.corba at 9/org.omg.CORBA.ORB.init(ORB.java:430)<mailto:java.corba at 9/
> org.omg.CORBA.ORB.init(ORB.java:430)>
> …
> 
> Exception when java.corba module is not used:
> java.lang.NoClassDefFoundError: javax/rmi/CORBA/Stub
>                at java.base/java.lang.ClassLoader.defineClass1(Native Method)
>                at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1007)
>                at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174)
>                at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:801)
>                at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:699)
>                at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:622)
>                at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:580)
>                at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:185)
>                at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:496)
>                at org.jacorb.orb.ORB.getReference(ORB.java:1243)
>                at org.jacorb.poa.POA.getReference(POA.java:1349)
>                at
> org.jacorb.poa.POA.servant_to_reference(POA.java:2038)
> …
> 
> ________________________________
> 
> Tento e-mail ani žádný z připojených souborů nejsou přijetím návrhu na uzavření smlouvy, ledaže je to v nich výslovně uvedeno. Pokud tomu tak není, nelze je považovat za jednání, které by zakládalo jakékoliv nároky vůči společnosti AiP Safe. Tento e-mail je určen pouze uvedenému příjemci a dalším osobám, které jsou jmenovitě uvedeny jako příjemci, a jeho obsah, včetně obsahu všech připojených souborů, je důvěrný. Jestliže nejste oprávněný příjemce, zdržte se, prosím, jakékoliv formy zveřejnění, reprodukce, kopírování, distribuce nebo šíření jeho obsahu, včetně obsahu všech připojených souborů. Pokud jste obdržel tento e-mail omylem, oznamte to, prosím, neprodleně jeho odesilateli a e-mail, včetně všech připojených souborů, vymažte. Všechny e maily adresované, přijímané nebo posílané AiP Safe s.r.o. nebo zaměstnanci AiP Safe s.r.o. jsou považovány za zásadně pracovní e-maily. V souladu s tím odesilatel nebo příjemce těchto e mailů souhlasí, že mohou být čteny jinými zaměstnanci AiP Safe s.r.o., než je daný příjemce nebo odesilatel, proto aby byla zajištěna kontinuita pracovních aktivit a byla umožněna jejich kontrola..
> _______________________________________________
> jacorb-developer maillist  -
> jacorb-developer at lists.spline.inf.fu-berlin.de
> https://lists.spline.inf.fu-berlin.de/mailman/listinfo/jacorb-develope
> r
> 

_______________________________________________
jacorb-developer maillist  -  jacorb-developer at lists.spline.inf.fu-berlin.de
https://lists.spline.inf.fu-berlin.de/mailman/listinfo/jacorb-developer

CONFIDENTIALITY NOTICE. This message is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information. Any unauthorized review, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please destroy all copies of the original message, including any and all attachments, and notify the sender immediately.

_______________________________________________
jacorb-developer maillist  -  jacorb-developer at lists.spline.inf.fu-berlin.de
https://lists.spline.inf.fu-berlin.de/mailman/listinfo/jacorb-developer
_______________________________________________
jacorb-developer maillist  -  jacorb-developer at lists.spline.inf.fu-berlin.de
https://lists.spline.inf.fu-berlin.de/mailman/listinfo/jacorb-developer

CONFIDENTIALITY NOTICE. This message is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information. Any unauthorized review, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please destroy all copies of the original message, including any and all attachments, and notify the sender immediately.