A Java application usually consists of several new class definitions. Each new class is usually defined in a separate file with a corresponding filename. For example a class named MyClass is defined in a file named MyClass.java.
One of those classes will contain a 'public static void main(String[] args)' method, and so this will be where execution starts.
These several class definition files are called a 'project'. This is not a Java keyword, but IDEs invite you to start a new 'project' and organises files and directories for you. As well as class definitions, a project may include resources such as image and sound files.
NetBeans (and other IDEs) allows you to have several projects open at the same time, and have one set as the 'main' project. When you hit Run, it is the main project which is compiled and executed.
This shows the stages of creating a new project in NetBeans 7.01:
Create a simple Java application Call it Demo Project parts
If we then do Run.. Clean and Build Main Project, the following folders are produced. Folder src contains the source code .java files which
we write. The build folder contains the .class files which the compiler produces.
The dist folder contains jar files for distribution - jars are described later. And the nbproject folder contains metadata about the project itself.
Packages
A project might have a considerable number of class definition files. It might be appropriate to group those classes into sections which are about the same activity, and it might be useful to re-use some of those sections in other projects.
These ideas are supported by the Java keyword 'package'. A package is simply a group of related classes. For example, the project JCartes2 draws graphs of mathematical functions. It has two packages, in addition to the default package which contains documentation. The package 'parsing' contains classes which handle calculations, and the package 'gui' handles the graphical user interface.
Syntactically, this is done using the keyword 'package' at the start of each class definition. For example to place a class in the package 'gui', simply have
package gui;
as the first line of the class file.
Packages also fix the problem of
the same name being chosen for different classes. As an example, there are two Date classes. One deals with dates in general, and the other is for dates in databases. The first is in the package java.util, whilst the other is in java.sql. If we just want to use the first, we can use an import
import java.util.Date;
and then through the code just refer to Date, like
Date someDate = new Date();
If we want to use both in the same file, we must use the fully-qualified class name, including the package name - for example
java.util.Date someDate = new java.util.Date();
Encapsulation
The only way for errors to occur in a program is by being put there by the author. No other mechanisms are known. Programs can't acquire bugs by sitting around with other buggy programs. ~Harlan Mills
One of the key concepts of OOP is encapsulation. The motivation is to prevent bugs which result from pieces of software corrupting data. As Dr. Mills' quote points out, all bugs are written by programmers. Encapsulation is an attempt to make the language make it hard for the programmer to write a bug.
Structured programming organised code into global shared data and sets of functions (in Java, methods) which processed that shared data. But there was no way to ensure that the global data could not be accidentally accessed, and unintentionally corrupted, by a function. In other words there was no way of saying that some data should only be accessible by certain functions.
The idea of an object by itself helps with this, since it links the data members with the methods which are supposed to process that data. But there needs to be a mechansim to prevent other code accidentally corrupting the data in the object. This is the purpose of encapsulation and access control. It is not intended for security purposes.
There are two parts to the mechanism - access modifiers and get/set methods.
public
There is a keyword 'public' which can be applied both to data members and methods. For example, the main method must be named as
public static void main(String[] args)
Here 'public' is an access modifier. It means that this method can be invoked from anywhere (instead of just from this class or from the package it is in). The method has to be public, since Java runtime must call this method to start the application, and the runtime is outside your package.
So methods which you want 'the world' to be able to call should be made public.
Data members should not normally be made public, since that would usually mean any code can change them to any value. An exception is if the data member is final, so it cannot be changed. A commonly used example is Math.PI. This is a member of the Math class, representing the value of π, so is constant. Math.PI is static (which means it is per class, not that it is constant) .
private
Data members and methods which are declared as 'private' can only be accessed from within their class. That means that methods which are only concerned with the internal operation of the class should be private.
no access modifier - default
Members can be declared with no access modifier. In that case, the default, they are package-private. That means they can be accessed within their package, only, and not from outside.
protected
This is like package-private, except that it can be accessed by sub-classes, which might be in other packages.
This table tries to summarise which one to use:
data methods
private yes - use get/set methods class-internal only default package-private constant data only if needed by package
protected constant data only if to be used in sub-class in different package public constant data only if needed outside package
Getter/setter methods
A getter method enables the value of a private data member to be read from outside the class or package. The idea is to make the data be private, and provide a non-private method so that there is read-only access to it. These methods are usually named getSomething - they do not have to be.
For example, a JFrame has a getBackground() which returns the colour of the window background.
Similarly a setter method allows a field to be given a value. A JFrame has a setBackground() method to set the background color. Setter methods are usually public.
Why make the data members private and write setter methods? Why not make the data public so they can be set directly? Because the setter method can validate the value being set, with an if, so that it will only allow suitable values to be given. This does not mean bugs are impossible, but it makes it more unlikely that the programmer will accidentally set invalid values.
Class level access modifiers
The access modifiers described above apply for individual data members and methods. We can also give an access modifier to a class as a whole. But only 'public' or the default package-private is allowed.
In other words if you say
public class ClassA..
then ClassA can be used anywhere. But
class ClassB..
can only be accessed from within its own package. You would do this if the class was needed for the internal operation of a package, but was not intended to be directly accessed.