Can program developed with Java 8 be run on Java 7?

Question

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?

Kirstiekirstin

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. – Niggardly

I don't understand your second question. Could you clarify that? – Julissa

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 ... – Skiles

yes, i mean if i can use a java 7 server for develop with java 8 or it's imposible? – Kirstiekirstin

I just checked and WildFly 8 runs on Java 8, Tomcat has some issues and doesn't. – Telethermometer

Thanks for your help Karol, i'll try with WildFly. Thanks again :) – Kirstiekirstin

@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. – Julissa

most of them won't -> most of other servers don't – Julissa

possible duplicate of Can Java 8 code be compiled to run on Java 7 jvm? – Candycandyce

What if one does not use any jdk8 features, compile 1.8 and target 1.8. Will it work? – Unifilar

Answer 1

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.

Telethermometer

So, that's means i can't develop jee applications with java 8, because there is no server for it? – Kirstiekirstin

Have you tried running your server on Java 8? Maybe it will work? – Telethermometer

well, a hello world with tomcat8, runs fine. – Kirstiekirstin

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 (and its comments) for details. AFAIK you'd need to use Compiler API to get that. – Julissa

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. – Julissa

@eis: I don't think you can meaningfully simulate annotations on type parameters using Java 7. – Telethermometer

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. – Julissa

@KarolS there has been type annotations in things like checker framework in java 7 already. Do you have any source for your claim that they couldn't be expressed in earlier bytecode? – Julissa

@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. – Telethermometer

Error:java: javacTask: source release 1.8 requires target release 1.8 – Gobang

What if one does not use any jdk8 features, compile 1.8 and target 1.8. Will it work? – Unifilar

Answer 2

Backward compatibility means

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

Cain

Answer 3

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.

Razzia

Answer 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

Cutin

That article's title is misleading. – Octagonal

@skiwi:- Yes but I dont think that the content is misleading too! Also I just copy pasted the title from the article as I thought that this article may help! Am I wrong? – Cutin

What if one does not use any jdk8 features, compile 1.8 and target 1.8. Will it work? – Unifilar

Answer 5

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

Topless

Answer 6

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

Amply