A few pieces of nonsense about Java

And I always thought ScienceWorld and, by extension, ComputerWorld were knowledgeable sources. After reading Where are those once-hot technologies? (via Pavel Houser’s piece How we got our predictions wrong: WAP, XML, the semantic web…), I’ll have to change my mind. I haven’t seen so much nonsense about Java packed into so little space in a long time.

Java absolutely everywhere

From the beginning Java was seen as something that would conquer the world. As a highly object-oriented language it was much more elegant than its predecessors. Write Java code once and it could run anywhere. It was fast, reliable and secure. It was… in short, Java offered everything you could ask of a development tool. Compared with what it promised, the range in which it’s actually successful is unbelievably small.

I’ll point out the areas of greatest success, which no one can seriously dispute. Mobile devices and middleware, meaning server technology.

Still, it’s hard to ignore some disappointments altogether. Java’s first problem was applets. Macromedia carved out the rich media market for itself, pushing client-side Java to the margins of cross-platform utilities and administration tools.

Perhaps that’s the one part I can agree with. Applets never became as widespread as expected. We can only speculate about how things would have turned out if Windows had included a more advanced version of Java.

The language eventually found its followers primarily on the server side. By then, however, years of constant changes to the SDK, along with APIs that were often hard to understand and sometimes poorly designed, had clouded its once-elegant design. This often confused newcomers and made preserving backward compatibility a hopeless task.

This is hopelessly vague nonsense. Java’s design hasn’t changed, if that means its architecture. The API extensions have been and will continue to be backward compatible. If any esteemed reader knows what the writer was getting at, give us a clue in the discussion.

Java 2 brought an enterprise variant, Enterprise Java, probably the first truly mature version.

Apparently no one explained Java’s versioning to the author, let alone the basic distinction between SE (Standard Edition) and EE (Enterprise Edition) and how they relate. Anyone who knows the subject knows EE builds on SE, which defines APIs and contains the language specification, among other things. Without SE, there’s no EE. For example, you don’t need any part of the enterprise edition to write a desktop application, an applet or a midlet for a mobile device in Java.

Even so, many development companies still prefer ordinary servlets to the much more complicated EJB (Enterprise JavaBeans) architecture, supposedly the brightest jewel of the J2EE platform (Java 2 Platform, Enterprise Edition).

Phew, where to start? EE consists of many technologies covering particular areas. In EE, servlets and JSP are for building web application user interfaces. EJB is, to put it simply, for distributed server components.

If you want a web application and decide to write the application layer in EJB, you use servlets and JSP to present the data. They work together and can’t be mutually exclusive, since each serves a different purpose. It’s also worth saying that EJB isn’t a crown jewel. The community criticized it heavily and looked for alternatives, which led to EJB 3.0. There’s some material on EJB and its alternatives in this article on the Spring J2EE container.

Moreover, those who moved straight to J2EE now largely sacrifice Java’s portability, the ability to write code once and run it anywhere, in favor of proprietary extensions to their application servers.

This is a badly phrased piece of nonsense. The portability of the Java program itself isn’t at risk. It’s the deployment descriptors, the XML configuration for deploying the application, that are proprietary and differ by server. As for API extensions, you can choose whether to tie your code to a proprietary API or use an alternative, which is nearly always available.

And given that even committed open-source developers increasingly bet on competing technologies such as Microsoft’s C# through Mono, Java’s chances of conquering the world are shrinking.

From this you might infer that people write open source in .NET, especially the unofficial Linux port, which, if I’m right, doesn’t even cover all of it. That hardly needs a comment…

What are we supposed to think of the rest of the article after reading nonsense like this?