When we were mapping out the plan for the third edition of Java Enterprise in a Nutshell, we started with a seemingly simple question. Six years after the publication of the first edition (when there was no J2EE, just a loose collection of standard "extension APIs"), and three years after the second edition (when J2EE was maturing and becoming entrenched), what does today's enterprise developer working in Java really need in a book like this? In other words, what is today's definition of enterprise Java, in a nutshell?
Oddly enough, pondering this question led me to think about SimCity.
SimCity was first released as a video game in 1989, and after a slow initial start, it rapidly became a hugely popular title. It still is. If you're not familiar with it, SimCity presents the player with a mostly blank landscape, a set of tools worthy of a metropolitan deity, and a simplified model of life in the big city. From there, the player creates either a thriving metropolis or a desolate wasteland, depending on how adept they are at wielding near-total power within this ecosystem. The analogy to enterprise software development should already be painfully apparent.
The reason SimCity was and is so popular, and has spawned so many sequels and spinoffs, is not the graphics, or the user interface, or the sales and marketing campaigns by the publishers of the game. SimCity captured a community of gamers because of the ecosystem that the game's designers created, and the empowered role that they created for the players within that ecosystem. The designers discovered a happy balance between too little and too much control over the parameters of the SimCity universe, allowing players to be creative, adventurous and "productive," in a recreational sense, without getting overwhelmed with detail.
They also left enough space for players to define their own goals. A player can work to create a larger and larger city with as little internal strife as possible (the "traditional" goal of the game), or create a city that is as volatile and violent as possible (the "perverse" version), or create a city limited in size but as robust as possible (the "bonsai" version), or pursue a variety of other self-imposed goals. And for the very advanced players out there, there are ways to create your own terrain and your own city building blocks, and share them with the rest of the SimCity community.
Now shift your attention back to the Java ecosystem. The "players" in this ecosystem are software developers, architects, software vendors, open source collectives, and other individuals and organizations, all using the Java platform to create tools, applications, online environments, games, and entire enterprise architectures. The ecosystem has its own tools and its own set of "maxims" in terms of how things work in the world. These maxims start with the Java language and the Java virtual machine, and expand upwards in layers of standards and specifications and contracts and APIs and tools.
The Java technology ecosystem is but one of many overlapping ecosystems in the technology universe. But the Java ecosystem has arguably one of the most diverse and complex communities living in it. The community is not made up entirely of open source advocates, though they make up a sizable percentage of the populace. It's also not dominated by its corporate members, by academics, or by individual visionaries, though all are significant voices and forces among the citizenry. Its governance is not controlled by a single corporate "monarch," though a single vendor (Sun) is responsible for its genesis and does play a stronger-than-average role in certain aspects of the community's "infrastructure."
It's not surprising, then, that the foundations of the Java ecosystem (the code, specs, tools, and so on) exist across a broad spectrum, running from formal, universal standards to informal, localized tools, as shown in the figure below. On the left are objective standards that form the basic rules of the ecosystem, and on the right are subjective tools born of the pragmatic needs of members of the community. As you move inwards from the extremes, you run across the results of the years of evolution that have resulted in the current ecosystem.
From the fundamental standards evolved a family of higher-level standard APIs and specifications, defined within the Java Community Process--a subset of these make up what we now call the Java 2 Enterprise Edition (J2EE) framework. From the many tools and APIs developed by the community (as components of products, or as open/community source efforts, or as individual hobbies), a few have been self-selected by the community, and over time have become de facto standard practices within the Java ecosystem. A few are mentioned here: Struts, Ant, Hibernate. There are many, many more.
These two trajectories (from standards towards tools, and from tools towards standards) meet at what I call the standards horizon.
Outside of the standards horizon, the community is driven primarily by local pragmatics, politics, and personalities. Deadlines, revenues, time to market, deadlines, performance, code complexity, and deadlines rule the day here. Wherever these issues leave space on the calendar, personal creativity also has a chance to bloom outside of the standards horizon, a big motivating factor for software developers and architects.
Inside of the standards horizon, the work is driven by global pragmatics, politics, and personalities. Here, the view is on the long run. Community members that stray (or run, or are pulled) past the standards horizon operate in a more formal, structured fashion, defining the basic fabric of the Java ecosystem. Time itself seems to slow down (at least to the outside observer). But the satisfaction of creating a piece of the Java landscape is a huge motivation to the participants, and the potential benefits to their constituents and to the community at large are significant.
Given this characterization of the current Java ecosystem, deciding how to structure the new edition of Java Enterprise in a Nutshell was fairly simple. We just needed to assess how Java developers and architects were actually operating within this standards-to-tools spectrum, and cover the most well-trodden areas related to enterprise development. This led us to the table of contents in the third edition. Like past editions, we cover the key enterprise standards within J2EE, but with an expanded list, since the community has been busy pushing out the standards horizon for the past three years. So we've included updated material on old favorites like servlets, JSP, and EJB, but we've added new elements of the standards soup, like JSF and JAX-RPC, plus key standard contracts like J2EE application deployment. But we also looked outside of the standards horizon, and included new coverage of a set of key de facto community standards, like Ant, Hibernate, and JUnit, because these tools play an equally important role in the Java ecosystem. They fill gaps in the Java standards framework. These gaps in the framework exist either because a standard for a particular area hasn't been devised yet, or because an area simply doesn't lend itself to standardization and must be solved with context-specific tools.
And in case it isn't obvious, the Java ecosystem remains very dynamic to this day. Like any viable ecosystem, the community and the fruits of the members' labors (technology, in this case) are constantly in motion, evolving and being refined. Typically, the "technology drift" is from right to left along the spectrum. Smart people create useful tools and libraries on top of the existing Java frameworks, the best of these are widely adopted, and some of these "standard practices" are either directly adopted as standards, or strongly advise new standards defined inside of the standards horizon. This effectively pushes the horizon out a bit, providing more breadth to the overall Java framework. A recent example of this technology drift is the upcoming EJB 3.0 specification, which is a radical departure from earlier versions of the specification, advised very strongly by Hibernate and the people that created it. Another is the annotations facility built into J2SE 5.0, which borrows many concepts from the popular XDoclet annotations tool.
But all is not always calm and peaceful in Java City. There are the occasional grumblings, skirmishes, and outright rebellions among the community members. Some disagree with specific standards defined within the horizon, feeling that a "better" solution could be developed, or already exists in the community. EJB 3.0 represents the results of such a skirmish--after four major releases (1.0, 1.1, 2.0, and 2.1) of the EJB specification over five years (1998-2003), the community found itself using non-standard alternatives to EJB as much as, if not more than, EJB-based solutions to the same problems (that is, business components and persistence management).
EJB 3.0 (now in draft form) is a change in direction that came from an outcry in the community about the need for a new standard that matched the members' practical needs, which they felt were better served by an alternate model built into a de facto standard, Hibernate.
Another well-known example that is still simmering is the Eclipse project and its development of the Standard Widget Toolkit (SWT) for GUI components, an alternative to the standard Swing components included in the Java core APIs. The Eclipse architects had issues with the underlying design of Swing as a cross-platform GUI solution, and argued that the design underlying SWT offered better performance and a more native look and feel in various windowing systems. The two solutions still exist today on either side of the standards horizon, occasionally taunting each other across the DMZ.
These and other struggles in the community have led to even deeper arguments over the years, driving some community members to demand more openness in the rules for access to the standards technology, and greater accessibility to the process of defining the standards themselves. Some have called for opening up various subsets of the Java standards (the Java language, or the language plus the core APIs, or everything within the J2EE specification), under one of several open source license schemes (GPL, Apache License, and so on). Some call for a subtler shift in the philosophy of the Java Community Process, advocating much closer ties with the community and injection of community source efforts directly into the standards process, citing examples of the "not invented here" syndrome resulting in standards that take longer to define and are sometimes redundant with existing community best practices.
Left unresolved, clashes like these could threaten the foundations of the Java ecosystem. If large parts of the community start to abandon key parts of the Java standards framework in favor of local or tool-specific "dialects," the community could fragment to the point of dissolution. So it would seem that some kind of resolution is needed in order to restore harmony.
I close this article with a question: "What is the best way to keep the Java community healthy?"
In other words, in what ways does the community need to be reorganized to ensure that its members are both prosperous and content? Does a radical shift in the Java Community Process need to be initiated? Does Sun's involvement in the ecosystem need to change? Wherein lies the right balance on the standards horizon? How well does the standards process reflect the needs of the community at large, and how can it improve? Should we allow "natural laws" to determine the future of the Java ecosystem, and not try to over-legislate the community? Why, for that matter, should we be worried about promoting a healthy Java community? Is everything just fine in Java City, and should we all just quit whining and carry on?
I'll be actively seeking opinions on this question here in the online discussions, at JavaOne next week, and elsewhere. A followup article will appear in the coming weeks summarizing what I hear. I hope your voice will be part of the dialog.
Jim Farley is a technology architect, strategist and IT manager.
Return to ONJava.com.
Copyright © 2009 O'Reilly Media, Inc.