Thanks for closing the loop on my late review.
Thumbs up!
Dan
On 6/16/14 11:39 AM, Staffan Larsen wrote:
On 16 jun 2014, at 17:01, Daniel D. Daugherty
<daniel.daughe...@oracle.com <mailto:daniel.daughe...@oracle.com>> wrote:
> updated webrev: http://cr.openjdk.java.net/~sla/6622468/webrev.2.01/
test/com/sun/jdi/VMConnection.java
line 62: System.out.println("vmOpts: "+vmOpts);
line 67: System.out.println("javaOpts: "+javaOpts);
line 68: if (javaOpts != null) {
Indent off by one in patch view; looks like there are tabs.
test/com/sun/jdi/connect/spi/DebugUsingCustomConnector.java
line 62: List launchers = vmm.launchingConnectors();
Indent off by one in patch view; looks like there is a tab.
Yes, I noticed the tab problem too. Fixed.
test/com/sun/jdi/sde/MangleStepTest.java
old line 85: waitForInput();
Why was this line deleted?
The waitForInput() method waits for input on stdin. There is no
process that provides that input so it’s not necessary. The reason it
works before my change is that System.in.read() returns -1 (end of
input) when run in “othervm” mode. With the “driver” change I wanted
the tests to be able to run in “agentvm” mode and there
System.in.read() blocks. I haven’t delved into the details of why, but
since there is no reason to wait for input here I simply removed the
line. I should have mentioned this in the review request.
Thanks,
/Staffan
No comments on the other files.
Dan
On 6/16/14 5:59 AM, Staffan Larsen wrote:
I would appreciate a Review of this change.
Thanks,
/Staffan
On 11 jun 2014, at 10:00, Staffan Larsen <staffan.lar...@oracle.com
<mailto:staffan.lar...@oracle.com>> wrote:
I realized that the code in VMConnection does not take into account
the test.java.opts property as it should.
updated webrev:
http://cr.openjdk.java.net/~sla/6622468/webrev.2.01/
<http://cr.openjdk.java.net/%7Esla/6622468/webrev.2.01/> (only
VMConnection changed)
Thanks,
/Staffan
On 10 jun 2014, at 13:59, Staffan Larsen <staffan.lar...@oracle.com
<mailto:staffan.lar...@oracle.com>> wrote:
On 10 jun 2014, at 11:44,serguei.spit...@oracle.com
<mailto:serguei.spit...@oracle.com>wrote:
Staffan,
It looks good, just one comment.
test/com/sun/jdi/VMConnection.java
61 String vmOpts = System.getProperty("test.vm.opts");
62 if (vmOpts != null) {
63 retVal += System.getProperty("test.vm.opts");
I wonder why not this:
63 retVal += vmOpts;
Uh. Yeah, I wonder that, too. Fixed. :-)
Thanks,
/Staffan
Thanks,
Serguei
On 6/10/14 12:58 AM, Staffan Larsen wrote:
This is a new take on this old bug. Since my previous attempt [0], jtreg has
been update with a “driver” feature and this is exactly what these tests need.
Specifying “@run driver” (instead of “@run main”) will launch the test with no
vm arguments. Whatever arguments were specified in -vmoptions to jtreg will be
available in the System property test.vm.opts and the test code can use those
arguments when launching other processes.
For the JDI tests this is a very good match. The tests run two processes: one
debugger and one debuggee. It is really the debuggee that is being tested, the
the debugger is just driving the testing. So it is the debuggee that should be
invoked with the specified -vmoptions.
In this change I’ve changed all debuggers to be launched with “@run driver” and
all debuggees to be launched using the test.vm.opts options. This will remove
the need to the esoteric @debuggeeVMOptions file that was previously used to
pass arguments to the debuggee.
webrev:http://cr.openjdk.java.net/~sla/6622468/webrev.2.00/
bug:https://bugs.openjdk.java.net/browse/JDK-6622468
The webrev is very boring to read, probably best to read the diff file
directly. test/com/sun/jdi/VMConnection.java has the only substantial change.
I have run this through JPRT with no failures.
Thanks,
/Staffan
[0]http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-August/011325.html
