Java Namespace - Two classes with the same name in different packages

Question

I am coming from Objective-C where we don't have packages and namespacing.

Android has android.text.format.DateFormat which has static methods that return java.text.DateFormat instances (getLongDateFormat() and getMediumDateFormat() specifically).

1. Are these methods referred to as "static methods" or "class methods" or both interchangeably?

2. Looking at Android documentation, how am I suppose to know that the android.text.format.DateFormat methods return a java.text.DateFormat instance and not an android.text.format.DateFormat instance (returning an instance of the latter is what I initially expected)?

3. How do I import the necessary packages to be able to use both of these classes in my source?

4. Is it possible to write my implementation code this way:

DateFormat df = DateFormat.getLongDateFormat(this.getActivity());
mLabel.setText(df.format(mEvent.getDate());

The other way I would write it would be to use the full package names, but this seems unnecessary:

java.text.DateFormat df = android.text.format.DateFormat.getLongDateFormat(this.getActivity());
mLabel.setText(df.format(mEvent.getDate());

Answer 1

Not sure why this is downvoted, it's a useful discussion.

1) I've always heard them referred to as "static methods".

2) The only way to see it is to follow the links. The documentation is definitely misleading in this case.

3/4) The typical way to do this in java is to not import one of the classes, and fully-qualify its class name. So if you elected to import java.text.DateFormat and not the android version, you'd do something like DateFormat df = android.text.format .DateFormat.getLongDateFormat(this.getActivity());

Answer 2

1. From the JLS:

   A method that is declared static is called a class method.

   I would say that I hear "static method" used more often than "class method", but both are in use and should be understood by competent Java developers.

2. The only option would be to hover the links on the return values. This is an example of extremely poor API design, with a name conflict built in, and the android.text.format.DateFormat should have been named something like DateFormatFactory. It appears that this class may have been intended to serve the same purpose as the java.text class originally and that API compatibility left it stuck. See java.sql.Date for a similar story.

3. Using import is a convenience only, allowing you to use the simple class name in your code. It's always legal to use a fully-qualified class name, and the compiler translates imported class names into fully-qualified ones. You can't import multiple classes with the same name because then there's no way to distinguish them

4. I suggest importing the class from java.text for two reasons: You'll probably be using it more often, and it's the more "standard" class. When faced with the choice of qualifying one of two classes with the same simple name, use the simple name for the one that developers would usually assume it refers to.