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

Alan Bateman Alan.Bateman at oracle.com
Wed Oct 19 07:48:15 UTC 2016

On 19/10/2016 03:28, Tom Hood wrote:

> It's unclear if there really is an interop issue.   The application 
> will launch with 7u55 if I don't set the ORBSingletonClass property, 
> although that isn't how visibroker 5.2.1 was intended to run, so not 
> setting it worries me.
> Our application does call ORB.init(args,props) once at startup and use 
> that instance throughout the code we have written.
> However, visibroker calls ORB.init() all over the idl generated code 
> and the vb jar itself.
> The javap of the vb jar does show some downcasts to its 
> com.inprise.vbroker.orb.ORBSingleton implementation in a few classes, 
> but I haven't tracked down if that code could execute in our 
> application or if the object it tries to downcast originated from 
> ORB.init().  The simple test of a basic launch and performing some 
> activities within the application seem to work.  Sadly we don't have 
> any automated tests that exercise our use of CORBA (java client 
> to/from c++ server).
> The idea of mixing ORB implementations worries me, even if only for 
> the singleton ORB.  I'm new to CORBA and the client side of our 
> application and still a newbie to java as I've been primarily working 
> on our c++ server.
> Do the reasons for the JDK change to ORB.init() apply in our use 
> case?  There's only one application/context and ORB vendor 
> implementation running in the jvm in production.  Do you think 
> approach #1 might be a reasonably safe workaround without the risk of 
> hidden interop issues?
I can't tell from this thread if you have tried with JDK 9 or not 
(you've mentioned 7u55 a few times).

I ask because in JDK 9 then the java.corba module is not resolved by 
default. If your application starts there then it suggests to me that 
Visibroker may be carrying its own copy of the org.omg.** (and RMI-IIOP) 
classes, in which case the JDK ORB (even singleton ORB) is not in the 
picture. Or maybe you've got past this and your JNLP contains:
   <j2se version="9+"" java-vm-args="--add-modules=java.corba">

which is the equivalent to the --add-modules command line option.

Another comment is that if there is code calling the no-arg ORB.init and 
blinding casting the return to com.inprise.vbroker.orb.ORBSingleton then 
it will never work in the scenario where the system-wide singleton ORB 
has been initialized by before Visibroker is used. I completely agree 
that it would be unusual to mix different ORB implementations in the 
same VM but the API has always allowed for that.

On approach #1 then one thing to be aware of is that the application 
class loader is not an instance of URLClassLoader in JDK 9. That is an 
implementation change that is known to trip up code that has been 
hacking into it.


More information about the core-libs-dev mailing list