Why is using the default package discouraged?

[J. Chris Miller]

Topic.

[Paul Clapham]

Classes which are in packages can't import classes which aren't in packages (which is what it means to be in "the default package"). That's just how the language turns out to work. You can't write "import Example", in other words.

And since any non-trivial application is usually divided into packages, classes in the default package aren't useful there. So if you're writing a quick and dirty program to do something, then putting it in the default package is okay. But if it's for real work, then it probably needs to be in a package.

[Henry Wong]

A better question would be "why is packages encouraged"? Packages are name spaces. It allows everything in the package to have some sort of a group name -- in addition of their names. This means that many teams can develop independently of each other, and not be too concerned about naming conflicts.


If all you intend to do is develop small programs, and not really work with anyone else, then I guess it should be fine. However, it is very easy to use packages, so why should you avoid it?

Henry

[J. Chris Miller]

So what should you name the package? A similar name to the Project?

[Jeanne Boyarsky]

On a "real project", it would be the company website name in reverse and then the project or anything after it. So com.coderanch.jforum.

For my test code, I often pick jb. as the package prefix.

[Paul Clapham]

And as always, There's A Tutorial For That™ -- Creating and Using Packages. The second page in that tutorial thread answers your recent question.

[Nam Ha Minh]

I think most developers use packages to organize their code structure better, e.g. separating code in different layers like model, DAO, bussiness, services, etc.
Also sometimes we separate code by functionality e.g. users, admin, books, sales, products, etc.