RFR: 6622468 TEST_BUG: Time to retire the @debuggeeVMOptions mechanism used in the com.sun.jdi infrastructure

[Daniel D. Daugherty]

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

test/com/sun/jdi/sde/MangleStepTest.java
     old line 85: waitForInput();
         Why was this line deleted?

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.larsen at oracle.com 
> <mailto:staffan.larsen at 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.larsen at oracle.com 
>> <mailto:staffan.larsen at oracle.com>> wrote:
>>
>>>
>>> On 10 jun 2014, at 11:44,serguei.spitsyn at oracle.com 
>>> <mailto:serguei.spitsyn at 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
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140616/3b6feb95/attachment-0001.html>