JDK7 language specification issue with MethodHandle

[Neal Gafter]

I'm really confused here.  Are you saying that jsr292 is "clarifying" the
language?  The sort of changes we're talking about don't qualify as
"clarifications" according to any dictionary definition I'm familiar with.
Even if they did, the language specification is out of scope for jsr292.
That is clear from its charter.  I'm not asking about the VM changes (i.e.
jsr-292's charter), but about language changes (Coin's charter).

Has there been a change in jsr292's charter that hasn't yet made it to
jsr-292's JCP website?

Cheers,
Neal

On Mon, Apr 18, 2011 at 4:13 PM, <joe.darcy at oracle.com> wrote:

> Hi Neal.
>
> Neither Project Coin nor JSR 334 have covered any JSR 292-related features
> for some time, although discussions of JSR 292-related features did take
> place on coin-dev in the past.
>
> Changes to the JSR 292 specification to clarify the Java language changes
> that support MethodHandle are in process.  Such changes include the
> definition of polymorphic signatures and extended rules for compile-time
> method resolution.
>
> Please direct all further inquiries related to JSR 292 to its spec lead,
> John Rose.
>
> Regards,
>
> -Joe
>
>
> On 4/4/2011 9:57 PM, Neal Gafter wrote:
>
>> Project coin took on the task of specifying language changes related to
>> method handles,  invokeDynamic, and other jsr292-related things.  In the end
>> project coin's leaders decided not to specify any Java language changes in
>> jdk7 for jsr292.
>>
>> The documentation for MethodHandle (see "Method Handle Compilation" in <
>> http://download.java.net/jdk7/docs/api/java/lang/invoke/MethodHandle.html>)
>> appears to contradict the requirements of the Java Language Specification by
>> describing compiler behavior that does not conform to the requirements of
>> the JLS.  I have not checked, but I would not be surprised if jdk7's javac
>> also fails to satisfy the specification in this area.  This is the kind of
>> backdoor language change that Java's corporate owner has consistently
>> considered a clear violation of Java trademark licensing requirements.
>>
>> Are there any plans to resolve this?  Are the required language changes
>> going into the JLS through some other mechanism?
>>
>> Cheers,
>> Neal
>>
>