February 2004 Archives

There are some import static nuances that didn't come through in the Java 1.5 public review draft spec; I didn't understand them until I started writing actual code. First, remember that methods can be overloaded (and fields and member types can have the same name as a method) so import static can import more than one static member. It imports a name into the namespace, not any particular member. For example, this line imports the name sort:

import static java.util.Arrays.sort;

java.util.Arrays defines 19 different sort methods. The compiler performs method overload resolution with the imported name sort() just as well as it would for the qualified name Arrays.sort()

That isn't all that surprising, once you think about it. Now look at these lines of code. Illegal right?

import static java.util.Arrays.sort;
import static java.util.Collections.sort;

Actually, these lines are not illegal. The static sort() methods of these two utility classes have distinct signatures, and so these two import declarations do not introduce any namespace collisions, even though it looks like they do!

Another thing I found surprising

Inspired by Gilad Bracha's generics tutorial, I put together a glossary for commonly used generics terminology that you might find helpful in conjunction with the tutorial or with your own investigations of generics.

The glossary is below. Comments and corrections are particularly welcome.

The generics tutorial I mentioned earlier, has now been released on the web (in pdf format).

It was written by Gilad Bracha, the spec lead for JSR -14 which created generics. If you want to understand generics, this is a great place to start.

I received 14 comments on my post about the appropriate name for the "enhanced for loop". I still like my own suggestion of "auto-iterator loop", but apparently no one else did.

There doesn't seem to be a consensus, but "foreach" or variations like "for each" and "for-each" (the space or hypen help to indicate that this is not a keyword) are by far the most popular.

jez gets the award for funniest suggestion. He wants to call it the "five" loop.

I just had the pleasure of reading a draft tutorial about how to actually use generics. Its written by Gilad Bracha, the spec lead for JSR 14 which defined generics. It is authoritative, but is much easier to read than the public review draft of the generics spec.

Look for this on Sun's web site next week. I found it very helpful.

Java 1.5 introduces a new looping construct that the public review draft calls the "enhanced for loop". That name is fine for the JSR process, but I don't think it will catch on for colloquial use, and I don't think it is suitable for those of us who have to write books about the new features of the language. The problems with "enhanced for" as I see them are:

• It inaccurately implies that this new for loop is somehow an enhancement of the original one. But it is not. It is often useful in place of the original for loop, but it is a completely different construct. It would be more accurate to call it the "new for" instead of "enhanced for". But this brings us to the second problem:
• Both "enhanced for loop" and "new for loop" are vague names that are not descriptive. They beg the questions "enhanced how?" and "what's new?"

So, I think we need a different name.

In Java 1.4 and before, the equality operators == and != allow you to compare two booleans, two numbers, or two references. Any other combination of operands was a compilation error.

In Java 1.5 auto-unboxing enters the picture. It is now possible to compare a boolean with a Boolean, and a number of primitive type with a number expressed as a reference type. That is, it is no longer a compilation error to use the equality operators with a primitive on one side and a reference type on the other. (The public review draft for autoboxing doesn't get this right. I have reported the bug, and the beta-release implementation appears to be correct.)

Now where it really starts to get interesting

I've been brushing up on some of the more obscure corners of Java. Here's a pop quiz:

1 << 32 evaluates to:

1. 0x100000000
2. 0
3. 1

Answers below...

Inspired indirectly by my post about the longest class name in J2SE, Rob Chartier looked for the longest and shortest type names in .NET

Looks like he includes the .NET equivalents of package names and nested class names, and also considers non-public types, so his results for .NET can't be directly compared to my results for Java.

In any case, this is not a healthy arena for competition between Java and .NET!

The Beta1 release of Java 1.5 is now available.

Sun has also published an article documenting the important new features of this release. (Hey, they stole the article title from my book) I haven't read the article carefully yet, but it looks like an informative overview.

As I noted earlier, there is still time to try out the new language features and comment on them in the JSR 201 public review.

This surpised me. The following program does not throw a NullPointerException

public class StaticFieldThroughNull {
    public static void main(String[] args) {
	Double d = null;
	System.out.println(d.MAX_VALUE);
    }
}

This really is supposed to work this way. See the JLS.

Check out the example at the end of the section of the spec linked above. Its even more surprising than mine, because it uses a method that returns null rather than a null variable.

Back in 1996 when I was writing the first edition of Java in a Nutshell, the book designers on the production team at O'Reilly need to know the longest class name so they could make sure it would fit in the title of reference entries. At the time it was StringIndexOutOfBoundsException at 31 characters. Tonight, I wondered if that record still stood...

So I used find, echo wc, grep, sed, and sort (isn't Unix great?) to process the filenames in the javadoc directory of J2SE 1.4.2 and find out what the longest class name is. I did not count the length of the package name, nor did I include inner classes in my count research. StringIndexOutOfBoundsException is still the longest class in java.lang, but it is matched in length by java.util.ConcurrentModificationException, and exceeded by 16 classes in less commonly used packages.

The longest of all, standing alone at 36 finger-fatiguing characters is javax.xml.transform.TransformerFactoryConfigurationError. The complete list of class names >= 30 characters is at the end of this post.

And what about short class names?