Dmitry,
On 6/20/15 8:22 AM, Dmitry Samersoff wrote:
Serguei,
Thank you for the review.
The comment needs a correction:
Typeos fixed and webrev is regenerated (in-place, press shift-reload).
Ok, thanks!
It is a little bit strange that an IOException is thrown
when the exit code does not match the expectation.
LingeredApp terminates with non-zero exit code if IOException happens,
so I "rethrow" it in a caller.
I guess, it can terminate with non-zero exit code for some other reasons.
Replacing it with Exception would be Ok.
Consider it reviewed.
Thanks,
Serguei
-Dmitry
On 2015-06-10 00:22, [email protected] wrote:
Hi Dmitry,
It looks good, just a couple of minor comments:
root_webrev/test/lib/share/classes/jdk/test/lib/apps/LingeredApp.java
324 * Delete lock file that signal app to terminate, then
325 * waits until app is actually terminated.
326 * @throws IOException
327 */
328 public void stopApp() throws IOException {
329 deleteLock();
330 waitAppTerminate();
331 int exitcode = appProcess.exitValue();
332 if (exitcode != 0) {
333 throw new IOException("LingeredApp terminated with non-zero exit
code " + exitcode);
334 }
335 }
The comment needs a correction:
that signal app => that signals app
waits until => wait until
It is a little bit strange that an IOException is thrown
when the exit code does not match the expectation.
Thanks,
Serguei
On 6/9/15 5:48 AM, Dmitry Samersoff wrote:
Everybody,
Please review a test-only fix:
http://cr.openjdk.java.net/~dsamersoff/JDK-8081576/webrev.01/
LingeredApp can throw an exception during initialization if it not able
to create a lock file for some reason. This exception cause NPE later,
when the test attempts to stop LingeredApp and original exception get lost.
Fixing it by adding static stopApp(app) method with null pointer check
inside.
