Re: [jdt-core-dev] Compiling against JDK8 but staying compatible with 1.

[Srikanth S Adayapalam <srikanth_sankaran@xxxxxxxxxx>]

> From: Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>
> Subject: [jdt-core-dev] Compiling against JDK8 but staying

> Hi,
>
> I'm in the position that I have to compile against JDK8 (because of
> libraries contained in there) but the .class file should still be
> useable in Java7.

Our understanding of the overall mix and match scenarios with Java 8
is still evolving and so I doubt that we can already give an
official position on this - When we raised some questions on the
JSR expert groups regarding this topic, we basically heard (paraphrasing)
that it is early and to come back with the questions after a few
months once things have stabilized.

We need some clarification here: Are you saying that the class files
produced would need to executable by both JVM7 and JVM8 ?  In the
former case, how do you propose to get JVM7 to load the classes/APIs
referenced from JDK8 ?

The scenario you describe is a bit different from the one discussed
in the bug you cite: https://bugs.eclipse.org/bugs/show_bug.cgi?id=390889,
which is about Java 7- source projects with build time class path
consisting of JRE8.

> Now I tried put the following settings in a project which runs against
> the BETA_JAVA8 branch.

In general, eclipse requires the compliance and the target class file
to be higher than the source level - The preferences UI expressly forbids
a user from compiling "down" from a certain source level - though there
have
been certain configurations in this category that seem to have enjoyed
official
or at least semi-official blessing in the past.

> And the code runs fine in Java7 and Java8. My question now is does this
> only work by chance, or is it possible to compile to 1.7 bytecode if no
> 1.8 features are used?

We have numerous tests in our test suite that are very close to this
configuration. We take a test, compile it as a 1.3, 1.4, 1.5, 1.6, 1.7
and 1.8 project and run in each case against the same 1.8 JRE to verify
the results. The test suite is also structured to run against previous
JREs in which case we skip the higher levels. Note however that to
accomplish
this in many cases we have had to modify the test (by adding overriding
implementations for default methods) to be able to do that.

Ignoring APIs, purely from a byte code point of view, if you don't use
any Java 8 constructs, you should expect to see the same code stream.
Attributes and such are decided based on the target class file level.
I would think the first order issue to understand is how would these
APIs that constitute the very reason for your move to consider building
against JDK8 be made available in a Java7 execution environment.


Srikanth.