Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 551728

Summary: Move org.eclipse.jdt.junit.runtime to 1.5
Product: [Eclipse Project] JDT Reporter: Noopur Gupta <noopur_gupta>
Component: UIAssignee: Noopur Gupta <noopur_gupta>
Status: VERIFIED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: carsten.hammer, daniel_megert, kalyan_prasad, mistria, stephan.herrmann
Version: 4.14   
Target Milestone: 4.14 M1   
Hardware: All   
OS: All   
See Also: https://git.eclipse.org/r/150531
https://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=f7e47667c0ad152d2844ca09afc3a718d7cdbde4
https://git.eclipse.org/r/150812
https://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=3d68b00d266a50d4026bb367e6f24d83dae76b17
https://git.eclipse.org/r/150868
https://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=28585ef4b76903c191ef9b94e28dbb9c80a2dcc1
https://bugs.eclipse.org/bugs/show_bug.cgi?id=571009
Whiteboard:
Bug Depends on:    
Bug Blocks: 551369, 551990    

Description Noopur Gupta CLA 2019-10-03 04:06:58 EDT 
Move org.eclipse.jdt.junit.runtime to 1.5 for bug 551369.

From bug 551369 comment #20:
> (In reply to Sravan Kumar Lakkimsetti from comment #19)
> > (In reply to Frederic Gurr from comment #7)
> > > You will need to create a custom docker image that runs JDK 1.4. The Jakarta
> > > EE TCK project did that based on a CentOS 7 image, see bug 539086 comment 42.
> > > 
> > > Please contact Anand directly, maybe he can share the Dockerfile.
> > 
> > I would rather prefer updating bree of jdt ui bundles to atleast 1.5. Using
> > custom Image should be last resort in my opinion
> 
> Discussed with Dani. We need to check if moving
> org.eclipse.jdt.junit.runtime to 1.5 from 1.4 will still allow writing and
> running JUnit tests in a 1.4 project. If so, it can be moved to 1.5. Need to
> investigate.
Comment 1 Noopur Gupta CLA 2019-10-03 04:08:16 EDT 
See also bug 551369 comment #34:

(In reply to Stephan Herrmann from comment #34)
> It seems that ship has sailed already: configure a Java project for 1.4, add
> JUnit 3 library, create a test case and observe:
> 
> 
> java.lang.UnsupportedClassVersionError: junit/framework/Test (Unsupported
> major.minor version 49.0)
> 	at java.lang.ClassLoader.defineClass0(Native Method)
> 	...
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.loadTestLoaderClass(RemoteTestRunner.java:380)
> 	...
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:208)
> 
> Probably because JUnit 3 library resolves to
> org.junit_4.12.0.v201504281640/junit.jar. My SDK install does not contain
> org.junit_3.x despite org.eclipse.jdt.junit.runtime being included, which
> declares:
>   Require-Bundle: org.junit;bundle-version="3.8.2"
> 
> Recent Orbit does not contain an org.junit_3.x. 
> 
> Am I missing s.t. and true junit 3 should still be supported somehow, or are
> we beating a dead horse?
Comment 2 Noopur Gupta CLA 2019-10-03 04:33:57 EDT 
Steps that I followed to verify the scenario:

- Moved org.eclipse.jdt.junit.runtime to 1.5 (will be attaching Gerrit patch for that).

- Selected org.eclipse.jdt.junit.runtime > right-click > Export > Deployable plug-ins and fragments > Install into host > Finish.

- Moved org.eclipse.ltk.core.refactoring.tests to 1.4 and deleted all other classes except RefactoringScriptApplicationTests and RefactoringScriptingTests, updated manifest accordingly, etc. to compile it as a simple 1.4 test project.

- Right-click on package org.eclipse.ltk.core.refactoring.tests.scripting > Run  As > JUnit Plug-in Test.

=> It ran successfully as a 1.4 project with JUnit 3 test runner (can be seen in the launch configuration) and should have picked up the updated 1.5 org.eclipse.jdt.junit.runtime bundle from the host or workspace.

So, moving org.eclipse.jdt.junit.runtime to 1.5 looks fine to me. Any concerns?
Comment 3 Eclipse Genie CLA 2019-10-03 04:37:55 EDT 
New Gerrit change created: https://git.eclipse.org/r/150531
Comment 4 Carsten Hammer CLA 2019-10-03 05:26:49 EDT 
What was wrong with https://git.eclipse.org/r/#/c/149960/ ?
Comment 5 Noopur Gupta CLA 2019-10-03 05:42:31 EDT 
(In reply to Carsten Hammer from comment #4)
> What was wrong with https://git.eclipse.org/r/#/c/149960/ ?

I see that it moves org.eclipse.jdt.junit.runtime to 1.8. Did you verify the concern in comment #0 with your change?
Comment 6 Stephan Herrmann CLA 2019-10-03 05:45:01 EDT 
(In reply to Noopur Gupta from comment #2)
> Steps that I followed to verify the scenario:
> 
> - Moved org.eclipse.jdt.junit.runtime to 1.5 (will be attaching Gerrit patch
> for that).
> 
> - Selected org.eclipse.jdt.junit.runtime > right-click > Export > Deployable
> plug-ins and fragments > Install into host > Finish.
> 
> - Moved org.eclipse.ltk.core.refactoring.tests to 1.4 and deleted all other
> classes except RefactoringScriptApplicationTests and
> RefactoringScriptingTests, updated manifest accordingly, etc. to compile it
> as a simple 1.4 test project.
> 
> - Right-click on package org.eclipse.ltk.core.refactoring.tests.scripting >
> Run  As > JUnit Plug-in Test.
> 
> => It ran successfully as a 1.4 project with JUnit 3 test runner (can be
> seen in the launch configuration) and should have picked up the updated 1.5
> org.eclipse.jdt.junit.runtime bundle from the host or workspace.
> 
> So, moving org.eclipse.jdt.junit.runtime to 1.5 looks fine to me. Any
> concerns?

Did you use a 1.4 JRE for launching the test?

Which version of org.junit was used for your launch?

In my tests, using a 1.4 JRE was not possible, but maybe this isn't really the goal here?

*If* we want to support running *on 1.4* I suggest trying to switch only BREE to 1.5 but keeping compiler settings at 1.4, it will give a warning, but ensure that compiled classfiles can be loaded on a 1.4 JRE.
Comment 7 Carsten Hammer CLA 2019-10-03 05:56:41 EDT 
(In reply to Noopur Gupta from comment #5)
> (In reply to Carsten Hammer from comment #4)
> > What was wrong with https://git.eclipse.org/r/#/c/149960/ ?
> 
> I see that it moves org.eclipse.jdt.junit.runtime to 1.8. Did you verify the
> concern in comment #0 with your change?

I don‘t understand that argument. You can leave support for java versions that are behind eol to former eclipse releases. Imho it is a pointless effort to spend time on this for the next evlipse release.
Comment 8 Noopur Gupta CLA 2019-10-03 07:11:46 EDT 
(In reply to Stephan Herrmann from comment #6)
> Did you use a 1.4 JRE for launching the test?
No, it used JRE 11 to launch.

> Which version of org.junit was used for your launch?
It used JUnit 3 runner and the bundle for that would be org.junit 4.12.0.v201504281640 (which itself is at 1.5).

Here's the output of the show command line button:

C:\Program Files\AdoptOpenJDK\jdk-11.0.4.11-openj9\bin\javaw.exe -ea -Declipse.pde.launch=true "-Declipse.p2.data.area=@config.dir\p2" --add-modules=ALL-SYSTEM -Dfile.encoding=UTF-8 -classpath "C:\Eclipse\Builds\eclipse-SDK-I20190919-1800-j13-ju\eclipse\plugins\org.eclipse.equinox.launcher_1.5.500.v20190715-1310.jar" org.eclipse.equinox.launcher.Main -os win32 -ws win32 -arch x86_64 -nl en_IN -consoleLog -version 3 -port 57953 -testLoaderClass org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestLoader -loaderpluginname org.eclipse.jdt.junit.runtime -testNameFile "C:\Users\NOOPUR~1\AppData\Local\Temp\testNames1354234759362558126.txt" -application org.eclipse.pde.junit.runtime.uitestapplication -product org.eclipse.sdk.ide -data "C:\Eclipse\Builds\eclipse-SDK-I20190919-1800-j13-ju\eclipse\ws/../junit-workspace" -configuration file:C:/Eclipse/Builds/eclipse-SDK-I20190919-1800-j13-ju/eclipse/ws/.metadata/.plugins/org.eclipse.pde.core/pde-junit/ -dev file:C:/Eclipse/Builds/eclipse-SDK-I20190919-1800-j13-ju/eclipse/ws/.metadata/.plugins/org.eclipse.pde.core/pde-junit/dev.properties -os win32 -ws win32 -arch x86_64 -nl en_IN -consoleLog -testpluginname org.eclipse.ltk.core.refactoring.tests

> In my tests, using a 1.4 JRE was not possible, but maybe this isn't really
> the goal here?
> 
> *If* we want to support running *on 1.4* I suggest trying to switch only
> BREE to 1.5 but keeping compiler settings at 1.4, it will give a warning,
> but ensure that compiled classfiles can be loaded on a 1.4 JRE.

The goal here is to check if org.eclipse.jdt.junit.runtime can be moved to 1.5 and still be used to write and run JUnit tests in a 1.4 project. So, I don't think keeping compiler settings at 1.4 is required.
Comment 9 Noopur Gupta CLA 2019-10-03 07:23:55 EDT 
(In reply to Noopur Gupta from comment #8)
> It used JUnit 3 runner and the bundle for that would be org.junit
> 4.12.0.v201504281640 (which itself is at 1.5).

Considering that org.junit 4.12 itself is at 1.5, looking at Stephan's and my experiment results, and considering comment #7, I think it's OK to move org.eclipse.jdt.junit.runtime to 1.5 at least.

Dani, do you have any other concerns that we should check before moving it to 1.5?
Comment 10 Stephan Herrmann CLA 2019-10-03 07:42:56 EDT 
(In reply to Noopur Gupta from comment #8)
> (In reply to Stephan Herrmann from comment #6)
> > In my tests, using a 1.4 JRE was not possible, but maybe this isn't really
> > the goal here?
> > 
> > *If* we want to support running *on 1.4* I suggest trying to switch only
> > BREE to 1.5 but keeping compiler settings at 1.4, it will give a warning,
> > but ensure that compiled classfiles can be loaded on a 1.4 JRE.
> 
> The goal here is to check if org.eclipse.jdt.junit.runtime can be moved to
> 1.5 and still be used to write and run JUnit tests in a 1.4 project. So, I
> don't think keeping compiler settings at 1.4 is required.

My question still is: what is meant by "run JUnit tests in a 1.4 project"? Is it only about compilation against 1.4 or about running on 1.4?

Seeing org.junit_3.x missing from Orbit is a sign for EOL for running on 1.4, right? In that light trying to keep classfile version at 1.4 is moot, indeed.
Comment 11 Carsten Hammer CLA 2019-10-03 08:13:09 EDT 
Maybe you can think about two other gerrits at the same time:

https://git.eclipse.org/r/#/c/149959/
https://git.eclipse.org/r/#/c/149961/

Given that these automatic tests have a responsibility to make sure that compatibility against supported java releases is given the status of these tests currently is the same as tests regarding upcoming but not yet released java versions - nice to have - but not needed. The question is if there are tests that make sure the compatibility with the supported java releases is given or if the eclipse sourcetree is blind on this eye because parts of the code are still working on old java versions.
Comment 12 Carsten Hammer CLA 2019-10-03 09:06:51 EDT 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=548309#c27
Here a change that removed support for java 1.5 in the jar in jar loader so that only java 16+ is supported.
Maybe a strategy to align supported java versions in the newest eclipse version to only the collection of already released and not yet eol java versions is missing?? It would be great to see matrix of officially supported java versions somewhere in the eclipse documentation. Maybe it is already there and somebody can give me a pointer?
Comment 13 Noopur Gupta CLA 2019-10-07 07:44:20 EDT 
(In reply to Eclipse Genie from comment #3)
> New Gerrit change created: https://git.eclipse.org/r/150531
I'll release it for M1 to get more time in 4.14 to make any changes if required.
Comment 16 Eclipse Genie CLA 2019-10-09 01:04:09 EDT 
New Gerrit change created: https://git.eclipse.org/r/150812
Comment 18 Noopur Gupta CLA 2019-10-09 02:44:28 EDT 
(In reply to Dani Megert from comment #15)
> (In reply to Eclipse Genie from comment #14)
> > Gerrit change https://git.eclipse.org/r/150531 was merged to [master].
> > Commit:
> > http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=f7e47667c0ad152d2844ca09afc3a718d7cdbde4
> > 
> This causes 70 warnings in our official build:
> https://download.eclipse.org/eclipse/downloads/drops4/I20191007-1800/compilelogs/plugins/org.eclipse.jdt.junit.runtime_3.5.0.v20191007-1131/@dot.html

The above Gerrit patch fixes the warnings.
Comment 19 Noopur Gupta CLA 2019-10-09 06:35:23 EDT 
https://download.eclipse.org/eclipse/downloads/drops4/I20191009-0300/testResults.php

doesn't have the warnings.
Comment 20 Noopur Gupta CLA 2019-10-10 01:17:32 EDT 
Verified in I20191009-0300.
Comment 21 Eclipse Genie CLA 2019-10-10 02:00:49 EDT 
New Gerrit change created: https://git.eclipse.org/r/150868
Comment 23 Mickael Istria CLA 2020-11-13 05:22:55 EST 
For the record and for future similar case, here are some additional ideas:
This issue could probably have been fixed by setting https://www.eclipse.org/tycho/sitedocs/tycho-compiler-plugin/compile-mojo.html#useJDK to "SYSTEM" for the concerned bundles (override the useJDK=BREE setting from parent pom). With that, Tycho would just pick the current Java 11 to build to Java 1.4 or whatever.
Also, what matters here is not really the BREE, but the version of the .class files. That can be controlled independently of BREE setting, via the typical compiler setting files, and also in the build.properties setting the javac.source/javac.target properties, and also in the pom.xml by setting the other customization options offered by tycho-compiler-plugin.