Hi,
On 9.11.2015 19:12, Alexandre (Shura) Iline wrote:
Hi
I have just realized that an NPE could also be possible in
test/lib/testlibrary/jdk/testlibrary/Platform.java so it should be updated also:
http://cr.openjdk.java.net/~shurailine/8139430/webrev.04/
As for the original (03) webrev - I wouldn't rename InputArguments into
RuntimeMXBeanTool. The new name really does not reflect the
functionality the class actually provides. IMO, you can keep the
original class name and still move it to jdk.testlibrary.management.
As for the last (04) webrev - this change doesn't seem to be related to
the issue. It is just a cleanup of a potential NPE. I would suggest
either updating the issue summary to be more generic or address the NPE
in a separate changeset.
-JB-
Shura
On Nov 9, 2015, at 8:54 PM, Alexandre (Shura) Iline
<alexandre.il...@oracle.com> wrote:
Hi,
This is one of the ways to fix 8139430:
http://cr.openjdk.java.net/~shurailine/8139430/webrev.03
Could you please take a look on it?
A few comments.
The biggest dependency on java.management was in
jdk.testlibrary.ProcessTools.getProcessId() method. I have changed the method
to use the new process API, which helped to avoid updating a lot of code.
I am moving the rest library code which depended on java.management and
jdk.management to a new “management" subpackage of the jdk library:
jdk.testlibrary.management. Another possibility I have considered is “ext” or
“extended” subpackage, which would have all the classes which depend on anything but
java.base. With “ext” there would be no way to keep the desired granularity with the
test modules dependencies.
The methods which worth moving fit well into two classes:
jdk.testlibrary.management.ThreadMXBeanTool - to include a couple of method
which previously belonged to the TestThread utility methods.
jdk.testlibrary.management.RuntimeMXBeanTool - previously named as
jdk.testlibrary.InputArguments
None of moved/renamed test library methods were used anywhere in tests, so no
test updates needed:
jdk.testlibrary.InputArguments is not used, instead every test which needs that
functionality directly calls RuntimeMXBean.getInputArguments()
jdk.testlibrary.TestThread.waitUntilBlockingOnObject(Thread, Thread.State,
Object) and jdk.testlibrary.TestThread.waitUntilInNative(Thread) also were not
used as there is a similar class outside of the test library:
./closed/com/oracle/jfr/common/jrockit/TestThread.java
Please let me know what you think.
Shura