可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效，请关闭广告屏蔽插件后再试):

问题:

Since updating to Java 7 update 55, I'm not able to run my WebStart java application.

This application worked fine under Java 7 update 51 when launched via WebStart.

It also works with update 55 when launched outside of WebStart.

Any suggestions for further investigation points?

org.omg.CORBA.INITIALIZE: can't instantiate default ORB implementation org.jacorb.orb.ORBSingleton  vmcid: 0x0  minor code: 0  completed: No
    at org.omg.CORBA.ORB.create_impl_with_systemclassloader(Unknown Source)
    at org.omg.CORBA.ORB.init(Unknown Source)
    at org.jacorb.orb.CDRInputStream.<init>(CDRInputStream.java:186)
    at org.jacorb.orb.etf.ProfileBase.initFromProfileData(ProfileBase.java:252)
    at org.jacorb.orb.etf.ProfileBase.demarshal(ProfileBase.java:172)
    at org.jacorb.orb.etf.FactoriesBase.demarshal_profile(FactoriesBase.java:124)
    at org.jacorb.orb.ParsedIOR.decode(ParsedIOR.java:235)
    at org.jacorb.orb.ParsedIOR.parse_stringified_ior(ParsedIOR.java:460)
    at org.jacorb.orb.ParsedIOR.parse(ParsedIOR.java:375)
    at org.jacorb.orb.ParsedIOR.<init>(ParsedIOR.java:192)
    at org.jacorb.orb.ORB.string_to_object(ORB.java:1824)

Caused by: java.lang.ClassNotFoundException: org.jacorb.orb.ORBSingleton
    at java.net.URLClassLoader$1.run(Unknown Source)
    at java.net.URLClassLoader$1.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(Unknown Source)
    at java.lang.ClassLoader.loadClass(Unknown Source)
    at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
    at java.lang.ClassLoader.loadClass(Unknown Source)
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Unknown Source)
    ... 56 more

Edit 12th June 2014

Looks like this issue has been fixed here:

https://bugs.openjdk.java.net/browse/JDK-8042789

This will hopefully be included in the next CPU on July 15th

Looks like the change that caused this issue was reverted so it now uses the current thread classloader again.

http://hg.openjdk.java.net/jdk8u/jdk8u-dev/corba/rev/009fc3f785a9

回答1:

I've opened a bug to Java for this (Review ID: JI-9011898). The issue is that in the org.omg.CORBA.ORB.init() method the system class loader is forced to use, while in the past the current thread's class loader was used.

UPDATE: a valid workaround is copying the JacORB jars inside the /jre/lib/endorsed folder, so these classes can be loaded outside the webstart class loader. See Java WebStart and endorsed directories and Java 7u55 Eclipse System Fragment Classloader for details.

回答2:

Did some more digging and I found a commit to ORB.java that is causing the issue.

changeset:   817:a8d27c3fc4e4
tag:         jdk7u55-b05
user:        msheppar
date:        Tue Jan 21 12:46:58 2014 +0000
summary:     8025005: Enhance CORBA initializations

This commit changed the way the ORB Singleton class was created. Instead of using the Thread context class loader it is now hard coded to use the SystemClassLoader.

-                singleton = create_impl(className);
+                singleton = create_impl_with_systemclassloader(className);
         }
     }
     return singleton;
 }

+   private static ORB create_impl_with_systemclassloader(String className) {
+
+        try {
+            ReflectUtil.checkPackageAccess(className);
+            ClassLoader cl = ClassLoader.getSystemClassLoader();
+            Class<org.omg.CORBA.ORB> orbBaseClass = org.omg.CORBA.ORB.class;
+            Class<?> singletonOrbClass = Class.forName(className, true, cl).asSubclass(orbBaseClass);
+            return (ORB)singletonOrbClass.newInstance();
+        } catch (Throwable ex) {
+            SystemException systemException = new INITIALIZE(
+                "can't instantiate default ORB implementation " + className);
+            systemException.initCause(ex);
+            throw systemException;
+        }
+    }

Putting the JacORB classes on the endorsed dirs or ext classpath is a valid work around. However, this definitely changes previous behavior.

Has anyone filed a bug for it?

--- UPDATE ---

There is a bug related to this issue: https://bugs.openjdk.java.net/browse/JDK-8042789

It is available in Java 8u22.
https://jdk8.java.net/download.html

回答3:

There is now a release note about this change in 7u55, see:

http://www.oracle.com/technetwork/java/javase/7u55-relnotes-2177812.html

回答4:

Can you say a bit more about the problem with OpenORB? Is it a ClassCastException or other error? A stack trace would be useful.

回答5:

The relevant JacORB issue is http://www.jacorb.org/bugzilla/show_bug.cgi?id=984 (for x-ref purposes).

If anyone has a sample test case they wouldn't mind uploading to that ticket it would be very helpful

回答6:

The (recently updated, as this information wasn' there before) release notes mentioned by user3054250 (thank you for this) point to another possible workaround.

Specifying only the org.omg.CORBA.ORBClass property but omiting org.omg.CORBA.ORBSingletonClass works in my CORBA/Webstart application together with JacORB 3.4.

it doesn't work with OpenORB (as OpenORB checks for the "right" instance of ORBSingleton) so I have to upgrade my application to JacORB.

Edit: With OpenORB (and I suppose with many other ORBs too) there is the same problem as mentioned by the questioner - a ClassCastException because ORB classes not visible to the SystemClassLoader in Webstart Applications but ORBSingleton loaded using SystemClassLoader now.

The difference to JacORB is that OpenORB checks if the ORBSingleton is of the right type when the ORB gets instantiated - which means (depending on the version) e.g. if it is of type org.openorb.CORBA.ORBSingleton. For me it is no problem to switch to JacORB but I wanted to mention that the approach of omiting ORBSingleton setting doesn't help with any ORB but for the questioner it could be a better solution than putting the ORB stuff into .../endorsed