new error building mlvm: nvoke/AdapterMethodHandle no class def found

John Rose john.r.rose at
Sat Jul 14 13:52:14 PDT 2012

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                  \
> 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
-------------- next part --------------
An HTML attachment was scrubbed...

More information about the mlvm-dev mailing list