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

[Volker Simonis]

Hi Maurizio,

thanks a lot for the detailed information. The integration indeed
makes more sense now.

I just asked because we had our first JCP JDK 18.3 EG meeting today
and I try to understand how the JEP process and the JSR JCP process
work together (JEP 286 is currently the only JEP targeted for Java
18.3 so I had to beat on you :).

In general (and this is not related to your JEP anymore which seems in
good shape) I think it would be nice if every JEP which is proposed to
be targeted contains some information about where the implementation /
test / specification can be found (binaries to easily test the new
feature would always be a plus of corse :)

Thanks,
Volker


On Thu, Oct 12, 2017 at 6:57 AM, Maurizio Cimadamore
<maurizio.cimadamore at oracle.com> wrote:
>
>
> 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
>>>
>