7173494: some jdk tests are not run in test/Makefile

Alan Bateman Alan.Bateman at oracle.com
Mon Oct 8 18:12:33 UTC 2012

On 08/10/2012 18:44, Mandy Chung wrote:
> It's good to clean this up and the change looks fine in general.    A 
> couple of minor comments:
> jdk_management - Might be good to include java/lang/management tests 
> in this target in case someone only runs one target to verify that 
> area.  On the other hands, they are currently covered by jdk_lang 
> target and might be better to take them out from jdk_lang (maybe in 
> the future).
The jdk_management target could run the java/lang/management tests too 
but it would mean these tests would run twice. I have experimented with 
moving these tests to test/java/lang_management (same thing for 
java/lang/instrument to java/lang_instrument) but decided not to include 
those changes here as it's a disruptive change. With compact profiles 
[1] and future modularization then we may need to look at this again as 
it would be really nice to be able to specify the test directories to 
jtreg that correspond to the modules or profiles (I think it's just a 
bit early to know how the tests will run).
> jdk_rmi target - you change "javax/rmi" to "javax/rmi/ssl".  There is 
> no test in the test/javax/rmi directory currently but if a new test 
> (or new subdirectory) is added under test/javax/rmi, you would have to 
> change the jdk_rmi target.  Would it be better to keep "javax/rmi" as 
> it is?
javax.rmi.CORBA has the classes for RMI-IIOP and I would expect tests 
for this area to be run by a different make target, say jdk_corba. As it 
happens we don't have any tests for this area in the jdk repository so 
it doesn't make any difference at this time So somewhat of a drive-by 
fix (again profiles and modules motivated so that "make jdk_rmi" would 
run the RMI tests only).

> test/sun/misc seems to belong to jdk_lang.  Do you know why they are 
> in jdk_other?
The tests in test/sun/misc provide very sparse coverage and are somewhat 
of a mixed bag so I decided to leave them where they are. I wouldn't 
object to moving them to the jdk_lang target, do you have a strong 
opinion on this?


[1] http://openjdk.java.net/jeps/161

More information about the core-libs-dev mailing list