When to use separate package in java?

Question

Sometimes when I view source java code I notice some files placed in another package besides the default one but have not understood when or why this practice is used. Are there situations where you must or mustn't use separate packages? Anyone care to explain please?

Answer 1

The short answer:

Use packages when your project requires a specific organization or hierarchy to it, or when your framework disallows the use of the default package. For simple CS projects, it can be overkill.

The longer answer:

Packages are folders recognized by Java that allow you certain perks:

• You can have two classes that are named the same that live in different folders, without causing conflicts.

  A common example is java.util.Date and java.sql.Date; depending on what you're doing, you may wind up using both. If you do, you'd have to use the fully qualified class name, which is like writing java.util.Date date = new java.util.Date();.

• You give your project a sense of hierarchy and organization; giving each class a sensible place to "live".

• Classes that have package-private methods and/or fields will not be accessible across package boundaries, which can be desirable in certain cases.

---

Take, for example, my current project. I have decided to write a metadata parser that will read MP3, FLAC, Vorbis, and AAC files.

Right away, I have four common interfaces:

MP3
FLAC
Vorbis
AAC

...however, these are all really compression formats (and FLAC is lossless, so there's no compression there), so they belong in a place that conveys that.

name.makoto.format
  - MP3
  - FLAC
  - Vorbis
  - AAC

That's all good and dandy. But where would the class that actually does the parsing live? What if it lived in a reader package?

name.makoto
    - reader
        MediaReader
    - format
        MP3
        FLAC
        Vorbis
        AAC

Suppose now I want to implement those format interfaces. Doesn't make sense to have them living at the same level as the interfaces themselves, since those are just an API into what the actual object will be anyway. Let's move that to an impl package.

name.makoto
    - reader
        MediaReader
    - format
        MP3
        FLAC
        Vorbis
        AAC
        - impl
            MP3Impl
            FLACImpl
            VorbisImpl
            AACImpl

I'd go on, but it gets kind of crazy from here.

What I have here is a sense of hierarchy and structure to my project. It's a sizable project, so I could benefit from the organization.

Answer 2

The most important use of packages is to organize code into modules that are bigger than individual classes.

By default (unless you make them public) fields, methods, and classes are not visible to code outside of the same package. This provides for "information hiding" and enforces de-coupling of your modules (so that they can only communicate via public interfaces and you can change implementation details of each package independently).