Blocks :
|
JDK-8186549 :
|
|
JDK-8186610 :
|
|
JDK-8211971 :
|
|
JDK-8211972 :
|
|
JDK-8211973 :
|
|
JDK-8211974 :
|
|
JDK-8211975 :
|
|
JDK-8211976 :
|
|
JDK-8211977 :
|
|
JDK-8211978 :
|
|
JDK-8211979 :
|
|
JDK-8212031 :
|
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.
|