Move to Java 8

[eclipse-qvt-oml-bot]

| --- | --- |
| Bugzilla Link | 424052 |
| Status | RESOLVED FIXED |
| Importance | P3 normal |
| Reported | Dec 14, 2013 09:42 EDT |
| Modified | Jul 30, 2024 12:11 EDT |
| See also | 583248 |
| Reporter | Sergey Boyko |

Description

For Luna M2 the Equinox framework switched to Java 1.6 as BREE (and compiled using Java 6), e.g. the plugin org.eclipse.osgi.
Equinox core announcement:
http://wiki.eclipse.org/Equinox/Luna_Framework#Requirement_on_Java_6\
Equinox tracking bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=416432

Eclipse platform starting from version 4.3 is targeted JDK 1.6 (http://www.eclipse.org/projects/project-plan.php?projectid=eclipse#target_environments).

QVTo Hudson build configuration for Luna stream utilizes JDK 1.6 for builds.

As consequence:

• it's not correct to claim compatibility with JDK version which is not used for building/testing
• Java 6 provides some language improvements (like @OverRide annotation) that makes sense to utilize

Migration process should be done for each plug-in separately. Also generification warnings should be fixed during migration.

[eclipse-qvt-oml-bot]

By Adolfo Sanchez-Barbudo Herrera on Aug 07, 2014 12:29

Hi Sergey,

If we are compiling with java 1.6, what you propose makes sense to me.

For your information, I've pushed to master the increment to my experimental (non built) plugins:

org.eclipse.qvto.examples.pivot.
org.eclipse.qvto.examples.xtext.

Cheers,
Adolfo.

[eclipse-qvt-oml-bot]

By Ed Willink on Jun 12, 2024 09:31

ECJ support for Java < 8 is being terminated: see eclipse-jdt/eclipse.jdt.core#2536

EMF is being updated: eclipse-emf/org.eclipse.emf@932bf62

Any ongoing reference to Java < 8 is therefore likely to cause build fails (or fails for generated code tests).

[eclipse-qvt-oml-bot]

By Ed Willink on Jun 16, 2024 03:34

(In reply to Ed Willink from comment #2)

Any ongoing reference to Java < 8 is therefore likely to cause build fails
(or fails for generated code tests).

OCL (see Bug 416470) is trying to move to Java 8 which uncovers an unsupported idiom for OCL.newInstance. A minor binary and source incompatibility seems unavoidable. And consequently today's qvto master build fails with:

[ERROR] https://ci.eclipse.org/qvt-oml/job/qvto-master/ws/plugins/org.eclipse.m2m.qvt.oml.ocl/src/org/eclipse/m2m/internal/qvt/oml/ocl/transformations/QvtLibraryOperation.java:[101]
[ERROR] OCL ocl = OCL.newInstance(env);
[ERROR] ^^^^^^^^^^^^^^^^^^^^
[ERROR] Type mismatch: cannot convert from OCL<EPackage,EClassifier,EOperation,EStructuralFeature,EEnumLiteral,EParameter,EObject,CallOperationAction,SendSignalAction,Constraint,EClass,EObject> to OCL
[ERROR] 1 problem (1 error)

since org.eclipse.ocl.ecore.OCL.newInstance has been removed on master to avoid the clash with org.eclipse.ocl.OCL.newInstance that has a less refined return type.

It looks as if OCL classic will need a major version change to publish the binary breakage.

[eclipse-qvt-oml-bot]

By Ed Willink on Jun 18, 2024 05:17

(In reply to Ed Willink from comment #3)

It looks as if OCL classic will need a major version change to publish the
binary breakage.

The OCL breakage is confined to an abstract class so that QVTo does not see a source or binary change. But OCL has a major version change so for QVTo there is a choice affecting two plugins.

a) Major version change
b) API filter of the re-exported major version change
c) API filter of the no longer re-exported OCL

Removal of exports has caused me releng pain over the years so it appears to be permissible to drop them despite the source API breakage, so let's remove the OCL re-exports and review all re-exports. I suspect that emf.ecore from the QVTo models is the only really 'necessary' one courtesy-wise.

[eclipse-qvt-oml-bot]

By Ed Willink on Jun 18, 2024 11:39

OCL has chosen to remove the four 'abstract' static methods without a gratuitous/pedantic major version change. QVTo is therefore unaffected by OCL's migration.

[eclipse-qvt-oml-bot]

By Ed Willink on Jun 19, 2024 03:59

For QVTo there is a design dilemma since half the plugins are new/UI-related and so already BREE 8; no version change needed.

The old non-UI plugins must have a minor, typically +0.1.0, version change to 3.11.0. However the many on-demand +0.0.1 maintenance fixes leave something of a mess version-wise. It would be tidy to move all regular plugins and features to 3.11.0. It would also be tidy to move the 1.x and 2.x plugins to x.11.0 too.

Comments?

[eclipse-qvt-oml-bot]

By Ed Willink on Jun 19, 2024 05:36

branch ewillink/424052 has one commit for the x.11.0 version numbers and another for BREE 8.

Moving to BREE 8 is seemingly straightforward except that a search for J2SE-1.5 reveals some version-specific code in JdtProjectIntegrationImpl.java that handles Java 2 and 3 with 5 as default. I've just changed to Java 8 as default, but a review of sub version 8 functionality could be appropriate.

[eclipse-qvt-oml-bot]

By Ed Willink on Jul 28, 2024 07:38

(In reply to Ed Willink from comment #7)

a search for J2SE-1.5 reveals some version-specific code

Bug 583503 is triggered by a further platform evolution so that compling with Jav 1.5 now bombs with a syserr message, Need to use JavaCore.VERSION_1_8 when compiling and sensibly when validating names too.

Available on branch ewillink/583503 that builds on Jenkins ok. OOMPH / manual config issues remain.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Jul 30, 2024 11:05

(In reply to Ed Willink from comment #6)

It would be tidy to move all regular plugins and features to 3.11.0. It would
also be tidy to move the 1.x and 2.x plugins to x.11.0 too.

Comments?

I can only endorse these suggestions. As a minor side effect, it would also indicate to some critics that Eclipse QVTo is still alive (at least releng-wise).

(In reply to Ed Willink from comment #7)

Moving to BREE 8 is seemingly straightforward except that a search for
J2SE-1.5 reveals some version-specific code in
JdtProjectIntegrationImpl.java that handles Java 2 and 3 with 5 as default.

The version-specific code refers to the "JavaSE-1.5" and "1.5" constants, right?

I've just changed to Java 8 as default, but a review of sub version 8
functionality could be appropriate.

Changing the constants to "1.8" is very reasonable. But it's not so clear to me whether the references to JavaCore.VERSION_1_3 should also be adjusted?

Unrelated, but I think we could get rid of the deprecation by invoking JavaConventions.validateJavaTypeName(name.trim(), JavaCore.VERSION_1_x, JavaCore.VERSION_1_x, null) with a trailing null argument.

[eclipse-qvt-oml-bot]

By Ed Willink on Jul 30, 2024 11:21

(In reply to Christopher Gerking from comment #9)

I can only endorse these suggestions.

Thanks.

Unrelated, but I think we could get rid of the deprecation by invoking
JavaConventions.validateJavaTypeName(name.trim(), JavaCore.VERSION_1_x,
JavaCore.VERSION_1_x, null) with a trailing null argument.

Will investigate once I get past the nightmare that 96818797af8c91732ab33c81420d6bac8be7cc0b fails today but built ok two days ago.

[eclipse-qvt-oml-bot]

By Ed Willink on Jul 30, 2024 11:39

(In reply to Ed Willink from comment #10)

Will investigate once I get past the nightmare that
96818797af8c91732ab33c81420d6bac8be7cc0b fails today but built ok two days
ago.

Now it works. Maybe all part of the Bug 583248 troubles.

But it's not so clear to
me whether the references to JavaCore.VERSION_1_3 should also be adjusted?

I wasn't sure, but I think a difference arises if a user name spelling is valid for Java 1.3 but invalid for Java 8 (e.g a new reserved word). Since Eclipse is now Java 8 minimum we should reject a spelling that is bad for Java 8 and likely to cause an obscure error if we accept it.

Unrelated, but I think we could get rid of the deprecation by invoking
JavaConventions.validateJavaTypeName(name.trim(), JavaCore.VERSION_1_x,
JavaCore.VERSION_1_x, null) with a trailing null argument.

Definitely.

[eclipse-qvt-oml-bot]

By Ed Willink on Jul 30, 2024 12:11

Pushed to master for 3.11.0M2.