On Jul 14, 2012, at 7:12 AM, Stephen Bannasch wrote:
> /Users/stephen/dev/java/src/mlvm/sources/build/macosx-x86_64/bin/java
> -XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions
> -XX:-LogVMOutput -Djava.awt.headless=true -Xmx512m -Xms512m -XX:PermSize=32m
> -XX:MaxPermSize=160m -cp
> /Users/stephen/dev/java/src/mlvm/sources/build/macosx-x86_64/classes
> sun.rmi.rmic.Main -classpath
> "/Users/stephen/dev/java/src/mlvm/sources/build/macosx-x86_64/classes"\
> -d
> /Users/stephen/dev/java/src/mlvm/sources/build/macosx-x86_64/classes
> \
> -v1.2 \
> -keepgenerated \
> javax.management.remote.rmi.RMIConnectionImpl
> Error occurred during initialization of VM
> java/lang/NoClassDefFoundError: java/lang/invoke/AdapterMethodHandle
I've seen errors like this too. They come from accidentally mixing an old
libjvm.dylib with a new rt.jar, or vice versa.
Because new only works with new and old with old, there will be a flurry of
such errors in various places, until the new is everywhere.
The error above suggests that an old libjvm.dylib is waking up and looking
around for AdapterMethodHandle, which is not part of the new rt.jar. (It is a
private implementation component found only in old the rt.jar.)
I don't see an -Xbootclasspath in your command line, so I'm guessing that your
build/macosx-x86_64 has a mix of old rt.jar and new libjvm.dylib in it,
somehow. Perhaps hotspot.log has a clue as to why.
— John___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
