Brian Goetz’s talk on Java Performance Myth had to be the funniest of them all. Laughing at C programmers who insist on writing object pools and backwards for loops is both fun and easy. Let’s all write “clean, dumb code” was Goetz’s plea to everybody and insisted the JVM doesn’t suck and is smarter than those sorry, mangled-up minds that think public getters/setters is an overhead. Basically, the JVM puts some serious thought in the optimization of compiled code including dead code elimination, optimized garbage collection and resource allocation.

His assault on all those pricks who write micro-benchmarks and happily conclude that X is faster than Y was also refreshing. A counter-example goes a long way in debunking a myth and that’s what he resorted to when showing that in some cases it might be faster to compute 1+1 by doing 1+2-1. Pure nonsense, it turns out the JVM remembers execution paths and the order of operation does matter. Conclusion: most micro-benchmarks are useless since they ignore JVM optimizations and runtime correction.

My favorite part of the talk was a production code example he gave when iterating an array, I reproduce it here for it’s humorous value:

int i = 0;
try {
  while (true)
  doSomething(array[i++]);
} catch (ArrayIndexOutOfBoundsException e) {
  /* exit loop */
}

Pure genius eh?

I’m starting to like this guy, he’s saying Java should be faster than C and since this is already true for resource allocation and memory management, it should be completely true in ten years when those JVM dudes figure out some more ways of stealing CPU cycles. Here’s a great example of some JVM optimization: Virtual methods have been a performance hit since the object hierarchy needs to be searched at runtime and since every method in Java is overridable and thus virtual, the JVM must do some searching. Or does it? Well, it doesn’t. If a method is not overridden, the JVM will treat it as mono-morphic and optimize it accordingly making it inline. Same goes true for declaring final methods - it doesn’t help, just clutters up the code base.

I’m glad that Vector has finally received a reprieve and can finally be used in Java code (local variables only please) without suffering embarrassment or humiliation. Synchronization for local variables is much different than members and Goetz authorized the use of Vectors with reckless abandon. I’m going to go and change all my ArrayLists to Vectors right now. No seriously, its good to know there’s no penalty where there shouldn’t be. JVMs are smart enough to make unshared synchronized collections as fast as unsychronized ones. But this leads me to a deeper question, why would you have an unshared synchronized collection, wouldn’t that be a paradox? Besides the point.

Poor Java does suffer from this label that it’s slow as molasses, but times have changed and so has the JVM, what might have been true 6 years ago is probably not anymore. Goetz’s claim that performance advice has a finite shelf life is 100% bang-on. The JVM now keeps multiple copies of compiled code and can swap it out based on runtime patterns, that’s a feature that .NET loves to pride itself on but it’s hardly even mentioned in the Java world.

Clever code is NOT faster code so stop trying to be a smart-ass and just write simple Java. Even if you have to make your code ugly to increase performance by a nanosecond, there’s a great chance that the next version of the JVM will make your efforts redundant. So unless you have some serious performance requirements, there’s no reason to write code that looks like shit.

Random Notes: International Terminal sucks, Blackjack is not easy, They make you walk through the casino to get to your room, Air Canada staff are idiots, Airport security is lax

There has to be a better way than to write Java code and have it “compile” to JavaScript for anybody to use AJAX functionality. Bruce Johnson’s cry to the crowd that there’s absolutely no performance hit in doing so was falling on on deaf ears until his claim of the “perfect caching” implemented by GWT. A statement that sent murmurs through the crowd and promptly encouraged everyone to grab their session evaluation sheet and circle the 1 in all categories.

All this talk of leveraging the Java language is making me nauseous. I can’t help but think of the poor bastard who’s been developing in JavaScript all these years and has pretty much become a guru at it, only to realize that he’s been using the wrong language all along. Basically they want your application to be one page and every transition happens using GWT - talk about being tied to a product! Not that Google’s going bankrupt anytime soon but once you go to GWT, you really, really can’t go back. GWT seems like a decent product but I’m wondering whether adopting it early in a project isn’t “slipping into poorly planned AJAX development” as Johnson claims people are doing.

So what happens if your application becomes too big and increases in size, why you GZip it of course! Give Google credit for thinking outside the box and adopting a Maven’ish approach to developing in JavaScript - compile, package, deploy. They even give you an embedded browser of sorts to use during development where your edited Java code is “deployed” using a simple refresh. All those Google aficionados are free to wet their pants at the sight of GWT, but they’d be a fool to not try out Scriptaculous or Dojo first. There’s no reason to kill a bird with a cannon.

Nati Shalom and some programmer talked about Space Based Architecture and it’s Spring Integration until he was blue in the face and the audience was close to tears. The coming up lunch break didn’t help matters. Yes, you guessed it, there’s also a <space> XML namespace in Spring2 making declarative SBA very easy to use and abuse. The concept of SBA is simple enough to wrap your head around but if your demo consists of showing the EXTREMELY verbose logging of three JVM’s at the same time, things are going to get hairy. At least have the decency to turn the log level down or maybe even completely off and just use System.out.println() statements. I tell you the people in the back were getting shifty for every time he said, “It’s that easy” or “It’s that simple”.

The cool part of this presentation was how nicely the architecture handled failover and relocation using SLA. The declarative approach of using annotations and Spring configuration was also something good.  It’s easy to extend the model and any underlying implementations without having an effect on the deployed application. But really, when have we ever been forced to swap out a DAO layer at runtime? The point is taken though. Gigaspaces seems to have it’s dirty little hands all over distributed persistence and JavaSpaces, it’s just too bad they don’t throw the parties Virtuas threw.

Chet Haase apologized on America’s behalf for Romain Guy (pronounced Gee) being denied a US visa insisting that Guy is not a terrorist, just French. He seemed almost apologetic for even being there and showed his genuine shock that he wasn’t alone in the Filthy Rich Clients presentation. He tried to get some hormones jumping by showing “cool” demos like Guy’s Aerith application but it would take a lot more than a fade-out to get this crowd excited. But wisely, Haase had a Plan B which included plugging his Timing Framework by showing interpolators, Glasspanes and non-linear interpolation, all good stuff, but hardly applicable to 90% of the developers out there. Some poor sap in the front row wondered where the HTML port and CSS integration was, to which Haase responded and I’m doing some serious paraphrasing, “You’re in the wrong room”.

Fades, Pulses, Morphing, Animated Transitions are all cool stuff and there’s no denying that but I wonder how much time companies doing Java clients have to make things look pretty, especially when testing this stuff is fairly hard. It’s not like you can use Selenium for this stuff. The coolest thing he showed was the PropertySetter and how it reduces the boilerplate code to do animations, tie this along with acceleration and deceleration and you got yourself a filthy rich client that will “ooze cool”. This would’ve been a much more impressive talk if the AV team had figured out how to dim the lights in the room. Main theme of the presentation: Buy the book, it’s called Filthy Rich Clients.

Ross Mason, the Mule head-honcho, tried his best to combat the increasingly hostile AV equipment while promoting Mule2’s integration with Spring2, the former not yet GA’d. His moaning of how hard the team is working to get Mule2 out was in direct contradiction with the entire weekend he spent gambling away at The Venetian - yeah Ross, I saw you near the slots over the weekend. So Mule2’s approach is something called “The Hollywood Principal” which means “Don’t call us, we’ll call you” - damned if I know what that means. Mule is the latest to create their own Spring XML namespace and from the examples, it didn’t seemed terribly hard to get an ESB going.

Mule’s also proud that you don’t have to mention class names in your Spring config files anymore which is seen as a big plus? Not sure if that’s really the case since there will be a tight binding somewhere else and you’ll just be jumping through another hoop to get Spring to work. Of course, no talk is complete this year without a mention of OSGi and this one was no exception. Turns out an OSGi container will do hot deployment of Mule endpoints, services, transformers and anything else you dream up. Not a bad talk, would be better if his audio worked.

The guy sure is proud that the Mule IDE doesn’t overwrite your code changes once you go from code-view to design-view. Is that really something so special that you have to point it out? And one more thing, stop showing the donkey from Shrek and pretending it’s a mule - it’s not a mule, it’s a donkey! I was going to download Mule to test it out, may as well do it once it’s got the Spring2 stuff in it. Also, stop wasting your time on Drag’n Drop features for the IDE, that’s stupidness.

Mark Richards seems like a guy who could talk for 16 hours straight without any water or oxygen. When this talk ended I felt a lot better because I finally saw some people who were as confused as me about what an ESB is and what it does and doesn’t do. Instead of defining what an ESB is, Richards first proved that nobody really knows what it is by whipping out three different but widely accepted definitions of an ESB through “Buzzword Bingo” which I loved. Instead, he tried to solve the problem of how to deploy a distributed environment and offered point-to-point solutions using JMS Queues and Adapters which ended up solving the problem but required additional work such as wrapping the messaging protocol etc. So even if we supply a good level of abstraction, we’re still bound to a contract and if the application changes, so must the client. The answer to this problem? An ESB.

Service Locational Transparency and enterprise wide security seem to be the two major benefits of having an ESB, both of which are currently undoable using point-to-point techniques and plain old web services. It was a great talk by Mark Richards who was nice enough to dumb it down to code examples when talking about SLT, consistent service access and implementation decoupling.

The talk was titled The Enterprise Service Bus: Do We Really Need it? and Richards seemed to answer, Yes, unless you’re a wannabe architect working on one pathetic system. The need for an ESB seems directly proportional to the number of different transport methods and disparate systems your services are being provided from. If you’re doing POWS (Plain Old Web Services) on a single cluster, it’s definitely overkill. If you’re managed to get yourself tangled up in queues, web services and RMI, I say go for it.

Rod Johnson pitched Adrian Colyer’s talk on Spring’s OSGi integration and I bit. It’s surprising that an idea so old and good is only now being realized and accepted. I raise me hand when I say I had little clue of what OSGi was until this conference except that Eclipse’s plugin system was based on it. Lots of talk about visibility, versioning and operational control coming through a British accent makes you feel warm and fuzzy but let’s face it, we’re years away from OSGi actually being adopted in the mainstream. No matter how hard Spring tries to “osgi” their modules, they’ll still have to wait for the likes of commons-lang to comply with OSGi before somebody can actually build a true OSGi based system.

So the idea of having more than one version of a module in the same JVM seems to excite everybody but I’m wondering if that really is a good thing? What does it say about your application if it’s dependent on spring-jdbc 1.2.8and spring-jdbc 2.0? Sounds to me you’re using OSGi to cover up some pretty crappy software design and decisions. Colyer had a good, concise and short-scoped talk on OSGi and anybody who didn’t know what it was before they entered the room, had a damned good idea when they left it. These Interface21 guys don’t seem so bad in person as they do on the forums.

Random Notes: Lost around 15 bucks, Cirque Du Soleil is overrated, Gondola rides are for posers, 10 dollars for a drink at The V is robbery