RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration)

[Magnus Ihse Bursie]

On 2015-06-09 15:26, Claes Redestad wrote:
> On 2015-06-09 15:12, Magnus Ihse Bursie wrote:
>>> langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java 
>>>
>>>     old L171:                 case "1.9":
>>>     new L171:                 case "9":
>>>         Should this logic support both versions? Will dropping
>>>         "1.9" here prevent a pre-version changeset JVM from
>>>         being dropped into a JDK for triage purposes?
>>>
>>>         Granted we don't often triage 'javac' with different JVMs, 
>>> but...
>> I'll defer that question to Kumar, who wrote that piece of code. My 
>> guess is that when Hotspot express was dropped, the ability to use a 
>> JVM from another JDK release bit rotteded away.
>>
>> /Magnus 
>
> While we know there's no guarantee that swapping in an older VM will 
> work, in the face of a regression in a promoted build we still 
> routinely (automatically, even) swap out the VM with a recent VM to 
> get a rough estimate of whether the regression was caused by a HotSpot 
> or JDK/tools change, mostly since this currently saves us time in 
> narrowing down the changes to bisect over/investigate. So, there's at 
> least some value in not intentionally breaking build-to-build 
> backwards compatibility, but we don't expect it to always work and 
> wouldn't make much fuss about it breaking. If an extra case "1.9" is 
> all it takes to make it work with last week's VM, however...

Actually, I think I messed up a bit there. I believe the real question 
here was not about mixing different versions of Hotspot and the JDK, but 
mixing different versions of javac and the JDK. I think. :)

/Magnus