JDK-8253545 : Add method to SourceVersion that returns the numeric version
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: javax.lang.model
  • Affected Version: 16
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2020-09-23
  • Updated: 2022-04-18
  • Resolved: 2022-04-18
Related Reports
Relates :  
Relates :  
Description
Working on JDK-8216497 we encountered a case where we need to retrieve the numeric feature release version from a `javax.lang.model.SourceVersion` constant. Currently, the only way to achieve this is to extract the version number from the value's name, which is not a very good solution. `SourceVersion` should provide a method that returns the release as an `int`.
Comments
The functionality in question was provided in JDK-8275888 using Runtime.Version objects as a level of indirection.
18-04-2022

[~darcy] what I really need in the context of JDK-8216497 is to get the identifier for the feature release of the JDK associated with a given SourceVersion in order to link to the proper set of API documentation. I don't really care about the properties of the identifier. The only reason I proposed an `int` return value was that I though it was guaranteed to be an `int` anyway. So for my purpose it would be ok to return an opaque `String` as feature release identifier. Would that be OK with you?
28-09-2020

There was a period of time where instead of using an integer increasing by one has as the primary way to refer to a JDK release, a year and month was going to be used instead (see history discussed in http://openjdk.java.net/jeps/322). There is an implicit assumption that the release versions can be fully linearized. This is a mild assumption, but one could imagine long-lived exploratory projects getting language levels or preview features being modeled in some way beyond the preview predicate now available.
25-09-2020

I would have thought that the versioning of the Java language moving in lockstep with JDK and JVM and having a feature release that is identified by an unsigned int is pretty much a given. Obviously the release model could change (again), but it seems unlikely that it would get rid of the current concept of a feature release (which would also break `java.lang.Runtime.Version` and the contents of system properties). We can use the ordinal() method with an assert to fail predictably, but it doesn't seem like a great solution: int versionNumber = sourceVersion.ordinal(); assert sourceVersion.name().equals("RELEASE_" + versionNumber);
25-09-2020

For now, I recommend using the built-in ordinal method for this purpose. I would be hesitant to commit to an API pledging to sensibly map the SourceVersion to an integer given possible future changes to the release model.
23-09-2020