What is the suggested way to name Java packages?

I've seen lots of examples like com.mycompany.someapp. Seems to be the reverse of th开发者_Go百科e domain. Which actually makes sense to me.

But at the end of the day, does it really matter? We are a small shop so maybe we don't see the benefits of proper domain naming.

So, is it good practice to name it to match the domain? If so, why?

Extracted from the link to Naming a Package (Java Tutorial) in Andrew's comment: (I claim no originality or ownership of the following).

Naming a Package

With programmers worldwide writing classes and interfaces using the Java programming language, it is likely that many programmers will use the same name for different types. In fact, the previous example does just that: It defines a Rectangle class when there is already a Rectangle class in the java.awt package. Still, the compiler allows both classes to have the same name if they are in different packages. The fully qualified name of each Rectangle class includes the package name. That is, the fully qualified name of the Rectangle class in the graphics package is graphics.Rectangle, and the fully qualified name of the Rectangle class in the java.awt package is java.awt.Rectangle.

This works well unless two independent programmers use the same name for their packages. What prevents this problem?

Naming Conventions

1. Package names are written in all lower case to avoid conflict with the names of classes or interfaces.

2. Companies use [their] reversed Internet domain name to begin their package names—for example, com.example.mypackage for a package named mypackage created by a programmer at example.com.

3. Name collisions that occur within a single company need to be handled by convention within that company, perhaps by including the region or the project name after the company name (for example, com.example.region.mypackage).

4. Packages in the Java language itself begin with java. or javax.

In some cases, the internet domain name may not be a valid package name. This can occur if the domain name contains a hyphen or other special character, if the package name begins with a digit or other character that is illegal to use as the beginning of a Java name, or if the package name contains a reserved Java keyword, such as "int". In this event, the suggested convention is to add an underscore. For example:

Legalizing Package Names Domain Name   Package Name Prefix
hyphenated-name.example.org            org.example.hyphenated_name
example.int                            int_.example
123name.example.com                    com.example._123name

Happy coding.

Matching the domain gives you greater confidence against name collisions. It's probably more important to designers of 3rd party libraries than you and your app.

Yes, that's the suggested convention in the Java Language Specification, section 7.7.

If unique package names are not used, then package name conflicts may arise far from the point of creation of either of the conflicting packages. This may create a situation that is difficult or impossible for the user or programmer to resolve. The class ClassLoader can be used to isolate packages with the same name from each other in those cases where the packages will have constrained interactions, but not in a way that is transparent to a naïve program.

You form a unique package name by first having (or belonging to an organization that has) an Internet domain name, such as sun.com. You then reverse this name, component by component, to obtain, in this example, com.sun, and use this as a prefix for your package names, using a convention developed within your organization to further administer package names.

You don't have to follow the convention, but it's generally considered good practice. After all, suppose at some point in the future you want to release some of your code as open source - but you want to avoid naming collisions. At that point, you really ought to follow the same conventions as everyone else - and as it doesn't hurt to do so from the start...

The idea behind using domain name is to avoid namespace collisions in packaging. This only works if everyone follows the convention. So, yes, the convention is important. That said, if you never plan on exporting your code as an API or providing it to a third party, it's likely there is little downside to using whatever package name you feel like.

Practically speaking I like it for a number of reasons:

• It gives users an easy place to go to just from looking at the package name
• It avoids collisions between packet names (i.e. two "media" packages could be very likely otherwise)
• It helps identify the same author over separate pieces of software
• It keeps package names roughly the same length (ok, this is just an aesthetic point but I like it!)

As well as this, it's also recommended in the JLS. It's not a requirement, but when it's practically 0 effort to do, I'd do it unless there's a good reason otherwise.

Perhaps a better question to ask is why don't you want to follow that convention? If there's no real reason, there's no harm in following it!

The main aim is to guarantee uniqueness of package names, but if you're never going to release code for others to use then it probably doesn't matter, but there is a lot to be said for sticking with convention and worrying about the stuff that does matter. Otherwise come the day that you realise you have a great library that you want to share you could be kicking yourself for going against the flow.

Yes, it is sensible to always use a naming scheme. As a counter-example, assume that everyone would use the default package for their classes.

Common classes like User or Address would be used by several libraries, but in the end there can be only one class of a certain name in the runtime environment. (loosely speaking, it is not completely correct.)

In big projects you will likely use many external libraries, like Apache Commons, Google Guava, Spring, Hibernate, Terracotta. It's good that these libraries all use their own namespace, so that their internal classes do not accidentally conflict.