On Aug 29 2013, at 22:37 , Alan Bateman wrote: > On 30/08/2013 01:13, Mike Duigou wrote: >> Hello all; >> >> This is a review for two changesets. The first change (JDK-8024014) splits >> up the jdk_util test group a bit by introducing three sub-groups, >> jdk_collections, jdk_stream and jdk_concurrent. The main advantage is that >> it's easier/quicker to test individual components. The intent is that the >> test groups are aligned with bug database sub-components. >> >> The second change moves some important lambda related tests from languishing >> in obscurity in the jdk_other group to the jdk_lang group to reflect their >> importance and relation to other tests. These tests are contained in the >> jdk/lambda directory. >> >> The combined webrev is here: >> >> http://cr.openjdk.java.net/~mduigou/JDK-8024015/0/webrev/ >> >> The effect of these changes won't be visible to most people until >> JDK-8015068 is integrated. >> >> Thanks, >> >> Mike > The jdk_other group was initially created to match the existing jdk_other > make file target so this is why jdk/lambda is there. I agree with moving it > as it is somewhat obscure. > > I'm not sure about splitting up jdk_util as proposed as it doesn't look very > maintainable. Have you considered just limiting this to simple groups for > java/util/stream/** and java/util/concurrent/** and not try carve up the > tests in java/util?
Did you see David Holmes' suggestion? Do you think it's adequate? I agree about the maintainability aspect as I really felt guilty re-creating FILES_JAVA.gmk... > If someone is changing something in the collection classes then is it a big > deal to run all of the java/util/** tests? Having a smaller subset (larger than a singleton) is always of some value. Collections by itself is about 30% of total util so there is a nice turn around reduction for iterative dev/test. > If there are good reasons then maybe it's time to look at how the tests are > organized instead. > > -Alan.
