[Syntax-jsr] Re: [Java Spec Report] Re: JSR 201 autobox comments

Hi Neal,

According to Gilad Bracha, extending the reflection API was not an
insurmountable obstacle.  As a recall, the extension primarily
involved statically overloading existing methods to use the new
interface types in place of the existing wrapper class types.

The .equals problem has a clean solution: introduce an operation
.primEquals on the boxed primitives that matches the behavior of == on
primitives.  There is no operation on primitives corresponding to
.equals but it could easily be added.  For boxed primitives, the
semantics of .equals would be defined as it is for the existing
wrapper classes so that autoboxing could be used with hash tables
without any surprises.

The most delicate issue is the definition of == on boxed primitives.
If we introduced new wrapper classes to implement the new interfaces
then my inclination would be to interpret == an abbreviation for
.primEquals if either operand has (static) type Primitive (a common
interface for the boxing interfaces).  Unfortunately, this option is
not available if the existing wrapper classes are used to represent
boxed primitives because the meaning of == is already fixed for these
classes.  Leaving == undefined for boxed numbers other than small
integers is perhaps the best that can be done if the existing wrapper
classes implement the new interfaces.  But

new Boolean(true) == new Boolean(true)  =>  false

is still very ugly.  If the classes for boxed objects were new
classes, then the constructors for boxed representations could all be
private.

As far as the date for FCS on Java 1.5 is concerned, I have been very
impressed by your rate of progress.  I particularly like the support
for wild cards (variance types) that you recently added to the
compiler.  In fact, the whole generic types extension has been well
conceived and orchestrated (even though I still favor adopting first
class generics at some future date [2010?]).  I just wish we had taken
several months longer (six months?) to produce a more carefully
thought out formulation of autoboxing.  We have treated it as a
syntactic hack rather than an opportunity to carefully revise the Java
data model to eliminate some (or most) of the awkward distinctions
between primitive and reference types.  We might even have been able
to provide limited (unoptimized) support for instantiating generic
type parameters as primitive types.

-- Corky



To unsubscribe from this mailing list, send an email to:
[email protected]
 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
     http://groups.yahoo.com/group/java-spec-report/

<*> To unsubscribe from this group, send an email to:
     [email protected]

<*> Your use of Yahoo! Groups is subject to:
     http://docs.yahoo.com/info/terms/