JFokus 2009

Just getting back from JFokus in Stockholm where I presented both a University and general session. The cool thing was the speakers gift. Following on from ORedev, the conference made a donation in the speakers name to a charity. While Oredev was giving away bricks to schools in Africa, JFokus gave Polio vaccines. Way cool!

 I did two talks a JFokus. My University session was somewhat bi-polar. On the one hand I watched people scratching down notes as fast as they could as I was speaking. On the other hand I got watch with demo daemons. It all started off with yet another video problem. I could not get the screen to clear up. Finally the techies came in with a new cable and that seemed to solve the problem. My first demo was to create a Apache JMeter script. The first half of the script worked perfectly. The second half of the script caused threads to fail. After some futzing about I finally got a working script, however the damage had been done. I might have recovered but then I suffered from 2 more demo bugs. Strange thing is, these were demo’s that I’ve done in the past and without any difficulties. In fact, one of the demos I did was one that I'd thrown into another talk that I did earlier in the year. It was a completely last minute decision to throw it into that talk and without any prep, the demo went off perfectly. Since that first talk, I'd presented the demo several times every time without any issues. I guess my luck finally ran out. 

My concurrency talk didn’t suffer from demo devils but the talk is still to complex and this is after I'd dumbed it down once again. The topic... non-blocking concurrent data structures. Next time I think I’ll try to give it a thread’s eye view.

Being a one day event I didn’t get a chance to attend many sessions. The biggest problem (if you can call it that) was constantly get caught up in hallway discussions that always seem more interesting than the session. I did manage the IntelliJ talk about Groovy. It was fun watch Ola Bini answer all the questions and win all of the stress balls. Ok, he left a few for others. Next was Cameron Prudy’s talk on based on his 10 ways to screw up theme.

Of course you know Cam is about Coherence when he speaks but he never mentions the product. Instead he always delivers a solid “vendor pitch” free talk typically using a 10 things theme. I particularly enjoyed the clever use of Dr. Seuss like poetry.

If I ran IT
Said young Gerald McGrew
I’d make a few upgrades
That’s just what I’d do

Follow that with tidbits like, building for scalability cannot speed up an application. So true! All you can do is keep it from slowing down but it is unlikely you’ll speed it up.

One of the more interesting hallway conversation that I can talk about was one with Rickard Oberg. The coding experiment he’s currently engaged in is; set the contract to state that you can’t pass in null. With that simple statement in the contract, he never bothers to check for null. If the framework encounters a null pointer, it will throw a null pointer exception. I can’t think of reason not to do this. If the user has passed in a null pointer, then they’ve violated the contract and they should be notified of that fact. And what better way to do this than to deliver the message in a null pointer exception.

Yet another conversation centered around the JVM. With all of the fragmentation going on the language arena these days, the conversation speculated on the possibility that we should also expect some fragmentation in the JVM space also. In fact I later learned that there is a possibility that we could start to see this happening this in the near future.

It’s been quite some time since I and a number of others started talking about how the JVM was much more important than Java the language. By placing a JVM between our application and the hardware, we opened the doors to a number of solutions to problems that are not so easily solvable if we were to immediately compile down to a binary. The first biggest bang for the buck is the ability to optimize byte code on the fly. Not only that, any language compiler that produces byte codes can take advantage of this capability and they do. Take JRuby for instance. It runs faster with each release of the JVM.

More over, if the JVM becomes the dominate application, we can tune our hardware and operating systems to better support it. And again, any application running in the JVM will automagically benefit from these optimizations.

Speaking of performance, I still see teams putting faith in the “Shot in the Dark” performance anti-pattern. In fact, I met managers for one team and their whole strategy with tools to help their customers make wins with performance was based on guessing which data to collect so just in case there is a performance problem and the customer wants to look at something, they’ll have something for them to look at. I don’t know. Maybe that will be good enough to cover a number of scenarios. That said, it’s clearly “shot in the dark”. I've no doubt that there is a measure don't guess solution avaliable to them.