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

Tom Hood tom.w.hood at gmail.com
Tue Oct 18 18:57:27 UTC 2016


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,

The two properties we set in the jnlp to specify the visibroker orb classes
        <property name="jnlp.org.omg.CORBA.ORBClass"
        <property name="jnlp.org.omg.CORBA.ORBSingletonClass"

The two approaches I'm considering so far are:

   1. add vb jar to system class loader at start of application using
   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

*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

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

P.S. I also posted this question at

More information about the core-libs-dev mailing list