Should there be any issues using sun.invoke.anon?

[John Rose]

Hi Mark.

I have to tell you that the anonymous class loader is a purely experimental feature, with no standard API.  For this reason, you can only use it reliably with MLVM builds.

To run on a standard JVM, your bytecodes need to be loaded under a name.  It can be an arbitrary name, of course.

For purposes of further experimentation, I suggest doing a portable implementation that doesn't rely on anonymous classes, and switching to it if you get a linkage error trying to use the anonymous class feature.

What advantage does the use of anonymous classes gain you?  Is there a performance advantage?

The http://asm.ow2.org framework is an excellent way to spin bytecodes.  This framework has an "asmifier" tool which takes pre-existing template-like classes and sets them up for modification, in a way similar to the CP patching feature of anonymous classes.

Should we consider anonymous classes  for a future version of JSR 292 (or another JSR)?  I've been looking for experience to justify standardizing them, but I don't see much yet.  Method handles give more flexibility and similar optimizability.

-- John


On Jul 11, 2011, at 5:18 PM, Mark Roos wrote:

> Hi all 
> 
> I have be using sun.invoke.anon.AnonymousClassLoader for generating my classes with 
> no issues until now.  With the 6/30 MacOs version from google code I find that my code runs fine but when 
> I go to recompile it I get the package not found error.   I see the package in the rt.jar using a file viewer so its 
> there.  No problems with Stephen's versions. 
> 
> Should this be in the distribution by default? Do I need some compiler flag to enable it? Or is this a bug I should report?   
> 
> thanks 
> 
> mark 
> 
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110711/64c17669/attachment.html