>From Valdimir We don't want to make Unsafe.defineAnonymousClass() part of public API, but consider moving forward on that front providing lightweight code loading machinery.
While I used defineAnno for awhile currently I just use defineClass in my own class loader. My only concern is that perhaps its slow as its probably checking security, validating byte codes etc. All things that don't add any value in my app. I did originally like the ability to patch the constants but found just making constant callsites just as easy. Again maybe not as efficient. Seems like a class loader that specializes in dynamic languages would be a way to hide and localize the unsafe code while maintaining ease of use. I am all for low level incremental improvements at this point. I am concerned about what seems to be a focus on specific guest language support enhancements. mark
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
