[project] Move to Java 6 #1189
Comments
|
By Ed Willink on Sep 06, 2013 07:35 (In reply to Ed Willink from comment #0)
The benefit of changing is that we reduce the number of problems that arise when a Java 5 JVM appears to be ok but turns out to be inadequate. Unfortunately Java 6/7 problems could start to arise in due course. The downside of changing is that we have to fix about 250 @OverRide warnings per plugin that is converted. (And we break any Java 5 users,) For the new pivot code that makes extensive of Xtext, Guava etc, eliminating the 5/6 hazards is helpful. For the classic code, it will work fine on 5, provided an old OSGI is in use. But as soon as an error message happens a crash will occur on Luna. Is it really helpful to allow these users to even start on Java 5. Since everything depends on ocl.common, I propose to move ocl.common to BREE 6 as a statement that the OCL project requires 6. Other plugins can stay at BREE 5 until there is some motivation to move them and fix the @OverRide warnings that result. The pivot plugins may gradually move; the classic will probably stay. |
|
By Ed Willink on Sep 06, 2013 08:45 Need to change test launches / test projects to get them to pass; might as well change the projects. |
|
By Ed Willink on Dec 03, 2013 06:13 The org.eclipse.ocl.examples.codegen.dynamic project exists solely to uisolate the Java 6 functionality from org.eclipse.ocl.examples.codegen and the rest that was Java 5. However org.eclipse.emf.codegen.ecore uses org.eclipse.text that uses org.eclipse.osgi that has moved to Java 6, so CG is necessarily Java 6 anyway. Move org.eclipse.ocl.examples.codegen to Java 6 and absorb/deprecate org.eclipse.ocl.examples.codegen.dynamic. commit 8f22b02 Pushed to master for M4. |
|
By Ed Willink on Jan 11, 2018 10:58 4 years on and we now have Java 8 / 9 considerations and EMF standalone is still Java 5. A quick verification demonstrates that so long as no use of IResource or IStatus is made an all Java 5 EMF application really works. (Only trivial problem is that BasicDiagnostic.toDiagnostic seems to have a parasitic IStatus depemdency.) EMF achieves this my making org.eclipse.core.* optional and by careful CNFE catching for EMFPlugin.IS_ECLIPSE_RUNNING. The corresponding org.eclipse.core.* dependencies for Classic OCL are not optional requiring their redundant existence on the classpath. Simple fix. UI and Xtext plugins are inevitably tracking the platform, so now at BREE 8. Once we have LPG parsers, the basic pivot plugin might offer a much lower level of purely standalone funtionality, but perhaps without Guava. |
|
By Ed Willink on Jun 12, 2024 10:06 6 years on: ECJ support for Java < 8 is being terminated: see EMF is being updated: Any ongoing reference to Java < 8 is therefore likely to cause build/generate fails. |
|
By Ed Willink on Jun 15, 2024 11:38 As noted in https://bugs.eclipse.org/bugs/show_bug.cgi?id=583338#c1 we do not need to move until there is a Tycho that requires the new ECJ. Ouch! Java 8 does not support the ecore/uml overload of abstract ocl for static specialised methods. e.g. The abstract org.eclipse.ocl.util.ToStringVisitor<C, O, P, EL, PM, S, COA, SSA, CT>. is 'overridden' by org.eclipse.ocl.ecore.utilities.ToStringVisitor. Unfortunately there is no org.eclipse.ocl.uml.utilities.ToStringVisitor that might allow a rename of the abstract static. Ditto OCL.newInstance. |
|
By Ed Willink on Jun 16, 2024 03:49 Using the Tycho build we get strange failures on @OverRide of interfaces. Wierd. Ah! yet another obsolete build practice. Some build.properties had javacSource = 1.5 eliminated and then we're ok after disambiguating newInstance/getInstance. But the disambiguation is not sound. For binary compatibility we must continue to provide both static T1.f(?) and T2.f(?) since existing code 'knows', via compile time decision, which to call. But providing both is not legal under Java 8 as a consequence of over-zealous application of the no same erasure for non-static methods to static methods too. We don't need 100% source compatibility since re-builders can edit provided we ensure a clear compilation error message. We can probably achieve some source compatibility by eliminating the derived T2.f() and recoding the base T1.f(?) to test its argument for Ecore/UML/abstract-or-other argument. But the return type cannot be derived so it will be a compilation error anyway. Choice: a) delete T2.f(?) and keep T1.f(?) - Ecore/UML functionality can be preserved by instanceof checks but return type is wrong. A third party derivation is broken. b) delete T1.f(?) and keep T2.f(?) - Ecore/UML functionality is probably ok for newInstance since the derived T2 is imported, but not for getInstnace for which there is no derived ToStringVisitor. A UML ToStringVisitor can be added but needs an import even if no one is probably using it. c) delete both T1.f(?) and T2.f(?) forcing recoding to use fEcore(?) or fUML(?) or ... c) is guaranteed source and binary breakage for everyone a) is probable source breakage on a return type and probably binary breakage on the deleted signature b) is probably ok source-wise except for UML ToStringVisitor users, probably ok binary since the base T1::f(?) might not be used. Finger trouble meant that a) was accidentally pushed to master and so the qvto build failed. Clearly a binary breakage is unavoidable so a major version change is required. b) is probably best for source compatibility. |
|
By Ed Willink on Jun 17, 2024 03:35 (In reply to Ed Willink from comment #7)
This was first considered as part of Bug 464193 but deferred since avoiding pack200 for a couple of plugins was preferable.
Actually the same obsolete build practice discovered in Bug 464193 but the elimination never happened. Eliminating now seems good, but the compatibility builds fail at 2023-03 and earlier that run on JDK 11. 2023-06 and later that run on JDK 17 are ok. The problem is an almost universal java.lang.NoClassDefFoundError: java/lang/constant/Constable Googling suggests that this occurs for a JDK 11 run of a JDK 12 build. We certainly fail on a JDK 11 run with an unsatisfied java.lang.constant.Constable. But we were trying to do a Java 8 build so clearly we didn't. |
|
By Ed Willink on Jun 17, 2024 05:54 (In reply to Ed Willink from comment #8)
The class file seem to be Java 1.8 version 52 ok. Sampling a few class files there is no obvious reference to Constable. As ok Java 12 String and Class and ... implement Constable so its in any code. Googling finds: "I suspect that you have made a mistake in building your code. Maybe you compiled with a Java 12+ tool chain, against the Java SE 12+ runtime using a target version of Java 11?" Yes the master build uses Java 17.0.2 for Maven 3.6.3 All master compiles seem to have [INFO] --- maven-toolchains-plugin:1.1:toolchain (default) @ org.eclipse.ocl.uml --- THe compatibility test build uses Java 17.0.2 for Maven 3.9.5 [INFO] --- toolchains:1.1:toolchain (default) @ org.eclipse.ocl.compatibility.tests --- No idea what the WARNING means, but we do have a dependency issue. |
|
By Ed Willink on Jun 17, 2024 06:34 If it is the masteer build that 'uses' Conbstable we have a problem. If it is only compatibility test harness we onl,y have a test problem. Attempting to create a JUnit test that uses the built OCL plugins as internal libraries something similar happens, but it is hard to set a breakpoint to examine jjava.lang.NoClassDefFoundError: java/lang/constant/Constable So the code clearly gets going and some printf shows: java.version: 1.8.0_371 So if we can get going run some extra test to prtinbt out the calsspath, it cannot be the test harness, it must be one of the above classpath entries that requires Constable. |
|
By Ed Willink on Jun 17, 2024 07:33 (In reply to Ed Willink from comment #7)
An optimistic change to 1.8 doesn't help. |
|
By Ed Willink on Jun 17, 2024 10:07 (In reply to Ed Willink from comment #10)
Adding code to mimic AbstractBasicEnvironment.java:124 creating a local clone of AbstractProblemHandler and we're ok. Examining AbstractProblemHandler.class and there it is: // Compiled from AbstractProblemHandler.java (version 1.8 : 52.0, super bit) in the 4th Stack map table entry. This confirms a not-really-Java-8 build. |
|
By Ed Willink on Jun 17, 2024 11:29 (In reply to Ed Willink from comment #12)
Corresponding local TYcho build in my workspace does niot have this in the class file. [INFO] [1m--- [0;32mtoolchains:1.1:toolchain[m [1m(default)[m @ [36morg.eclipse.ocl[0;1m ---[m is ok but [INFO] --- maven-toolchains-plugin:1.1:toolchain (default) @ org.eclipse.ocl.uml --- is not. Using an ls we get latest -> 11.0.2+9 the OPenJDK page lists a 11.0.23+9 so clearly latest is not anything like latest. https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/4735 raised. |
|
By Ed Willink on Jun 18, 2024 01:02 (In reply to Ed Willink from comment #13)
In the meantime search for a JDK that works on Jenkins. While searchjing convenient to disable toolchains so that only one java in use with good version id. openjdk-jdk17-latest: openjdk-jdk21-latest: temurin-jdk17-latest: semeru-jdk17-latest: (In reply to Ed Willink from comment #13)
oops. No. Mistake looking at the wrong class file. Problem is bad locally too. Cleary a solid compiler bug that arises when a Java >= 12 flow analysis identifies Constable (rather than Comparable for Java <= 11) as the statically known type of a local variable and emits that in the Stack map table frame. The Java class writer should have promoted the Constable reference to its super type. Solutions: |
|
By Ed Willink on Jun 18, 2024 07:59 (In reply to Ed Willink from comment #14)
This should be sound, but presumably means a custom rather than autogenerated pom.xml for each plugin.
This could be unsound since we have to fix all instances without an easy way to detect them lacking 100% coverage testing. However the problem is obviously very rare and seemingly triggered by perhaps distinctive ?: constructs to initilaize a new Object[]. So let's start by trying to adjust the code. Problem seems to be a ?: unifying a String and Enum as not-null Constable. Refactoring to extract explicitly String locals and the unification is trivialized. Compatibility tests now pass. Pushed to master for 2024-09. |
|
By Ed Willink on Jun 18, 2024 08:28 Final major version consideration. The major version has been pushed to master and announced on cross-project-dev but has yet to be contributed as an M0 for SimRel. Pedantically, the rules say we must have a major version change, but the rules don't count for much these days; the platform should have a major version change almost every quarter. e.g. the signature removals that break CVS. The breakage is removal (spelling change) of three org.eclipse.ocl.OCL.newInstance signatures and one org.eclipse.ocl.util.ToStringVisitor.getInstance signature. Sane Ecore-based code should call the Ecore derivations and so should be unaffected by vanishing abstract variants. QVTo code is unaffected. Similarly, UML-based code should call the UML derivations for newInstance, but there is no getInstance derivation. ToStringVisitor.getInstance is a debug aid unlikely to be used prior to failure diagnosis. Are there any UML-based consumers? certainly not Papyrus. It is therefore very unlikely that any users are actually broken by the change, so the pedantically correct major version change is a minor inconvenience to all users without actually helping any. The minor invenience can actually be a blocker for the user of a third party product that exploits Eclipse OCL. If the third party product is mature, an update to accommodate the pedantic major OCL version change may not be forthcoming. The end user may be forced to either live in the past forever or abandon the Eclipse OCL-based functionality. With a major version change, all consumers find out at compile-time and resolve the minor inconvenience. Users may discover at run-time with at least a class not found and may be a bad version diagnostic. Without the major version change consumers are only aware if there is a source breakage which is easily fixed. Users may again discover at run-time with a class not found diagnostic. A small number of affected users are similarly broken either way. The large number of unaffected users are gratuitously broken by a pedantic major version change. Conclusion: the major version change is not justified. |
|
By Ed Willink on Jun 19, 2024 03:49 Migration to Java 8 pushed to master with major version change reverted. JustJ seems to try to keep the highest version and there was a network fail while the promoter ran leaving the nightly repos in a mess. Fortunately nightlies can be deleted in their entirety. |
| --- | --- |
| Bugzilla Link | 416470 |
| Status | RESOLVED FIXED |
| Importance | P3 normal |
| Reported | Sep 03, 2013 15:48 EDT |
| Modified | Jun 19, 2024 03:49 EDT |
| See also | 464193 |
| Reporter | Ed Willink |
Description
Guava moving to Java 6 was awkward.
Now OSGI (which we use for NLS) is Java 6 so half the classic tests fail on a Java 5 VM.
"The platform has required Java 6 since Helios" !
The Modeling EPP requires Java 6.
I see no point in making any eefort to retain any illusion of Java 5 compatibility.
We could retain Java 5 for the classic runtime JAR, but users wanting Java 5 probably don't want the new Luna release anyway, so why struggle.
Change all BREEs to 6.
The text was updated successfully, but these errors were encountered: