File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Why doesn't autoboxing work here ?

 
Sreedevi Vinod
Ranch Hand
Posts: 117
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1608
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
marc weber
Sheriff
Posts: 11343
Java Mac Safari
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As Tony points out, autoboxing doesn't allow you to dereference a primitive. But you can do this...

((Integer)count).equals(counter)
 
Sreedevi Vinod
Ranch Hand
Posts: 117
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 195
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic