53

I am a little confused.

  1. Oracle says Java 8 is highly compatible with Java 7 (backward). But, what possibilities exist that Java 8 program can be run on Java 7 successfully (SE/EE)?

  2. If point one was true, Java 8 applications will be deployed and executed on a Java 7 server support? for example, Tomcat 8 or WildFly?

Alan B
  • 4,086
  • 24
  • 33
Mitsu Garcia
  • 593
  • 2
  • 5
  • 7
  • 11
    Backward compatible means Java 7 will run under Java 8. In order to run Java 8 byte code on Java 7 you'd need to use a retrotranslate-type process, I expect. – Dave Newton Mar 24 '14 at 13:13
  • I don't understand your second question. Could you clarify that? – eis Mar 24 '14 at 13:16
  • You could not run jdk 8 compiled code in jdk 7 but jdk 7 compiled code could not run on jdk8. But you can compile jdk 7 compatible code using jdk8 with specify some property during compile time eg javac -target 1.7 YourClass.java ... – Naveen Ramawat Mar 24 '14 at 13:22
  • yes, i mean if i can use a java 7 server for develop with java 8 or it's imposible? – Mitsu Garcia Mar 24 '14 at 13:23
  • I just checked and WildFly 8 runs on Java 8, Tomcat has some issues and doesn't. – Karol S Mar 24 '14 at 13:35
  • Thanks for your help Karol, i'll try with WildFly. Thanks again :) – Mitsu Garcia Mar 24 '14 at 14:15
  • @MitsuGarcia some servers hava java 8 support, some don't. Wildfly has support, most of them probably won't. You will need java 8 support to deploy java 8 apps. – eis Mar 24 '14 at 15:16
  • most of them won't -> most of other servers don't – eis Mar 24 '14 at 21:02
  • possible duplicate of [Can Java 8 code be compiled to run on Java 7 jvm?](http://stackoverflow.com/questions/16143684/can-java-8-code-be-compiled-to-run-on-java-7-jvm) – Ciro Santilli OurBigBook.com Mar 18 '15 at 08:02
  • 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:44

6 Answers6

79

In general, no.

The backwards compatibility means that you can run Java 7 program on Java 8 runtime, not the other way around.

There are several reasons for that:

  • Bytecode is versioned and JVM checks if it supports the version it finds in .class files.

  • Some language constructs cannot be expressed in previous versions of bytecode.

  • There are new classes and methods in newer JRE's which won't work with older ones.

If you really, really want (tip: you don't), you can force the compiler to treat the source as one version of Java and emit bytecode for another, using something like this:

javac -source 1.8 -target 1.7 MyClass.java

(the same for Maven), and compile against JDK7, but in practice it will more often not work than work. I recommend you don't.

EDIT: JDK 8 apparently doesn't support this exact combination, so this won't work. Some other combinations of versions do work.

There are also programs to convert newer Java programs to work on older JVM's. For converting Java 8 to 5-7, you can try https://github.com/orfjackal/retrolambda To get lower than 5, you can pick one of these: http://en.wikipedia.org/wiki/Java_backporting_tools

None of these hacks will give you new Java 8 classes and methods, including functional programming support for collections, streams, time API, unsigned API, and so on. So I'd say it's not worth it.

Or, since you want to run your Java 8 JEE applications on an application server, just run your entire server on Java 8, it may work.

radistao
  • 14,889
  • 11
  • 66
  • 92
Karol S
  • 9,028
  • 2
  • 32
  • 45
  • So, that's means i can't develop jee applications with java 8, because there is no server for it? – Mitsu Garcia Mar 24 '14 at 13:20
  • 1
    Have you tried running your server on Java 8? Maybe it will work? – Karol S Mar 24 '14 at 13:22
  • well, a hello world with tomcat8, runs fine. – Mitsu Garcia Mar 24 '14 at 13:50
  • 1
    Can't test it right now, but I highly suspect running `javac -source 1.8 -target 1.7 MyClass.java` will not even try to do anything. See [this thread](http://stackoverflow.com/questions/9260448/which-jdks-distributions-can-run-javac-source-1-6-target-1-5) (and its comments) for details. AFAIK you'd need to use Compiler API to get that. – eis Mar 24 '14 at 15:28
  • 2
    I also disagree with "some language constructs cannot be expressed in previous versions of bytecode", since as far as I've understood, retrolambda [is based on the fact that they can be expressed](http://stackoverflow.com/questions/17756604/has-anybody-yet-backported-lambda-expressions-to-java-7). – eis Mar 24 '14 at 15:32
  • @eis: I don't think you can meaningfully simulate annotations on type parameters using Java 7. – Karol S Mar 24 '14 at 20:14
  • Now I was able to confirm it: `javac: source release 1.8 requires target release 1.8`, so you cannot really do what you claim. – eis Mar 24 '14 at 20:40
  • @KarolS there has been type annotations in things like [checker framework](http://types.cs.washington.edu/checker-framework/) in java 7 already. Do you have any source for your claim that they couldn't be expressed in earlier bytecode? – eis Mar 24 '14 at 20:57
  • @eis: type parameter annotations with runtime retention are not supported by Checker, .class files don't contain them, ergo they are not expressed in Java 7 bytecode even if Checker uses them for something. – Karol S Mar 25 '14 at 00:16
  • `Error:java: javacTask: source release 1.8 requires target release 1.8` – naXa stands with Ukraine Aug 18 '17 at 15:41
  • 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:44
13

Backward compatibility means

You can Run Lower configuration on Higher Configuration not Vice-Versa .

Kick Buttowski
  • 6,709
  • 13
  • 37
  • 58
Deepu--Java
  • 3,742
  • 3
  • 19
  • 30
8

Well, there is the -target compiler option, which lets you target the class file format of previous java versions. However, this doesn't fix or detect things such as using classes or methods introduced in JDK APIs after the target version.

Nate
  • 16,748
  • 5
  • 45
  • 59
4

No backward compatibility means that Java7 programs will run under Java8 but the reverse is not always true

You may also check Oracle Limit Backward Compatibility

Kerem Baydoğan
  • 10,475
  • 1
  • 43
  • 50
Rahul Tripathi
  • 168,305
  • 31
  • 280
  • 331
3

In general, new versions have to give backwards compatibility, so people dont have to throw their work and can upgrade easily. The other way round (newer version running in older version) is not necesarily true because if you use some new implemented feature, that feature obviously does not exist in the previous version and won't work.

Regards

ctutte
  • 131
  • 5
-1

I generated stubs from WSDL, compiled in java 8 and was able to deploy them on server having java 1.6 jvm on it.

Sandeep Shankar Harikrishnan
  • 27
  • 1