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? On Tue, Oct 18, 2016 at 1:30 PM, Alan Bateman <alan.bate...@oracle.com> wrote: > On 18/10/2016 19:57, Tom Hood wrote: > > 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 ? >> >> The singleton ORB is the system-wide type code factory so having it be > located via the TCCL is highly problematic (many reasons including > security, memory leaks, and of course it's not going to work then there two > or more applications/contexts in the same VM trying to do the same thing). > > I assume your application can use the 2-arg ORB.init to create the ORB, in > which case the implementation will be located via the TCCL (so you can > bundle the ORB implementation with the application). From your mail then it > sounds like the issue is that something in Visibroker is using the zero-arg > ORB.init and so gets the JDK ORB as the singleton ORB. Does this lead to an > interop issue or does Visibroker assuming the singleton ORB is its own type? > > -Alan >
