Eclipse Java project folder organization

Question

I am coming to Java and Eclipse from a C#/Visual Studio background. In the latter, I would normally organize a solution like so:

\MyProjects\MyApp\MyAppsUtilities\LowerLevelStuff

where MyApp would contain a project to build a .exe, MyAppsUtilities would make an assembly DLL called by the .exe, and LowerLevelStuff would probably build an assembly containing classes used by the higher-level utilities DLL.

In Eclipse (Ganymede, but could be convinced to switch to Galileo) I have:

\MyProjects\workspace\MyApp

When I create my initial project. There is an option to put source and build files in same folder, but I have .java files created on a path that is reflective of my package hierarchy:

\MyProjects\workspace\MyApp\src\com\mycompany\myapp\MyApp.java

My question is this: when I create subprojects (is that the right Java/Eclipse term?) for .jar files that will be analogous to the above MyAppsUtilities and LowerLevelStuff assembly DLLs in .NET, can (should) I organize the folders equivalently? E.g.:

\MyProjects\workspace\MyApp\src\com\mycompany\myapp\myapputilities\MyAppsUtilities.java

What is the standard/right way to organize this stuff, and how is it specifcally done in the IDE?

Answer 1

Typically you would create related/sub projects as different Projects in Eclipse.

Answer 2

Maven has a well thought out standard directory layout. Even if you are not using it Maven directly, you can think of this as a defacto standard. Maven "multi module" projects are a fair analogy to the .net multiple assembly layout that you described.

Answer 3

Think of Java sourcecode packages as one big namespace. Commercial applications typically live under com.mycompany.myapplication' for example. How you organize stuff under your MyApplication package is largely up to you. The distinction you make for C# between executable (.exe), DLL's and low-level classes does not exist in the same form in Java. All Java source code is compiled into .class files (bytecode) which can be executed by a Java Virtual Machine (VM) on many platforms. So there is no inherent distinction in high-level/low-level classes, unless you attribute such levels via your packaging. A common way of packaging could be for example:

com.mycompany.myapp: main class; MyApp (with a main method) com.mycompany.myapp.model: domain model classes; Customer, Order, etc. com.mycompany.myapp.ui: user interface (presentation or view) code com.mycompany.myapp.service: services within your application, i.e. 'business logic' com.mycompany.myapp.util: helper classes used in several places

this suggests a standalone Java app, it might be different if it is a webapp using one of the many frameworks.

These packages of course correspond to a directory hierarchy in your project.

Now if you deploy this application, it would normally be compiled into .class files and bundled in a .jar (which is basically a fancy name for a .zip file plus some manifest info). Making a .jar is not necessary to run the application, but handy when deploying/distributing your application (using the manifest info you can make a .jar file 'runnable', so that a user with Java installed can just double-click it).

Usually you will also be using several libraries, i.e. existing .jar files you obtained from the Internet. Very common examples are log4j (a logging framework) or JDBC libraries for accessing a database etc. Also you might have your own sub-modules that are deployed in separate jarfiles (a security module handling your single sign on). How things are split over jarfiles is a deployment/distribution matter, they still all share the universal namespace for Java source code. So in effect, you could unzip all the jarfiles and put the contents in one big directory structure if you wanted to (but you generally don't).

When running a Java application which uses/consists of multiple libraries, you run into what is commonly referred to as 'Classpath hell'. One of the biggest drawbacks of Java as we know it. (note: help is on the way). To run a Java application on the command line (not from Eclipse) you have to specify every single .jar file location on the classpath. When you are using one of Java's many frameworks (Maven, Spring, Tapestry) there is usually some form of support to alleviate this pain. If you are building a web application you would generally just have to adhere to its layering/deployment conventions to be able to easily deploy the thing in the web container of your choice (Tomcat, Jetty, Glassfish).

I hope this give some general insight in how things work in Java!

Answer 4

There are two things you need to clarify before this question can be answered:

1. Which source code repository will you use?
2. Which build system will you use to automatically build artifacts outside of Eclipse?

The answers will strongly influence your options.

We have opted for "one Eclipse project pr component" which may be either a library or a finished runnable/executable jar. This has made it easy to automate with Hudson. Our usage of CVS is also easier, since single projects do not have multiple responsibilities.

Note, each project may contain several source folders separating e.g. test code from configuration from Java source. That is not as important as simplifying your structure.