> http://cr.openjdk.java.net/~sla/8024985/webrev.01/
Thumbs up. Of course, the proof is in the running of the tests... :-)
test/com/sun/jdi/ExceptionEvents.java
No comments (7 excludes here).
test/com/sun/jdi/FilterNoMatch.java
The original code filtered out "com.*" so the new code filters
less, but I think it's OK (7 excludes here).
test/com/sun/jdi/JDIScaffold.java
No comments (7 excludes here).
test/com/sun/jdi/MethodEntryExitEvents.java
No comments (7 excludes here).
test/com/sun/jdi/PopAndStepTest.java
No comments (7 excludes here).
test/com/sun/jdi/RepStep.java
No comments (7 excludes here).
test/com/sun/jdi/TestScaffold.java
No comments (7 excludes here).
Dan
On 9/19/13 12:17 PM, Staffan Larsen wrote:
On 19 sep 2013, at 17:49, Daniel D. Daugherty <daniel.daughe...@oracle.com>
wrote:
On 9/19/13 7:53 AM, Staffan Larsen wrote:
All,
Please review this fix for a JDI test. The problem and fix is described in the
bug report.
bug: https://bugs.openjdk.java.net/browse/JDK-8024985
webrev: http://cr.openjdk.java.net/~sla/8024985/webrev.00/
Thumbs up.
test/com/sun/jdi/TestScaffold.java
As long as you are in there, are there any 'com.oracle.*' classes
to filter out?
You do have a point there. And when running testing on this fix I ran into
JDK-8024416 which happens to be a manifestation of the same problem, but in a
different test, with a different exclude list. And then I started looking
through the other tests and found a couple of other places this should be fixed.
So here is an updated webrev will all these fixes:
http://cr.openjdk.java.net/~sla/8024985/webrev.01/
Thanks,
/Staffan
