Why I love and hate statics in Java

I was chatting with some fellow geeks earlier this evening and it occurred to me that I've said to people that they should almost ALWAYS use static and also told people they should almost NEVER use static. Am I schizophrenic, a hypocrite, or just dumb. Maybe all three but it has nothing to do with this blog. I'm talking about two different language usages of the static reserved word.

USAGE 1, where the love is:
Inner classes. I hate non-static inner classes. IMHO non-static inner-class is unnecessary syntactic sugar that leads to hard to read code and subtle bugs. For those who don't know, non-static inner classes maintain a hidden instance variable holding a parent instance. It then uses specially generated methods to give access to the parent's private fields and auto-magically calls methods on the parent if no local method of the used name exists. I've seen this lead to memory leaks (people passing around instances of inner classes and not realizing that they are keeping around parents), all kinds of confusing issues with methods of the same name in inner and outer classes and variable problems of the like. On the occasions I use inner classes I almost always go with the static kind.

USAGE 2, no love here:
Static variables. With the exception of constants I have a strong dislike of static variables. Why you ask? When used to create various versions of singletons it leads to messy hidden code dependencies . It also makes it hard to do mock object stuff for testing, creates hidden initialization stuff and makes it difficult to create multiple environments in a single JVM. Just darn inflexible for no gain. I would go into details but this has been covered quite nicely here

Anyway, in summary, STATIC inner classes good, STATIC variables bad.
Goodnight ...

Saved by a Time Machine...

In the last 4 months I have had the good fortune of twice having my hard drive crash on me on my Macbook Pro. The first time I lost of bunch of stuff but was lucky to be able to recover some data off of various other machines. This last time I was saved by Time Machine. I'll be taking my computer to the apple store tonight for another hard drive replacement but I already have access to all my files. I just connected my backup drive to my wife's mac and clicked the time machine button. Selected use previous configuration, and I was able to recover some of the directories and files I needed to her machine. It was very simple and effective. So for those of you who have had lousy backup experiences and have given up. I recommend giving it another try with time machine. It bailed me out this time.

First experiment with JDK 1.6 on OS X

Ran into this article on JDK 1.6 on OS X from slashdot. I figured I would give it a whirl with Terracotta as an experiment. Turns out I just needed to hack the Terracotta OS version check in the ./common/src/com/tc/util/VendorVmSignature.java class because this jvm calls the OS Darwin instead of osx and then things just worked. Was kind of odd to see the JTable demo come up as an X window but things worked like a charm.

Using Web Clipping to Monitor DZone

Now that I've installed Leopard I figured I would try out a few of it's new features. At first I didn't really get this new Web clip button on Safari. Turns out, it's really kind of useful. It allows one to choose a piece of a web page and auto magically turn it into a widget.



I like DZone's little rising links section on the top left of the home page so I thought I would try it out on that. It's pretty much so easy that even the least technical person should be able to handle this. Here are the steps:

1. Go to the web page that has a part that you like to watch. Some examples might be my.yahoo.com or dzone.com (the one I chose)
2. Click on the button in the top bar of your web browser that looks like a pair of scissors and a dotted rectangle. Should be between the refresh button and the add link button.
3. Move your mouse around and see what clips get highlighted. When one you want to use as a widget is highlighted just click on it.
   
4. Towards the upper right click the "add" button if you like what you have selected and you are done.
5. Now, when you go to your widgets it will be there and refreshed every time.

Enjoy...

No Java, Bye Bye Macbook Pro's...

I have liked Mac's for as long as they have had OS X, didn't like them before that. Over 50 percent our Development/Field Eng team, have a mac. I've been accused of being an Apple fan boy on a few occasions. Unfortunately Apple is backing us into a corner. We develop Java infrastructure software and if Apple isn't going to take JVM on OS X seriously we will have to move off the platform.

http://www.cio.com/article/149200

http://javablog.co.uk/2007/10/26/apple-os-x-leopard-doesnt-have-java-6/

This would be very unfortunate for me, since I like my Macbook Pro, my team, because they like theirs and for Apple itself because we will stop spending thousands of dollars a year on Apple hardware. Hopefully they resolve this issue as I will be unable to purchase more Macs if this situation doesn't get resolved soon.

Goodbye Randy Pausch

Don't need to be a geek to learn from this one. One of the best CS professors I ever had is going too pass in the next month or so at the way to young age of 46. He has inoperable pancreatic cancer. For those who had the luck to have met or learned from him and for those who have not, this is his must see last lecture.

The Lecture
WSJ piece on him

Also check out some of his projects:

Alice
A bunch of his papers

My best to his family and friends and may his legacy live on. I only wish I could take one more class with you at the helm.

3.5 Rules in Distributed Algorithm Design

In highly concurrent distributed computing their are all kinds of algorithms one can learn. One can read books like Concurrent and Distributed Programming in Java and Distributed Systems: Principles and Paradigms. One can learn how to write scalable servers by reading things like these papers on SEDA. But when creating a distributed algorithm their are 3 simple Goals/Rules you need to follow. While these rules were developed with the Terracotta approach in mind they are mostly applicable to any distributed computing approach:

• Use algorithms that allow for maximum concurrency
• Seems obvious but design your algorithm to allow maximum concurrency. In a single JVM concurrency is important. In a distributed environment where lock acquire and release is almost certainly more expensive it is that much more important
• Use read locks where possible. If you can have multiple readers look at something, duh, don't stop them.
• Try strategies like striping, lock on fine grained objects etc (this is some of what concurrent hash maps do).
  
• Minimize chatter
• Many really cool concurrent algorithms are less good for distributed computing because of the amount of chatter (data that needs to be communicated between nodes).
• Algorithms that require too much cross node book keeping are a problem. Networks are slow and relatively thin pipes. Chattiness plays into that weakness and can also eat cpu.
• Take advantage of locality of reference
• Use algorithms that partition well
  
• Use algorithms that can mostly or entirely act on local data.
  
• Scale-out architectures don't have all the data everywhere. They rely on various levels of caching both near and far for optimal performance. When hitting data try to hit data in the same node where possible.

Rule 3.5 exists as well. Remember not to guess at the performance of something. Test it, time it and automate as much as possible of those tests and timings.

This has been a public service announcement.