GMail does not understand dots...

I recently discovered some little-known ways to use a GMail address that can give you greater control over your inbox and save you some time. Actually, when you choose a Gmail address, you actually get more than just "yourusername@gmail.com"; here are two different ways you can modify your Gmail address and still continue getting your mails:

• Append a plus ("+") sign and any combination of words or numbers after your email address. For example, if your name was yourusername@gmail.com, you could send mail to yourusername+friends@gmail.com or yourusername+mailinglists@gmail.com.
• Insert one or several dots (".") anywhere in your email address. Gmail doesn't recognize periods as characters in addresses -- Google mail just ignores them. For example, you could tell people your address was hikingfan@gmail.com, hiking.fan@gmail.com or hi.kin.g.fan@gmail.com.
  

For me, the real value in being able to manipulate your email address is that it makes it really easy to filter on those variants. For example you could use yourusername+bank@gmail.com when you sign up for online banking and then set up a filter to automatically star, archive or label emails addressed to yourusername+bank. You can also use this when you register for a service and think they might share your information. For example, I added "+yahoogrp" when I subscribed to some yahoo groups once, and now when I see emails from other groups to that address, I know how they got it and can apply a filter to auto-delete the mails.

Simple Serialization

The Simple XML serialization framework has released version 1.2. Simple is a serialization framework for Java that intends to provide an XML serialization framework that requires no configuration or mappings to serialize objects bi-directionally; i.e. to and from standard XML. Below is a list of some of the capabilities of the framework.

Simple framework with powerful capabilities
The framework used to provide XML serialization is simple to use and revolves around several annotations an a single persister object used to read and write objects to and from XML. Both serialization and deserialization are fully supported.

It requires absolutely no configuration
Unlike many of the XML frameworks for Java there are no mappings or configuration required to serialize objects regardless of its complexity, not even code to establish mappings. Everything is done at runtime, only annotations are required to perform the object to XML structure. The XML schema is represented using field and method annotations.

Converts to and from human editable XML
A primary goal for the framework is that the XML data used to deserialize and serialize objects is human readable. All XML elements and attributes take a simple structure that can be easily created with a text editor. Also the serialization format is compatible with the C# XML serialization format.

Contains an XML templating system
As part of the deserialization process template markers within the XML elements and attributes can be replaced with variables. This allows the system to be easily adapted for use as a configuration system with dynamic value substitution. Stock template filers include OS environment variable substitution, system properties, as well as an API that enables custom filters to be introduced.

Provides persister callback methods
During serialization and deserialization an object can recieve persister callbacks, to validate and prepare data during the process. Each callback allows the object to manipulate the persistance session, which allows values to be passed in to and out of the templating engine, and allows arbitrary attributes to be passed between the persisable objects.

Allows XML to drive composition
The serialization and deserialization process is controlled by an exensible strategy API, which allows objects to be created based on custom XML attributes. This allows interception of the object creation in order to delegate instantiation to object factories.

Fully self contained
For Java 6 the framework has no external dependancies and is completely self contained. For Java 5 two external JAR files are required, the StAX API and the StAX implementation, both are provided with the download.

Open source
Released under the LGPL and so can be fully integrated or adapted for both commercial and open source projects.

The Simple Home : http://simple.sourceforge.net

Is Java String really immutable...?

In many texts String is cited as the ultimate benchmark of Java's various immutable classes. Well, I'm sure you'd have to think the other way once you have read this article.

To start with, let's get back to the books and read the definition of immutability. The Wikipedia defines it as follows -

'In object-oriented and functional programming, an immutable object is an object whose state cannot be modified after it is created.'

I personally find this definition good as it mentions that an immutable instance's state should not be allowed to be modified after it's construction.

Now keeping this in the back of our minds, let's decompile Java's standard String implementation and peep into the hashCode() method -

public int hashCode() {
int h = hash;
if (h == 0) {
int off = offset;
char val[] = value;
int len = count;
for (int i = 0; i < len; i++) {
h = 31*h + val[off++];
}
hash = h;
}
return h;
}

A detailed look at the above code reveals this to be a classic implementation of the 'lazy evaluation' pattern; i.e. the String class instead of computing the hash value [1] during an instance's construction or [2] computing it each time the hashCode() method is called; computes it once, i.e. on the first call to hashCode(), and saves the computed value in the hash attribute.

Now, here is a test to prove the above quoted statement -

String string = "MyDearString";

Field field = String.class.getDeclaredField("hash");
field.setAccessible(true);

System.out.println("Before: " + field.getInt(string));

string.hashCode();

System.out.println("After: " + field.getInt(string ));

Anxious to know what the output would looks like? Here it is...

Before: 0
After: -1554135584

So this infers that for a given String instance which we create, but for which we never call hashCode(), the private hash field will remain to be zero. It is only changed when we call hashCode().

Well, don't you find this in contrast with the basic definition of an object's immutability?

One might argue that we can not observe a String instance in a different state without a reflective read of String's hash field and because the call to retrieve the state actually modifies it; if we can't observe it changing.

Well, if one doesn't observe a change does that mean it never happened...?

This reminds me about the other day when i scratched my new car, from below, against an irregular speed-breaker and my friend Manish said that I should not be worried about that because if a scratch is not visible its never been there. Well, is it really never there...?

However it seems like String is not immutable. Although it seems safe, ignoring reflective access, it definitely looks incorrect.

Post me your views around this...