{"id":43663,"date":"2015-09-18T21:43:03","date_gmt":"2015-09-18T18:43:03","guid":{"rendered":"http:\/\/www.javacodegeeks.com\/?p=43663"},"modified":"2023-12-06T12:01:53","modified_gmt":"2023-12-06T10:01:53","slug":"how-to-create-and-destroy-objects","status":"publish","type":"post","link":"https:\/\/www.javacodegeeks.com\/2015\/09\/how-to-create-and-destroy-objects.html","title":{"rendered":"How to create and destroy objects"},"content":{"rendered":"

This article is part of our Academy Course titled Advanced Java<\/a>.<\/p>\n

This course is designed to help you make the most effective use of Java. It discusses advanced topics, including object creation, concurrency, serialization, reflection and many more. It will guide you through your journey to Java mastery! Check it out here<\/a>!<\/em><\/p>\n

\n

Table Of Contents<\/h4>\n
\n
1. Introduction<\/a><\/dt>\n
2. Instance Construction<\/a><\/dt>\n
\n
\n
2.1. Implicit (Generated) Constructor<\/a><\/dt>\n
2.2. Constructors without Arguments<\/a><\/dt>\n
2.3. Constructors with Arguments<\/a><\/dt>\n
2.4. Initialization Blocks<\/a><\/dt>\n
2.5. Construction guarantee<\/a><\/dt>\n
2.6. Visibility<\/a><\/dt>\n
2.7. Garbage collection<\/a><\/dt>\n
2.8. Finalizers<\/a><\/dt>\n<\/dl>\n<\/dd>\n
3. Static initialization<\/a><\/dt>\n
4. Construction Patterns<\/a><\/dt>\n
\n
\n
4.1. Singleton<\/a><\/dt>\n
4.2. Utility\/Helper Class<\/a><\/dt>\n
4.3. Factory<\/a><\/dt>\n
4.4. Dependency Injection<\/a><\/dt>\n<\/dl>\n<\/dd>\n
5. Download the Source Code<\/a><\/dt>\n
6. What’s next<\/a><\/dt>\n<\/dl>\n<\/div>\n

<\/a>1. Introduction<\/h2>\n

Java programming language, originated in Sun Microsystems and released back in 1995, is one of the most widely used programming languages in the world, according to TIOBE Programming Community Index<\/a>. Java is a general-purpose programming language. It is attractive to software developers primarily due to its powerful library and runtime, simple syntax, rich set of supported platforms (Write Once, Run Anywhere – WORA) and awesome community.<\/p>\n

In this tutorial we are going to cover advanced Java concepts, assuming that our readers already have some basic knowledge of the language. It is by no means a complete reference, rather a detailed guide to move your Java skills to the next level.<\/p>\n

Along the course, there will be a lot of code snippets to look at. Where it makes sense, the same example will be presented using Java 7 syntax as well as Java 8 one.<\/p>\n

<\/a>2. Instance Construction<\/h2>\n

Java is object-oriented language and as such the creation of new class instances (objects) is, probably, the most important concept of it. Constructors are playing a central role in new class instance initialization and Java provides a couple of favors to define them.<\/p>\n

<\/a>2.1. Implicit (Generated) Constructor<\/h3>\n

Java allows to define a class without any constructors but it does not mean the class will not have any. For example, let us consider this class:<\/p>\n

package com.javacodegeeks.advanced.construction;\n\npublic class NoConstructor {\n}\n<\/pre>\n
This class has no constructor but Java compiler will generate one implicitly and the creation of new class instances will be possible using new<\/code> keyword.<\/p>\n
final NoConstructor noConstructorInstance = new NoConstructor();<\/pre>\n
<\/a>2.2. Constructors without Arguments<\/h3>\n
The constructor without arguments (or no-arg constructor) is the simplest way to do Java compiler\u2019s job explicitly.<\/p>\n
package com.javacodegeeks.advanced.construction;\n\npublic class NoArgConstructor {\n    public NoArgConstructor() {\n        \/\/ Constructor body here\n    }\n}\n<\/pre>\n
This constructor will be called once new instance of the class is created using the new<\/code> keyword.<\/p>\n
final NoArgConstructor noArgConstructor = new NoArgConstructor();<\/pre>\n
<\/a>2.3. Constructors with Arguments<\/h3>\n
The constructors with arguments are the most interesting and useful way to parameterize new class instances creation. The following example defines a constructor with two arguments.<\/p>\n
package com.javacodegeeks.advanced.construction;\n\npublic class ConstructorWithArguments {\n    public ConstructorWithArguments(final String arg1,final String arg2) {\n        \/\/ Constructor body here\n    }\n}\n<\/pre>\n
In this case, when class instance is being created using the new<\/code> keyword, both constructor arguments should be provided.<\/p>\n
final ConstructorWithArguments constructorWithArguments = \n    new ConstructorWithArguments( \"arg1\", \"arg2\" );\n<\/pre>\n
Interestingly, the constructors can call each other using the special this<\/code> keyword. It is considered a good practice to chain constructors in such a way as it reduces code duplication and basically leads to having single initialization entry point. As an example, let us add another constructor with only one argument.<\/p>\n
public ConstructorWithArguments(final String arg1) {\n    this(arg1, null);\n}\n<\/pre>\n
<\/a>2.4. Initialization Blocks<\/h3>\n
Java has yet another way to provide initialization logic using initialization blocks. This feature is rarely used but it is better to know it exists.<\/p>\n
package com.javacodegeeks.advanced.construction;\n\npublic class InitializationBlock {\n    {\n        \/\/ initialization code here\n    }\n}\n<\/pre>\n
In a certain way, the initialization block might be treated as anonymous no-arg constructor. The particular class may have multiple initialization blocks and they all will be called in the order they are defined in the code. For example:<\/p>\n
package com.javacodegeeks.advanced.construction;\n\npublic class InitializationBlocks {\n    {\n        \/\/ initialization code here\n    }\n\n    {\n        \/\/ initialization code here\n    }\n\n}\n<\/pre>\n
Initialization blocks do not replace the constructors and may be used along with them. But it is very important to mention that initialization blocks are always called before<\/strong> any constructor.<\/p>\n
package com.javacodegeeks.advanced.construction;\n\npublic class InitializationBlockAndConstructor {\n    {\n        \/\/ initialization code here\n    }\n    \n    public InitializationBlockAndConstructor() {\n    }\n}\n<\/pre>\n
<\/a>2.5. Construction guarantee<\/h3>\n
Java provides certain initialization guarantees which developers may rely on. Uninitialized instance and class (static) variables are automatically initialized to their default values.
 
<\/div> <\/div><\/p>\n
\n\n\n\n\n\n\n\n\n\n\n\n\n
Type<\/strong><\/td>\nDefault Value<\/strong><\/td>\n<\/tr>\n
boolean<\/strong><\/td>\nFalse<\/td>\n<\/tr>\n
byte<\/strong><\/td>\n0<\/td>\n<\/tr>\n
short<\/strong><\/td>\n0<\/td>\n<\/tr>\n
int<\/strong><\/td>\n0<\/td>\n<\/tr>\n
long<\/strong><\/td>\n0L<\/td>\n<\/tr>\n
char<\/strong><\/td>\n\\u0000<\/td>\n<\/tr>\n
float<\/strong><\/td>\n0.0f<\/td>\n<\/tr>\n
double<\/strong><\/td>\n0.0d<\/td>\n<\/tr>\n
object reference<\/strong><\/td>\nnull<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Table 1<\/p>\n<\/div>\n
Let us confirm that using following class as a simple example:<\/p>\n
package com.javacodegeeks.advanced.construction;\n\npublic class InitializationWithDefaults {\n    private boolean booleanMember;\n    private byte byteMember;\n    private short shortMember;\n    private int intMember;\n    private long longMember;\n    private char charMember;\n    private float floatMember;\n    private double doubleMember;\n    private Object referenceMember;\n\n    public InitializationWithDefaults() {     \n        System.out.println( \"booleanMember = \" + booleanMember );\n        System.out.println( \"byteMember = \" + byteMember );\n        System.out.println( \"shortMember = \" + shortMember );\n        System.out.println( \"intMember = \" + intMember );\n        System.out.println( \"longMember = \" + longMember );\n        System.out.println( \"charMember = \" + \n            Character.codePointAt( new char[] { charMember }, 0  ) );\n        System.out.println( \"floatMember = \" + floatMember );\n        System.out.println( \"doubleMember = \" + doubleMember );\n        System.out.println( \"referenceMember = \" + referenceMember );\n    }\n}\n<\/pre>\n
Once instantiated using new<\/code> keyword:<\/p>\n
final InitializationWithDefaults initializationWithDefaults = new InitializationWithDefaults(), <\/pre>\n
The following output will be shown in the console:<\/p>\n
booleanMember = false\nbyteMember = 0\nshortMember = 0\nintMember = 0\nlongMember = 0\ncharMember = 0\nfloatMember = 0.0\ndoubleMember = 0.0\nreferenceMember = null\n<\/pre>\n
<\/a>2.6. Visibility<\/h3>\n
Constructors are subject to Java visibility rules and can have access control modifiers which determine if other classes may invoke a particular constructor.<\/p>\n
\n\n\n\n\n\n\n\n
Modifier<\/strong><\/td>\nPackage<\/strong><\/td>\nSubclass<\/strong><\/td>\nEveryone Else<\/strong><\/td>\n<\/tr>\n
public<\/strong><\/td>\naccessible<\/td>\naccessible<\/td>\naccessible<\/td>\n<\/tr>\n
protected<\/strong><\/td>\naccessible<\/td>\naccessible<\/td>\nnot accessible<\/strong><\/td>\n<\/tr>\n
<no modifier><\/strong><\/td>\naccessible<\/td>\nnot accessible<\/strong><\/td>\nnot accessible<\/strong><\/td>\n<\/tr>\n
private<\/strong><\/td>\nnot accessible<\/strong><\/td>\nnot accessible<\/strong><\/td>\nnot accessible<\/strong><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Table 2<\/p>\n<\/div>\n
<\/a>2.7. Garbage collection<\/h3>\n
Java (and JVM in particular) uses automatic garbage collection. To put it simply, whenever new objects are created, the memory is automatically allocated for them. Consequently, whenever the objects are not referenced anymore, they are destroyed and their memory is reclaimed.<\/p>\n
Java garbage collection is generational and is based on assumption that most objects die young (not referenced anymore shortly after their creation and as such can be destroyed safely). Most developers used to believe that objects creation in Java is slow and instantiation of the new objects should be avoided as much as possible. In fact, it does not hold true: the objects creation in Java is quite cheap and fast. What is expensive though is an unnecessary creation of long-lived objects which eventually may fill up old generation and cause stop-the-world garbage collection.<\/p>\n
<\/a>2.8. Finalizers<\/h3>\n
So far we have talked about constructors and objects initialization but have not actually mentioned anything about their counterpart: objects destruction. That is because Java uses garbage collection to manage objects lifecycle and it is the responsibility of garbage collector to destroy unnecessary objects and reclaim the memory.<\/p>\n
However, there is one particular feature in Java called finalizers<\/strong> which resemble a bit the destructors but serves the different purpose of performing resources cleanup. Finalizers<\/strong> are considered to be a dangerous feature (which leads to numerous side-effects and performance issues). Generally, they are not necessary and should be avoided (except very rare cases mostly related to native objects). A much better alternative to finalizers<\/strong> is the introduced by Java 7<\/strong> language construct called try-with-resources<\/a><\/strong> and AutoCloseable<\/a><\/code> interface which allows to write clean code like this:<\/p>\n
try ( final InputStream in = Files.newInputStream( path ) ) {\n    \/\/ code here\n}\n<\/pre>\n
<\/a>3. Static initialization<\/h2>\n
So far we have looked through class instance construction and initialization. But Java also supports class-level initialization constructs called static initializers<\/strong>. There are very similar to the initialization blocks except for the additional static<\/code> keyword. Please notice that static initialization is performed once per class-loader. For example:<\/p>\n
package com.javacodegeeks.advanced.construction;\n\npublic class StaticInitializationBlock {\n    static {\n        \/\/ static initialization code here\n    }\n}\n<\/pre>\n
Similarly to initialization blocks, you may include any number of static initializer blocks in the class definition and they will be executed in the order in which they appear in the code. For example:<\/p>\n
package com.javacodegeeks.advanced.construction;\n\npublic class StaticInitializationBlocks {\n    static {\n        \/\/ static initialization code here\n    }\n\n    static {\n        \/\/ static initialization code here\n    }\n}\n<\/pre>\n
Because static initialization block can be triggered from multiple parallel threads (when the loading of the class happens in the first time), Java runtime guarantees that it will be executed only once and in thread-safe manner.<\/p>\n
<\/a>4. Construction Patterns<\/h2>\n
Over the years a couple of well-understood and widely applicable construction (or creation) patterns have emerged within Java community. We are going to cover the most famous of them: singleton, helpers, factory and dependency injection (also known as inversion of control).<\/p>\n
<\/a>4.1. Singleton<\/h3>\n
Singleton is one of the oldest and controversial patterns in software developer\u2019s community. Basically, the main idea of it is to ensure that only one single instance of the class could be created at any given time. Being so simple however, singleton raised a lot of the discussions about how to make it right and, in particular, thread-safe. Here is how a naive version of singleton class may look like:<\/p>\n
package com.javacodegeeks.advanced.construction.patterns;\n\npublic class NaiveSingleton {\n    private static NaiveSingleton instance;\n    \n    private NaiveSingleton() {        \n    }\n    \n    public static NaiveSingleton getInstance() {\n        if( instance == null ) {\n            instance = new NaiveSingleton();\n        }\n        \n        return instance;\n    }\n}\n<\/pre>\n
At least one problem with this code is that it may create many instances of the class if called concurrently by multiple threads. One of the ways to design singleton properly (but in non-lazy fashion) is using the static<\/code> final<\/code> property of the class.<\/p>\n
final property of the class.\npackage com.javacodegeeks.advanced.construction.patterns;\n\npublic class EagerSingleton {\n    private static final EagerSingleton instance = new EagerSingleton();\n    \n    private EagerSingleton() {        \n    }\n    \n    public static EagerSingleton getInstance() {\n        return instance;\n    }\n}\n<\/pre>\n
If you do not want to waste your resources and would like your singletons to be lazily created when they are really needed, the explicit synchronization is required, potentially leading to lower concurrency in a multithreaded environments (more details about concurrency in Java will be discussing in part 9<\/strong> of the tutorial, Concurrency best practices<\/strong>).<\/p>\n
package com.javacodegeeks.advanced.construction.patterns;\n\npublic class LazySingleton {\n    private static LazySingleton instance;\n    \n    private LazySingleton() {        \n    }\n    \n    public static synchronized LazySingleton getInstance() {\n        if( instance == null ) {\n            instance = new LazySingleton();\n        }\n        \n        return instance;\n    }\n}\n<\/pre>\n
Nowadays, singletons are not considered to be a good choice in most cases, primarily because they are making a code very hard to test. The domination of dependency injection pattern (please see the Dependency Injection<\/strong> section below) also makes singletons unnecessary.
\n[ulp id=’w6F4W4SAMiyTapBF’]
\n <\/p>\n
<\/a>4.2. Utility\/Helper Class<\/h3>\n
The utility or helper classes are quite popular pattern used by many Java developers. Basically, it represents the non-instantiable class (with constructor declared as private<\/code>), optionally declared as final<\/code> (more details about declaring classes as final<\/code> will be provided in part 3<\/strong> of the tutorial, How to design Classes and Interfaces<\/strong>) and contains static<\/code> methods only. For example:<\/p>\n
package com.javacodegeeks.advanced.construction.patterns;\n\npublic final class HelperClass {\n    private HelperClass() {        \n    }\n    \n    public static void helperMethod1() {\n        \/\/ Method body here\n    }\n    \n    public static void helperMethod2() {\n        \/\/ Method body here\n    }\n}\n<\/pre>\n
From seasoned software developer standpoint, such helpers often become containers for all kind of non-related methods which have not found other place to be put in but should be shared somehow and used by other classes. Such design decisions should be avoided in most cases: it is always possible to find another way to reuse the required functionality, keeping the code clean and concise.<\/p>\n
<\/a>4.3. Factory<\/h3>\n
Factory pattern is proven to be extremely useful technique in the hands of software developers. As such, it has several flavors in Java, ranging from factory method<\/strong> to abstract factory<\/strong>. The simplest example of factory pattern is a static<\/code> method which returns new instance of a particular class (factory method<\/strong>). For example:<\/p>\n
package com.javacodegeeks.advanced.construction.patterns;\n\npublic class Book {\n    private Book( final String title) {\n    }     \n\n    public static Book newBook( final String title ) { \n        return new Book( title );\n    }\n}\n<\/pre>\n
The one may argue that it does not make a lot of sense to introduce the newBook<\/code> factory method<\/strong> but using such a pattern often makes the code more readable. Another variance of factory pattern involves interfaces or abstract classes (abstract factory<\/strong>). For example, let us define a factory interface<\/strong>:<\/p>\n
public interface BookFactory {\n    Book newBook();\n}\n<\/pre>\n
With couple of different implementations, depending on the library type:<\/p>\n
public class Library implements BookFactory {\n    @Override\n    public Book newBook() {\n        return new PaperBook();\n    }\n}\n\npublic class KindleLibrary implements BookFactory {\n    @Override\n    public Book newBook() {\n        return new KindleBook();\n    }\n}\n<\/pre>\n
Now, the particular class of the Book<\/code> is hidden behind BookFactory<\/code> interface implementation, still providing the generic way to create books.<\/p>\n
<\/a>4.4. Dependency Injection<\/h3>\n
Dependency injection (also known as inversion of control) is considered as a good practice for class designers: if some class instance depends on the other class instances, those dependencies should be provided (injected) to it by means of constructors (or setters, strategies, etc.) but not created by the instance itself. Let us consider the following example:<\/p>\n
package com.javacodegeeks.advanced.construction.patterns;\n\nimport java.text.DateFormat;\nimport java.util.Date;\n\npublic class Dependant {\n    private final DateFormat format = DateFormat.getDateInstance();\n    \n    public String format( final Date date ) {\n        return format.format( date );\n    }\n}\n<\/pre>\n
The class Dependant<\/code> needs an instance of DateFormat and it just creates one by calling DateFormat.getDateInstance()<\/code> at construction time. The better design would be to use constructor argument to do the same thing:<\/p>\n
package com.javacodegeeks.advanced.construction.patterns;\n\nimport java.text.DateFormat;\nimport java.util.Date;\n\npublic class Dependant {\n    private final DateFormat format;\n    \n    public Dependant( final DateFormat format ) {\n        this.format = format;\n    }\n    \n    public String format( final Date date ) {\n        return format.format( date );\n    }\n}\n<\/pre>\n
In this case the class has all its dependencies provided from outside and it would be very easy to change date format and write test cases for it.<\/p>\n
<\/a>5. Download the Source Code<\/h2>\n