96

Would I encounter any problems running Java programs and associated libraries compiled in Java version 1.6 and 1.7 (I'm compiling using 1.7 whereas some libraries are compiled using 1.6) and running the entire program in a 1.7 JRE?

vvvvv
  • 25,404
  • 19
  • 49
  • 81
shawn
  • 4,063
  • 7
  • 37
  • 54

2 Answers2

111

As answered already you are mostly safe and most products and 3rd party libraries will simply work. However there do exist (not so-) rare binary incompatibilities.

These incompatibilities happen where the classes compiled using older JDK fail to run in the newer JVM due to compatibility breaking changes introduced in the JDK itself (e.g. class removal, class/method visibility reduction, method signature changes or package changes) were introduced after the code using JDK has been written and compiled.

For Java 9 and earlier:
Official list of Oracle Java incompatibilities:

For Java 9 and later:
Compatibility tool

Packaged with JDK 9 and onwards, there is jdeprscan tool, which verifies the compatibility, lists no longer used APIs within your code and suggests alternatives(!). You can specify the target JDK version (works for JDK 17, 11, 9, 8, 7 and 6) and it will list incompatibilities specific to your target version.

Additional comment in case of libraries:

A reasonable rule of thumb is to use latest stable release version of library for the JRE version your software targets. Obviously you will find many exceptions from this rule, but in general stability of publicly available libraries usually increases with time.

Naturally API compatibility and versioning have to be considered when changing versions of dependencies.

Again most popular dependencies will have web pages where such information should be available.

If however you are using something a bit more obscure, you can discern which JRE were the classes within your dependency compiled for.

Here is a great answer on how to find out class version. You might need to unzip the JAR file first.

diginoise
  • 7,352
  • 2
  • 31
  • 39
  • 12
    Actually this should be the right answer, since it is NOT completely safe to upgrade to a newer java version. – dehlen Mar 17 '15 at 11:29
  • What if one does not use any jdk8 features, compile 1.8 and target 1.8. Will it work? – Gaurav Nov 19 '19 at 10:45
  • Unclear on what "since" means, Does In java SE 9 since Java SE 8 mean java 8 compiled java programs wont work on 9? What about those after 9? – Mark Deven Dec 23 '21 at 19:16
  • 1
    @MarkDeven From Java 9 onward a lot of old fluff has been removed from the standard library. Code relying on those classes will no longer work unless an external dependency providing those classes is introduced into the classpath. When that's done, it should once again work (mind that some of those classes do NOT have external equivalents, but those should never have been used directly anyway and always carried warnings to that effect). – jwenting May 11 '23 at 06:31
100

*** UPDATE ***

Since around 2020, the below answer is sadly no longer accurate. So much has changed in Java over the previous decade and compatibility was sacrificed to move things forward.

While it remains true that most of your code and knowledge transfers to newer versions, there are many exceptions these days, though, in my experience, migrations can sometimes be quite easy.

*** UPDATE ENDS ***

You would not encounter any problems - that's the magic of Java -it's backwards compatible.You can run almost all code from Java 1 on Java 8. There's no reason why Java 6 code won't run on a Java 8 Runtime.

What is interesting, is that for applications written in, let's say, Java 1.4, you even have speed increases when running them on later runtimes. This is because Java is constantly evolving, not just the language known as "Java", but also the JVM (Java virtual machine). I still have source code from more than 10 years ago that still work, as expected in the latest JVM.

If you want to target, let's say, a Java 5 VM, then you can do that with the Java 8 SDK tools. You can ultimately specify which target VM you wish to support, as long as you bear in mind that a version 5 VM might not support all the features a version 8 VM will.

I've just tested code I wrote in Java 5 against the new Java 8 runtime and everything works as expected, so, even though we have a more powerful language and runtime now, we can continue to use our investments of the past. Just that alone makes Java a great development choice for companies.

Ewald
  • 5,691
  • 2
  • 27
  • 31
  • So even though half my program(some libraries I'm using) are compiled using 1.6 and the other half compiled in 1.7, it will still work? – shawn Jun 06 '12 at 03:08
  • 2
    If you run it in a Java 7 runtime, yes. There's no reason for it not to work. – Ewald Jun 06 '12 at 08:11
  • this may sound silly but I need a clarification, in this case programs developed using jdk 1.7 will not run in jre 5 jre 6 etc ? in that case whenever I want to the users to run my application I have to tell them to upgrade to java 7? – Abi Feb 13 '13 at 02:01
  • 1
    If you develop with JDK 7, and compile the application as a JDK 7 application, then, no, it won't work on an older runtime. There are a number of reasons to ask users to please upgrade to the latest runtime, primarily security reasons, but also some performance issues. I'd go for Java 7 if I can, there's little point in supporting older versions unless you really have to. – Ewald Feb 13 '13 at 12:53
  • 1
    -1 MagicDraw doesnt work on newer versions of Java, even the comanpany made a tutorial for downgrading http://www.nomagic.com/files/Java%20downgrade%20tutorial.pdf – NeDark Feb 18 '15 at 19:44
  • 3
    Did you see the bit about "You can run almost all code from Java 1 on Java 8" ? There are some small incompatibilities, mostly in esoteric parts of the JVM. On the whole though, Java still remains very backwards-compatible. – Ewald Mar 09 '15 at 16:01
  • And this might not be so true for Java8 to Java9 migration I guess. There are things backward incompatible in there for that change. Preferably [this](https://stackoverflow.com/a/28605204/1746118) answers better. – Naman Mar 20 '18 at 04:11
  • What if one does not use any jdk8 features, compile 1.8 and target 1.8. Will it work? – Gaurav Nov 19 '19 at 10:45
  • 6
    Around 8 years later and this is, sadly, no longer true. I'm having lots of issues with Java14 and older Java apps that relied on features that have now been removed from the Java Runtime. For standard code, yes, it still works, but there are a few enterprise libraries that you can no longer rely on having present. Likewise with JavaFX. Pity, this forced us at work to look at moving away from Java to Rust. – Ewald Jul 10 '20 at 06:58
  • Then why are we getting stuff like https://stackoverflow.com/questions/69814385/exception-in-thread-main-java-lang-illegalaccesserror-class-org-apache-spark ? – Joan May 09 '23 at 20:44
  • 1
    @Joan see Ewald's comment above. Java 9+ deprecated (and Java 11+ removed) a lot of fluff that was added in the past to turn the standard library into a one size fits all thing, but are better served through external dependencies that can be maintained individually. – jwenting May 11 '23 at 06:29
  • @jwenting yes, I'm pointing out that this answer is wrong. Thanks for the explanation! – Joan May 12 '23 at 15:56