RFR(M) JDK-8031819: Remove legacy jdk checks and code

[Staffan Larsen]

On 6 jun 2014, at 23:07, David Holmes <david.holmes at oracle.com> wrote:

> On 6/06/2014 11:07 PM, Daniel D. Daugherty wrote:
>> On 6/5/14 11:26 PM, David Holmes wrote:
>> 
>> > But everyone needs to be very aware that once this goes in you
>> > can forget about placing a JDK 9 VM anywhere but a JDK 9 JDK.
>> > (Or did we already hit that?)
>> 
>> This caught my eye... Have we already reached a point where we
>> can't put the current JDK9 JVM into various JDK8 builds? I know
>> we have restrictions about putting the current JVM (and the
>> HSX-25 JVM) into JDK7...
> 
> I think I over generalized. We can no longer drop it into any JDK for which we previously had special code guarded with a version check. That would generally mean 7+ is okay _but_ we already made changes that make the VM incompatible with 7 (long ago) so that leaves 8+. We just have to watch for semantic changes in 9 versus 8.

In general I think we need to stop making the assumption that a JVM works with any other JDK than the JDK it is part of. The assumption should be that there is a 1-1 mapping between JDK and JVM. It may still be possible to run simple things such as “java -version” with unmatched JDK/JVM combinations, but that is not a very complete test. 

/Staffan


> 
> David
> -----
> 
>> If the current JDK9 JVM (prior to this changeset) can still be
>> dropped into JDK8 and this changeset makes it so that the JDK9
>> JVM can no longer be dropped into JDK8, then we need to get
>> wider feedback than hotspot-runtime-dev at ...
>> 
>> In particular, the HotSpot Compiler and Performance teams should
>> be notified since dropping the current JVM into an older JDK is
>> one of their standard failure analysis techniques; don't know
>> if the HotSpot GC team does that trick much.
>> 
>> Dan