Because interfaces are static, public and don’t change, by definition any members you declare in them are static, public and final. Therefore you don’t need to qualify such members.

For example:

public interface A {
  String FOO = "foo";
}

is the same as:

public interface A {
  public final static String FOO = "foo";
}

You can read some more about this in the forum Interface member variable by default static?

I never liked seeing people put constants in an interface and then implementing that interface in a class so that they can have direct access to those constants. That always seemed wrong to me and now this Sun article, Static Import, verifies my intuition.

In order to get around this, people sometimes put static members into an interface and inherit from that interface. This is a bad idea. In fact, it’s such a bad idea that there’s a name for it: the Constant Interface Antipattern (see Effective Java Item 17). The problem is that a class’s use of the static members of another class is a mere implementation detail. When a class implements an interface, it becomes part of the class’s public API. Implementation details should not leak into public APIs.

The suggested method is to use a static import.

import static java.lang.Math.PI;

However the article suggests using this sparingly.

Only use it when you’d otherwise be tempted to declare local copies of constants, or to abuse inheritance (the Constant Interface Antipattern). In other words, use it when you require frequent access to static members from one or two classes. If you overuse the static import feature, it can make your program unreadable and unmaintainable, polluting its namespace with all the static members you import. Readers of your code (including you, a few months after you wrote it) will not know which class a static member comes from. Importing all of the static members from a class can be particularly harmful to readability; if you need only one or two members, import them individually. Used appropriately, static import can make your program more readable, by removing the boilerplate of repetition of class names.

You can also do static import of methods.

import static com.betweengo.util.CollectionUtils.isEmpty;

However I would never do this, I like knowing where my static methods come from.

I always forget how to do these things so I thought I should write it down.

Changing Dates:

Here is an example of getting the date for seven days ago from now.

    Calendar sevenDaysAgo = Calendar.getInstance();
    sevenDaysAgo.add(Calendar.DATE, -7);
    sevenDaysAgo.set(Calendar.HOUR_OF_DAY, 0);
    sevenDaysAgo.set(Calendar.MINUTE, 0);
    sevenDaysAgo.set(Calendar.SECOND, 0);
    sevenDaysAgo.set(Calendar.MILLISECOND, 0);

Formatting Dates:

Here is the simple way to format a date and time.

    DateFormat.getDateTimeInstance().format(sevenDaysAgo.getTime()))

The output is:

    May 21, 2008 12:00:00 AM

Note that according to the JavaDoc, DateFormats are inherently unsafe for multithreaded use. You should not make a call to a static instance of a DateFormat nor share a single instance across thread boundaries without proper synchronization.  The same applies to Calendar.  For more information on this see Sun Bug #6231579 and Sun Bug #6178997.

Creating Dates:

Here is an example of creating a date, the birth date January 1, 1970.

    Calendar birthDate = Calendar.getInstance();
    birthDate.clear();
    birthDate.set(Calendar.YEAR, 1970);
    birthDate.set(Calendar.MONTH, 0);
    birthDate.set(Calendar.DATE, 1);

For further reading please Create a Date object using the Calendar class and of course the JavaDocs for Calendar, Date and DateFormat.