As Tony points out, autoboxing doesn't allow you to dereference a primitive. But you can do this...
"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
Joined: Jan 17, 2005
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 ?
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.
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 patternPrimary . 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’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com