(Not So) Stupid Questions 4: Assigning Packages Blog

    (Not So) Stupid Questions

    Assigning Packages

    Editor's note: Sometimes, the most interesting discussions begin when someone says, "This may be a stupid question, but ..." If the person asking the question has taken the time to think about the problem before asking, the question is often not stupid at all. Uncertainty points out an ambiguity in the specs, holes in the docs, or a search for how more experienced programmers might address a particular problem. From time to time, we will publish one of the "(Not So) Stupid Questions" we receive and invite our readers to answer the question in the feedback section.

    Remember that new people are joining the Java community all the time and may be looking for help from those with more experience. Also, those who began with Java as their first language can benefit from those coming to the community with experience in other languages. As always, answer the questions with kindness. You are also welcome to submit your questions to .

    This may be a stupid question, but ... "I have no idea when to create a new package and what should go in it."

    First thoughts:

    I have recently joined an open source project where all of their classes are in one single package that is more of a namespace than anything else. My first impulse is to suggest that they organize the project into packages and subpackages, but how do you decide what goes where? I've looked around for documents online, but most talk about packaging for deployment modules. I've looked at the java and javax packages to try to figure out what the recommended practices are.

    Once you move some classes around and package them, you have to change accessibility and you might introduce dependencies. How do you balance organizing your project against introducing possible dependencies between packages? Is there a magic number of classes in a package that is too small to warrant a package, or too large to be  a single package?

    This brings me to three questions:

    1. When do I introduce a new package?

    2. How do I decide whether or not the package is a sibling to an existing package or a subpackage? and

    3. When should a class be moved from one package to another?

    (Not So) Stupid Questions is where we feature the questions you want to ask, but aren't sure how.