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
// Make "out" refer to System.out
import static java.lang.System.out;
public class StandardOut {
// Now we shadow the imported name
static java.io.PrintStream out = System.err;
public static void main(String[] args) {
// This line writes to System.err
out.println("Hello, World");
}
}
This isn't meant as criticism of static import; just an exploration of it. Static import is one of the more controversial new features of Java 1.5, but I think that overall, it is a good thing. The confusing thing about the code above is not the static import. It is the misleading line that assigns System.err to a field named "out"
Holy crap. I think I'll be forced to shoot the first developer who tries to use this shite on one of my projects ;-)
The imports:
(import static java.lang.System.out;import static java.util.Arrays.sort; import static java.util.Collections.sort;) are NEVER used.
Any decent IDE would flag this.
Why dont you put on yor thinking cap and come up with an interesting example.
>"This isn't meant as criticism of static import;"
Static imports are evil.It was a STUPID idea.They are only usefull for obdfucating source code.
yeah, static imports are just confusing..don't see their added value..
to person above:
>Any decent IDE would flag this.
haha, which decent IDE suports java 1.5? Omnicore is the one that suports it..what's second decent one?
Any decent IDE would flag un-used imports.
The anonymous "Dum Example" reader above has missed the point: it is surprising (at first) that importing a static member does not prevent you from defining another static member with the same name. The reason that this is surprising is that when you import a toplevel type, you cannot (obviously) define a toplevel type with the same name.
The fact that some IDEs flag unused imports is not relevant to my point here.
David's example is fine and I don't see anything terribly surprising in the behavior. I like the new static imports. I think it will make a lot of code more readable and certainly more pleasant to write.
People who rely heavily on IDEs may not see any great benefit to this but they certainly won't be harmed.
Pat
import java.awt.Button;
//import org.eclipse.swt.widgets.Button;
>The anonymousreader above has missed the point.
I did not miss the point.I just thought your examples were un-interesting .I do not need Tiger to come up with with an example just as Stupid:
public class AnotherStupidExample {
class Button{}
}
//-------------------------------
>import static java.util.Arrays.sort;
>import static java.util.Collections.sort;
>Actually, these lines are not illegal.
Did you try using these methods?
Now that example is just as un-interesting.
DumExample/StupidExample:
Thoughtful comments on this blog are welcome, even from anonymous posters. Courtesy suggests, however, that you try to be less insulting in your comments.
Your comments have been fairly cryptic, but I gather that you think (1) static imports are a bad idea and (2) my examples are boring. If those are your only points, then you've made them and we're done.
To respond to your most recent comment, however:
Yes, I did try using the sort() method after importing it. If you import sort() from Arrays and Colletions, then you can indeed use the unqualified name sort to sort either an array or a List.
The example you give in your comment uses a member type to shadow a top-level type imported with a type import statement. This is similar to what I was demonstrating in my original post, but not the same. I was demonstrating that static import allows you to import a member type and then hide that type with another member type. This is surprising (at least a little) if you think of static import by strict analogy to the standard type import: when you import a toplevel type, you can't define another toplevel type with the same name. Thus, you might expect that when you import a static member, you would not be allowed to define another static member with the same name.
This is not a big deal. I did find it interesting enough to include an entry in my blog.
Now can we drop the "uninteresting" comments?
Now, say you static import a bunch of CENTER fields (everyone should be cringing), obviously you'd have to qualify those, right? JButton.CENTER, FlowLayout.CENTER, the method that "CENTER" is being passed has no way of resolving which value of CENTER you meant.
Guy,
I believe (but have not tested) that the compiler will not let you do this. Unless you use a wildcard:
import static javax.swing.JButton.*;
import static java.awt.FlowLayout.*;
And if you do this, the compiler won't let you use CENTER without qualifying it with a typename.
The same is true about static import of methods if they have the same argument types as well as the same name.
I think these experiments are most interesting. I can think of some good uses for import static (e.g. the import of the System.out-method you described above).
I can equally think of bad uses (e.g. the sort-thing described above). If you don't use an IDE, it will be damn hard to find which sort-method is used in the latter example. And even with an IDE, it gets really hard to understand what's happening.
Furthermore, for the first case, the "out" can easily be 'imported' in previous java-versions using the following statement:
PrintStream out = System.out;
So, for static member _variables_, nothing really changed. And static _methods_ look somewhat dangerous to me.
So I tend to conclude that using these static imports is not really a good idea. And IF you do, do so with extreme care :)
You bring up an interesting point that I didn't consider before: actually being able to do the static import when it looks like you shouldn't be able to. Thanks for the insight!