Is the Use of Java's Default Package a Bad Practice

Is the use of Java's default package a bad practice?

Yes, it is. Ideally, package names should be globally unique, to avoid naming collisions. Using the default package breaks this convention. It's also impossible to import a class from the default package.

Why do unnamed packages exist at all, if it's such a bad idea? From the JLS §7.4.2:

Unnamed packages are provided by the Java platform principally for convenience when developing small or temporary applications or when just beginning development.

Is it considered bad practice in java for a package to contain both classes and sub-packages?

No it's normal structure and not a bad practice. You have different levels in the tree structure. If the class logically is best suited in the parent package then leave it there. If these two classes share a common role that differs them from the others then you can move them to a separate package.

Why shouldn't we use the (default)src package?

Using the default package may create namespace collisions. Imagine you're creating a library which contains a MyClass class. Someone uses your library in his project and also has a MyClass class in his default package. What should the compiler do? Package in Java is actually a namespace which fully identifies your project. So it's important to not use the default package in the real world projects.

Is this a good practice to use the default Java access to hide classes and methods from client

The "default" access does not guarantee much of anything, since any rogue programmer can declare their class in your package. Also, regardless of your package structure, in java, you almost always can do an "instance of" check, and then downcast to the "instance of" type. So, if your goal is to prevent any downcasting whatsoever, you must use the private keyword. For example, you can declare the concrete implementations of your Product interface as private static or as anonymous inner classes within your Factory. Indeed, in Bloch's "How to design a good API" article, he makes a point that you should "Minimize Accessibility of Everything."

That said, I think you're being a little paranoid here. Does it really matter that much to you if somebody downcasts? Any code that you write can be misused, and certainly if you include a well-documented factory then you have provided clear information about how to use your API properly. Also, if you build a real factory method that takes arguments and has clear method names, as opposed to this toy Factory example that takes no arguments, then I think you'll find that you're broadcasting the publicly relevant part of what's being created anyway.

Is it a bad practice to import all the sub classes of a class at a time?

To be specific, what exactly is the difference between import java.applet.*; & import java.*;

The first import makes all types (classes, interfaces, enums) from the java.applet package visible to the compiler, while the second makes all types from the java package visible.

Note that there is no "subclass" relationship between packages - packages make up a package hierarchy, but not a class hierarchy. With a wildcard import (import package.*), all types from one single package are imported, not from a whole package hierarchy. In particular, import java.* does not import java.applet or any other package below java in addition.

In practice, by the way, you should avoid wildcard imports at all as they pollute your name space and might cause naming conflicts when identical type names exist in different packages. Most IDEs today organize the imports (semi-)automatically, so there is no need to use the wildcard import.

Can I set the default package in java?

I'm sure enough that all of these are not possible to just post, "no, these are not possible." Note you can't do it with reflection since these are all compile-time questions.

(4), "can I change the default base class from Object," is not like the others, and is the most ludicrous. That would break many many programs at compile, because even doing something like System.out.println(user) relies on the fact that the object user has a toString method. In particular String is broken, because its toString method is inherited from Object.

Everything else you asked is compile-time only, so less ludicrous, but still not possible.

For completeness, it also would be strange and bad practice. I've heard of a C programmer who included #define retrun return in a headers file. So when any other developer maintaining his code saw retrun eta; they had to dig out the headers file to know what it meant. This is write-optimized code but software engineering is about read-optimizing code (yes I'm generalizing; trying to cover this in a paragraph). Cluttered imports do that - it makes it very obscure to tell where things come from, which is fine for String and Exception, but problematic even for things in java.util. Yes, this line was arbitrary at some point, but I feel it's intelligent and certainly should not include more things.

Is it possible to avoid package and import statement?

package is mandatory if your class finds itself in a package other than the default package

---

If you don't want to use import you may simply use the fully-qualified name of the class like for example java.util.regex.Pattern

---

Related Topics