The JSR 292 EG was talking about corner cases for method invocation, specifically the invocation of dynamically selectable superclass constructors. Although this probably does not admit of a direct solution (without breaking the verifier's protections), the conversation leads to the concept of a "categorical superclass". I'm pretty sure a number of people on this list have worked out the details. It would be good to discuss this, and see if method handles and invokedynamic can play a supporting role.
For any given superclass S, define a "categorical subclass" K as a single bytecoded subclass of S that uses a display (metaobject) of method handles (or other pluggable API) to express all degrees of freedom implicit in the subclassing mechanism, as applied specifically to S. Call the display API M. There will be one instance of M for each dynamically defined subclass of S that is implemented using K. There might also be a range or lattice of such K, with the riches handling all degrees of freedom, and the simplest handling just the commonly-used options. For example, every non-final method S.m(T) will have two features in M, one corresponding to the binding of m(T) in S, and one "pluggable" feature which defaults to S.m(T) but which can be overridden (for an instance of M) to another method (specified as a method handle or an override in an anonymous subclass of M). There are two features because even if M specifies an override for m(T), there must be a way for the override code to access the original S.m(T) to emulate "super.m(...)". The implementation of K becomes categorical by overriding m(T) with code that consults M in the obvious way. Constructors are trickier, since the verifier makes special demands on the shape of their code. It's not enough to say "invoke a method handle from M", since that makes it impossible for the verifier to ensure, for any constructor in K, that exactly one constructor in S (or K) has been invoked before the rest of the constructor body is executed. Basically, K's constructors have to pass the verifier, but they cannot constrain future users of K beyond the limits naturally imposed by the constructors of S. I think if K contains a protected constructor for each superclass constructor, the metaobject M can "wire around" the restrictions and make it appear as if the subclass possesses an arbitrary set of public constructors, at least with respect to some factory API associated with K. There is no cleverness that can allow K to somehow spoof java.lang.reflect APIs into seeing a programmable set of methods. That degree of customization requires spinning a new K' with the required features. But I believe a bytecode-spinning API for generating K' could be nicely designed based on the K/M design pattern, and perhaps the K' could be a subclass of K with a suitable M[K']. Something like this stuff has probably been done by several people on this list. Anyone want to share war stories? -- John P.S. I did the K/M pattern in the early 90's for C++ with my "esh" Scheme implementation; the header file compiler created, for each C++ class with a virtual, a categorical subclass with a vtable of Scheme functions. That's why I know it can exist for Java. -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
