Resurrecting this old review thread. After some internal discussion,
I've dropped the minor edit that was made in
StackTraceElementCompositeData. It could be noisy data for exception
purposes. I've corrected the other issues raised by Alan and Jim has
long pushed the changes mentioned below.
webrev : http://cr.openjdk.java.net/~coffeys/webrev.8151832.v3/webrev/
Regards,
Sean.
On 01/06/16 16:00, Seán Coffey wrote:
On 01/06/16 10:21, Alan Bateman wrote:
On 31/05/2016 18:57, Seán Coffey wrote:
new webrev :
http://cr.openjdk.java.net/~coffeys/webrev.8151832.v2/webrev/
Also in JprtPath.checkPath then I assume path.getClass() is enough as
the toString is specified to return a useful string.
In JrtPath then "nul" has been renamed to "null". I'm not sure why
this has changed. If it is confusing the NUL (one L) should be fine.
nul looked odd/wrong. I'll replace with NUL then.
Jim might want to comment on the jimage updates. In most cases then
hitting any of these means the JDK is hosed. That is, if we have a
bug here or the jimage container file is corrupted then it will
likely not start.
Ok - will pass this by Jim.
In StackTraceElementCompositeData then I'm not sure if printing the
CompositeType adds anything useful. I might be better to extract
wording from the table in ThreadInfo.from to make it clear that the
stackTrace attribute is missing attributes. This reminds me, I
suspect this table might need to be updated for JDK 9. I will create
a bug for that.
CompositeType.toString() is pretty comprehensive and iterates through
the instance's keyset. I thought the extra output would hint at what
went wrong. I could print both Objects if you want a better
comparison. Or I can start delving into the ThreadInfo.from table if
you think that's a more correct approach.
regards,
Sean.
-Alan
