Write a java code to detect the JVM version The objective is to write java code that detects the JVM version relying in compatibility changes, side effects, bugs and/or undefined behavior that works in a way in one version and another way in another version. Further, the code should be at least a bit readable, without sacrificing whitespaces and legible variable names.

To ensure that objective, the exact formal rules are:


The code must be written in java and should output the JRE version in which it is running.
The code must not use any JDK or JRE API provided specifically for detecting the java version or which gives the JDK or JRE version for free.
The code must not use reflection.
The code is only required to work in Hotspot Java SE 5, 6 and 7, but may work in other JVMs.
The code must not use any third-party libraries in the classpath.
The code must not start any other process, java or not.
The code must not use environment variables.
The code must not search the file system looking for pre-existing files or folders.
The code must be contained in a single file and be called via public static void main(String[] args) or public static void main(String... args).
The code must not use any non-public API present in the JRE.
The code must not generate any NoClassDefFoundError, NoSuchMethodError, ClassNotFoundException or NoSuchMethodException during its execution.
The code should run in a system disconnected from the internet or from any local network.
You should provide an explanation of why it behaves in one way in a version and another way in another version.


Scoring

The method used for measuring the best solution is max(n/s), where n is the number of different java versions detected without violating any of these rules (at least versions 5, 6 and 7) and s is the number of lexical tokens in the solution.
I'm not sure what my score is, because it depends on what precisely you consider to be a lexical token, but I'm trying to abuse that counting system as much as possible with a long string...

It also depends on whether you count this as identifying 7 different versions or 16... (It could trivially be extended up to 190).

class V extends ClassLoader
{
    public static void main(String[]args)
    {
        for(byte b=60;;)
            try {
                byte[]buf="\u00ca\u00fe\u00ba\u00be\u0000\u0000\u00002\u0000\u0005\u0007\u0000\u0003\u0007\u0000\u0004\u0001\u0000\u0001A\u0001\u0000\u0010java/lang/Object\u0006\u0000\u0000\u0001\u0000\u0002\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000".getBytes("ISO-8859-1");
                buf[7]=b--;
                new V().defineClass(buf,0,53);
                System.out.println(b-43);
                break;
            }
            catch(Throwable t){}
    }
}


It works by attempting to define an interface in a custom classloader with descending major version numbers of the class format. The first one which doesn't throw a java.lang.UnsupportedClassVersionError corresponds to the VM's version.