Static import in jdk 5.0

[Santosh Maskar]

hi
In jdk5.0 ther is a concept somthing called as static import , what this meas , i already read this documentation but not cleared

anybody ........knows how this static import in the application , why it needs really.

[zmarak ahmad djan]

import static java.awt.BorderLayout.* ;
 
...
...
 container.add(component, CENTER); //instead of BorderLayout.CENTER

so it's syntactic sugar
my advice: don't overuse (specifically don't overuse with static methods)

[Santosh Maskar]

Originally posted by zmarak ahmad djan:

import static java.awt.BorderLayout.* ;
 
...
...
 container.add(component, CENTER); //instead of BorderLayout.CENTER

so it's syntactic sugar
my advice: don't overuse (specifically don't overuse with static methods)

what is the differce between

import java.awt.BorderLayout.* ;
container.add(component, CENTER);

VS

import static java.awt.BorderLayout.* ;
container.add(component, CENTER); //instead of BorderLayout.CENTER

[zmarak ahmad djan]

code number one will issue an error
Borderlayout is not a package

[Julian Kennedy]

It's something I've been wishing for for a while. It can be used to make code more readable in a lot of cases. I'm particularly thinking of (a fairly common case in my experience) the following:

switch (aVariable) {
    case AnnoyinglyLongClassNameConstants.A_CONSTANT_ONE:
        methodOne(AnotherStupidNameConstants.SOME_VALUE);
        break;
    case AnnoyinglyLongClassNameConstants.A_CONSTANT_TWO:
        methodTwo(AnotherStupidNameConstants.ANOTHER_VALUE);
        break;
    default:
        Logger.log("Unknown annoying constant: " + aVariable);
}

Using static imports this can be simplified to:

switch (aVariable) {
    case A_CONSTANT_ONE:
        methodOne(SOME_VALUE);
        break;
    case A_CONSTANT_TWO:
        methodTwo(ANOTHER_VALUE);
        break;
    default:
        Logger.log("Unknown constant: " + aVariable);
}

Typically in these kind of situations the package that the constant relates to is clear from the context and the actual constant name. The package name in these cases is just syntactic noise (opposite of sugar?).

The only arguments against the inclusion of static imports in Tiger that I've heard is that they can be abused. So name me a feature of Java that can't. :roll:

Jules

[Tony Morris]

switch (aVariable)
{
    case AnnoyinglyLongClassNameConstants.A_CONSTANT_ONE:
        methodOne(AnotherStupidNameConstants.SOME_VALUE);        
        break;    
    case AnnoyinglyLongClassNameConstants.A_CONSTANT_TWO:        
        methodTwo(AnotherStupidNameConstants.ANOTHER_VALUE);        
        break;    
    default:        
        Logger.log("Unknown annoying constant: " + aVariable);
}

Unfortunately, the J2SE 5.0 static import mechanism is going to promote this kind of atrocity even further.

One should consider using a java.util.Map keyed by what would otherwise be the arguments to the case statements, whose values are of some abstract type that performs the common behaviour. Procedural programming constructs generally do not belong in an object-oriented language.
[/PURISM]