From my limited knowledge of this, it look ok to me.

-Chris.

On 20/12/2012 01:11, Stuart Marks wrote:
Hi all,

Please review the fix [1] for bug 8005290 [2].

[1] http://cr.openjdk.java.net/~smarks/reviews/8005290/webrev.0/

[2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005290

I just filed this bug, so it hasn't made it to the public website yet.
The salient text from the bug report is as follows:

------------------------------------------------------------
The RMI test library (jdk/test/java/rmi/testlibrary) has a convenience
API (the JavaVM class) for launching a JVM subprocess. When starting the
subprocess, it adds the -showversion option to the JVM command line and
waits for the version output to arrive from the subprocess before
returning to the caller. This is intended to avoid race conditions where
the test might try to contact the subprocess before it's fully initialized.

It turns out this doesn't really work and it's also unnecessary.

The reason it doesn't really work is that the version string is emitted
when the JVM subprocess has mostly started up, but it hasn't yet
executed any user code. Even after the version string has been emitted,
the caller may still have to wait and retry before successfully
contacting a service exported by the subprocess. The current code
returns after two seconds, even if the version string hasn't been
received from the subprocess. So the caller has to wait and potentially
retry anyway. Since the callers have to do this anyway, having the
library wait for the version string isn't helpful.

Other library code (e.g., RMID) starts the subprocess and waits until a
particular RMI service is ready, so the -showversion mechanism is
redundant in that case. Finally, many tests start the subprocess and
wait until it finishes, so they don't need the -showversion mechanism
either.

Finally, the -showversion mechanism adds a lot of complexity, as it has
to interpose between the subprocess output stream and the caller, so
we're better off just removing it. All RMI tests continue to pass even
with this mechanism removed.
------------------------------------------------------------

This is basically just test cleanup (no library code changes) to clear
the way for future test enhancements to improve performance and
reliability.

Thanks,

s'marks

Reply via email to