RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) (original) (raw)
Claes Redestad claes.redestad at oracle.com
Tue Jun 9 13:26:27 UTC 2015
- Previous message: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration)
- Next message: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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...
/Claes
- Previous message: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration)
- Next message: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]