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

Mandy Chung mandy.chung at oracle.com
Mon Oct 8 10:44:51 PDT 2012


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).

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?

test/sun/misc seems to belong to jdk_lang.  Do you know why they are in 
jdk_other?

Mandy

On 10/7/2012 12:35 PM, Alan Bateman wrote:
>
> This one is a small clean-up of the test targets defined in 
> jdk/test/Makefile. The union of the tests executed by each of the make 
> targets should be the entire test suite but this isn't so, there are 
> small number of tests that aren't run.
>
> I've renamed jdk_misc to jdk_other (the original name is confusing 
> because of sun.misc) and expanded it to run additional areas that have 
> a small number of tests. If more tests are added to these areas over 
> time then it may make sense to add new targets in the future.
>
> "make jdk_jmx" now runs the JMX tests as it was confusing to have 
> those tests split between management1 and management2. I've also 
> renamed jdk_tools1 to jdk_jdi to make it clear that this is the JDI 
> tests rather than tools. When Kelly originally set this up he split 
> the NIO tests into 3 batches, I don't think this is necessary any 
> longer (the really slow tests have been long been dialed down or 
> changed to run much faster).
>
> The webrev with the proposed changes is here:
> http://cr.openjdk.java.net/~alanb/7173494/webrev/
>
> -Alan.


More information about the serviceability-dev mailing list