Hi Max,
Please see inline.
On 03/19/2015 05:33 PM, Wang Weijun wrote:
This looks fine.
One comment,
156 cmds.add("-Duser.dir=" + WORK_DIR);
Looks unnecessary. In fact, I've never seen people setting user.dir on the
command line.
Agree. I removed this.
Another comment,
80 * @run main NestedActions jar ReadPropertyExceptionAction.jar
81 * ReadPropertyExceptionAction.class
ReadPropertyException.class
82 *
83 * run tests
Will line 83 make any trouble? I remember bare words (not in a tag) will be
absorbed by the previous action so the lines above will be interpreted as
@run main NestedActions jar ReadPropertyExceptionAction.jar
ReadPropertyExceptionAction.class ReadPropertyException.class run tests
Or maybe that blank line can end an a tag? Anyway I dare not use this.
Yes, it makes a trouble. I removed this, but didn't update the webrev.
Sorry about that and thanks for attention.
Please take a look at
http://cr.openjdk.java.net/~asmotrak/8048147/webrev.03/
Artem
Thanks
Max
On Mar 19, 2015, at 19:39, Artem Smotrakov <artem.smotra...@oracle.com> wrote:
Hi Max,
I agree that sometimes use of a shell script makes a test clearer. On the other
hand, if we are trying to create pure Java tests, it increases overall coverage
of Java APIs.
I updated the tests to use ProcessTools, and simplified a little bit policy
files for negative tests to make them clearer. Please take a look:
http://cr.openjdk.java.net/~asmotrak/8048147/webrev.02/
Artem
On 03/18/2015 06:08 PM, Wang Weijun wrote:
On Mar 18, 2015, at 19:31, Artem Smotrakov <artem.smotra...@oracle.com> wrote:
The tests can be updated to start a new process with ProcessTools, or use a
script.
Choose anyone you like.
Maybe you can a few experiments to see what is the difference between a script
test and a Java test that launches processes.
I'm a little surprised that with the classpath not pointing to jars the test
still succeeds. The jars should have been granted different permissions. Maybe
the test is not designed smart enough to detect the problem?
--Max
Artem
