Google annouces Gmail offline…

Google will begin to offer browser-based offline access to its Gmail Webmail application, a much-awaited feature.

This functionality, which will allow people to use the Gmail interface when disconnected from the Internet, has been expected since mid-2007.

That’s when Google introduced Gears, a browser plug-in designed to provide offline access to Web-hosted applications like Gmail.

Gears is currently used for offline access to several Web applications from Google, like the Reader RSS manager and the Docs word processor, and from other providers like Zoho, which uses it for offline access to its e-mail and word processing browser-based applications.

Rajen Sheth, senior product manager for Google Apps, said that applying Gears to Gmail has been a very complex task, primarily because of the high volume of messages accounts can store. “Gmail was a tough hurdle,” he said.

Google ruled out the option of letting users replicate their entire Gmail inboxes to their PCs, which in many cases would translate into gigabytes of data flowing to people’s hard drives. It instead developed algorithms that will automatically determine which messages should be downloaded to PCs, taking into consideration a variety of factors that reflect their level of importance to the user, he said. At this point, end-users will not be able to tweak these settings manually.

“We had to make it such that we’re managing a sizable amount of information offline and doing it well in a way that’s seamless to the end-user,” he said.

For example, in Gmail, users can put labels on messages, as well as tag them with stars to indicate their importance, and Google can use that information to determine which messages to download. Sheth estimates that in most cases Gmail will download several thousand messages, preferring those that are more recent as well. Depending on the amount of messages users have on their accounts, they may get downloads going back two months or two years, he said.

Google will begin to roll out the Gmail offline functionality Tuesday evening and expects to make it available to everybody in a few days, whether they use Gmail in its standalone version or as part of the Apps collaboration and communication suite for organizations.

While the feature was “rigorously” tested internally at Google, it is a first, early release upon which Google expects to iterate and improve on. That’s why it’s being released under the Google Labs label. Users are encouraged to offer Google feedback.

Users have been able to manage their Gmail accounts offline via other methods for years, since Gmail supports the POP and IMAP protocols that let people download and send out messages using desktop e-mail software like Microsoft Outlook and others.

However, the Gears implementation will let people work within the Gmail interface without the need for a separate PC application. When offline, messages will be put in a Gears browser queue, and the desktop and online versions of the accounts will be synchronized automatically when users connect to the Internet again. This will come in handy for people who travel a lot and often find themselves without Internet access, Sheth said.

Immutable Class.

Immutable class is a class which once created, it’s contents can not be changed and cannot be inherited. Immutable objects are the objects of immutable class whose state can not be changed once constructed. e.g. String class

To create an immutable class following steps should be followed:

Create a final class.
Set the values of properties using constructor only.
Make the properties of the class final and private
Do not provide any setters for these properties.
If the instance fields include references to mutable objects, don’t allow those objects to be changed:
1. Don’t provide methods that modify the mutable objects.
2. Don’t share references to the mutable objects. Never store references to external, mutable objects passed to the constructor; if necessary, create copies, and store references to the copies. Similarly, create copies of your internal mutable objects when necessary to avoid returning the originals in your methods.

E.g.
public final class FinalPersonClass {

      private final String name;
      private final int age;

      public FinalPersonClass(final String name, final int age) {
            super();
            this.name = name;
            this.age = age;
      }
      public int getAge() {
            return age;
      }
      public String getName() {
            return name;
      }
}

All wrapper classes in java.lang are immutable –
String, Integer, Boolean, Character, Byte, Short, Long, Float, Double, BigDecimal, BigInteger

Java classloaders..

Classloader allows JVM to load classes. Regular Java applications running from command line involve three classloaders – Bootstrap, Extensions and System-Classpath classloaders. The three class loaders have a parent child relationship among themselves

1. Classes in the list of bootstrap classes— These are classes that embody the Java platform, such as the classes in rt.jar.

2. Classes that appear in the list of extension classes— These classes use the Extension Mechanism Framework to extend the Java platform, with archive files (.jar, .zip, etc.) located in the /lib/ext directory of the runtime environment.

3. User classes—These are classes that do not use the extension mechanism architecture identified using the -classpath command-line option or the CLASSPATH environment variable.

Classloader problems, when they occur are difficult to debug. There are only three basic principles to understand.

Classloader hierarchy illustrating the delegation.

The first principle is Delegation Principle. According to this principle, if a particular class is not loaded already, the classloaders delegate the requests to load that class to their parent classloaders. This delegation continues until the top of the hierarchy is reached and the primordial classloader loads the class. The System-ClassPath classloader loads a class called MyApp. MyApp creates a new instance of java.util.Vector. Assume that java.util.Vector has not been loaded already. Since System-Classpath classloader loaded the MyApp class, it first asks its parent, the extension classloader to load the class. The extension classloader asks the Bootstrap classloader to load java.util.Vector. Since java.util.Vector is a J2SE class, the bootstrap classloader loads it and returns. Consider a slightly different scenario. In this case, MyApp creates a new instance of MyClass, another application specific class. Assume that MyClass has not been loaded yet. As usual, when the System-Classpath classloader receives the request to load the class, it delegates it to its parent. The request finally reaches the Bootstrap classloader. It cannot find the class. Hence its child, Extensions classloader tries to load it. It cannot find it either. Finally the request comes back to the System-Classpath classloader. It finds the class and loads it. This explains the alternative path when everything is not a happy day scenario.

Classloader hierarchy illustrating the delegation when classes cannot be found

Classloader hierarchy and classes visibility.

The second principle is the Visibility principle. According to this principle, Classes loaded by parent classloaders are visible to child classloaders but not vice versa. What this means is that a class can only see other classes loaded by the ClassX’s classloader or one of its parents. The reverse is not true i.e. a class loaded by ClassX’s parent classloader cannot see ClassX. An example will make things clearer. Look at above figure. Four classloaders are shown- ClassLoaders A, B, X and Y. Class A is the topmost Classloader. ClassLoader B is its child. ClassLoaders X and Y are B’s siblings. Each of them loads classes with same names i.e. A, B, X and Y. A is the only class visible as far as other classes loaded by ClassLoader A are concerned. As far as classes loaded by ClassLoader B is concerned, A and B are the visible classes. Similarly for classes loaded by ClassLoader X, classes A, B and X are visible, but not class Y. Sibling classloaders cannot see each other’s classes.

The third principle is the class Uniqueness Principle. According to this principle, when a classloader loads a class, the child classloaders in the hierarchy will never reload the class. This follows from the delegation principle since a classloader always delegates class loading to its parents. The child classloader will load it (or try to load it) only if the parent hierarchy fails to load the class. Thus the uniqueness of the class is maintained. An interesting scenario emerges when both parent and child classloaders load the same class. You might think how is this feasible after all. Isn’t this contradicting the class uniqueness principle? To answer this question look at figure again. Let us assume that none of the classes have been loaded anywhere in the hierarchy. Let us also suppose that X, loaded by ClassLoader X, forcefully uses its classloader to load B. This can be done as shown in example below by using an API such as Class.forName(). The code shows such a scenario. Using Class.forName() 01 public class X { 02 03 public X() { 04 ClassLoader cl = this.getClass().getClassLoader(); 05 Class B = Class.forName(“B”, true, cl); 06 } 07 } In the constructor for X, the class B is loaded by explicitly using Person’s parent classloader, i.e. the parent of the classloader that loaded Person. By doing so, the delegation is overridden and B is loaded by ClassLoaderX – the classloader of X. Now suppose that another class loaded by ClassLoader B tries to access B, it cannot find it and hence follows the delegation principle. Since the delegation principle only consults the parents, ClassLoader B also eventually loads Class B. When some other code tries to compare two objects of type B – each loaded by different classloaders, it gets a ClassCastException.

What is JAR hell ?

JAR hell is a term similar to DLL hell used^{[citation needed]} to describe all the various ways in which the classloading process can end up not working.

One case is when a developer or deployer of a Java application has accidentally made two different versions of a library available to the system. This is not considered an error by the system. Rather, the system will load classes from one or the other library. A developer who thinks he has replaced a library with a new version, but who has instead simply added the new library to the list of available libraries, may be surprised to see the application still behaving as though the old library is in use, which it may well be.

Another version of the problem arises when two libraries (or a library and the application) require different versions of the same third library. If both versions of the third library use the same class names, there is no way to load both versions of the third library with the same classloader.

The most complex JAR hell problems arise in circumstances that take advantage of the full complexity of the classloading system. A Java program is not required to use only a single “flat” classloader, but instead may be composed of several (or, in fact, an indefinite number of) nested, cooperating classloaders. The interactions between classloaders is too complex to be fully described here. It is sufficient to say that classes loaded by different classloaders may interact in ways which may not be fully comprehended by the developer, leading to inexplicable errors or bugs^{[citation needed]}.

The OSGi Alliance specified (starting as JSR 8 in 1998) a modularity framework that solved JAR hell for current and future VM’s both in ME, SE, and EE that is widely adopted. Using metadata in the JAR manifest, JAR files (called bundles) are wired on a per-package bases. Bundles can export packages, import packages and keep packages private, providing the basic constructs of modularity and versioned dependency management

Java supports pass by value or reference?

I have seen people getting confused with this. Just to make clear – Java always pass by value and not by reference.

Now comes the confusing part. If Java pass by value, then how come the value of properties in objects get changed. Well, the reference of object is passed as parameter.