Java Serialisation – the gift that keeps on taking, Part 2.

Unexpected Consequences

In the previous post we started to look at the reasons why Java serialisation is required and what the requisite and necessary  design points were.

In this entry we’ll examine these particular characteristics and design points to reveal  a few unexpected consequences.

 As always when looking at software designs that have been around for some time is important to consider the wider context in place at the time.  So as we go through these unexpected consequences and later explore how Java serialisation can be exploited, remember that Java was very new,  the internet was just beginning and the concept of external cyber attacks was practically unknown. Viruses were a peculiar Windows thing and spread by the most common internet medium – email.   

Sponsorships Available

Sponsorships Available

Sponsorships Available

The original designers of Java serialisation and those that support it now may curse at how it can be abused, but hindsight is always right and at the time what was created was agreed to be a good practical solution.

Unreplaceable?

It turns out the the design and implementation of Java serialisation is so practical and useful that not using it is a challenge. With native Java serialisation being so embedded in the design of the Java runtime and being so performant, alternative methods of serialisation are often ignored simply because they are slower and harder to use.  

Simple to use

Using Java serialisation is simple.  A few lines of Java code and a working serialisation process is achieved.  The only other requirement is that the Java class to be serialised implements the java.io.Serializable interface. 

Three lines of Java code will serialise a Java object to a file. In this case the object is of some arbitrary type referenced by the variable hw 

 (Read more...)