PROPOSAL: language support for JSR 292
brucechapman at paradise.net.nz
Fri May 1 03:07:17 PDT 2009
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):
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)
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
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.
> 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:
> 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:
> P.P.S. Here is a text-only copy of the basic proposal:
More information about the coin-dev