On Aug 15, 2014, at 5:03 AM, Florian Weimer <fwei...@redhat.com> wrote:
> On 08/14/2014 10:15 PM, Mark Roos wrote: >> Look into sun.Misc.Unsafe > > [and at defineAnonymousClass(Class, byte[], Object[])] > > Thanks. Could we turn this into a supported API, with a suitable security > manager check? Hi Florian and Mark. Here's the story about that. Unsafe.defineAnonymousClass is used inside the JDK for loading small classes of indeterminate lifetime. Many of them contain single static methods, which makes it, in effect, an anonymous method loader. Because the small bits of code often need to be injected into a pre-existing class, a "host class" can be designated, which means the anonymous class has access to everything the host class can access, including host class privates. Because the small bits of dynamically generated code can depend on (meta-)data values that are dynamically computed and/or are anonymous, the class's constant pool can be "patched" to refer to "live" values that do not have symbolic names. So it allows some low-level tinkering with the JVM internals. Like any non-standard internal API, if you use it, you are tightly coupled to the JVM implementation, and you are on your own if something goes wrong. We fix bugs in this internal feature only if it fixes a bug in a standard J2SE feature that somehow depends on it. I expect that defineAC and its use cases will help inform future consideration of next-generation class loading APIs. I don't expect it to become a standard feature on its own. For one thing, the design is "not quite right": It should really be a method loader, but we don't have a separate format for methods. The constant pool patching part of the API, while necessary, requires knowledge of constant pool layout, which feels wrong too. Specifically, in the context of a (not yet existing) "classfile 2.0" effort, defineAC should help us think about the format of a stand-alone method, about the interaction of packaging and access rights, and about the division of labor between constant pool and bytecode. Since these are (to my mind) open-ended design questions, I don't think we will promote the existing ad hoc API to a public one, unless there is a compelling short term reason to do so. The most obvious security interaction is with the host-class feature; as it stands the API is very unsafe because you could use it to inject code into any system class. Just allowing the existing API with a security manager check is too coarse-grained to make the feature useful, except to highly trusted code. If the host-class token were changed to a MethodHandles.Lookup object, we could restrict the host-class to be one which the user already had appropriate access to. Seems simple, but of course the rest of the project is complicated: API design, spec completion, security analysis, positive and negative test creation, code development, quality assurance—all these would be expensive, and (again) most easily justified in the context of a larger refresh of our classfile format. Do you have a use case in mind that could be expressed as a more tightly focused API? It might be easier to standardize on a very specific API that used dAC. Or, most or all of dAC could be simulated using regular class loading, into a single-use ClassLoader object. The nominal bytecodes would have to be rewritten to use invokedynamic to manage the linking, at least to host-class names. But given that ASM is inside the JDK, the tools are all available. (Remi could do most of it in an afternoon. :-) ) Given such a simulation, the internal dAC mechanism could be used as an optimization, when available, but there would be a standard (complex) semantics derived from ordinary classes and indy. — John > I'm surprised there aren't any callers of this method in Fedora. Anonymous > classes look very useful for run-time code generation. > > -- > Florian Weimer / Red Hat Product Security > _______________________________________________ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
