There has been a lot of debate on the various new Tiger language improvements. One of the most debated is the new static import functionality: static import java.lang.Math.*;
This would allow the math geeks to use:
return cos( sqrt(9) );
instead of:
return Math.cos( Math.sqrt(9) );
but this is controversial…
People are discussing the feature on TSS and elsewhere.
Cedric puts up a defense
The new feature does allow you to bypass qualifying static methods all of the time, and also static variables:
static import javax.naming.Context.*; ... settings.setProperty(INITIAL_CONTEXT_FACTORY, "weblogic.jndi.TengahInitialContextFactory");
One of the main considerations was the fact that currently a lot of people place “constants” in empty interfaces, and have their classes implement that interface to suck in the values. Some people really think this is an antipattern as it tightly couples components together and can be dangerous.
The “right way ™” to do things with 1.5 is to create a class that can’t be instantiated, and use static import to read in the values.
Nic has an interesting idea.
He would like to see an alias setup. If you work with SQL dates and normal Java dates you can get fed up with qualifying the class name all the time:
new java.sql.Date(new java.util.Date());
Nic suggests aliasing:
import SqlDate=java.sql.Date; import StrangeDate=blah.blah.blah.blah.Date; new SqlDate(new Date());
Now that would be a change :/
I don't even like normal * imports
I encourage developers on the teams I work on to avoid * imports unless they're from well-known packages like java.util.* or java.sql.*. I personally don't like having to go hunting through 10 packages to find out where some unknown "DocUtil" class came from. I forsee much more headache if they make it so I'm not just searching for classes but the many methods some sloppy programmers might import.
The alias idea seems like a perfect alternative!
Python style import would be more readable
Why not use a variation on the much more readable syntax from Python?
import java.sql.Date as SqlDate;
import java.util.Date;
Python already has aliased imports
In Python you can import xxx as yyy. Very handy!
I don't even like normal * imports
That's why you have things like IDEA.
I _know_ exactly what class I'm using there, so why should I worry about my imports at all?
Aliassing considered harmful?
Although it seems like a really nice feature, but in my opinion, the aliasing of imported types does more harm than good. What prevents my fellow obfuscators to import foo.Bar as Integer? Or the same type twice with different aliasses?
It will only make understanding the code worse instead of clarifying it.
Python style import would be more readable
Why not just use Python?
I don't even like normal * imports
It is just common courtesy. Someday, if you luck, you are going to find yourself at a client site in someone else's code and you are not going to have your swank IDE available to you. If the original developer was lazy, and imported my.obscure.package.* and my.other.obscure.package.* along with a few other lazy imports, you are going to be pissed as you look for documentation on MyObscureClass and the client is asking every five minutes "How long is this going to take?"
Now if you just took the few minutes it would take to make explicit imports. Everybody's life will be easier.
I don't even like normal * imports
That's why I wrote classfind. See here
I don't even like normal * imports
I agree fully with this practice, and I have used it for years.
Furthermore, I am concerned about the number of major language changes that Tiger is introducing, and I think that most of them are bad. Generics is a feature that sounds great in principle but doesn't work nearly as well in practice. It so complicates both the syntax and semantics of the language that it destroys much of the simplicity of Java. In earlier times I have used similar features in both Ada (called generics) and C++ (called templates), and when I moved to Java I was surprised to learn that, not only could I could live without this feature, but I preferred Java's way of doing things.
I think that the Java community will learn to regret the changes in Tiger.