Saturday, January 1, 2011

Java mistakes which should be corrected in future.

These days i am re-iterating all my language concepts especially java concepts. Actually i am reading a book called Java: The Good Parts. So reading this after doing a good amount of ruby coding gave me some understanding of things which i would like to be changed in Java Future versions.

1. Primitive Types : Primitive types certainly breaks the notion of "everything is an object". It makes special rules for those small types. Yes Autoboxing is smart thing and we dont need to thing about conversion anymore but we can go one step ahead and replace primitives types by real objects and compiler can take care of optimization.

2. Static : First thing i learned in my pairing session at ThoughtWorks was not to use Static as much as possible instead create a singleton object. Reason again it breaks the "everything is an object" model.We lose the freedom to override the behaviour as static calls are are linked compile time. And testing a static method is lot more tough task as mocking is cumbersome.

3. Checked Exceptions : Because nobody use them anymore. Most of the time if problem occurs we can't do much other than telling user something wrong happened and continue or shutdown.

4. Every Object is a Lock Object : This i realized while reading the book and i was like what. I am doing java programming now for three years and i didnot realized this we can take lock on every object while writing synchronised block because every object has in-built lock. This sounds pretty waste of resource. Instead we can start using explicit Lock object like we do in C++.

If we try to make these changes than the resulting java will not be compatible with its previous versions but it will be lot more cleaner and awesome language.
And i also want ruby/python hash like datatype. It is so so awesome just like swiss army knife ;-).

I wanted to start the year with a bang just the way i ended last year thats why this post. So happy new year to all.
Cheers,

3 comments:

Dushyanth Chickabasapa said...

Java does have Java.util.locks package which has classes like ReentrantLocks......which are nothing but explicit locks..... and about the internal locks they are thin locks hence the memory wastage is minimal..... but true we can do without having intnisic locks..... but again compatibility is an issue....

Asif said...

yes i know about the java explicit lock mechanism. that complete concurrent package added in java5 is awesome. I was talking from POV of JVM optimization. Yes it will be a non-backward compatible java. Thats the first criteria to implement any of these 4-5 things.

tuxdna said...

Quite interesting observations on Java you have. Java has a lot of baggage and limitations ( compared to newer languages ).

Thanks for sharing.