Java Instance Initialiser

I have almost always taken the Java object creation process for granted, mainly because there is nothing much to do for me and if I write my constructor properly, it will do it. When I have an integer field, let's say pages in a class called Book, I never cared to see if explicitly initialising this with a value such as 0 makes any sense in my constructed object since the default integer (when used primitive int) itself is 0. It may not be good as an example but something similar in an age old code made me to realise that though the values are the same, since the explicit initialisation of a field happens after the object construction in the parent classes, they could produce different results.

The following simple code would probably make you to think a while whether it would print 0 or 100.

public abstract class Book {
 public Book() {
  setPages(100);
 }
 public abstract void setPages(int pages);
 public abstract int getPages();
}

public class MyBook extends Book {
 private int pages = 0;

 public void setPages(int pages) {
  this.pages = pages;
 }

 public int getPages() {
  return pages;
 }

 public static void main(String[] args) {
  Book myBook = new MyBook();
  System.out.println(myBook.getPages());
 }
}

It may be obvious for some but the point is that why not 100? Simply because the initialisation of a field happens after the construction of parent objects and prior to the code within it's own constructor, whatever value the field got to have during the parent objects construction is simply vanished. I think it is more of a philosophy of a language based on it's principles than any hard and fast rules. For instance, the same piece of code in C# which is considered to be a close one to Java in many ways would behave just the opposite.

Inexperienced Linus!

I was totally taken aback when I heard from Linus Torvalds that he did not know C Programming and not heard of Unix till the previous year (1990) of his project Linux!. While what makes something like that possible is only Linus can explain, I wonder how many of us would have counted for an inexperienced guy in Linus for a project of Linux kind in the conventional software development environment?

Immutable objects. Really?

One of the important characteristics of the object world is favour immutability. It's a simple and efficient way of protecting data and functionality of an object from misuse by the users for years to come. When an object is composed of Java library classes (such as java.util.Date or java.sql.Time) or other third party classes which are themselves mutable, then the immutability is broken thus there is a possibility for the change of state of the object by other objects.

The following class, RequestBatch looks pretty much like immutable given that it does not allow inheritance and provides no mutators. But it's field _requestsBatch breaks all of it.

import java.util.ArrayList;

import java.util.List;



public class RequestBuilder {



 public static void main(String[] args) {



  List<requestbatch> requestBatchList = new ArrayList<requestbatch>();

  List<String> requests = new ArrayList<String>();

  for (int reqBatchCount = 0; reqBatchCount < 5; reqBatchCount++) {

   for (int reqCount = 0; reqCount < 10; reqCount++) {

    requests.add("Request_" + reqBatchCount + "_" + reqCount);

   }

   RequestBatch requestBatch = new RequestBatch(requests);

   requestBatchList.add(requestBatch);

   requests.clear();

  }



  for (RequestBatch requestBatch : requestBatchList) {

   for (String request : requestBatch.getRequests()) {

    System.out.println(request);

   }

  }

 }

}

If we attempt to print the requests in the batches, we see no requests get printed as there were none stored. All the five batches have no requests but empty list. Though this might be obvious given that the constructor is passed with a copy of the reference value of the same List (pass-by-value) all the time, the clear() method clears the _requestBatch member of the supposed to be immutable objects without their knowledge.
So, care must be taken when creating an object composing of mutable objects. With the defensive copying of the in and out parameters, the following RequestBatch class would make it possible to create immutable objects.

import java.util.ArrayList;

import java.util.List;



public final class RequestBatch {



 private List<String> _requestBatch;



 public RequestBatch(List<String> requests) {

  _requestBatch = new ArrayList<String>(requests);

 }



 public int batchSize() {

  return _requestBatch.size();

 }



 public List<String> getRequests() {

  return Collections.unmodifiableList(_requestBatch);

 }

}