Ok. I'll remove toHex() and fromHex().
thanks,
Chris
On 2/15/19 8:13 PM, [email protected] wrote:
Hi Chris,
It looks good in general.
One question:
It seems, the methods toHex() and fromHex() are no longer used and
can be removed now.
Thanks,
Serguei
On 2/15/19 5:08 PM, Chris Plummer wrote:
Hi,
Please review the updated webrev:
http://cr.openjdk.java.net/~cjplummer/8218947/webrev.02/
https://bugs.openjdk.java.net/browse/JDK-8218947
I removed "hex" from "object description and hex id" and removed the
java.lang. prefix from java.lang.Long references. There was no need
to update the man page since it no longer references the "threads"
command. The entire "Basic jdb Commands" section is gone.
Also, it turns out one test was failing. Not sure how I missed it.
I've been sitting on this change for months and never noticed it
before. Maybe I didn't run the right set of tests.
Anyway, the test (somewhat erroneously) searches the entire output
line for the first thing that looks like a hex number, and assumes it
is the thread id. If there was something that looked like a hex
number in the class name, it would fail. I changed it to grab the
first token after the classname.
BTW, I also learned that in nsk/share/jdb/Jdb.java there is a
getThreadIds() method that this test uses (along with about a dozen
other tests). It returns a String[] containing all the thread ids. It
finds the thread ID in a way similar to what I did. It first skips
the class name and then grabs everything up to the first space (my
code goes up to the first whitespace character).
thanks,
Chris
On 2/13/19 7:37 PM, Chris Plummer wrote:
Hi,
Please review the following:
http://cr.openjdk.java.net/~cjplummer/8218947/webrev
https://bugs.openjdk.java.net/browse/JDK-8218947
Tested by running the following on all supported platforms:
open/test/hotspot/jtreg/vmTestbase/nsk/jdb
open/test/jdk/com/sun/jdi
thanks,
Chris