SWT build still requires Java 11

[iloveeclipse]

Nashorn JavaScript Engine was removed in Java 15, see https://openjdk.org/jeps/372

However, SWT build still uses it in ant file:
See

• eclipse.platform.swt/bundles/org.eclipse.swt/buildSWT.xml

  Line 371 in c26d1ff

  <script language="javascript">

• eclipse.platform.swt/bundles/org.eclipse.swt/buildSWT.xml

  Line 385 in c26d1ff

  <script language="javascript">

• eclipse.platform.swt/bundles/org.eclipse.swt/buildSWT.xml

  Line 415 in c26d1ff

  <script language="javascript">

This has to be solved if we want to get rid of Java 11 in SWT.

Once that is done, we also can change Jenkinsfile

Beside supporting ant execution on 11, Jenkinsfile uses different JDK 11 versions also in other places, see this comment.
and following places:

• eclipse.platform.swt/Jenkinsfile

  Line 143 in 04678a2

  def armJDK = '/usr/lib/jvm/java-11-openjdk-arm64'

• eclipse.platform.swt/Jenkinsfile

  Line 146 in 04678a2

  javaHome = '/usr/lib/jvm/java-11-openjdk-11.0.15.0.10-3.el8.ppc64le'

• eclipse.platform.swt/Jenkinsfile

  Line 148 in 04678a2

  javaHome = tool(type:'jdk', name:'temurin-jdk11-latest')

[mickaelistria]

It's possible to use the java task instead; but we need to rework things a bit to avoid dereferencing the project in the code, but instead pass the properties we're willing to process. eg

<project default="blah">
	<target name="blah">
		<property name="tags"><![CDATA[
			a
			b
			c]]></property>
		<echo file="dummyTags.java">
			<![CDATA[
				public class lastTag { public static void main(String... args) {
					var tags = args[args.length - 1].split("\n");
					System.out.println(tags[tags.length - 1].strip());
				}}
			]]>
		</echo>
		<java fork="true" outputproperty="swt_tag" sourcefile="dummyTags.java">
			<arg value="${tags}"/>
		</java>
		<echo>${swt_tag}</echo>
	</target>
</project>

For the more complex one that sets multiple properties at once, the java block could output a key=value dictionary in a property and this property be loaded as properties in a property step.

[HannesWell]

My goal with #513 is to get rid of ANT as far as reasonable possible, which of course also includes to get rid of the java-script scripts in ANT tasks. For example with #613 one stage was already made ANT and javascript free. But it is a larger task I carry out step by step.

This has to be solved if we want to get rid of Java 11 in SWT.

Since these ANT/javascript script scripts are only used to perform the SWT natives build this is not completely correct. As described in #625 (comment) the Build and test stage of the SWT pipeline already uses Java-17 and we could leave the other parts at Java-11 for the moment.

[HannesWell]

I have analyzed in depth from which JDKs the headers are used:

• linux.x86_64: /opt/tools/java/temurin/jdk-11/latest
• linux.aarch64: /usr/lib/jvm/java-11-openjdk/
• linux.ppc64le: /usr/lib/jvm/java-11-openjdk-11.0.15.0.10-3.el8.ppc64le
• macosx.aarch64: /Library/Java/JavaVirtualMachines/temurin-17.jdk
• macosx.x86_64: /Library/Java/JavaVirtualMachines/temurin-19.jdk
• win32.x86_64: C:\Program Files\AdoptOpenJDK\jdk-11.0.11.9-hotspot

The mixture is coming from multiple discrepancies in the SWT-natives builds, which existed in the https://ci.eclipse.org/releng/view/SWT%20Natives jobs.

For Linux it is the expected mixture.

For Windows the environment variable from which the headers are included is name SWT_JAVA_HOME and without it defined the build.bat starts auto-searching.

eclipse.platform.swt/bundles/org.eclipse.swt/Eclipse SWT PI/win32/library/make_win32.mak

Line 41 in 6912a16

AWT_LIBS = "$(SWT_JAVA_HOME)\lib\jawt.lib"

eclipse.platform.swt/bundles/org.eclipse.swt/Eclipse SWT PI/win32/library/make_win32.mak

Lines 53 to 55 in 6912a16

	CFLAGS = -O1 /WX /W4 -DNDEBUG -DUNICODE -D_UNICODE /c $(cflags) $(cvarsmt) $(CFLAGS) \
	-DSWT_VERSION=$(maj_ver)$(min_ver) -DSWT_REVISION=$(rev) $(NATIVE_STATS) -DUSE_ASSEMBLER \
	/I"$(SWT_JAVA_HOME)\include" /I"$(SWT_JAVA_HOME)\include\win32" /I.

For macos is it is more or less hard-coded to use JDK on the system path (as far as I understand the script):

eclipse.platform.swt/bundles/org.eclipse.swt/Eclipse SWT PI/cocoa/library/build.sh

Lines 18 to 22 in 6912a16

	if [ -d /System/Library/Frameworks/JavaVM.framework/Headers ]; then
	export CFLAGS_JAVA_VM="-I /System/Library/Frameworks/JavaVM.framework/Headers"
	else
	export CFLAGS_JAVA_VM="-I $(/usr/libexec/java_home)/include -I $(/usr/libexec/java_home)/include/darwin"
	fi

I downloaded the Java-17 JDKs for all of the mentioned platforms from Adoptium and compared their include folder (the one that contains the headers which are interesting for the SWT natives build. The comparison result was that for Java-17 the header files are equal per OS (linux, win, mac) regardless of the architecture. And the only difference between the OSs is a OS-specific subfolder containing the jni_md.h and jawt_md.h (and for Windows a bridge) with OS-specific content. The headers directly in the include folder are equal for all platforms.

This leads me to the conclusion that we only need one JDK respectively one set of headers per OS.

[laeubi]

I have already prototypes a way that is compatible with PDE/Eclipse + Tycho without the use of ANT but it would require

• Merge swt.binaries repo in the swt one eclipse.platform.swt.binaries#2

So if LFS is too complicated / no progress, one might probably reconsider the submodules as an intermediate solution... as soon as we have a combined repo (using whatever technique) I can try finish my prototype and open a PR... adding JDK headerfiles to the repo seems not a very good solution, even though the visible result of a headerfile should not differ between OS there is no guarantee.

[vogella]

Can this issue be closed? AFAIK SWT now requires Java 17.

[iloveeclipse]

Can this issue be closed?

No, see bug description / comments.

AFAIK SWT now requires Java 17.

That's the point of the issue. We require Java 17 for runtime but still need Java 11 for build!

[HannesWell]

The build of SWT now doesn't use ANT-scripts anymore, only very few executions of the maven-antrun-plugin are left, but those don't require JavaScript and there is ot ANT script left in org.eclipse.swt.
All tasks encoded in the former scripts where either obsolete or have been migrated to Maven, the Jenkins pipeline (which uses Groovy) or to one JEP 330 single source Java script.