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

[Volker Simonis]

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.

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
>