Skip to main content

About Static Imports in Java 5.0.

8 replies [Last post]
kkskrishna
Offline
Joined: 2004-10-14
Points: 0

HI,

The static imports introduced in Java 5.0(Tiger).But, this is not a good feature. It will clutters up the code.I think it should be removed from Java Language.

Regards,
Krishna Srinivasan

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
brucechapman
Offline
Joined: 2004-03-18
Points: 0

And how do you propose removing the static import functionality in a way that doesn't break existing code that uses it?

Sorry, I don't agree with your logic completely, and even if I did, the horse has bolted, it is too late to change this. You should have raised the issue during the relevant JSR review phases. If you did, well done, but obviously you lost. If you didn't, then I don't think you have a right to complain after the fact.

vpatryshev
Offline
Joined: 2004-06-30
Points: 0

It depends on your view. Do you believe, for instance, that mathematical functions "belong" to a special object named Math? There are plenty of operations that are not "object-oriented" at all. Not everything is an object.

And even if something is an object, e.g. we can think of a matrix as of an object - matrix multiplication is not something that belongs to that object or to matix class; it is rather an operation in the _class of matrices_; and if we want to operate within that universe, we can eitehr subclass from Matrices class, or static import its methods (all its methods must be static, I guess).

steveftoth
Offline
Joined: 2003-06-11
Points: 0

True, but when you are writing code in java your context is almost always within an object (the only exception being static functions, there is no 'this' in that context).

when you write...
int x () {
float x = sin( 5 );
...
}
one would assume that this code is the same as writing

int x () {
float x = this.sin( 5 );
...
}

Not

int x () {
float x = Math.sin( 5 );
...
}

which would be the case if you staticly imported the Math class.

IMO static imports are a bad feature that only saves a couple of keystrokes at the expense of readibility and maintainability.

subanark
Offline
Joined: 2004-11-26
Points: 0

static imports should not hurt maintainability. You can just refactor to use/not use static imports.

steveftoth
Offline
Joined: 2003-06-11
Points: 0

Maintainability is all about code readability. If someone new comes onto a project or if the main developer leaves then you have code that must be re-read and digested again. The easier it is for a person who has never seen the code to read it, the easier it will be to fix bugs, add features and 'maintain' it.

Thare are many tools that make refactoring easy, but these same tools also remove the need for useing static imports since they have features like auto-completion that makes typing
Math.sin()
almost trivial ( like in Netbeans/Eclipse/IntelliJ)

Static imports seem to me to be a tool for those people who cannot or will not use an ide.

To that effect it is a bad feature since it reduces code readability.

subanark
Offline
Joined: 2004-11-26
Points: 0

overly verbose code can hurt readability. E.g.
[code]
@java.lang.Access(access = java.lang.Access.Public)
@java.lang.TypeDecleration(type = java.lang.TypeDecleration.CLASS, virtual = java.lang.TypeDecleration.CONCERTE, overridable = java.lang.TypeDecleration.FINAL, floating = java.lang.TypeDecleration.NON_STRICTFP)
com.mycompany.mylab.myproject.MyClass extends java.lang.Object implements {}
{
/*The body of the class is worse*/
}
[/code]

steveftoth
Offline
Joined: 2003-06-11
Points: 0

> overly verbose code can hurt readability. E.g.

If you take it to that extreme, then yes it can. However, the middle ground that java allows without static imports is IMO a good comprimise between explicit declaration of everything and uncertainty of what exactly is being called.

It's like when you can do this in java code...
[code]
class X {
static void myFun(){
System.out.println("x");
}
}

class Y extends X{
static void myFun(){System.out.println("y");}
public static void main (String[] args ) throws Exception{
Y y = new Y();
X x = y;
y.myFun(); //prints y
x.myFun(); //prints x
}
}
[/code]
This kind of code is ambigious unless you know all the methods of x and y and their static states. The proper way of doing this call is.
[code]
Y.myFun();
X.myFun();
[/code]
even though it is legal in the java language, the first method of calling is bad form. The compiler can tell the difference, but can most programmers ? Probably not unless they know everything about both classes.

Without going even more tangental, what benefit does static imports provide besides reduced typing for a programmer? Can't your ide do the same thing for you?

subanark
Offline
Joined: 2004-11-26
Points: 0

Well its bad form to call classes X and Y anyways.

And yes overusing the static imports can be bad, but using them sparingly is good. Usually good for utility functions.
I admit to often using import static on KeyEvent so I don't need to type KeyEvent.VK_LEFT for every switch statement. Chances are someone is not going to define VK_UP.