Java application updated to jdk 1.7.25, hit a run time Exception, what's your opinion?

Question

We have a java application recently updated to jdk 1.7.25 from jdk 1.7.21, without any source changed, but hits a run time exception on Windows server 2003. We use OpenORB 1.2 (no more supported) which was provided 10 years ago as a 3rd party library. Here is the trace print:

org.omg.CORBA.INITIALIZE: Unable to create CDROutputStream class  vmcid: 0x0  minor code: 0  completed: No
               at org.openorb.iiop.CDRCodec.encode_value(CDRCodec.java:147)
               at org.openorb.iiop.IIOPServerProtocol.create_profile(IIOPServerProtocol.java:258)
               at org.openorb.net.ServerManagerImpl.construct_ior(ServerManagerImpl.java:697)
               at org.openorb.adapter.poa.POA.create_reference(POA.java:1602)
               at org.openorb.adapter.poa.RootPOA$DomainManagerPOA.create_reference(RootPOA.java:162)
               at org.openorb.adapter.poa.POA.create_reference_with_id(POA.java:1397)
               at org.openorb.adapter.poa.RootPOA.create_poa_domain_manager(RootPOA.java:135)
               at org.openorb.adapter.poa.POA.get_domain_managers(POA.java:848)
               at org.openorb.adapter.poa.POA.create_reference(POA.java:1593)
               at org.openorb.adapter.poa.POA.create_reference_with_id(POA.java:1397)
               at org.openorb.adapter.poa.DelegateImpl.this_object(DelegateImpl.java:121)
               at org.omg.PortableServer.Servant._this_object(Servant.java:79)
               at org.omg.PortableServer.Servant._this_object(Servant.java:98)
               at DPEM.src.presentation.adaptation.adaptationIfc.SessionAdapterPOA._this(SessionAdapterPOA.java:18)
               at DPEM.src.presentation.adaptation.SessionAdapterImpl.<init>(SessionAdapterImpl.java:91)
               at DPEM.src.presentation.adaptation.SessionAdapterImpl.instance(SessionAdapterImpl.java:164)
               at DPEM.src.presentation.adaptation.AdapterFactory.getAdapter(AdapterFactory.java:166)
               at DPEM.src.presentation.adaptation.AdapterFactory.getAdapter(AdapterFactory.java:121)
               at DPEM.src.presentation.dialogControl.DialogController.createAdapterReferences(DialogController.java:320)
               at DPEM.src.presentation.dialogControl.DialogController.<init>(DialogController.java:112)
               at DPEM.src.presentation.dialogControl.PresentationFactory.getDialogController(PresentationFactory.java:470)
               at DPEM.src.presentation.dialogControl.ThreadedClient.run(ThreadedClient.java:136)

I couldn't work out further, and I am seeking for java/CORBA expertise advise.

Thank you very in advanced!

Answer 1

Seems like there is a long history of incompatibility errors associated with OpenORB (see here, here, and here).

This time the culprit is probably this security fix introduced in JRE 7u22.

Since you are using a legacy library (last update was in 2005) for a legacy technology, I would downgrade the production JDK (as a workaround) and further investigate where exactly things were broken...

Once you find it, maybe there is an easy workaround with no library changes... If there isn't you have two choices:

• Drop CORBA altogether (if you can, this is probably the best road... While I understand that this would be a huge undertaking and that your company may be less than willing to spend money at this, if they want this Software to survive to the end of this decade, now is the time to do something)
• Look at more active CORBA libraries such as JacORB (it may get you running with minimal developing effort, but will require extensive testing before you are able to release a production version)

Answer 2

I've no idea why this isn't working on 1.7.25 with just looking at the stack trace you provided. However I took a glance at the change log of 1.7.25 and one possible thing that can be the problem is the change of Runtime.exec behavior on Windows platform.

Possible workaround:

In JDK 7u25, the system property jdk.lang.Process.allowAmbigousCommands can be used to relax the checking process and helps as a workaround for some applications that cannot be changed. The workaround is only effective for applications that are run without a SecurityManager.

Also take a look at:

https://blogs.oracle.com/thejavatutorials/entry/changes_to_runtime_exec_problems http://www.oracle.com/technetwork/java/javase/7u25-relnotes-1955741.html

This is just guess, but I hope it'll help you with your problem.