aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Why doesn't autoboxing work here ? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Why doesn Watch "Why doesn New topic
Author

Why doesn't autoboxing work here ?

Sreedevi Vinod
Ranch Hand

Joined: Jan 17, 2005
Posts: 117
I tried compiling this code, but line 6 is not compiling. Can someone tell me why the primitive 9 is not getting autoboxed into the wrapper object type in this case ?



Thanks
Devi
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608
Attempting to dereference a primitive type does not imply that it is boxed.

Take a look at section 5.1 of JLS 3.0 proposed.
http://java.sun.com/docs/books/jls/jls-proposed-changes.html


Tony Morris
Java Q&A (FAQ, Trivia)
marc weber
Sheriff

Joined: Aug 31, 2004
Posts: 11343

As Tony points out, autoboxing doesn't allow you to dereference a primitive. But you can do this...

((Integer)count).equals(counter)


"We're kind of on the level of crossword puzzle writers... And no one ever goes to them and gives them an award." ~Joe Strummer
sscce.org
Sreedevi Vinod
Ranch Hand

Joined: Jan 17, 2005
Posts: 117
hi

I downloaded the JLS file java_language-3_0-mr-spec-1.zip and went through the file conversions.pdf. However I could not find the exact statement which states that it is not allowed to dereference a primitive type as I've shown above. Can some one direct me to the exact point stating this in this JLS file ?

Thanks
Devi
[ April 16, 2005: Message edited by: Sreedevi Vinod ]
Joe Sondow
Ranch Hand

Joined: Apr 10, 2005
Posts: 195
I haven't read the document, so I can't make any assurances about whether or not it explicitly states that you cannot dereference a primitive variable.

However, it is generally best to assume that the documentation will only tell you what you can do, rather than tell you all the things you cannot do. If you cannot find a place in the document where it says you can dereference a primitive because of autoboxing, then that should be sufficient explanation for why it doesn't work when you try it.


SCJA 1.0 (98%), SCJP 1.4 (98%)
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
The problem with that is that it would be nearly impossible to ever be sure the rule you're looking for is not in the JLS somewhere. In general the JLS does specifically tell you if something is illegal and results in a compiler error. In this case however, I believe they've accidentally omitted the relevant rules. Compare sections 15.11 and 15.12. The first gives rules for field access. If you have an expression of the form Foo.bar, that fits the pattern Primary . Identifier. Which leads us to section 15.11.1, which tells us: "The type of the Primary must be a reference type T, or a compile-time error occurs." This tells us unambiguously that if you have an expressions Foo.bar, then if Foo is a primitive type, that's an error. Period. No possibility of autoboxing is mentioned; it's not an option in this context. Good, that's clear.

However, we're not interested in field access; we're interested in method access. That's covered in the next section, 15.12 - and there is no clear statement that a Primary must be a reference type in this section. The closest is this, from 15.12.1: "If the form is Primary . Identifier, then the name of the method is the Identifier. Let T be the type of the Primary expression; then the class or interface to be searched is T if T is a class or interface type, or the upper bound of T if T is a type variable." OK, great, so what if type type of Primary is not a class, interface, or type variable, but a primitive? No mention. However in 15.12.2 we search "the class or interface determined by compile-time step 1 (15.12.1)" for applicable methods, and are told it's a compile-time error if no methods can be found. If type T was primitive, we were never told what type to search for applicable methods. I suppose we may infer that the search fails in this case, and a compile-time error occurs. That's certainly what happens when we compile with a real compiler. But the specification is annoyingly vague here.

Note that this problem was present in previous editions of the JLS as well. It's a bit more of an issue now that autoboxing has been introduced. As we've seen in this thread, the existence of autoboxing leads people to expect boxing in some cases where it doesn't actually happen; the JLS should explicitly state that a compile-time error is the result here.
[ April 16, 2005: Message edited by: Jim Yingst ]

"I'm not back." - Bill Harding, Twister
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Why doesn't autoboxing work here ?