Forum Stats

  • 3,760,325 Users
  • 2,251,685 Discussions
  • 7,871,061 Comments

Discussions

JDK 9 org.omg.CORBA.ORBSingletonClass loading will not use context class loader

3328368
3328368 Member Posts: 3
edited Oct 18, 2016 3:02PM in Java User Groups Discussions

Hello,

We have a Java Webstart application that uses CORBA and requires an old version of the Visibroker ORB (5.2.1) that will not launch with Java 9 due to its inclusion of a change originally added to 7u55 and later backed out:

       Bug ID: JDK-8042789 org.omg.CORBA.ORBSingletonClass loading no longer uses context class loader

What approaches should we consider for our application to support Java 9 ?

Constraints we must satisfy:

  • cannot upgrade visibroker
  • continue to support clients with java versions 1.6+

Constraints we are trying to satisfy:

  • avoid using different vendor ORB
  • avoid replacing CORBA
  • avoid modifying user's machine configuration (e.g. CLASSPATH) or jre installation with application-specifics (i.e. java.security, java.policy, etc.)

The two properties we set in the jnlp to specify the visibroker orb classes are:

<property name="jnlp.org.omg.CORBA.ORBClass" value="com.inprise.vbroker.orb.ORB"/>

<property name="jnlp.org.omg.CORBA.ORBSingletonClass" value="com.inprise.vbroker.orb.ORBSingleton"/>

The two approaches I'm considering so far are:

  1. add vb jar to system class loader at start of application using URLClassLoader.addURL
  2. edit vb jar to avoid calling org.omg.CORBA.ORB.init()

Approach #1: add vb jar to system class loader at start of application

This works with 7u55.  The application will launch as long as I disable the security manager (System.setSecurityManager(null)) or use a policy file entry that explicitly grants AllPermission to the vb jar.  This is necessary even though our jnlp file has always specified <security><all-permissions/></security>.  To add the vb jar to the system class loader, it appears necessary to call the protected URLClassLoader.addURL method via reflection.

Questions I have about Approach #1:

  1. Are there additional security concerns with disabling the security manager at the start of main instead of granting AllPermission via policy files?  Our goal is for our application to continue to have the same access the user has to the user's machine (mostly windows).  The users do not have/run our application with administrator/root privileges.
  2. Is there a better way to make the vb jar visible to the system class loader when the application starts without calling a protected addURL method?

Approach #2: edit vb jar to avoid calling org.omg.CORBA.ORB.init()

I haven't gone down this path too far other than attempt to identify edits that would be needed.  The source is unavailable (javap and http://asm.ow2.org have been helpful).  Here's the list of possible edits I have so far:

  1. Replace calls to org.omg.CORBA.ORB.init() with a call to our own class such as AppORB.init() that always returns the vb ORBSingleton instance
  2. Replace any object that is being downcast to the vb ORBSingleton (and/or its subclasses, if any) with a call to AppORB.init()
  3. Check if vb jar calls methods in the jre which then call ORB.init().  If such calls exist, then I think I may need to replace these calls with something equivalent, because otherwise the default jre provided singleton will be used (com.sun.corba.se.impl.orb.ORBSingleton).  Maybe it's okay to mix the two Singleton ORB implementations in the same jvm, but not knowing enough about CORBA at this point it seems like a potential problem.  The javadoc does say it is a restricted implementation allowing use as a TypeCode factory only, but I'm not sure yet if it is possible to mix and match TypeCodes from the two ORB implementations.  Feels a little dicey to me.

Please let me know if you can think of any alternate approaches to consider or potential issues/solutions to the ones outlined above.

Thank you,

-- Tom

Message edited to change java versions we need to support from 1.5+ to 1.6+

3328368

Answers