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.
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.
Thanks
Max
> On Mar 19, 2015, at 19:39, Artem Smotrakov <[email protected]> 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 <[email protected]>
>>> 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
>
