PROPOSAL: language support for JSR 292 (original) (raw)
Neal Gafter neal at gafter.com
Sun Mar 29 00:55:42 PDT 2009
- Previous message: PROPOSAL: language support for JSR 292
- Next message: PROPOSAL: language support for JSR 292
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
John-
Could you please send the proposal to this list?
I don't really understand the intended specification with respect to Dynamic. It is one the one hand described as an object type (e.g. section 1.9) but on the other hand it doesn't inherit from Object (section 1.1). You can't have it both ways. I can't tell, for example, whether Dynamic is a valid type in a generic type parameter. If the answer is yes, then it must have Object as a supertype. You might find it useful to review what C# has done in this area with their type "dynamic". In short, it occupies the same location in C#'s type lattice as Object, but it has some additional conversions defined that are not subtype relationships.
I don't believe this is a "small change". However, if it is going to happen anyway in JDK 7 to support jsr292, I can see the sense in having it dealt with in the same expert group as four or so other small, local changes.
Regards, Neal
On Sat, Mar 28, 2009 at 11:53 PM, John Rose <John.Rose at sun.com> wrote:
Hello, colleagues. Here is a proposal which is linked to JSR 292 (invokedynamic).
http://wikis.sun.com/display/mlvm/ProjectCoinProposal http://blogs.sun.com/jrose/entry/jsr292supportinjavac Here's the teaser (from my blog): In order to work with dynamic types, method handles, and invokedynamic I have made some provisional changes to javac as part of the Da Vinci Machine Project. The mlvm wiki has a full description for Project COIN. It is most desirable, of course, to program invokedynamic call sites as Java expressions, not just ASM code, and that's what those langtools patches are for. The essential features are four: • The type java.dyn.Dynamic will accept any method call and turn it into an invokedynamic instruction, and the full range of such instructions can be spelled from Java code. • The type java.dyn.MethodHandle will accept any argument and return types for a call to the method named invoke, which means that Java code can spell the full range of method handle invocations. • The full range of bytecode names acceptable to the JVM can be spelled from Java code, using an exotic identifier quoting syntax. • The type java.dyn.Dynamic serves as a bare reference type: Anything implicitly converts to it, and it can be cast to anything, but it is not a subtype of java.lang.Object. Its methods, of course, are those from point #1, so it is handy for forming invokedynamic calls. The rationale is pretty simple: If we put some minimal support into Java for defining and using names in other languages, then Java can be used as a system programming language for implementing them. Otherwise, the system programming language will be assembled bytecode. (I like to visit ASM, but don't want to live there.) Do check out the wiki page; it has the full Project COIN proposal format. Best wishes, -- John Rose (Da Vinci Machine Project)
- Previous message: PROPOSAL: language support for JSR 292
- Next message: PROPOSAL: language support for JSR 292
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]