Classfile representation of specializable classes

[Dan Smith]

On Jul 11, 2014, at 10:58 AM, Brian Goetz <brian.goetz at oracle.com> wrote:

> The example in the writeup has many pleasing properties (one artifact, so can't get out of sync; encode minimal additional metadata needed to efficiently transform an erased classfile to a specialized classfile; the "template" can be used as an erased classfile as is, just by ignoring the specialization metadata attributes.)
> 
> It also has an unpleasant property: the bytecode for an already loaded class is not available easily through its classloader or reflection, meaning that a runtime specialization mechanism would have to jump through hoops (e.g., retransform-classes) to get at the bytecode.  Since specializing a class under this scheme requires, as input, the bytecode of the original class, this could become problematic for classes that are themselves generated (i.e., not findable with ClassLoader.getResource("Foo.class")).

Maybe what you're after with classdynamic is (primarily) a ClassLoader feature rather than a VM feature?  That is, maybe 'defineClass' should be parameterized by a pluggable class-generation system, and that's where the expansion should take place, intercepting the bytes and spitting out the special class.  It's not totally clear to me how this would work, but I think it may be the right place for it.  (I have consistently felt like what we really want with classdynamic is ClassLoaders 2.0.)

—Dan