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

Liam Miller-Cushon cushon at google.com
Wed Dec 14 18:10:54 UTC 2016

Thanks for the review,

The update change is at:

> should probably be replaced with:
> Assert.check(var.type.tsym == syms.stringType.tsym)
> Done.

> 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:

> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20161214/6a353d09/attachment.html>

More information about the compiler-dev mailing list