Interim JDK 10 RFR of 8187951: Update javax.lang.model.SourceVersion for "var" name

[Maurizio Cimadamore]

On 12/10/17 11:33, Volker Simonis wrote:
> Hi Joe,
>
> I just have a quick question regarding the overall development
> approach for jdk 10 (aka jdk 18.3).
>
> As Mark has wrote several times (e.g. [1]) "every feature must be
> complete before it's integrated". Your change clearly belongs to "JEP
> 286: Local-Variable Type Inference" which doesn't seem to be complete
> until now. So from my understanding of Mark's "Accelerating the JDK
> release cadence" proposal [2], where he writes that "..the bar to
> target a JEP to a specific release will, however, be higher since the
> work must be Feature Complete in order to go in..", this requires "at
> the very least, all necessary code, specification text, and unit
> tests" [1].
>
> While JEP 286 has already been targeted for JDK 10, I can only find a
> specification attached to the JEP issue but no full implementation and
> unit tests. Maybe the implementation is already in the Amber
> repository (I can't really judge) but I saw that 'lvti' branch in
> Amber was created just two weeks ago.
Hi Volker,
the lvti prototype has been available for several months now; it has 
been first discussed here [1]. Then, when we create project Amber, lvti 
was one of the first branch to be created [2]. What you see (2 weeks 
ago) is the re-creation of same branch when we moved to a consolidated 
amber repo - which we did by moving contents over from old 
non-consolidated amber repo to the new one. Both repos are still 
available for people to see [3].

Unit tests are available (and have been for quite some time) [4], and 
the spec text has also been available for some time [5], although it has 
recently been rebased and improved (as part of the CSR process).

Ultimately, I think this feature was "complete" when it was integrated 
into JDK 10 [6], by some reasonable definition of complete. For every 
feature there's always a small tail of things that have been missed, or 
that need to be adjusted/tweaked based on feedback - JEP 286 is no 
exception to this.

Cheers
Maurizio

[1] - 
http://mail.openjdk.java.net/pipermail/platform-jep-discuss/2016-March/000037.html
[2] - 
http://mail.openjdk.java.net/pipermail/amber-dev/2017-March/000019.html
[3] - http://hg.openjdk.java.net/amber/
[4] - 
http://hg.openjdk.java.net/amber/amber10-old/langtools/file/940ff165a2c3/test/tools/javac/diags/examples/LocalNonDenotable.java
[5] - 
http://mail.openjdk.java.net/pipermail/amber-spec-experts/2017-March/000015.html
[6] -http://hg.openjdk.java.net/jdk10/master/rev/48ec75306997


>
> So to cut a long story short: according to the new development model,
> shouldn't the complete JEP 286 be developed and tested in its own repo
> or branch and only integrated into jdk10 once it is "feature complete"
> ?
>
> Thanks,
> Volker
>
> [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-October/000001.html
> [2] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html
>
> On Wed, Oct 11, 2017 at 5:57 PM, Joseph D. Darcy <joe.darcy at oracle.com> wrote:
>> Hi Jon,
>>
>> Catching up post-JavaOne...
>>
>> On 9/29/2017 11:12 AM, Jonathan Gibbons wrote:
>>
>> Joe,
>>
>> I guess I would ask, who are these methods targeted at?
>>
>> Both isIdentifier and isKeyword are fuzzy at best.
>>
>> isIdentifier does not take the appropriate Unicode standard into account,
>> although it is probably "good enough".
>>
>>
>> Right; specifically it doesn't use the Unicode standard that was in force at
>> the time of the earlier releases. Each major JDK platform release generally
>> bumps the supported Unicode version and set of identifier characters
>> expands. To be 100% accurate the isIdentifier check on release (N - k) for
>> some k > 0 would need the Unicode tables used on JDK (N - k). That
>> information is not available via the platform APIs.
>>
>> isKeyword has certainly become more complex in 9 and after, and anyone who
>> really needs this info (e.g. IDEs) is probably already doing it for
>> themselves, properly.
>>
>> Do you have any reasonable use-cases for a fuzzy definition of isKeyword, or
>> should we just deprecate it words the Big Bit Bucket in the sky?
>>
>>
>> My thought was for annotation processor authors to have some easy ways to
>> verify a name was valid to use on a given source version, etc.
>>
>> I agree tools like IDEs will need more precise implementations of such
>> checks, but I think there is still benefit in providing less formal checking
>> too.
>>
>> -Joe
>>