RFR 8171132: Improve class reading of invalid or out-of-range ConstantValue attributes

[Alex Buckley]

On 12/14/2016 10:10 AM, Liam Miller-Cushon wrote:
>     On a related note, your convertType routine seems weak - it does all
>     the required conversions - but without actively checking ranges and
>     throwing errors if something bad is detected (e.g. a 'byte' field,
>     whose constant value is 1000). Instead, I believe your code just
>     truncates the part in excess, which, while acceptable (after all,
>     the creator of such a bad classfile gets what he/she deserves) -
>     could lead to some painful debugging; so an eager check/error would
>     be preferrable, I think.
>
> I may have misunderstood Alex's message here:
> http://mail.openjdk.java.net/pipermail/compiler-dev/2016-November/010500.html
>
>  > javac must not reject Lib.class on this basis. However, javac should
> handle an out-of-band value in the CONSTANT_Integer c.p. entry as a
> quality-of-implementation detail.
>
> I agree that truncating could be surprising and hard to debug. So if an
> error is permitted by the spec I'm happy to make the suggested change,
> and the details you suggested sound good to me.

I'm not sure which spec you're asking about ... the JLS, for example, 
doesn't mention reading class files so it can't be that. I mentioned 
"quality-of-implementation detail" to highlight that javac can react to 
the ConstantValue attribute for Lib.B (or Test.TWO I guess) how ever it 
wishes. javac could convert the value on Monday, zero it on Tuesday, and 
throw error every other day.

Alex