hg: jdk7/tl/langtools: 2 new changesets

Neal Gafter neal at gafter.com
Thu Jun 9 08:41:58 PDT 2011


Alex-

Thanks!

Cheers,
Neal

On Tue, Jun 7, 2011 at 6:24 PM, Alex Buckley <alex.buckley at oracle.com>wrote:

> Bunch of spec issues here.
>
> The text claiming casting conversion is more inclusive than assignment
> conversion is not new, and is only a discussion note, but I agree it's false
> - a casting conversion does not allow narrowing-primitive-then-boxing
> whereas an assignment conversion sometimes does.
>
> Rather than complicating the note with if's and but's about the
> assignment/casting relationship, I will remove the note for JLS7.
>
> The compiler was compliant in rejecting (Byte)0 in the past, and it's
> compliant in rejecting it now. We are aware of improvements possible when
> casting primitive values, but they will not be specified for SE 7.
>
> Regarding the "compile-time legality" clauses, they are a centralization
> and rewording of existing clauses. I was too strong with "always ... without
> error", since exceptions may occur as in 5.2. I softened the wording so an
> expression of primitive type _may_ undergo casting conversion to a reference
> type without error, by boxing conversion. (These clauses are an example of
> normative text which should not be tested, since it's an overview of rules
> elsewhere.)
>
> Alex
>
>
> On 6/7/2011 5:46 PM, Neal Gafter wrote:
>
>> One more thing: the casting conversion from "0" to "Byte" is also required
>> to be allowed by the draft JLS by this curious sentence:
>>
>> The compile-time legality of a casting conversion is as follows:
>> • ...
>> • An expression of a primitive type can always be [sic] undergo casting
>> conversion to a reference type without error, by boxing conversion.
>>
>> Since 0 is an expression of primitive type and Byte is a reference type,
>> the former can "always" undergo a casting conversion to the latter "without
>> error".
>>
>> On Tue, Jun 7, 2011 at 5:38 PM, Neal Gafter <neal at gafter.com <mailto:
>> neal at gafter.com>> wrote:
>>
>>    Regarding the fix for "bug" 7041730... I was under the impression
>>    that recent changes to the language and compiler were intended to
>>    allow assignment conversions as casting conversions too.  The
>>    conversion from the constant zero (0) to a Byte is among the
>>    assignment conversions.  Draft SE7 JLS 5.2 (Assignment Conversion) says
>>
>>    In addition, if the expression is a constant expression (§15.28) of
>>    type ... int ... a narrowing primitive conversion followed by a
>>    boxing conversion may be used if the type of the variable is ...
>>    Byte and the value of the constant expression is representable in
>>    the type byte...
>>
>>    And 5.5 (Casting Conversion) says
>>
>>    ...casting conversions are more inclusive than assignment or method
>>    invocation conversions: a cast can do any permitted conversion other
>>    than a string conversion or a capture conversion (§5.1.10).
>>
>>    Yet this change claims to "fix" the bug 7041730, which requests that
>>    the casting conversion from "0" to "Byte" be illegal; that violates
>>    this JLS quote.
>>
>>    Cheers,
>>    Neal
>>
>>
>>    On Wed, May 11, 2011 at 4:16 AM, <maurizio.cimadamore at oracle.com
>>    <mailto:maurizio.cimadamore at oracle.com>> wrote:
>>
>>        Changeset: 95fc7fd39be2
>>        Author:    mcimadamore
>>        Date:      2011-05-11 13:12 +0200
>>        URL:
>> http://hg.openjdk.java.net/jdk7/tl/langtools/rev/95fc7fd39be2
>>
>>        7041730: Regression: compiler accepts invalid cast from int to Byte
>>        Summary: Implementation of cast conversion rules between
>>        primitive and boxed types is too liberal
>>        Reviewed-by: jjg
>>
>>        ! src/share/classes/com/sun/tools/javac/code/Types.java
>>        ! test/tools/javac/types/BoxingConversionTest.java
>>        ! test/tools/javac/types/CastTest.java
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20110609/c4b2e822/attachment.html 


More information about the compiler-dev mailing list