Fragmentation or Diversity?

'Diversity Clucks' by chrisjfry

In conversation with a client recently, we discussed the issue of fragmentation in the Java EE space, and how it impacts large organisations. Java EE (previously J2EE) is a set of specifications and standards, with no definitive IDE or application platform. This is by design, and is in contrast with .NET development, which (almost) invariably takes place in Microsoft’s Visual Studio IDE, and deployed to Microsoft’s Internet Information Server application platform runnning on Windows. Java EE systems may, on the other hand, be developed in Oracle’s JDeveloper, IBM’s Rational Application Developer for Websphere, IntelliJ, Eclipse, or NetBeans. Applications may be deployed to Tomcat, BEA Weblogic, IBM Websphere, JBoss, Glassfish, Oracle’s Application Server, and so on.

As an example, consider a large organisation with several development projects on the go at any time, each one started by a different owner/business unit, and potentially hiring individual contractors to get started on the bones of the project, from a spec they’ve created together. The contractor often chooses the framework based on their own experience, and so begins the tie-in for that particular project. As projects mature, their internal development staff take over maintenance of the project, and discover that they have to learn another framework, platform, or even IDE as they transfer between offices.

One solution employed may involve hiring the same large consultancy firm for many of their projects. This ensures consistency — a large consultancy firm will have internal development guidelines and standards — but is quite expensive, so far from ideal. Many organisations hire individuals to provide the expertise required to kickstart a project, and then add their own developers once the maintenance phase arrives. This is where the fun begins.

A modern Java EE application might use JSF or even Visual JSF. Or maybe Struts 2. Or perhaps Spring MVC. Each of these relies on a proper build process, so maybe we’ll use the IDE to build it. Netbeans. Or perhaps Eclipse. Or maybe an IDE-independent build tool, like Ant. Or perhaps Maven. Then we’ll deploy it to a suitable application platform. Glassfish, maybe. Or JBoss. It’s no longer enough just to learn the language; one must also learn the multivarious frameworks, tools, platforms to get one’s work done. One client told me that of the ten developers they had working in their Java EE team, each one had a distinct setup on their workstation. And this was on the same application, all using the same tools and the same platform. So why not just stick with one framework?

Consider Struts. Well, actually, we can’t, and that’s sorta the point. Struts (1) and Struts 2 are significantly different from each other, to the point that migration from Struts to Struts 2 is quite tricky. The developer’s website links to a three-hour tutorial, a three-part guide, and in the Migration Strategies, suggests (as its first option) running Struts 1 and Struts 2 in parallel. So, I think it’s fair to say they are sufficiently different platforms as to be considered separate.

Having said all that, I still think it’s a good thing that this diversity exists. Yup, what I called fragmentation earlier is now diversity. Look at the open source world: the Linux kernel has had thousands of developers working on it, yet is as enterprise-ready (if not more so) than many more monolithic systems. There is no single Linux distribution; Red Hat, Ubuntu, SuSE — all have carved their own very large niches in the industry, and each with a large degree of success. Sure, a project may start and then flounder as another, similar project dominates the niche. Perhaps one or two major players succeed at the expense of others, and we end up with competition in the space, with quality improving on both sides; KDE vs. Gnome, Eclipse vs. NetBeans, .NET vs. Java EE. Evolution is needed to get to that point, and that’s where diversity is a good thing.

Therein lies the challenge for large organisations. The results of such evolution are good for the industry, but the process of evolution is painful. Your modern large organisation is not the instrument of change and improvement; you are not in the business of helping the world decide which framework is the next big thing. You need to make the decision: either reap the benefits of the last generation’s evolution, and back the previous winner, or pick one of the current generation of technologies and stick with it. This is the challenge of conservatism vs. early adoption, but it’s a nettle that must be grasped.

Photo “Diversity Clucks” by chrisjfry

Returning a copy of an object

Consider an object passed (by reference) into a method, which then modifies the object. Should the method return the object on completion?

Well, it’s redundant. Here’s why.

There are two approaches to doing this – the classic way (caller chooses what to manipulate/change), and callee changes (which is what happens when you pass in an object by reference:

If the caller chooses what to manipulate, then your method will operate on a copy of the dataset, and return that copy, leaving the original untouched. Then the caller may overwrite the original, if desired. Many array operations in Perl work like this.
The alternative lets the called method do the in-place operation, in which case the return value is more typically a boolean (“Yes, I’ve succeeded!”) or an int containing the number of values affected. This is how database updates work.

Of course, if the object is not passed by reference (i.e. a copy is passed into the method) or if the method explicitly returns a modified copy, then returning an object is the right way to do it.

Installing Java Applications via "Setup" Utilities

As with many applications, you may wish to install a Java program with a setup utility that installs the files and sets up appropriate shortcuts. However, there are some subtleties with Java application installation that require some extra thought.

Java applications can only be run on a machine with a JRE (Java Runtime Environment), so any setup utility won’t run quite the same as other application setup files; you won’t be able to give someone your setup file and expect it to run correctly, unless they already have the appropriate JRE.

It is still possible to install Java applications using standard Windows Installer utilities; some tools allow you to bundle (or download and install) a suitable JRE as part of the Windows Installer process, resulting in the application’s files being installed along with any dependencies.

It’s even possible to install Java applications as a service in Windows, using additional wrapper utilities.

However, in Java, the usual way to do the “setup routine” is typically going to result in a “jar” file. This way, you can launch the program by using a shortcut that launches the JVM and points it to the appropriate jar file. From the user’s point of view, this is indistinguishable from any other shortcut, but of course it requires that the files and JRE have already been installed.