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
<http://bugs.java.com/view_bug.do?bug_id=8042789>
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
P.S. I also posted this question at
https://community.oracle.com/message/14072662#14072662
