RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg

Vitaly Davidovich vitalyd at gmail.com
Wed Jan 16 07:29:32 PST 2013


Some of this is style so feel free to ignore:

I'd mark all these classes final for now.  I'd also hide the default ctor
for the util classes that only have static methods.

JDKToolFinder
- Check that the jdk.test sysprop is not empty as well.

- Remove the throws clause from the method - don't think it adds any value.

- RuntimeException seems more idiomatic instead of Exception

- after creating the full path string, might be nice to verify that it
exists and throw if not (things will not work later but you can provide a
better error message here).  Perhaps even return a File or Path instance
instead of string.

OutputAnalyzer
- any reason fields are default visible? Make them private and final.

- should probably check that output is not null in the constructors

- it's possible to chain the constructors here

- same comment about throws clauses on methods + RuntimeException as above

ProcessTools
- getOutput swallows IOException and returns "".  Not sure this is best - I
think the test should fail as you can't trust the results at this point.

- StreamPumper extends Thread so I don't think you need the wrapper threads
here.  Cleaner is to make StreamPumper implement Runnable though and use
threads here.

- interruption is caught and restored but no guarantee caller will observe
it now. Again, don't think returning "" is right as results are
indeterminate.  I'd let the interrupt bubble up.

- there's no non-reflective way to get the pid?

- not entirely sure what getPlatformSpecificVMArgs is really meant for.
Maybe just have an is64bitJVM() instead? You can just return "new
String[0]" though (I'm not a fan of extra braces)

-createJavaProcessBuilder() can probably just use
List.addAll(Arrays.asList(...)) but Collections. addAll is OK too.

StreamPumper
- check ctor args for null reference.  The fields can be final as well.

That's all for now :).

Thanks
Sent from my phone
On Jan 16, 2013 9:42 AM, "Christian Törnqvist" <
christian.tornqvist at oracle.com> wrote:

> Hi Vitaly,****
>
> ** **
>
> Setting them as daemon sounds like a good idea :)****
>
> ** **
>
> I’d like your feedback on the other things as well, the quality of test
> code is important.****
>
> ** **
>
> Thanks,****
>
> Christian****
>
> ** **
>
> *From:* Vitaly Davidovich [mailto:vitalyd at gmail.com]
> *Sent:* den 16 januari 2013 14:50
> *To:* Christian Törnqvist
> *Cc:* hotspot-dev at openjdk.java.net
> *Subject:* Re: RFR (S): 8006413: Add utility classes for writing better
> multiprocess tests in jtreg****
>
> ** **
>
> Hi Christian,****
>
> Not sure how polished you want/need this code to be since it's just
> utility, but one thing that jumped out was the stream pumper threads for
> reading stdout/err should be daemonized just to play it safe.****
>
> There are some other things that can be done, but not sure it's worth the
> effort for a testing utility.  Let me know though if you'd like to cover
> everything.****
>
> Thanks****
>
> Sent from my phone****
>
> On Jan 16, 2013 7:36 AM, "Christian Törnqvist" <
> christian.tornqvist at oracle.com> wrote:****
>
> Hi everyone,
>
>
>
> This RFE adds a few utility classes to make it a bit easier to write
> multi-process tests in jtreg, webrev can be found at
> http://cr.openjdk.java.net/~brutisso/8006413/webrev.00/
>
>
>
> Thanks,
>
> Christian****
>


More information about the hotspot-dev mailing list