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

[Tom Hood]

I haven't tried JDK 9 yet.  I was assuming the 7u55 change in JDK 9 would
impact our application the same way.  I hope to try it next week as I'm
currently stuck testing on windows XP which limits me to 1.7 or earlier.
So maybe Approach #3 will be:  "It should just work"  [*I think I'm
required to add a quarter to some jar whenever I use that phrase*]    :-)

That's good  to know about the java.corba module.  The vb jar does carry a
bunch of org.omg.* classes, so it sounds like with JDK 9 everything corba
related will be taken from the vb jar (assuming I don't explicitly use
--add-modules).

The realization I'm now having is that JDK 9 will use more code from the vb
jar than earlier versions did which I think will be a good thing.  The
scary thought is that right now we must be running in production with a
Frankenstein mix of some org.omg.* classes from the vb jar and some from
the JDK which could in theory vary across JDK updates, making the whole
thing more fragile in my mind.  I believe the parent-first model is used by
the JNLPClassLoader will choose the JDK version of a class over one with
the same name from the vb jar.  So the mixing of different ORB
implementations I was so concerned about is probably already the way we're
running?  Yikes!

That's also good to know about JDK 9 application class loader not being an
instance of URLClassLoader.  I'll probably use approach #1 when jre is
older than 9 so our app will work with the select versions of 6, 7, and 8
with the ORB.init() change.

Any thoughts on question 2 of approach #1 (i.e. disabling security manager
vs. granting the application AllPermission via policy file)?  It seems like
they should be equivalent.  I'm told it is near impossible to reliably get
IT at customer facilities to make desired modifications to the jre
installation, such as a policy file.

Thanks for all your help.  Looking forward to trying JDK 9 soon.


On Wed, Oct 19, 2016 at 12:48 AM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> 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.
>
> -Alan
>