Couldn't agree more with Eckel here. Java's had some strange feature bloat in recent years. I really like Java 5, but I think if they keep throwing stuff in to the language it will get worse, not better. LeGros would probably argue that Groovy is our sanctity.

Eckel's post made me think of something that I believe is a true death-knell to all technologies: backwards compatibility. I've argued strongly and consistently over the years that I believe a big key to Apple's success and some of Microsoft's failings have been due to Apple's willingness to break backwards compatibility to move forward.

At CFI, we have consistently "wasted" three to six months per year of development effort on "upgrading" our Oracle database and application servers. In most cases, the databases have become slower and the new features added between releases have made very little impact to our environment; we're basically just upgrading to stay PCI compliant and guarantee Oracle's support. Each time we've gone through this rigmarole, we've had to modify our apps in slight ways to make them compatible. This would be an example in my mind of trying to make a technology backwards compatible with a software application.

This "waste" has been a fixture of mine as we set up our new software architecture. I don't ever want to be held back from a new technology or have to rewrite anything at any point in time. Of course, we'll make decisions on upgrades and changes, but I'm fine with that so long as our hand is never forced the way it has been in the past. Oracle's Forms technology has a horrible coupling between the application server and the database, and this was something I knew we had to avoid as we move forward.

Luckily, the ESB and SOA principles seem to offer real hope here. All of our current services and apps are being written in Java and Flex, and but it won't be long before we add Ruby, and maybe even some .NET for really tight integration with some Windows-only functionality. Because everything speaks XML and SOAP (and those technologies that don't can provide something we can transform in to one of those two) it's going to be pretty simple to make switches as we see fit. Sure, there is always an overhead to adopting a technology, but that will just be another element we factor in to the decision. The choice will always be ours to upgrade or not, and in the interim I can run Flex 1.5 alongside Flex 3 talking to a mix of services written in Java, Ruby, or access our legacy apps via messaging over Oracle's AQ (an example of 100% painless backwards compatibility, with no constraints imposed). They can all run on different OSs for all I care; that's the beauty of the service architecture.

So, I say this: make things evolve, or watch them die. I'm already convinced that CF is on its way out, and I think Java is destined to be dethroned in the coming years (although I bet it has five to ten really good years left in it before that happens). Either way, it will be fun to watch.