Java project structure explained for beginners?

Question

I come from a .NET background and completely new to Java, and I'm trying to figure out the structure of a Java project.

My typical .NET decision framework contains projects that denote logically different components, usually called using a format:

MyCompany.SomeApplication.ProjectName

The name of the project is usually equal to the root namespace for the project. I could break the namespace further if it's a big project, but more often than not I don't see the need for a namespace.

Now in Java you have applications consisting of projects, and then you have a new logical level - a package. What is a package? What should it contain? How do you project the space inside this App.Project.Package structure? Where does the jar fit into all this? Basically, can someone introduce a beginner to an introduction to the structure of a Java application?

Thank!

Edit: Some really cracked answers thanks guys. Then the following questions follow:

• Do .JAR files have compiled code? Or just compressed source files?
• Is there a good reason why package names are lowercase?
• Do packages have circular dependencies? In other words, can Package.A use Package.B and vice versa?
• Can someone just show the typical syntax for declaring a class as being in a package and declare that you want to refer to another package in the class (maybe?)?

Answer 1

"Simple" J2SE projects

As cletus explained, the structure of the source directory is directly equivalent to the structure of the package and, in fact, is built into Java. Everything else is a little less clear.

Many simple projects are organized manually, so people can choose a structure in which they feel good. What is often done (and this is also reflected in the project structure in Eclipse, the very dominant Java tool) is to have the source tree begin in a directory called src . Your source files without packages will be located directly in src, and your package hierarchy, usually starting with the com directory, will also be contained in src . If you CD into the src directory before running the javac compiler, your compiled .class files will fall into the same directory structure, with each .class file located in the same directory and next to its .java .

If you have a lot of source and cool files, you want to separate them from each other to reduce clutter. The management and organization of Eclipse often places the bin or classes directory parallel to src , so .class files fall into a hierarchy that reflects the src structure.

If your project has a set of .jar files for delivering capabilities from third-party libraries, then the third directory, usually lib , is placed in parallel with src and bin . Everything in lib must be placed in the classpath for compilation and execution.

Finally, there is a bunch of this and what is more or less optional:

• docs to doc
• resources in resources
• data in data configuration
• in conf ...

You get the idea. The compiler does not care about these directories, these are just ways to organize (or confuse) yourself.

J2EE Projects

J2EE is roughly equivalent to ASP.NET, it is a massive (standard) structure for organizing web applications. Although you can design your code for J2EE projects as you wish, there is a standard standard for the structure that the web container expects from your application. And this structure, as a rule, is also slightly reflected in the original layout. Here is a page that details project structures for Java projects (they don’t really agree with what I wrote above) and for J2EE projects in particular:

http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html

Maven Projects

Maven is a very versatile project building tool. Personally, my building needs are perfectly met by ant , which roughly compares to nmake . Maven, on the other hand, is a full-lifecyle of construction management with addiction management bolts. Libs and the source for most of the code in the Java world are freely available on the web, and maven, if asked beautifully, will scan it for you and bring home everything you need without even having to talk about it. He also manages a small repository.

The disadvantage of this extremely hardworking seeker is the fact that he is very fascist regarding the structure of the project. You do it in a Maven way or not at all. By making his standard go down, Maven manages to make projects around the world more similar in structure, easier to manage, and easier to create automatically with minimal input.

If you ever choose Maven, you can stop worrying about the structure of the project, because there can only be one. This is it: http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html

Answer 2

A package in Java is very similar to a .Net namespace. The package name essentially creates a path to the classes that live inside it. This path can be thought of as a class namespace (in terms of .Net) because it is a unique identifier for the specific class that you want to use. For example, if you have a package named:

 org.myapp.myProject 

And inside you had a bunch of classes:

 MyClass1 MyClass2 

To specifically reference those classes that you would use:

 org.myapp.myProject.MyClass1 org.myapp.myProject.MyClass2 

The only real difference between this and .Net (what I know) is that Java organizes its “namespaces" structurally (each package is a separate folder), while .Net allows you to scope using the namespace keyword and ignores it where the document is located.

A JAR file is roughly the same as a DLL in most cases. This is a compressed file (you can open them using 7zip) that contains the source code from other projects, which can be added depending on your application. Libraries are usually contained in the JAR.

What you need to remember about Java is very structural; WHERE the files live is very important. Of course, there is a story, and then what I wrote, but I think this should make you start.

Answer 3

The package is very similar to the .Net namespace. The general convention in Java is to use your return domain name as the package prefix, so if your company is example.com, your packages are likely to be:

 com.example.projectname.etc... 

It can be divided into several levels, and not just one (project name), but usually this is enough.

Inside the structure, project structures are usually divided into logical areas: controllers, models, views, etc. It depends on the type of project.

Java has two dominant build systems: Ant and Maven.

Ant is basically a domain-specific scripting language and quite flexible, but you end up writing a lot of template details (build, deploy, test, etc.). It is fast and convenient.

Maven is more modern and more perfect and deserves attention (imho). Maven differs from Ant in that Maven states that this project is a "web application project" (called an archetype). After this is declared, the directory structure is set after specifying your groupId (com.example) and artifactId (project name).

This way you get a lot of things for free. The real bonus of Maven is that it manages your project dependencies for you, so with pom.xml (the Maven project file) and properly configured Maven, you can provide this to someone else (with the source code) and they can create, deploy , test and run your project with automatic loading of libraries.

Ant gets something similar with Ivy.

Answer 4

Here are some notes on Java packages that should run you:

The best practice with Java package names is to use the organization's domain name as the start of the package, but in reverse, for example. if your company owns the domain "bobswidgets.com", you can start your package with "com.bobswidgets".

The next level down will often be the application or library level, so if these are your e-commerce libraries, it could be something like "com.bobswidgets.ecommerce".

Further than this often represents the architecture of your application. The classes and interfaces that are fundamental to the project are at the root, for example. com.bobswidgets.ecommerce.InvalidRequestException.

Using packages to separate functions is further general. usually a template is to put interfaces and exceptions in any unit root and implementation in subpackages, for example.

 com.bobswidgets.ecommerce.payment.PaymentAuthoriser (interface) com.bobswidgets.ecommerce.payment.PaymentException com.bobswidgets.ecommerce.payment.paypal.PaypalPaymentAuthoriser (implementation) 

This makes it easy to pull classes and payment packages into your own project.

Some other notes:

Java packages are closely related to the directory structure. Thus, within the framework of the project, the class with the package com.example.MyClass will always be in com / example / MyClass.java. This is because when it is packaged in a Jar, the class file will definitely be in com / example / MyClass.class.

Java packages are loosely related to projects. It is likely that projects will have their own package names, for example. com.bobswidgets.ecommerce for e-commerce, com.bobswidgets.intranet for the intranet project.

Jar files will contain class files that are the result of compiling your .java code into bytecodes. These are just zip files with the .jar extension. The root of the Jar file is the root of the namespace hierarchy, for example. com.bobswidgets.ecommerce will be / com / bobswidgets / ecommerce / in the Jar file. Jar files can also use container resources, for example. property files, etc.

Answer 5

A package is a grouping of source files that allows them to see individual methods and variables between separate parts, so that this group of classes can access things with each other that other classes cannot execute.

It is expected that all java classes have a package that is used to disambiguate them. Therefore, if you open the jar file in your project, for example spring, each package starts with org.springframework. Class loaders are not aware of the jarfile name, they only use the package.

There is a common practice of violating things by the type of object or function, not everyone agrees with this. Like the Cletus hosted here, there is a tendency to group web controllers, domain objects, services, and data access objects into their own packages. I think that some people working with domain management do not think this is good. The advantage is that usually everything in your package has the same dependencies (controllers can depend on services and domain objects, services depend on domain objects and data access objects, etc.), so this can be convenient.

Answer 6

So in java you have three different types of access for member functions of classes and variables

public protected <i> Package-private and private

All classes in one package can see all other publicly available, protected, and packaging-related items.

Packages are not hierarchical in the system. They are usually organized hierarchically, but as far as runtime is concerned, com.example.widgets is a completely different package from com.example.widgets.cogs

Packages are organized into directories, which helps organize things: your file structure is always similar to your package structure.

They plan to add a modular system to Java in JDK7 (called Project Jigsaw ), and there is an existing module system called OSGi . These modular systems will / can give you much more flexibility and power than a simple package system.

Also, package names are usually lowercase. :)

Answer 7

From Wikipedia:

The Java package is a mechanism for organizing Java classes in Namespaces.

and

Java packages can be saved in compressed files called JAR files

So, for the abc package, you can have Java classes in the a, ab, and abc packages. Usually you group classes within the same package when they represent related functionality. Functionally, the only difference between classes in one package and classes in different packages is that the default access level for members in Java is a “protected package”, which means that other classes in the same package have access.

For the abcMyClass class, if you want to use MyClass in your project, you would import abcMyClass or, less recommended, import abc* In addition, so that MyClass is always in the abc package, you must declare it in the first line of MyClass.java: package abc; .

To do this, you can add the whole package (including packages b and c and the MyClass class) and put this JAR in your $CLASSPATH ; this will make it available for use by your other source code (via the above import statement).

Answer 8

To answer a sample question:

 package com.smotricz.goodfornaught; import java.util.HashMap; import javax.swing.*; public class MyFrame extends JFrame { private HashMap myMap = new HashMap(); public MyFrame() { setTitle("My very own frame"); } } 

Answer 9

Do .JAR files have compiled code? Or just compressed source files?

They can contain both or even completely different types of files, such as pictures. This is a zip archive in the first place. Most often, you will see JARs that contain class files, and those that contain source files (convenient for debugging in your IDE if you use third-party code) or those that contain javadoc (sourcecode documentatin), are also convenient if your environment The IDE supports documentation binding when accessing lib functions.

Is there a good reason why package names are lowercase?

Yes, there is a good reason for package names to be lowercase: there is a manual that says only cool names are capitalized in front.

Do packages have circular dependencies? In other words, can Package.A use Package.B and vice versa?

Packages do not use each other. Classes only. And yes, it is possible, but bad practice.

Can someone just show the typical syntax for declaring a class as being in a package and declare that you want to refer to another package in the class (maybe?)?

Suppose you want to use the ArrayList class from the java.util package, or use

  import java.util.ArrayList; ArrayList myList = new ArrayList(); 

or use without import (for example, you are using two different classes named ArrayList from different packages)

  java.util.ArrayList myList = new java.util.ArrayList(); your.package.ArrayList mySecondList = new your.package.ArrayList(); 

Answer 10

Although working with circular dependent classes is not easy, it may not be possible. I made it work in one case. class A and class B depended on each other and were not built from scratch. but realizing that parts of class A did not need class B, and this part was what class B had to completely compile, I left that part of class A that class B did not need, and the rest of class A could compile, then I managed to compile class B. Then I was able to undo the section of class A that needed class B, and was able to compile the full class A. Both classes then functioned properly. Although this is not typical if the classes are related to each other in such a way, it is kosher and sometimes necessary. Just make sure you leave special compilation commands for future updates.