Re: RFR (S) 8007142: Add utility classes for writing better multiprocess tests in jtreg
Alan,
thanks for the review!
// Katja
On 02/05/2013 12:54 PM, Alan Bateman wrote:
On 05/02/2013 10:51, Yekaterina Kantserova wrote:
On 02/04/2013 02:18 PM, Alan Bateman wrote:
On 04/02/2013 11:03, Yekaterina Kantserova wrote:
But JDKToolFinder.getJDKTool is used even for finding java, e.g. I
need to fork a java process - JDKToolFinder.getJDKTool("java") for
some JRE tests?
It might be better to rename JDKToolFinder to something like
JdkFinder and have it define getJavaLauncher() and getTool(String
tool) methods.
I think it's good idea to separate java launcher and tools. Here is
the new JdkFinder:
http://cr.openjdk.java.net/~ykantser/8007142/webrev.02/test/lib/testlibrary/jdk/testlibrary/JdkFinder.java.html.
It now possible to retrieve java/tools both from the test.jdk and
compile.jdk.
If you don't agree then you could at least change
ProcessTools.createJavaProcessBuilder so that it looks like "java"
in the JDK/JRE under test.
JDKToolFinder.getJDKTool("java") became JdkFinder.getJavaLauncher in
the createJavaProcessBuilder
(http://cr.openjdk.java.net/~ykantser/8007142/webrev.02/test/lib/testlibrary/jdk/testlibrary/ProcessTools.java.html).
-Alan.
It looks right to me now.
-Alan
Re: RFR (S) 8007142: Add utility classes for writing better multiprocess tests in jtreg
On 05/02/2013 10:51, Yekaterina Kantserova wrote:
On 02/04/2013 02:18 PM, Alan Bateman wrote:
On 04/02/2013 11:03, Yekaterina Kantserova wrote:
But JDKToolFinder.getJDKTool is used even for finding java, e.g. I
need to fork a java process - JDKToolFinder.getJDKTool("java") for
some JRE tests?
It might be better to rename JDKToolFinder to something like
JdkFinder and have it define getJavaLauncher() and getTool(String
tool) methods.
I think it's good idea to separate java launcher and tools. Here is
the new JdkFinder:
http://cr.openjdk.java.net/~ykantser/8007142/webrev.02/test/lib/testlibrary/jdk/testlibrary/JdkFinder.java.html.
It now possible to retrieve java/tools both from the test.jdk and
compile.jdk.
If you don't agree then you could at least change
ProcessTools.createJavaProcessBuilder so that it looks like "java" in
the JDK/JRE under test.
JDKToolFinder.getJDKTool("java") became JdkFinder.getJavaLauncher in
the createJavaProcessBuilder
(http://cr.openjdk.java.net/~ykantser/8007142/webrev.02/test/lib/testlibrary/jdk/testlibrary/ProcessTools.java.html).
-Alan.
It looks right to me now.
-Alan
Re: RFR (S) 8007142: Add utility classes for writing better multiprocess tests in jtreg
On 02/04/2013 02:18 PM, Alan Bateman wrote:
On 04/02/2013 11:03, Yekaterina Kantserova wrote:
But JDKToolFinder.getJDKTool is used even for finding java, e.g. I
need to fork a java process - JDKToolFinder.getJDKTool("java") for
some JRE tests?
It might be better to rename JDKToolFinder to something like JdkFinder
and have it define getJavaLauncher() and getTool(String tool) methods.
I think it's good idea to separate java launcher and tools. Here is the
new JdkFinder:
http://cr.openjdk.java.net/~ykantser/8007142/webrev.02/test/lib/testlibrary/jdk/testlibrary/JdkFinder.java.html.
It now possible to retrieve java/tools both from the test.jdk and
compile.jdk.
If you don't agree then you could at least change
ProcessTools.createJavaProcessBuilder so that it looks like "java" in
the JDK/JRE under test.
JDKToolFinder.getJDKTool("java") became JdkFinder.getJavaLauncher in
the createJavaProcessBuilder
(http://cr.openjdk.java.net/~ykantser/8007142/webrev.02/test/lib/testlibrary/jdk/testlibrary/ProcessTools.java.html).
-Alan.
Thanks,
Katja
Re: RFR (S) 8007142: Add utility classes for writing better multiprocess tests in jtreg
On 04/02/2013 11:03, Yekaterina Kantserova wrote:
But JDKToolFinder.getJDKTool is used even for finding java, e.g. I
need to fork a java process - JDKToolFinder.getJDKTool("java") for
some JRE tests?
It might be better to rename JDKToolFinder to something like JdkFinder
and have it define getJavaLauncher() and getTool(String tool) methods.
If you don't agree then you could at least change
ProcessTools.createJavaProcessBuilder so that it looks like "java" in
the JDK/JRE under test.
-Alan.
Re: RFR (S) 8007142: Add utility classes for writing better multiprocess tests in jtreg
On 02/04/2013 11:55 AM, Alan Bateman wrote:
On 04/02/2013 10:33, Yekaterina Kantserova wrote:
No, it was a bad example. Let's take another one:
/java -jar jtreg.jar -jdk MONKEY -compilejdk LION test.java/
In this case JDKToolFinder.getJDKTool("jcmd") will return
LION/bin/jcmd, but I need to test MONKEY/bin/jcmd.
The -compilejdk option should only be used when testing a JRE -- ie:
no tools in the runtime under test.
So this your example shouldn't include the -compilejdk option as it is
testing a JDK.
-Alan.
But JDKToolFinder.getJDKTool is used even for finding java, e.g. I need
to fork a java process - JDKToolFinder.getJDKTool("java") for some JRE
tests?
// Katja
Re: RFR (S) 8007142: Add utility classes for writing better multiprocess tests in jtreg
On 04/02/2013 10:33, Yekaterina Kantserova wrote:
No, it was a bad example. Let's take another one:
/java -jar jtreg.jar -jdk MONKEY -compilejdk LION test.java/
In this case JDKToolFinder.getJDKTool("jcmd") will return
LION/bin/jcmd, but I need to test MONKEY/bin/jcmd.
The -compilejdk option should only be used when testing a JRE -- ie: no
tools in the runtime under test.
So this your example shouldn't include the -compilejdk option as it is
testing a JDK.
-Alan.
Re: RFR (S) 8007142: Add utility classes for writing better multiprocess tests in jtreg
On 02/01/2013 04:18 PM, Alan Bateman wrote:
On 01/02/2013 15:06, Yekaterina Kantserova wrote:
Thanks for explanation! But I'm still confused.
In my use case I need to test /_the tool_/ I'll find with
JDKToolFinder. It will work if just -jdk will be specified. But if
-compilejdk happens to be specified the results of my tests will be
useless. Furthermore, it would be hard to detect. Do you think there
is a solution that covers all use cases?
I don't think it make sense to specify -compilejdk and not -jdk. Does
that help?
-Alan
No, it was a bad example. Let's take another one:
/java -jar jtreg.jar -jdk MONKEY -compilejdk LION test.java/
In this case JDKToolFinder.getJDKTool("jcmd") will return LION/bin/jcmd,
but I need to test MONKEY/bin/jcmd.
There is an example in ProcessTools.java:
...
/**
* Create ProcessBuilder using *the java launcher from the jdk to
be tested*
* and with any platform specific arguments prepended
*/
public static ProcessBuilder createJavaProcessBuilder(String...
command)
throws Exception {
String javapath = JDKToolFinder.getJDKTool("java");
ArrayList args = new ArrayList<>();
args.add(javapath);
Collections.addAll(args, getPlatformSpecificVMArgs());
Collections.addAll(args, command);
return new ProcessBuilder(args.toArray(new String[args.size()]));
}
...
May be we need another solution for testing a JRE? JREToolFinder for
example, which can be implemented later?
Thanks,
Katja
Re: RFR (S) 8007142: Add utility classes for writing better multiprocess tests in jtreg
On 01/02/2013 15:06, Yekaterina Kantserova wrote: Thanks for explanation! But I'm still confused. In my use case I need to test /_the tool_/ I'll find with JDKToolFinder. It will work if just -jdk will be specified. But if -compilejdk happens to be specified the results of my tests will be useless. Furthermore, it would be hard to detect. Do you think there is a solution that covers all use cases? I don't think it make sense to specify -compilejdk and not -jdk. Does that help? -Alan
Re: RFR (S) 8007142: Add utility classes for writing better multiprocess tests in jtreg
On 02/01/2013 03:20 PM, Alan Bateman wrote: On 01/02/2013 13:32, Yekaterina Kantserova wrote: I've done some testing before I've changed JDKToolFinder. Bellow are 2 cases: 1) *compile.jdk != test.jdk* ./build/linux-amd64/j2sdk-image/bin/java -jar jtreg.jar -compilejdk /localhome/java/jdk1.7.0_09 test.java test.jdk=../build/linux-amd64/j2sdk-image/jre compile.jdk=/localhome/java/jdk1.7.0_09 java.home=../build/linux-amd64/j2sdk-image/jre 2) *compile.jdk == test.jdk* ./build/linux-amd64/j2sdk-image/bin/java -jar jtreg.jar -jdk|-testjdk /localhome/java/jdk1.7.0_09 test.java test.jdk /localhome/java/jdk1.7.0_09 compile.jdk /localhome/java/jdk1.7.0_09 java.home /localhome/java/jdk1.7.0_09/jre It seems like test.jdk is always equal to java.home (besides /jre part). Are there some rules how -jdk and -compilejdk should be used? Normally you specify the JDK/JRE to test via the -jdk option. When you only specify -jdk then you will see that test.jdk and compile.jdk have the same value. When testing a JRE then you need to specify both -jdk and -compilejdk, the latter being the JDK to use to compile the tests. In that scenario you will see that test.jdk and compile.jdk are different (as expected). Thanks for explanation! But I'm still confused. In my use case I need to test /_the tool_/ I'll find with JDKToolFinder. It will work if just -jdk will be specified. But if -compilejdk happens to be specified the results of my tests will be useless. Furthermore, it would be hard to detect. Do you think there is a solution that covers all use cases? // Katja -Alan.
Re: RFR (S) 8007142: Add utility classes for writing better multiprocess tests in jtreg
On 01/02/2013 13:32, Yekaterina Kantserova wrote: I've done some testing before I've changed JDKToolFinder. Bellow are 2 cases: 1) *compile.jdk != test.jdk* ./build/linux-amd64/j2sdk-image/bin/java -jar jtreg.jar -compilejdk /localhome/java/jdk1.7.0_09 test.java test.jdk=../build/linux-amd64/j2sdk-image/jre compile.jdk=/localhome/java/jdk1.7.0_09 java.home=../build/linux-amd64/j2sdk-image/jre 2) *compile.jdk == test.jdk* ./build/linux-amd64/j2sdk-image/bin/java -jar jtreg.jar -jdk|-testjdk /localhome/java/jdk1.7.0_09 test.java test.jdk /localhome/java/jdk1.7.0_09 compile.jdk /localhome/java/jdk1.7.0_09 java.home /localhome/java/jdk1.7.0_09/jre It seems like test.jdk is always equal to java.home (besides /jre part). Are there some rules how -jdk and -compilejdk should be used? Normally you specify the JDK/JRE to test via the -jdk option. When you only specify -jdk then you will see that test.jdk and compile.jdk have the same value. When testing a JRE then you need to specify both -jdk and -compilejdk, the latter being the JDK to use to compile the tests. In that scenario you will see that test.jdk and compile.jdk are different (as expected). -Alan.
Re: RFR (S) 8007142: Add utility classes for writing better multiprocess tests in jtreg
On 02/01/2013 01:32 PM, Alan Bateman wrote:
On 01/02/2013 12:12, Yekaterina Kantserova wrote:
Hi everyone,
Here comes a http://cr.openjdk.java.net/~ykantser/8007142/webrev.01/
with following fixes compared to .00:
* new line is added at the end of the StreamPumper.java
* is changed to {@code in the StreamPumper.java
* JDKToolFinder.java will use the system property "java.home" instead
of "test.jdk" (thus -compilejdk problem is solved)
I see you've changed the package to jdk.testlibrary - thanks for doing
that.
Ops, I've forgotten to mention it. Thanks for pointing on it.
On JDKToolFinder and finding the path to jcmd or other tools used by
the test then it really depends what you are testing. What you have is
fine when testing a JDK but it's not going to work when testing a JRE
(runtime only, no tools). When testing a runtime then jtreg needs to
invoked the -jdk and -compilejdk options (the latter being the JDK to
use to compile the tests). So I think the right answer for
JDKToolFinder is to use "compile.jdk". That will work when testing a
JDK too as "compile.jdk" and "test.jdk" are set to the same value for
that case.
I've done some testing before I've changed JDKToolFinder. Bellow are 2
cases:
1) *compile.jdk != test.jdk*
./build/linux-amd64/j2sdk-image/bin/java -jar jtreg.jar -compilejdk
/localhome/java/jdk1.7.0_09 test.java
test.jdk=../build/linux-amd64/j2sdk-image/jre
compile.jdk=/localhome/java/jdk1.7.0_09
java.home=../build/linux-amd64/j2sdk-image/jre
2) *compile.jdk == test.jdk*
./build/linux-amd64/j2sdk-image/bin/java -jar jtreg.jar -jdk|-testjdk
/localhome/java/jdk1.7.0_09 test.java
test.jdk /localhome/java/jdk1.7.0_09
compile.jdk /localhome/java/jdk1.7.0_09
java.home /localhome/java/jdk1.7.0_09/jre
It seems like test.jdk is always equal to java.home (besides /jre part).
Are there some rules how -jdk and -compilejdk should be used?
-Alan
Thanks,
Katja
Re: RFR (S) 8007142: Add utility classes for writing better multiprocess tests in jtreg
On 01/02/2013 12:12, Yekaterina Kantserova wrote:
Hi everyone,
Here comes a http://cr.openjdk.java.net/~ykantser/8007142/webrev.01/
with following fixes compared to .00:
* new line is added at the end of the StreamPumper.java
* is changed to {@code in the StreamPumper.java
* JDKToolFinder.java will use the system property "java.home" instead
of "test.jdk" (thus -compilejdk problem is solved)
I see you've changed the package to jdk.testlibrary - thanks for doing that.
On JDKToolFinder and finding the path to jcmd or other tools used by the
test then it really depends what you are testing. What you have is fine
when testing a JDK but it's not going to work when testing a JRE
(runtime only, no tools). When testing a runtime then jtreg needs to
invoked the -jdk and -compilejdk options (the latter being the JDK to
use to compile the tests). So I think the right answer for
JDKToolFinder is to use "compile.jdk". That will work when testing a JDK
too as "compile.jdk" and "test.jdk" are set to the same value for that case.
-Alan
