Proposal: Newer version-string scheme for the Java SE Platform and the JDK

[joe darcy]

On 11/2/2017 2:21 PM, John Rose wrote:
> On Nov 2, 2017, at 2:08 PM, Stephen Colebourne <scolebourne at joda.org> wrote:
>> The proposal does not indicate what happens with the class file
>> version, but replies on Twitter indicate an intention to update that
>> number with each feature release. IMO this would be a mistake, as
>> changing the class file number has a knock on effect on a lot of
>> low-level downstream tools that often take months to update, with
>> nasty impacts on the ability to adopt a feature release. As such, I
>> *strongly* argue that the class file version should only change when
>> it is required to do so. This will occur naturally when a change is
>> merged into master that requires a new version, so there is no impact
>> on process that I can see.
> This argument works backwards if class file version changes
> are likely to occur in each feature release.  In that case, we
> have the same knock-on effects as a deterministic lock-step
> rule, *plus* unpredictability.
>
> And we *are* likely to be introducing class file format changes
> frequently going forward.  The tools will just need to keep
> up.  In that environment, would you rather have a predictable
> lock-step rule for tool development, or would you still prefer
> your scheme, which optimizes for the infrequent "null" change,
> at the cost of guessing on a random variable?
>
>

The version of class file in jar provides an implicit mechanism to 
indicate the minimum JDK version needed to run the jar.

-Joe