hg: jdk7/tl/langtools: 6979683: inconsistent interaction of reference cast with box/unbox conversions leaves out a useful case

[Neal Gafter]

John and Alex-

JLS section 5.5 is pretty clear about what casts are legal, and though that
section might not be perfect, I can't find anything in it that would justify
allowing a cast to convert from Object to int.  I also can't find any
general rule about casting being allowed to do the reverse of multi-step
conversions, which seems to be your "bottom line" justification.

6979683 <http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6979683>is
internally inconsistent claiming both

This specification does not [...] allow a combined conversion between Object
and a primitive type.

and

A careful reading of JLS 5.5 allows both [...] because the initial paragraph
lists the allowed conversions performed by a cast.

Both of these sentences cannot be true; either it is allowed or it is
disallowed.

The initial paragraph<http://java.sun.com/docs/books/jls/third_edition/html/conversions.html#5.5>lists
the following allowed conversions

*Casting conversion* is applied to the operand of a cast operator
(§15.16)<http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#238146>:
the type of the operand expression must be converted to the type explicitly
named by the cast operator. Casting contexts allow the use of:


   - an identity conversion
(§5.1.1)<http://java.sun.com/docs/books/jls/third_edition/html/conversions.html#25209>
   - a widening primitive conversion
(§5.1.2)<http://java.sun.com/docs/books/jls/third_edition/html/conversions.html#25214>
   - a narrowing primitive conversion
(§5.1.3)<http://java.sun.com/docs/books/jls/third_edition/html/conversions.html#25363>
   - a widening reference conversion
(§5.1.5)<http://java.sun.com/docs/books/jls/third_edition/html/conversions.html#190646>optionally
followed by an unchecked conversion
   (§5.1.9)<http://java.sun.com/docs/books/jls/third_edition/html/conversions.html#190772>
   - a narrowing reference conversion
(§5.1.6)<http://java.sun.com/docs/books/jls/third_edition/html/conversions.html#25379>optionally
followed by an unchecked conversion
   - a boxing conversion
(§5.1.7)<http://java.sun.com/docs/books/jls/third_edition/html/conversions.html#190697>
   - an unboxing conversion
(§5.1.8)<http://java.sun.com/docs/books/jls/third_edition/html/conversions.html#190699>.


Of these, only the unboxing conversion could possibly be a candidate for the
conversion in question, but
§5.1.8<http://java.sun.com/docs/books/jls/third_edition/html/conversions.html#190699>is
clear that Object->int is not an unboxing conversion.  The paragraphs
that follow only clarify these rules, and add nothing that would justify the
Object->int conversion.

In short, you appear to have submitted a change to javac that makes it less
compliant with its specification.

By the way, 6979683<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6979683>also
claims incorrectly that

On the other hand, the JLS 5.5 language (in version 3) is imperfect, because
it also seems to allow undesirably complex chains of conversion, such as a
spurious long to float to double, or a speculative one like Object to Byte
to byte to int, or a reboxing like Integer to int to long to Long, or a
combination of unboxing and truncation like Long to long to int (cf.
4995668). Implementors have been right to be cautious to implement these in
the absence of guidance.

None of these "seemingly allowed" conversions is supported by any reading of
the JLS I can construct.  The referenced bug,
4995668<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4995668>,
appears to be unhelpful to the claims made in this paragraph.

Cheers,
Neal

On Wed, Sep 1, 2010 at 5:59 PM, John Rose <john.r.rose at oracle.com> wrote:

> On Sep 1, 2010, at 5:43 PM, Neal Gafter wrote:
>
> > You appear to have added a new kind of casting conversion not yet
> proposed or described in JLS3 (section 5.5).  Is there a language change
> proposal that corresponds to this code change?
>
> No.  The change reflects logic already present in JLS3, though not (it
> seems) implemented widely, because (it seems) the spec. has an ambiguity
> about what conversion sequences are allowed for casts.  In this case, the
> code is allowing the reverse of certain multi-step conversions which are
> also defined in the same way by the spec., and (it seems) widely
> implemented.  See the bug 6979683 for discussion.  If you think our reading
> of the spec. is somehow wrong, please let Alex know.
>
> Bottom line:  If the spec. allows (Object)(int) it must also be allowing
> (int)(Object).  My change makes the latter available to users of the RI of
> javac.
>
> Why now?  Answer: For dynamic language support, specifically in the inner
> workings of JSR 292 code.
>
> -- John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20100901/eca51a65/attachment.html