Alphabet soup

More so lately, I've been doing a fair amount of work in Java with Eclipse as a development environment. I've been working on both Linux (my main platform for development) and Mac OS X (which I keep around for digital audio / music applications and a few games). The experience is about the same on both platforms; it's nice to see some of the advantages of desktop Java applications shining through.

What gets me about the development world is the sometimes almost comical barrier to entry in terms of nomenclature. Specifically, the endless swarm of acronyms, marketing speak, and double talk that surrounds certain technologies, that is almost damaging. Learning Java, the programming language, is trivial compared to learning Java, the marketing object. I understand differentiating one's self within a market place; fear not Sun - you're different.

One of the worst offenders of terminology warfare is J2EE. I've spent the last few weeks sorting through all of the Blueprints, Tech Articles, White Papers, FAQs, API Specifications, and Glossaries that Sun has to offer at the main java site and I'm not sure it had to be as soup-ish as it was. I'm positive a lot of the ire that Java has been awarded by certain communities is due, in part, to the thickness of said barrier to entry. Some people don't have an enterprise to worry about and are alienated by some of this kind of opacity.

And, more to the point, it's really a shame. When you dig into the ideas behind the Java Message Service, for example, it all makes perfect sense and really is a pleasure to use (most of the time). I understand that with abstraction comes a certain degree of, well, abstraction, but this is kind of silly.

The JMS API enhances the Java EE platform by simplifying enterprise development, allowing loosely coupled, reliable, asynchronous interactions among Java EE components and legacy systems capable of messaging.

I know what it means, but it really raises more questions than it answers for those that don't have a clear understanding of what (exactly) a Java EE component is. Admittedly, the Java 5 EE Tutorial is one of the better guides I've seen for jumping into a framework, but finding it when you don't know it exists is a daunting task, in and of itself.

Eclipse, as a platform, also suffers from a bit of the same. Again, here's a case of a great tool buried under a strange sheen of marketing cruft. The Eclipse project page is daunting to someone who's looking to figure out just exactly what it can do. Clearly, it's extensible, but does it have to actually optimize solely for the beginner and the expert, only? As a real world example, I wanted to find an integrated UML editor for Eclipse. I won't tell you how that experiment ended, but it included a tour of EMF, GMF (which isn't at all like the GEF), GMT, M2T, Model Driven Development integration (affectionately dubbed MDDI), and MDT. In the end, I was rewarded with a tree view that allowed me to add children like Class, or Interface Realization. I know what that means, but I swear I saw screenshots of a graphical UML editor, didn't I? Surely those G* projects do something other than draw trees.

I hope that, one day, a bit of transparency can be brought to these kinds of tools (or platforms; whatever). Until then, I suppose it's just the price of entry into a world that does, in fact, have a lot to offer to a wider audience.