Organize packages in a java project


When creating a project on Android , the IDE itself suggests that the main package have its own naming type (com.example.packagename), and it also creates a whole hierarchy of already defined directories.

As with Android , is there any convention to follow when programming in java (whether desktop or web), about organization and naming of application packages, or is only MVC applicable for this type of organization?


Oracle itself defined certain conventions to avoid conflicts between Java classes from different programmers/companies/projects.

She suggests that a company (or any programmer) use their own inverted web domain as the name of their packages (since the domain is unique). Example: my company has the domain . The main package of my projects would be defined as follows:


For cases where the web domain is not a valid package name (has a hyphen, dots, starts with digits, etc), Oracle suggests using the underscore _ . Example: my domain is , so my package would be:


In addition to this top level organization suggested by Oracle, the rest basically becomes the opinion and preference of each programmer/company. A tip for when your project gets too big is to separate it into modules that deal with only one category of functionality. Example: you have X classes in your project that deal only with database access, so put them in a db :


and another sub-package could be called package; and would contain your classes that deal with operating system files.

And a final tip, take a look at big open source projects. Analyze how they are organized. Some java projects I've had contact with and recommend to get a better idea of ​​the subject: Apache Hadoop , Apache Giraph and Apache Hama .

But before setting out to create packages with names that have 40 characters, an invocation spell and the blood of a virgin, consider whether this is really necessary. If you're just doing a pet project (a project to learn something new that won't really be used by anyone), it's hardly going to be necessary to encapsulate your project in a package.


Scroll to Top