JDK-8075327 : Merge jdk and hotspot test libraries
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: test
  • Affected Version: 9,10
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-03-17
  • Updated: 2024-09-12
  • Resolved: 2018-10-02
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 12
12Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Sub Tasks
JDK-8098823 :  
JDK-8098824 :  
JDK-8098825 :  
JDK-8098827 :  
JDK-8180195 :  
JDK-8180386 :  
JDK-8180391 :  
JDK-8180395 :  
JDK-8180397 :  
JDK-8180399 :  
JDK-8180621 :  
JDK-8180644 :  
JDK-8180724 :  
JDK-8180793 :  
JDK-8180802 :  
JDK-8180805 :  
JDK-8180887 :  
JDK-8180888 :  
JDK-8180890 :  
JDK-8180898 :  
JDK-8181118 :  
JDK-8181335 :  
JDK-8182154 :  
JDK-8182404 :  
JDK-8182565 :  
JDK-8186548 :  
JDK-8186613 :  
JDK-8210022 :  
JDK-8210039 :  
JDK-8210112 :  
JDK-8210732 :  
JDK-8210894 :  
JDK-8211171 :  
Description
Currently there are test libraries both in hotspot and in jdk, which provide the same functionality. This approach has the expected drawbacks with code duplication, there are now differences in them and there is a maintenance cost associated with it. To improve this, the hotspot and jdk test libraries should be merged and moved to top-level repository. 

This does not mean that all test libraries shall go into top repo, there can still be repo local and test folder local test libraries. The idea is to give a home for the test libraries that make sense to share. 

The best thing is if this new common location has the same layout as other things, lets use the java.base as an example. There is an addition however - it should also include the test folder for the test library tests. 


Here are some examples of the suggested folder structure, basically making the test library a project of its own.
  <jdk9 root>/test/lib/share/classes/  (package root) 
  <jdk9 root>/test/lib/share/conf/
  <jdk9 root>/test/lib/share/native/ 

  <jdk9 root>/test/lib-test    // <test src root, same layout as lib, but without native redirection> 


Package jdk.test.lib is the main package for all test libraries. Few things go at top level, but some will.

Package jdk.test.lib.processtools is the package for utilities for launching processes and analyzing the output.
  <jdk9 root>/test/lib/share/classes/jdk/test/lib/processtools/OutputAnalyzer.java
  <jdk9 root>/test/lib/share/classes/jdk/test/lib/processtools/OutputBuffer.java
  <jdk9 root>/test/lib/share/classes/jdk/test/lib/processtools/ProcessTools.java
  <jdk9 root>/test/lib/share/classes/jdk/test/lib/processtools/StreamPumper.java
  <jdk9 root>/test/lib/share/classes/jdk/test/lib/processtools/JDKToolFinder.java
  <jdk9 root>/test/lib/share/classes/jdk/test/lib/processtools/JDKToolLauncher.java

  <jdk9 root>/test/lib-test/jdk/test/lib/processtools/OutputAnalyzerTest.java 


Asserts can stay at top level. 
  <jdk9 root>/test/lib/share/classes/jdk/test/lib/Asserts.java
  <jdk9 root>/test/lib-test/jdk/test/lib/AssertsTest.java 


For VM specific info, it would have vm package. Note that the whitebox API moves here.
  <jdk9 root>/test/lib/share/classes/jdk/test/lib/vm/InputArguments.java
  <jdk9 root>/test/lib/share/classes/jdk/test/lib/vm/Platform.java


Ok, so then there are the stuff which just is a bucket of stuff and fluff.
A later exercise could be to break this class into better named and placed classes, but this is a start:
  <jdk9 root>/test/lib/share/classes/jdk/test/lib/misc/Utils.java
Comments
fixed: the test libraries have been merged, remaining JDK and JAXP test library classes aren't part of common test library and are to be handled by JDK-8211290.
02-10-2018

hotspot/test/testlibrary_tests/whitebox should be moved to /test/lib-test as well.
22-08-2017

hotspot/test/testlibrary_tests/*Test.java and jdk/test/lib/testlibrary/*Test.java should be merged and moved to /test/lib-test/. /test/lib-test should be maden a real test suite and added into regular test execution.
22-08-2017

ModuleUtils is used by several core-libs tests: java/lang/module/AutomaticModulesTest.java java/lang/module/ConfigurationTest.java java/lang/ModuleLayer/BasicLayerTest.java java/lang/ModuleLayer/LayerAndLoadersTest.java java/lang/ModuleLayer/LayerControllerTest.java it doesn't seem reasonable to move this library class to the top-level library, and it might make sense to move it closer to the tests which use it.
22-08-2017

jdk/test/lib/testlibrary/java/util/jar is specific for a few core-libs tests and shouldn't be moved to the top-level library.
22-08-2017

jdk.testlibrary.OutputBuffer, OutputAnalyzer, StreamPumper and ProcessTools is another group of coupled classes which have to be moved/replaced together.
21-08-2017

jdk.testlibrary.ProcessThread, TestThread and XRun classes are coupled together and have to be moved together.
21-08-2017

jdk.testlibrary.OSInfo seems to duplicate functionality of jdk.test.lib.Platform, this clean up should be done as a separate task
21-08-2017

jdk.testlibrary.OptimalCapacity does not look very generic to be in top level testlibrary, and most probably should be left in jdk/test
21-08-2017

JDK-8157957 moved hotspot testlibrary to top level, but we still have 3 test libraries: <top>, jdk, jaxp. there is significant difference b/w jdk and <top> libraries, so <top> library (as it today) is not really suitable for jdk people. the libraries should be cleaned up and merged.
05-05-2017

FC Extension Request Justification: unification, removing code duplication which makes it hard to understand code, having it done in JDK 9 will simplify backporting. Risk: very low, test only changes Remaining work: merge jdk and hotspot testlibaries, update hotspot tests Due date: Aug 1st
15-06-2016

Will this require further changes to the tests using the testlibrary - to modify @build or @library statements?
29-04-2015

Yes, the changes will be required because the shared files are moved to the hs-rt/test/ directory, so this directory will have to be present in @library statements, if it is not there. I'm not sure why share/classes directory is necessary in the hs-rt/test/lib/share/classes. Doing so we will have to have both @library test/lib and @library test/lib/share/classes which can be confusing. It seems simpler to create the jdk.test.lib package directly in the hs-rt/test/lib directory. This way the existing @library test/lib will remain valid for finding this new package as well.
29-04-2015

The division of the utilities into different packages serve multiple purposes: - To group things that belong together, thereby removing the other, in order to make it easier to find what is needed. - To simplify for wild card builds and imports in the modules world. It will be possible to include a package but not get "more than you want". The canonical example is usage of sun.misc.Unsafe in test library class Utils.java.
22-04-2015