Steve Levine

Well folks, another year, another Java One has passed. This conference has definitely got me thinking about a lot of things, especially the future of Java “The programming language”. You must be thinking, why in the world did I add that little blurb about “The programming language”, I mean, Java is nothing but a programming language right?

Wrong! There is a little thing called the JVM (Java Virtual Machine) that most of take for granted each and every day, when we open our IDE’s, start up our Application Servers, run our debuggers, etc…

Did you know that over 200 programming languages have been ported to run atop the JVM? All this talk about Java showing its age, and being out dated doesn’t necessarily mean that Java is going away. The language may go away, and when I say go away, I don’t mean go away, I mean maybe not be the top choice of language for writing future applications on top of the JVM. Java will never go away, just like Cobol is still around. There are enough core business systems written in Java/J2EE to last a life time. Just ask any Cobol programmer, after 30 years, they still have jobs available to them.

You must be thinking how can I compare Java to Cobol! Well, let me pose this question to you, namely, if a recruiter calls you up today describing an excellent opportunity working with J2EE/Struts 1 application. What would you think? J2EE/Struts 1? To me, that is “legacy” code, and it is nothing that I would like to work with now a days.

Dare I say it? Parts of the Java ecosystem are starting to look like Cobol? This is not a new concept at all. It all started many years ago. I would say some of the first people to publicize it was people such as Rod Johnson (Creator of The Spring Framework and CEO of Spring Source) and Bruce Tate (Author of Bitter Java, Better Faster Lighter Java, and Beyond Java). I would have to say that Bruce Tate said it best in his book Beyond Java. Keep in mind that book was authored many years ago. Thus, what I am saying is nothing new at all, it is just a concept that was thought of many years ago finally coming in to fruition.

Where is the proof? The proof is in the pudding (The JVM pudding). At Java One this year, it felt like it shouldn’t really be called Java One anymore, but maybe JVM One. It was interesting to see all of the slides at Java One this year said “The Java Programming Language” instead of just Java. Each session I attended the Presenter found it interesting how their slides were modified making this distinction. If you look beyond the slides, you start to see something interesting, namely, the fact that over half of the sessions offered had nothing to do with Java the language. Sessions like, “The Scripting Bowl”, which was a competition putting some of the leading scripting languages against one another. (I will go in to more details in a separate post, it was quite an interesting session), “Grails In The Enterprise”, “JRuby on Rails”, “Functional Programming with Scala”, to name a few. There were many more.

After a weekend of recovering from information overload, I think I have finally drawn a conclusion, namely, Sun has realized that Java the programming language has lost steam with all of the “Cool” folks. There are tons of efforts going on to try to make Java more appealing again like adding Closures to it. Right now, that effort is confused at best. No one has a clear and direct answer to how/if they should be added. It is of the opinion of some folks, that we should stabilize Java as it is, and create a new and improved Java 3.0.

The main point to focus on here is the distinction Sun is making between Java the language and Java the Platform, and the reasoning behind it. If you piece all of the clues together, you can draw the conclusion that Java as a language is loosing steam, and Sun realizes this, but Java as a platform, (JVM), is not going anywhere. There are tons of compelling languages available now that run atop the JVM. Some dynamic, some static, some functional, you name the programming paradigm, and there is a language available to use to target the JVM.

The main point of this post is to show a clear distinction between Java the language and Java the platform. In my next post I will discuss which languages have the best change of being the new Java 3.0.

I have been using Eclipse for the past 5 years.  During that time, there have been projects where I have been exposed to Intellij.  Recently, after a conversation with a colleague, they convinced me to give the latest and greatest Intellij a try.  They bragged about the wonderful Spring integration and code inspection.  So I decided to give it a try.  After using it for about a month now, I must admit, I have seen the light.  It took a while to get used to the different keyboard shortcuts even though Intellij has the default Eclipse key bindings available as a selection.  I decided to do a clean break from Eclipse, and learn the new keys. 

Since I develop on the Mac, there was one HUGE problem for me with Intellij, but I am not sure if it is an Intellij or a OS X problem.  I want to be able to map cmd-space to content assist.  For some reason, every time I hit cmd-space in Intellij, I just get a system level beep.  On my Mac Pro at home, it is not really an issue, since I have a full keyboard, and I have a ctrl key on the right side of the keyboard.  On my Macbook Pro I do not, and it is very awkward for me to have to move my left hand to try to find the ctrl key.  I am SO used to using my right hand for ctrl, it was starting to become painful. 

I looked around to try to figure out a way to create the key binding with no luck.  I tried to remap ctrl-j to it, but then it looses the live template content assist.  If I can use ctrl-j for both of them, that would not be so bad.  I also tried to find a system level solution, that would allow me to override the cmd-space limitation in Intellij with no luck.

Finally… One morning I was looking at my keyboard, and I noticed this somewhat useless key on the right hand side of my keyboard called the “enter” key.  What is that?  Why do I need two enter keys?  Oh, I see, if I want to use the “numeric” keypad on the keyboard, it would be useful to have an enter key there.  What am I an accountant? 

I started thinking, if I can remap the useless enter key to be a ctrl key, my problems would be solved.  Low and behold I found Double Command.  What an totally useful program.  It allowed me to remap the enter key to be a ctrl key. 

Problem Solved.

What happens when you try to synchronize on a static method? When a static synchronized method is called, which object are we referring to? A static method does not have a notion of a this reference. It is not possible to obtain a lock on an object that does not exist.

How does it work? When a static synchronized method is called a Class lock is obtained before calling the method. This mechanism is exactly the same as the non-static implementation. It just obtains a different lock. The same exact synchronization rules apply to a class lock that apply to an object lock.

How is this lock related to the object lock? They are not related at all. In fact, they can be used independenly of each other. If a non-static synchronized method calls a static synchronized method, they are effectivly obtaining both a class lock and an ojbect lock. Achieving a deadlock between these two locks is difficult, but not impossible since a static synchornized method can only call a non-static synchronized method via an ojbect reference.

What happens if two different object hash to the same hashcode and then are placed in a HashMap?

If two keys hash to the same hashCode, or to the same hashCode modulo the size of the table, all still works. It just takes a little longer to look up that key, since get() has to chase a chain of clashing keys to find the match. Keys are matched with the equals() method, not ==, or simply by comparing hashCodes.

Let me repeat this another way. Collisions happen not only when two of the HashCodes are identical, (quite infrequent) but when two of the Hashcodes modulo the initial capacity are equal (which almost always happens at least a few times). Collisions are unavoidable. The Hashtable class deals with them automatically. They slow down lookup, but do not derail it. The smaller the load factor, the more RAM you waste, but the fewer the collisions, so the faster the lookup. Using prime numbers for the divisor/capacity also tends to reduce collisions.

HashCodes are usually not unique. If you think about it, how could they be? Consider Strings of length 10 characters (20 bytes, 160 bits). How many different possible strings are there? 2^160. HashCodes are only 32 bits long. How many possible different hashCodes are there? 2^32. You can see there are way more strings that HashCodes, so strings would have to share HashCodes.