Java 6 vs Java 7

Java 6 was released in 2006 and is still having a good innings in some software projects around the world, even though Oracle stopped public updates in February 2013. New versions of Java (7 and 8) have emerged since then and that makes it an even more desirable platform to develop software with. 


above image is from the website: https://plumbr.eu/blog/java/java-version-and-vendor-data-analyzed-2016-edition

This article looks at the major additions that I noticed that came with Java 7, which is by the way also not updated publicly anymore since April 2015. I will comment on the changes that Java 8 brought in March 2014 in my next post.

Java is very good in being downward compatible to its older versions. It is very likely that you did not notice much change if you stuck to a more general usage of the language. 

  

above: A different look at the Java SE changes over the years from Tim Ellison: From the Slideshare presentation What's new in IBM Java 8 SE

Remembering Java 6

Let's remember, Java 6 brought two almost revolutionary new ways into the coding paradigm, it firstly allowed for the selection and invocation of a java compiler programmatically! This neat little trick opened up the door to allow us to use new and very creative ways of extending and integrating code into our applications. The second one was the "new kid around the blog" called "Support for pluggable annotations". These two additions allowed frameworks such as Spring and Hibernate to continue to flourish and do so even more powerfully, which largely impacted on the way we write our Java applications today.

Java 7 additions

Java 7 had also a fair share of its own revolutionary additions. First of all, the Java Virtual Machine started to support dynamic languages. This made the integration of languages such as Ruby, Scala, JavaScript, and many more possible.

On the programming front, changes that I welcomed, were, for example, allowing underscores in numeric literals (I use it to make a number with many digits more readable), catching multiple exception types and rethrowing exceptions with improved type checking allowed me to remove unwieldiness in my code, the diamond operator <> saved me from unnecessarily duplicating information in my code when I wanted to use generic instance creation, and finally try-with-resources made my code cleaner and stopped me from losing important exception information in some cases.

The new file I/O library added support for multiple file systems, file metadata, and symbolic links - not that I need this functionality too often. Having said this, the Tiniest Module Container uses local file access and so I might update the code to use this new library.

There were also additions and optimizations in Java2D, several encryption methods were added/deprecated, and Unicode was updated to 6.0, along with a number of other internationalization enhancements.

Java 7 continues being one of the major forces in the software development industry and the latest Java version updates together with the rise of Android have made Java the number one software development language at this moment. 


above image is from the LinkedIn post by Sony George: Most popular programming languages today

Tiniest Module Container (Serialization)

This post builds on previous posts:

• Introduction to the Tiniest Module Container
• Module Handling of Tiniest Module Container

Today we have a look at a Java concept that we will make extensive use of during the development of this project:

Serialization in Java

Serialization is a built-in Java concept that allows us to save (persist) the state of a Java object (instance) to a Stream. In our example, we save it to the hard drive as a file.

Implementation

The concept is relatively easy to implement, all you have to do is to add
implements java.io.Serializable to your class definition.

Be aware that you need to do this for all of your classes that might end up being persistable properties!

I wrote a utility class that contains the code needed to effectuate the persisting and loading of an instance's state:

The Serializer

/**
 * @author      Michael Appelt 
 * @version     0.1 Initial          
 * @since       0.1  
 * @copyright   2016/2017 Michael Appelt        
 */
package appiappelt.util;

import java.io.BufferedInputStream;
import java.io.BufferedOutputStream;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.InputStream;
import java.io.ObjectInput;
import java.io.ObjectInputStream;
import java.io.ObjectOutput;
import java.io.ObjectOutputStream;
import java.io.OutputStream;
import java.io.Serializable;

import appiappelt.shell.Shell;

public class Serializer {

 /**
  * Persist state to disk
  * @throws IOException 
  */
 public static void persist(Object obj) throws IOException {
  if (obj instanceof Serializable) {
      String className = obj.getClass().getName();
             className = className.replace('.', '_');
      OutputStream file = new FileOutputStream(Shell.getCurrentDir()+File.separatorChar+className+".dat");
      OutputStream buffer = new BufferedOutputStream(file);
      ObjectOutput output = new ObjectOutputStream(buffer);
      output.writeObject(obj); 
      output.close();   
  }
 }
 
 /**
  *  Load persisted state
  * @param  obj - The object wanting its persistent state
  * @return a new object representing the loaded state. do remember to copy properties
  * @throws IOException
  * @throws ClassNotFoundException
  */
 public static Object loadState(Object obj) throws IOException, ClassNotFoundException {
  if (obj instanceof Serializable) {
       String className = obj.getClass().getName();
       className = className.replace('.', '_');
       InputStream file = new FileInputStream(Shell.getCurrentDir()+File.separatorChar+className+".dat");
       InputStream buffer = new BufferedInputStream(file);
       ObjectInput input = new ObjectInputStream (buffer);
       obj = input.readObject();
       input.close();
  } else {
       return null;
  }
  return obj;
 }
}

The File name is composed of the current directory String* (operating System independent I hope), the class name ('.' replaced by '_') and a ".dat" as the file type.

*I want that the state is saved within the directory "where the Shell is running". We will "parameterize" this at a later stage.

The loading of the state is nothing else but reading the state out of the File Stream and assigning it to the receiving object instance.

Application

You can see the usage of the Serializer in the JUnit test method below:


Let's unwrap the code above:

1. We first instantiate a Shell object and add a "test Module" to it.
2. Using the Serializer, we serialize the collection (a Hashtable) that contains all Modules belonging to the Shell.
3. We instantiate a new Shell object, load the state that we persisted in 2. and "enumerate" through the collection of Modules, printing to screen the instance's names.

Shell obj instance and Shell newobj instance are now in an identical state with regards to the Module collection and other serializable properties.

Conclusion

With this post, I demonstrated the concept of Java's object serialization to you. We are now able to persist and load state, which is one of the core concepts needed for our Tiniest Module Container to work. 

Stay put for more ... and yes, you will be able to access/download all of the implementation code once the project is finished.

Tiniest Module Container (Module handling)

I introduced the Tiniest Module Container (TMC) in my previous post: Introduction of Tiniest Module Container

Let me remind you what TMC is: It is an application shell that carries the Modules (a Java construct that has a defined purpose, a defined and unique set of functionality) that make up the total functionality of the application within itself. We use the concept of a customized Class loader and persistent state to achieve this.

Illustration

I extended the illustration from my previous post:

We can say the following about the design:

• The Shell has a customized Classloader
• The Shell has a collection of Modules (code and instantiated objects)
• The Shell has a collection of Interfaces (interface objects that point towards one Module)
• A Module is installed into a Shell: The customized Classloader reads JAR files containing the Module code, loads these into the application (JVM), stores the code (String) in a Module collection and saves the Shell's persistent state containing the ingested code. The JAR file of the installed Module is deleted.
• The Shell's persistent state can contain application parameters and many more attributes (operation).
• A previously installed Module will be instantiated at the Shell's instantiation (start-up / initialization). 
• One Interface Object is instantiated for each Module, other Modules (application code) evoke functionality of the Module through it. 

Process flows

So far we have discovered two process flows, one for installation, and one for initialization:

Below you will find a draft version of the Instantiation Process Flow. I might employ a slightly different organization/strategy once I start to implement it but for the moment these steps seem reasonable.

Draft Instantiation Process Flow:

Conclusion

I do not want to overwhelm or bore the reader with too much detail. I think that the explanation above describes an aspect of the idea and points into the direction that I want to go with this.

My next post will take a closer look at Java's Serialization Concept