Are Java references "pointers"?

The difference between Java references and C++ pointers is a much-discussed topic on the Internet. Java purists mostly shun the word "pointer" as a historical abomination that made code insecure. They insist on never calling a Java reference a pointer. However, I found it interesting that Java has a NullPointerException class - not a NullReferenceException.

A few days ago, I happened to come across an article titled "Java is Pass-by-Value, Dammit!" that gave me a part of the answer. In it, Scott Stanchfield tries to clear the confusion about Java's parameter passing - pass-by-reference or pass-by-value - and in doing so, shows that Java references act more like C/C++ pointers than C++ references. The article also mentions NullPointerException in passing and provides a quote from the Java Language Specification (JLS) , 3rd Edition as part of the legacy of pointers in Java. The JLS states (at http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.3.1 - emphasis not mine):
"The reference values (often just references) are pointers to these objects, and a special null reference, which refers to no object."

However, Java does not allow pointer arithmetic as C++ does. Probably to emphasize this and to distance Java from C++, Sun later tried to create a distinction between Java references and pointers. To be fair to Sun, there is a subtle difference between Java references and C++ pointers but it is in the way they are implemented. This is explained in the Best Rated Answer on the page http://www.geekinterview.com/question_details/32288. However, the behavior of both is the same, as far as programming with them is concerned (except that many memory-related problems are avoided by eliminating pointer arithmetic).

Primitive Assignments in Java

While studying to upgrade my Sun Certified Java Programmer status from version 1.4 to version 6, I came across what appears to be an anomaly in the Java compiler. In Java, a literal integer (like 8) is always implicitly an int, i.e. a 32-bit value. A byte is only 8 bits. However, the following narrowing assignment is legal. No explicit cast is required.

     byte b = 30;

The compiler automatically narrows the literal 30 to a byte. It can do this because 30 is a compile-time constant that is within the range of a byte. Now, recall that a floating point literal (like 43.4) is implicitly a double, i.e. a 64-bit value; but a float is only 32 bits. Consider the following code:

     float f = 43.4;

You might think that this is legal because 43.4 is a compile-time constant that is well within the range of a float. If the compiler obliges us by implicitly casting an int constant to a byte, why shouldn't it do the same for double to float assignments? However, the compiler does no such thing. The above code does not compile. The literal value has to be either explicitly cast to a float, or have an f (or F) appended to it to make it a float literal. Thus, the following assignments are all legal and compile successfully:

     float f = (float) 43.4;
     float f1 = 43.4f;
     float f2 = 43.4F;

Why is the compiler so finicky about floating points? I have not been able to think of an answer. Can you?

C++ After Java

It's true!! I have been assigned to a project requiring me to program in C++. I have to leave my beloved Java programming language and move back in with C++ again. It is now about ten years since I last worked with either C or C++. It occurred to me that there might be others who have been in the same predicament, so I did a Google search on "moving from Java to C++". Lo and behold! It came up with a page with exactly the same title. There is some good stuff there that refreshed my memory about C++. Others might find it useful, too; so here is the link: Moving from Java to C++

I backtracked the link to www.horstmann.com which turned out to be the home page of Cay Horstmann, a computer science professor at San Jose State University and an author of many books on C++, Java and object-oriented programming including Core Java from Sun Microsystems Press. I found it interesting and checked out Cay's blog, too. Good stuff for Java and OO-technology afficionados.