RFR: 8151832: Improve exception messages in exceptions thrown by jigsaw code

[Seán Coffey]

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
>