JDK-8211290 : reorganizing the remaining JDK and JAXP test library classes
  • Type: Enhancement
  • Component: other-libs
  • Sub-Component: other
  • Affected Version: 12,15
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2018-09-28
  • Updated: 2021-10-21
  • Resolved: 2020-09-17
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 15
15Fixed
Related Reports
Blocks :  
Sub Tasks
JDK-8186549 :  
JDK-8186610 :  
JDK-8211971 :  
JDK-8211972 :  
JDK-8211973 :  
JDK-8211974 :  
JDK-8211975 :  
JDK-8211976 :  
JDK-8211977 :  
JDK-8211978 :  
JDK-8211979 :  
JDK-8212031 :  
Description
the main of JDK-8075327 has been to merge (in one way or another) test library classes which existed in the top-level (former hotspot) test library and JDK/JAXP test libraries. this is (almost) done, but JDK and JAXP test libraries still have classes which can be useful for any test suites and hence worth to be moved to the top-level directory.

moving all these classes w/o analyzing them into the top-level library isn't an option as it increases the cost of change/errors in classes and might be inadequate. All changes in top-level libraries must be reviewed and tested more carefully, and the changes which break behavioral compatibility must be done with great care. 

Leaving all the classes as-is is another extreme and it has its drawbacks, including the possibility of new test library forks and introducing of "unintended" test library, which is a situation when some tests use other tests' classes which aren't part of test library and have never been treated that one. Although, it is technically possible, expecting someone to test or fix someone else's tests when they change their internal classes would be unreasonable. Thus using classes which are not part of any test libraries and not part of the tests must be discouraged by guidelines and rejected during a review.

All test libraries classes can be split into three logical categories and placed accordingly:
 1) classes which are intended to be used by all test suites are to be moved to the top-level test library;
 2) classes which are used by a certain test group and would have very low, if any, usefulness for other test suites. Such classes should be kept in a test library specific for a test suite.
 3) classes which are very specific to a few particular tests should be moved closer to the tests which depend on them.
Comments
closing as fixed: all but JDK-8210925 sub-tasks have been finished, 8210925 has been "promoted" to a standalone issue as the fate of the bytecode library isn't fully decided yet and, strictly speaking, having this library in the common testlibrary location isn't required to declare victory here nor does block any further planned improvements.
17-09-2020

security/cacerts/VerifyCACerts.java and security/CheckBlacklistedCerts.java are tests on the cacerts and blacklisted.certs files inside lib/security. That's why they were created in the test/lib/security directory. I'd suggest moving them into sun/security/lib so they automatically stay inside jdk_security3.
09-10-2018

grepping test/jaxp for @library found the following jaxp-specific test libraries: - /javax/xml/jaxp/functional - /javax/xml/jaxp/isolatedjdk - /javax/xml/jaxp/libs - /javax/xml/jaxp/unittest at a glance, only jaxp/javax/xml/jaxp/libs/jaxp/library/ directory has some classes which might be considered as generic and suggested for moving to the top-level library. and it seems there is only one such classed remained -- jaxp.library.SimpleHttpServer. jaxp.library.SimpleHttpServer seems to be a more functional fork of jdk.testlibrary.SimpleHttpServer. therefore suggest merging them and moving to the top-level testlibrary. I'd really appreciate someone of jaxp team to (dis)confirm that there are no other "generic purpose" test library classes within jaxp test suite.
02-10-2018

as of today (10/02/2018), there are the following classes in jdk/test/lib: - security/cacerts/VerifyCACerts.java which is a jtreg test and not a test library class. suggest moving to test suite dir. - security/CheckBlacklistedCerts.java is also a jtreg test, and not a library class. suggest moving to test suite dir. - testlibrary/AssertsTest.java, OutputAnalyzerReportingTest.java, and OutputAnalyzerTest.java are tests for some of the test library classes. suggest moving to test library test dir -- /test/lib-test/. - testlibrary/ExtendedRobot.java is a library used by client tests. suggest introducing a client test library located in test/jdk/lib/client - testlibrary/ModuleTargetHelper.java is a library used by a couple of tests, it provides wrappers around a non-exported package -- jdk.internal.module. suggest moving closer to the tests into test/jdk/tools/jlink/plugins/SystemModuleDescriptors - testlibrary/ModuleUtils.java is a library used by several tests, seems generic enough to be moved to the top-level library. suggest moving to jdk.test.lib.utils in the top-level - testlibrary/bytecode/ is a bytecode generation, can and should be used by other test suites. suggested moving to the top-level library, but since this version misses several fixes, it makes sense to wait till it's updated first. meanwhile, it can be moved to jdk/test/lib/bytecode - testlibrary/bootlib/ contains patches for java.base module (mostly for stream testing). it seems quite specific for core-lib testing, therefore it makes sense to leave it in jdk/test/lib, but it'd be better to move it from jdk/test/lib/testlibrary, as testlibrary history was a test library itself, not a directory w/ other libraries. - testlibrary/java/util/jar/Compiler.java is in-memory java-compiler which supports "release" flag, it's not used directly by any tests, only by classes testlibrary/java/util/jar/. suggest removing and using jdk.test.lib.compiler.InMemoryJavaCompiler instead - testlibrary/java/util/jar/CreateMultiReleaseTestJars.java creates a very specific .jar files used by several core-libs tests, doesn't make much sense to put into the top-level testlibrary. suggest introducing a separate library in jdk/test/lib, e.g. test.mrjar. - testlibrary/java/util/jar/JarBuilder.java provides API to create .jar file, can be moved to the top-level testlibrary and merged w/ other utility classes w/ the same goal. - testlibrary/java/util/jar/SimpleHttpServer.java -- a http server which returns multi-release.jar file, can be generalized (by merging w/ jaxp version) and placed into the top-level - testlibrary/jdk/testlibrary/OptimalCapacity.java provides wrappers around reflections to check sizes of collections, suggest moving to the top-level - testlibrary/jdk/testlibrary/SimpleSSLContext.java and testkeys. SimpleSSLContext creates an SSLContext using the keystore from testkeys file, used by network tests. suggest moving to jdk/test/lib/network
02-10-2018