jdt-core-dev

Re: [jdt-core-dev] Compiling against JDK8 but staying compatible with 1.7 bytecode

srikanth_sankaran@xxxxxxx (Srikanth S Adayapalam) — Fri, 17 May 2013 05:36:52 GMT

> From: Tom Schindl 
> 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.

[jdt-core-dev] Welcome Manoj Palat as a new eclipse.jdt.core Committer

portal-noreply@xxxxxxx (portal on behalf of Jayaprakash Arthanareeswaran) — Thu, 16 May 2013 13:35:02 GMT

eclipse.jdt.core Committers,
This automatically generated message marks the completion of all the legal
paperwork and webmaster provisioning for Manoj Palat. Manoj Palat is a new
full Committer on the eclipse.jdt.core project.

Welcome!

[jdt-core-dev] Compiling against JDK8 but staying compatible with 1.7 bytecode

tom.schindl@xxxxxxx (Tom Schindl) — Thu, 16 May 2013 10:29:36 GMT

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.

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

eclipse.preferences.version=1
org.eclipse.jdt.core.compiler.codegen.inlineJsrBytecode=disabled
org.eclipse.jdt.core.compiler.codegen.targetPlatform=1.7
org.eclipse.jdt.core.compiler.codegen.unusedLocal=preserve
org.eclipse.jdt.core.compiler.compliance=1.7
org.eclipse.jdt.core.compiler.debug.lineNumber=generate
org.eclipse.jdt.core.compiler.debug.localVariable=generate
org.eclipse.jdt.core.compiler.debug.sourceFile=generate
org.eclipse.jdt.core.compiler.problem.assertIdentifier=warning
org.eclipse.jdt.core.compiler.problem.enumIdentifier=warning
org.eclipse.jdt.core.compiler.source=1.8


As a test I've created a project which looks like this:

import java.util.AbstractList;
import java.util.Comparator;


public class Test extends AbstractList {
	private String[] internal = {"Hello","World"};

	@Override
	public void sort(Comparator c) {
		// TODO Auto-generated method stub
		
	}

	@Override
	public String get(int index) {
		return internal[index];
	}

	@Override
	public int size() {
		return internal.length;
	}
	
}

import java.util.function.Consumer;


public class Bla {

	public static void main(String[] args) {
		System.err.println("HELLO WORLD");
		Test t = new Test();
//		t.forEach(new Consumer() {
//
//			@Override
//			public void accept(String t) {
//				System.err.println("Value: " + t);
//			}
//		});
		
		for( String s : t ) {
			System.err.println(s);
		}
		
	}

}

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?

From https://bugs.eclipse.org/bugs/show_bug.cgi?id=390889 I somehow have the feeling that this is not supposed to work at all.

Tom

[jdt-core-dev] Committer vote for Manoj Palat has been approved by the PMC

portal-noreply@xxxxxxx (portal on behalf of portal-noreply) — Tue, 14 May 2013 05:49:02 GMT

eclipse.jdt.core Committers,
This automatically generated message marks the PMC's approval of the vote
for Manoj Palat's full Committer status on the eclipse.jdt.core project.
The next step is for the project lead to return to the portal and fill in
the VCS package and employer information for Manoj Palat.

The PMC's comments were: Welcome!

If you have any questions, please do not hesitate to contact your project
lead, PMC member, or the EMO

[jdt-core-dev] Committer vote for Manoj Palat has concluded successfully

portal-noreply@xxxxxxx (portal on behalf of ) — Tue, 14 May 2013 04:01:01 GMT

eclipse.jdt.core Committers,
This automatically generated message marks the successful completion of
voting for Manoj Palat to receive full Committer status on the
eclipse.jdt.core project. The next step is for the PMC to approve this
vote, followed by the EMO processing the paperwork and provisioning the
account.

Vote summary: 6/0/0 with 7 not voting 
  +1  Jayaprakash Arthanareeswaran
   ?  David Audel
   ?  Frederic Fusier
   ?  Walter Harley
  +1  Stephan Herrmann
   ?  Ayushman Jain
   ?  Satyam Kandula
  +1  Markus Keller
   ?  Jerome Lanneluc
  +1  Jesper Moller
   ?  Philippe Mulet
  +1  Srikanth Sankaran
  +1  Olivier Thomann

If you have any questions, please do not hesitate to contact your project
lead, PMC member, or the EMO

[jdt-core-dev] +1 for Manoj Palat on eclipse.jdt.core by Stephan Herrmann

portal-noreply@xxxxxxx (portal on behalf of ) — Tue, 07 May 2013 12:20:02 GMT

Stephan Herrmann voted:
    +1
Welcome!

Voting summary: http://portal.eclipse.org/

[jdt-core-dev] +1 for Manoj Palat on eclipse.jdt.core by Olivier Thomann

portal-noreply@xxxxxxx (portal on behalf of ) — Mon, 06 May 2013 13:01:01 GMT

Olivier Thomann voted:
    +1
Welcome

Voting summary: http://portal.eclipse.org/

[jdt-core-dev] +1 for Manoj Palat on eclipse.jdt.core by Jesper Moller

portal-noreply@xxxxxxx (portal on behalf of ) — Mon, 06 May 2013 10:15:01 GMT

Jesper Moller voted:
    +1
Welcome, Manoj!

Voting summary: http://portal.eclipse.org/

[jdt-core-dev] +1 for Manoj Palat on eclipse.jdt.core by Markus Keller

portal-noreply@xxxxxxx (portal on behalf of ) — Mon, 06 May 2013 10:14:01 GMT

Markus Keller voted:
    +1
+1

Voting summary: http://portal.eclipse.org/

[jdt-core-dev] +1 for Manoj Palat on eclipse.jdt.core by Srikanth Sankaran

portal-noreply@xxxxxxx (portal on behalf of ) — Mon, 06 May 2013 09:15:01 GMT

Srikanth Sankaran voted:
    +1
Welcome Manoj. Thanks for all the
past contributions, look forward to
continued collaboration.

Voting summary: http://portal.eclipse.org/