Friday May 09, 2008

Announcing Project Socialsite

The SocialSite project is delivering social networking functionality by adding social networking platform support based on the OpenSocial standard to any community site. Any social application written for the OpenSocial based social network can be seamlessly and easily hosted on a transformed community site that is powered by the SocialSite project.

Check out this cool video.

Wednesday Mar 19, 2008

Blob vs file system storage

Images can be stored as a database blob or in the file system. How do you decide what to choose? What are the performance impacts of each one?

Well, there are several reasons why you should not store binary data in your database:

  • The whole point of storing data in a SQL database, is to put some kind of ordering and structure on your data, as well as being able to search on these data. But how do you search in the binary data of a picture?
  • For large data sets, storing binary data will quickly run up the size of your database files, making it harder to control the size of the database.
  • In order to store binary data in the database, you must continually escape and unescape the data to ensure that nothing breaks.
  • Storing images on the file system has a marginally faster retrieval rate.

Now here are some reasons why you should:

  • There is one good reason why you might want to store the binary data in the database: Replication. Storing images in a database allows for all of your data to be central stored which is more portable, and easy to replicate.

Here's one solution that takes into account the points above:

Store a link (e.g. a file path) to the image file in the database. Whenever you need the image, use the link in whatever program you use to retrieve the file containing the image.

Or you could think of storing your images in the database to gain the benefits there (preferable for smaller images and for limited images), but also use file system caching of these to obtain the performance benefits.

Some tips for getting the best performance out of the file system:

  • Limit the number of images in any one directory.
  • Include not only an image identifier in the filename, but also a secret code.

Thursday Mar 13, 2008

Boxing and unboxing

What's boxing anyway?

Every type in Java is either a reference type or a primitive type. A reference type is any class, instance, or array type. All reference types are subtypes of class Object, and any variable of reference type may be set to the value null. There are eight primitive types, and each of these has a corresponding library class of reference type. The library classes are located in the package java.lang.

Primitive : Reference Mapping
byte : Byte
short : Short
int : Integer
long : Long
float : Float
double : Double
bool : Boolean
char : Character

Conversion of a primitive type to the corresponding reference type is called boxing and conversion of the reference type to the corresponding primitive type is called unboxing.

But what's autoboxing?

Autoboxing / unboxing is the automated under the covers conversion between primitive types and their equivalent object types. For example, the conversion between an int primitive and an Integer object or between a boolean primitive and a Boolean object. This was introduced in Java 5.

// Assigning primitive type to wrapper type : Boxing
   Integer iWrapper = 10;

 // Assigning object to primitive : Unboxing
   public void intMethod(Integer iWrapper){
      int iPrimitive = iWrapper;

The basic differences between primitive and reference types

  • Primitive types are typically fast and lightweight - they have a small memory footprint. Object equivalents are heavyweight and can burden the VM if created in large numbers.
  • Primitive types are not objects - they are not polymorphic and cannot exhibit any object behavior. Object equivalents behave polymorphically (the numeric ones form an inheritance hierarchy derived from java.lang.Number) and exhibit useful behaviour - e.g. Integer.compareTo(Integer).
  • Primitive types are passed by value into methods. Object equivalents are passed by reference.
  • Primitive types are not reference counted or garbage collected. Object equivalents are.
  • Primitive types are mutable. Their object equivalent classes are all immutable.

Saturday Mar 08, 2008

On Generics

What is Generics?

Generics provides a way for you to communicate the type of a collection to the compiler, so that it can be checked. Once the compiler knows the element type of the collection, the compiler can check that you have used the collection consistently and can insert the correct casts on values being taken out of the collection.

When we declare c to be of type Collection, this tells us something about the variable c that holds true wherever and whenever it is used, and the compiler guarantees it (assuming the program compiles without warnings). A cast, on the other hand, tells us something the programmer thinks is true at a single point in the code, and the VM checks whether the programmer is right only at run time.

When was Java Generics introduced?

JDK 1.5

How is this different from C++'s template mechanism?

You might think that generics are similar, but the similarity is superficial. Generics do not generate a new class for each specialization, nor do they permit “template metaprogramming.”

Generics and subtyping

Is the following code snippet legal?

List<String> ls = new ArrayList<String>(); //1
List<Object> lo = ls; //2

Line 1 is definitely legal. But line 2 will give a compile time error.

Well, take a look at the next few lines:

lo.add(new Object()); // 3
String s = ls.get(0); // 4: attempts to assign an Object to a String!

In general, if Foo is a subtype (subclass or subinterface) of Bar, and G is some generic type declaration, it is not the case that G is a subtype of G. This is probably the hardest thing you need to learn about generics, because it goes against our deeply held intuitions.

What is the supertype of all kinds of collections?

It’s written as

(pronounced “collection of unknown”) , that is, a collection whose element type matches anything.

Is this valid?

Is the following code valid?
Collection c = new ArrayList(); //1
c.add(new Object()); //2
Line 2 will give a compile time error since we don't know what element type of c stands for, we cannot add arbitrary data to it.

Tuesday Mar 04, 2008

Java Serialization

What is serialization?

The process of saving an object's state to a sequence of bytes, as well as the process of rebuilding those bytes into a live object at some future time.

What can I use?

The Java Serialization API.

The Rules

Rule #1: The object to be persisted must implement the Serializable interface or inherit that implementation from its object hierarchy.

To persist an object in Java, we must have a persistent object. An object is marked serializable by implementing the interface, which signifies to the underlying API that the object can be flattened into bytes (and subsequently inflated in the future).

public class PersistedClass implements Serializable

Rule #2: The object to be persisted must mark all nonserializable fields transient

On the other hand, certain system-level classes such as Thread, OutputStream and its subclasses, and Socket are not serializable. These should be marked transient since it doesn't make sense to serialize them.

transient private Thread notserialthread;

Version control Gotcha!

Imagine you have a serialized flattened object sitting in your file system for sometime. Meanwhile, you update the class file, perhaps adding a new field. What happens when you try to read in the flattened object?

An will be thrown! -- because all persistent-capable classes are automatically given a unique identifier. If the identifier of the class does not equal the identifier of the flattened object, the exception will be thrown.

If you wish to control versioning, you simply have to provide the serialVersionUID field manually and ensure it is always the same, no matter what changes you make to the classfile.

How? JDK distribution comes with a utility called serialver which returns the generated serialVersionUID. (it is just the hash code of the object by default).

Simply copy the returned line with the version ID and paste it into your code.

The version control works great as long as the changes are compatible. Compatible changes include adding or removing a method or a field. Incompatible changes include changing an object's hierarchy or removing the implementation of the Serializable interface.




« June 2016