Hi Andrew,

I'm redirecting this to jigsaw-dev as it seems to be a modularity related problem.

Additional comment below ...

David

On 16/12/2016 7:48 AM, Andrew Guibert wrote:


Hello all,

I've been doing some experimentation with WebSphere Liberty on Java 9 and
ran into a problem that I believe is specific to the hotspot 9 JVM.  I am
using a Liberty image compiled with Java 7, and am trying to get the server
running with Java 9 at runtime.  So far things are working with the IBM JDK
I have access to, but with the openjdk builds the boot process fails
immediately.

When I try to boot Liberty with OpenJDK (here I used 9-ea+149) I get a
NCDFE as indicated in the title (see end of message for full stack trace).
I believe this same issue may have been reported by Jon Berg back in April
[1] but it looks like he didn't follow up on his initial note when asked
for more info.

I've done some digging and I believe that this error was introduced when
classes were moved from sun.reflect to jdk.internal.reflect [2],
specifically when sun.reflect.MagicAccessorImpl was moved to
jdk.internal.reflect.MagicAccessorImpl.  According to the javadoc of
MagicAccessorImpl, there are special tolerences in the VM which allow
MagicAccessorImpl and its subclasses to bypass verification, and the
javadoc also warns not to change the name of MagicAccessorImpl without
updating the corresponding VM code. Since this was just indicated in a
class-level javadoc comment, it could have been easily missed. The
MagicAccessorImpl javadoc references bug 4486457, but I have not been able
to find this id number in any public bug repository.

No it isn't public. Basically when the code-generating reflection mechanism was introduced verification had to be bypassed because the generated code didn't obey the expected subclassing rules for protected access - hence MagicAccessor.

Switching over the the VM codebase, as far as I can tell everything has
been updated properly, except for a reference in systemDictionary.hpp [3]
which refers to MagicAccessorImpl as reflect_MagicAccessorImpl.  I assume
this should instead be jdk_internal_reflect_MagicAccessorImpl (and other
class entries in the block of lines 145-151 also seem to be missing the
"jdk_internal_" prefix).

No those are just variable names that get mapped to full symbolic names e.g.:

./share/vm/classfile/vmSymbols.hpp: template(reflect_MagicAccessorImpl, "jdk/internal/reflect/MagicAccessorImpl")

David
-----

I haven't been able to reproduce this error in a standalone test case.
However, if anyone wants to see the error for themselves the issue can be
reproduced with Liberty in a matter of minutes by downloading a Liberty
zip, extracting it, and doing wlp/bin/server create myServer &&
wlp/bin/server run myServer with jdk9 set as $JAVA_HOME in the environment.

[1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-April/004121.html
[2] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/8606d027b2c2
[3]
http://hg.openjdk.java.net/jdk9/hs/hotspot/file/545ddc149651/src/share/vm/classfile/systemDictionary.hpp#l145

And finally, here is the stack trace:

[12/15/16, 12:50:41:368 CST] 00000010 LogService-8-com.ibm.ws.config
E CWWKE0701E: FrameworkEvent ERROR Bundle:com.ibm.ws.config(id=8)
org.osgi.framework.BundleException: Exception in
com.ibm.ws.config.internal.WSConfigActivator.start() of bundle
com.ibm.ws.config
  at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator
(BundleContextImpl.java:795)
  at org.eclipse.osgi.internal.framework.BundleContextImpl.start
(BundleContextImpl.java:724)
  at org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0
(EquinoxBundle.java:932)
  at org.eclipse.osgi.internal.framework.EquinoxBundle
$EquinoxModule.startWorker(EquinoxBundle.java:309)
  at org.eclipse.osgi.container.Module.doStart(Module.java:581)
  at org.eclipse.osgi.container.Module.start(Module.java:449)
  at org.eclipse.osgi.container.ModuleContainer
$ContainerStartLevel.incStartLevel(ModuleContainer.java:1620)
  at org.eclipse.osgi.container.ModuleContainer
$ContainerStartLevel.incStartLevel(ModuleContainer.java:1600)
  at org.eclipse.osgi.container.ModuleContainer
$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1571)
  at org.eclipse.osgi.container.ModuleContainer
$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1514)
  at org.eclipse.osgi.container.ModuleContainer
$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)
  at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent
(EventManager.java:230)
  at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run
(EventManager.java:340)
Caused by: java.lang.NoClassDefFoundError:
jdk/internal/reflect/SerializationConstructorAccessorImpl
  at java.base/jdk.internal.misc.Unsafe.defineClass0(Native Method)
  at java.base/jdk.internal.misc.Unsafe.defineClass(Unsafe.java:1173)
  at java.base/jdk.internal.reflect.ClassDefiner.defineClass
(ClassDefiner.java:63)
  at java.base/jdk.internal.reflect.MethodAccessorGenerator$1.run
(MethodAccessorGenerator.java:400)
  at java.base/jdk.internal.reflect.MethodAccessorGenerator$1.run
(MethodAccessorGenerator.java:394)
  at java.base/java.security.AccessController.doPrivileged(Native Method)
  at java.base/jdk.internal.reflect.MethodAccessorGenerator.generate
(MethodAccessorGenerator.java:393)
  at
java.base/jdk.internal.reflect.MethodAccessorGenerator.generateSerializationConstructor
(MethodAccessorGenerator.java:112)
  at java.base/jdk.internal.reflect.ReflectionFactory.generateConstructor
(ReflectionFactory.java:404)
  at
java.base/jdk.internal.reflect.ReflectionFactory.newConstructorForSerialization
(ReflectionFactory.java:396)
  at java.base/java.io.ObjectStreamClass.getSerializableConstructor
(ObjectStreamClass.java:1416)
  at java.base/java.io.ObjectStreamClass.access$1500
(ObjectStreamClass.java:74)
  at java.base/java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:499)
  at java.base/java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:474)
  at java.base/java.security.AccessController.doPrivileged(Native Method)
  at java.base/java.io.ObjectStreamClass.<init>(ObjectStreamClass.java:474)
  at java.base/java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:371)
  at java.base/java.io.ObjectOutputStream.writeObject0
(ObjectOutputStream.java:1132)
  at java.base/java.io.ObjectOutputStream.writeObject
(ObjectOutputStream.java:348)
  at
com.ibm.ws.config.admin.internal.ConfigurationStore.serializeConfigurationData
(ConfigurationStore.java:213)
  at com.ibm.ws.config.admin.internal.ConfigurationStore$2.run
(ConfigurationStore.java:123)
  at java.base/java.security.AccessController.doPrivileged(Native Method)
  at com.ibm.ws.config.admin.internal.ConfigurationStore.saveConfiguration
(ConfigurationStore.java:120)
  at com.ibm.ws.config.admin.internal.ExtendedConfigurationImpl.updateCache
(ExtendedConfigurationImpl.java:471)
  at com.ibm.ws.config.xml.internal.ConfigUpdater.updateConfiguration
(ConfigUpdater.java:266)
  at com.ibm.ws.config.xml.internal.ConfigUpdater.updateConfiguration
(ConfigUpdater.java:195)
  at com.ibm.ws.config.xml.internal.ConfigUpdater.update
(ConfigUpdater.java:110)
  at com.ibm.ws.config.xml.internal.ConfigUpdater.update
(ConfigUpdater.java:96)
  at com.ibm.ws.config.xml.internal.ChangeHandler.updateAtStartup
(ChangeHandler.java:381)
  at com.ibm.ws.config.xml.internal.SystemConfiguration.start
(SystemConfiguration.java:137)
  at com.ibm.ws.config.xml.internal.WSConfigXMLActivator.start
(WSConfigXMLActivator.java:108)
  at com.ibm.ws.config.internal.WSConfigActivator.start
(WSConfigActivator.java:38)
  at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run
(BundleContextImpl.java:774)
  at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run
(BundleContextImpl.java:1)
  at java.base/java.security.AccessController.doPrivileged(Native Method)
  at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator
(BundleContextImpl.java:767)
  ... 12 more
Caused by: java.lang.ClassNotFoundException:
jdk.internal.reflect.SerializationConstructorAccessorImpl cannot be found
by com.ibm.ws.config_1.0.16.20161111-1635
  at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal
(BundleLoader.java:461)
  at org.eclipse.osgi.internal.loader.BundleLoader.findClass
(BundleLoader.java:372)
  at org.eclipse.osgi.internal.loader.BundleLoader.findClass
(BundleLoader.java:364)
  at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass
(ModuleClassLoader.java:161)
  at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:473)
  ... 48 more


- Andy Guibert

Reply via email to