A co-worker and I recently had a discussion about Java versions and the JVM. I use Java 7 but we use Java 6 for our client (while he says that some are still on 5). My immediate thought was, why can't we target those VMs too?

The Java VM is somewhat different than a real machine in that it has a bunch of runtime features. Type checking, exception handling, garbage collection, etc. But it's still a virtual machine which has a bytecode. (Which is why we can have things like C to JVM compilers.) So why can't we target older VMs with newer version of Java? Why does the language and the runtime have to be tied together? Besides the obvious performance penalties, it seems like it should be completely possible to compile Java 7 code to the Java 6 JVM. (And considering how little changed from Java 6 to 7, I can't imagine the compiler changes being that extensive.)


I think the main reason is simply that the demand for this feature is not very high, because upgrading to newer JVMs is generally quite painless. And the kind of organizations and people who insist on running outdated JVMs anyway are probably not keen on using the newest language features either.

Of course, it's certainly possible - nobody prevents you from writing such a compiler. But the only example I'm aware of that saw widespread use is Retroweaver, which let you use the Java 5 features on 1.4 JVMs. But then, Java 5 has the biggest, most useful new features of any Java version, so there was much more value in having this than with other versions.

  • I think this is the most likely answer. It just bugs me that I can't use something as simple as String in a switch statement on JVM 6. – GJK Jul 22 '13 at 14:06

the main culprit are the library updates, java is crazy backwards compatible such that code written for 1.1 will still run on java 8 without needing to be recompiled

the biggest changes are internals and JRE libraries, at bytecode level not much as changed

it is up to you(r manager) to decide whether you'll target 1.5 or 1.7 and then deal with the limited library available

  • So are you saying that I can target older versions with the new compilers? Like I can compile Java 8 lambdas to work on the Java 6 JVM? – GJK Jul 22 '13 at 13:51

If the JVM team was to start all over again they would probably look to have a modularised JVM so that you could mix and match JVM implementations and language features. For example you could have Lambdas implemented as anonymous inner classes or using invokedynamic and MethodHandles.

Hmm, actually they are looking at something like doing this for Java 9 with project Jigsaw

  • So do you think it's more of an effort issue at this point? Mix and matching the JVMs and language features would be more effort than it's worth? However, if that was the case, I would have the same question about .NET and C#. It just seems like there's a good reason that neither MS or Oracle are doing it. I just can't seem to find that reason. – GJK Jul 22 '13 at 14:01
  • 1
    @GJK: Oracle and Microsoft don't want to maintain a bunch of old versions either. It's much more efficient for them (and, frankly, everyone) to instead spend the effort on making upgrades to newer VMs easier and let the old ones die. I mean, from May 2014 on, Oracle stop supporting Java 5, even for enterprise customers willing to pay millions of dollars for the privilege of running outdated software. – Michael Borgwardt Jul 22 '13 at 14:04
  • 1
    @GJK, you can mix different runtime libraries versions within the same .NET runtime environment - that's what strong names are for. – SK-logic Jul 22 '13 at 14:04
  • I did not know that about .NET. That's very interesting. – GJK Jul 22 '13 at 14:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.