PROPOSAL: language support for JSR 292

[Bruce Chapman]

resent - didn't make the coin list first/2nd/3rd time. - maybe it was 
html  only? resending as  plain text.

John Rose wrote:
> I have factored out the Dynamic type from the proposal, leaving a 
> static-only type called InvokeDynamic in its place.  Here is the 
> updated spec (also enclosed FTR):
>   http://wikis.sun.com/display/mlvm/ProjectCoinProposal
John,

Do you think you could find someone with more intimate JLS knowledge to 
help you write this. You seem to be out of your area of (undoubted) 
expertise here.


For example, section 1.2 says
" The type name InvokeDynamic may be qualified with any method name 
whatever, and invoked on any number and type of arguments."

which is wrong on the following counts.
1. Type names are qualified by either enclosing types, or package 
names.(not by method names)
2. Type names are not invoked, methods are.

Being a bear of very little brain myself, by the time I have worked out 
what your words are trying to say, I have completely exhausted my 
ability to comprehend the proposal. For example I can't decide whether

int y = InvokeDynamic.<int>myHashCode(x);  // type (Object) -> int


returns a MethodHandle of type (Object) -> int, or indirectly invokes a 
method of unknown name but of that signature on some unspecified class 
or instance.

If the former, then how can it be assigned to an int, and if the latter, 
I can't see how the target class/object is determined, or the method's 
name,  is determined neither at compile time nor runtime, nor any 
combination of cooperation between the two?

And no, I don't really want you to answer that in a reply, I would like 
the proposal to be written so that it was obvious. I have found your 
descriptions of what happens in the JVM to be very lucid - It would be 
wonderful if this proposal was at least half as such.

completely confuzzled.

Bruce
>
> The type java.dyn.InvokeDynamic is a uninstatiable class (like 
> Collections or Arrays) with no apparent methods. However, the compiler 
> treats it has if it had an infinite supply of static methods of all 
> names and signatures, for which it generates invokedynamic 
> instructions instead of invokestatic instructions.
>
> By removing the value type Dynamic from the base proposal, we serve 
> the immediate need for system programming on top of JSR 292, while 
> deferring the question (a truly absorbing and important question) of 
> integrating dynamic values with Java's type system.
>
> -- John
>
> P.S.  The factored-out parts, about interface Dynamic and its 
> interesting rules for conversion and method invocation, are placed here:
>   http://wikis.sun.com/display/mlvm/InterfaceDynamic
>
> And, should you have an appetite for even more of the same, some rough 
> notes a fuller integration of Java with dynamic types is here:
>   http://wikis.sun.com/display/mlvm/DynamicJava
>
> P.P.S. Here is a text-only copy of the basic proposal:
>
>
> ------------------------------------------------------------------------
>
>
>