RCP: Store the state of your application

A really nice feature of RCP applications is the ability of persisting the current state of the application. Well this is realy nice to know that you have such support, but knowing how to do it  is a bit harder. After you find out how to do it than it is a peace of cake.

Check this short article and you will see how simple it can be:  http://eclipse.dzone.com/articles/remember-state

The whole thing is a nice implementation of the Mememento Design pattern.

Happy coding.

Java modularisation (JDK 7.0)

Recently I have red some interesting articles regarding this new plan of Sun’s, to modularize the JDK.

I have to say that when I first read about this I was a bit angry because of theyr intention to change the Java language and implement the modularization mechanism directly using special keyword. At first glance I had the feeling that this is too much change to implement a runtime modularization mechanism, considering the fact that OSGi has done it really nicely without any change in the language, but back than I have overlooked something, which I just realized after reading some articles about this topic.

Sun tries to address the most urging problem of Java platform: The huge monolithic runtime.
So the first taught seem to be to have this big JRE and split into modules and have a dynamic update mechanism which would ONLY update the changed parts of the runtime and not all, hereby minimizing the amount of download needed and time spent on updating. To achieve this there is no other way than implementing the modularization concept at the Java language level. Nice idea. This, if done well, will actually take the Java Runtime to a next level, and maybe will put the language back to the RIA race, next to Flex and Silverlight (even if not a 100% real competitor but still…).

Even if there a huge debate over if this approach mostly because of why is Sun implementing a new modularization system and is not using the already de-facto standard, OSGi, to accomplish the modularization task, I still think that the JRE and JDK modularization should be done in lower layers (inside the language or VM) rather than in some layers above the runtime. I have to highlight that I find this approach as good idea ONLY for JRE and JDK modularization.

If I think of runtime I think that the OSGi would be the best way to have application modularization done well, because of the flexibility and maturity of this concept. So hereby I would consider as bad idea to imply using a language based modularization for everybody. I guess the backward compatibility should be maintained and the option to chose any modularization framework should be left in the hands of the application developers.

Have look at the articles I found about this topic:

The massive, monolithic JDK
The Modular Java Platform
Project Jigsaw
OSGI-About Jigsaw
Project Jigsaw II
Project Jigsaw III
Modularity in Java-Alex Buckley 

JDK 7

And some related articles:

OSGI standard questions
Classpath hell just froze over

Happy coding

N

The pitfalls of .equals()

I have recently ran into an interesting article about the way a good .equals() method should be implemented.

This made me realize that I usually do not care about how I implement (if I even implement) the  equals()  method of a newly written class.

Let’s have a look at how Sun has defined the following contract for this method:

public boolean equals(Object obj)

Indicates whether some other object is “equal to” this one. The equals method implements an equivalence relation on non-null object references:

* It is reflexive: for any non-null reference value x, x.equals(x) should return true.
* It is symmetric: for any non-null reference values x and y, x.equals(y) should return true if and only if y.equals(x) returns true.
* It is transitive: for any non-null reference values x, y, and z, if x.equals(y) returns true and y.equals(z) returns true, then x.equals(z) should return true.
* It is consistent: for any non-null reference values x and y, multiple invocations of x.equals(y) consistently return true or consistently return false, provided no information used in equals comparisons on the objects is modified.
* For any non-null reference value x, x.equals(null) should return false.

The equals method for class Object implements the most discriminating possible equivalence relation on objects; that is, for any non-null reference values x and y, this method returns true if and only if x and y refer to the same object (x == y has the value true).

Note that it is generally necessary to override the hashCode method whenever this method is overridden, so as to maintain the general contract for the hashCode method, which states that equal objects must have equal hash codes.

Parameters:
obj – the reference object with which to compare.
    Returns:
true if this object is the same as the obj argument; false otherwise.
    See Also:
hashCode(), Hashtable

After reading the article How to Write an Equality Method in Java i guess, starting now I will have to reconsider the way I treat the equals() method implementation, because (as you can read in the above article) there are too many scenarios where this can kick back, really hard.

How do you feal about this? Do you pay a some attention to the equals() method whenever you write a data class?

Happy coding.

N