Alex Rivera | Logout

Java project structure explained for newbies?

Asked 2009-12-23T14:16:34.790
57

I come from a .NET background and am completely new to Java and am trying to get my head around the Java project structure.

My typical .NET solution structure contains projects that denote logically distinct components, usually named using the format:

MyCompany.SomeApplication.ProjectName

The project name usually equals the root namespace for the project. I might break the namespace down further if it's a large project, but more often than not I see no need to namespace any further.

Now in Java, you have applications consisting of projects, and then you have a new logical level - the package. What is a package? What should it contain? How do you namespace within this App.Project.Package structure? Where do JARs fit into all this? Basically, can someone provide a newbies intro to Java application structure?

Thanks!

Edit: Some really cracking answers thanks guys. A couple of followup questions then:

  • Do .JAR files contain compiled code? Or just compressed source code files?
  • Is there a good reason why package names are all lower case?
  • Can Packages have 'circular dependencies'? In other words, can Package.A use Package.B and vice versa?
  • Can anyone just show the typical syntax for declaring a class as being in a package and declaring that you wish to reference another package in a class (a using statement maybe?)
java development-environment
Edit
Report

1 Answer

4

A package is a grouping of source files that lets them see each others' package-private methods and variables, so that that group of classes can access things in each other that other classes can't.

The expectation is that all java classes have a package that is used to disambiguate them. So if you open a jar file in your project, like spring, every package starts with org.springframework. The classloaders don't know about the jarfile name, they use only the package.

There's a common practice of breaking things down by type of object or function, not everybody agrees about this. Like Cletus posted here, there's a tendency to group web controllers, domain objects, services, and data access objects into their own packages. I think some Domain-Driven Design people do not think this is a good thing. It does have the advantage that typically everything in your package shares the same kind of dependencies (controllers might depend on services and domain objects, services depend on domain objects and data access objects, etc.) so that can be convenient.

answered 2009-12-23T14:27:28.863

Your Answer