J2EE and beyond

Impressions from the "No Fluff, Just Stuff" Java Symposium

Launched in 2001 from Denver Colo., the "No Fluff, Just Stuff" (NFJS) Java Symposium series is quickly becoming the hottest training conference among Java developers all over the country. Distinguishing itself from megaconferences such as JavaOne, the NFJS conference limits attendance; does not require time off from work; costs a fraction of JavaOne; and claims to focus on the technology rather than any commercial product. Touted as the technology conference with the highest signal-to-noise and quality-to-price ratios, NFJS is now offered in 15 US cities.

Does it really live up to the hype? For those of us who do attend the conference, what are the latest trends and tools we learn? With those questions in mind, in February 2003, I attended the Austin, Texas version of the NFJS conference: the Lone Star Software Symposium. I had a great time there.

Developer-focused conference

Updating skill sets represents one of the biggest reasons why developers should attend technology conferences. With the uncertain future of any specific technology platform and the irreversible trend of overseas outsourcing, developers themselves are responsible for diversifying their skill sets and moving up the value chains to stay employable. With leading experts, informal sessions, and diverse topics, the NFJS conference provides an excellent format and environment for learning new skill sets.

Industry leading experts

The NFJS conferences feature an impressive list of expert speakers, including best-selling authors, Apache project contributors, and leading local software consultants. They speak on a variety of topics focused on J2EE (Java 2 Platform, Enterprise Edition), open source, and agile software development. The inclusion of local talents certainly helps bring diversity and fresh perspectives to the conference. In fact, some of the best sessions I attended were presented by local speakers.

Speakers referenced in this article
  • Mike Clark, president, Clarkware Consulting
  • Damon Clinkscales, senior software engineer, Vital Source Technologies
  • James Duncan Davidson, freelance author, software developer, and consultant
  • Sharon Fay, chief software productivity strategist, Flashline
  • Erik Hatcher, coauthor, Java Development with Ant
  • Jason Hunter, author, Java Servlet Programming
  • Ted Husted, author, Struts in Action
  • Norman Richards, senior engineer, Zilliant
  • Dr. Venkat Subramaniam, president and cofounder, DuraSoft
  • Eitan Suez, founder, UptoData
  • Bruce Tate, author, Bitter Java
  • Dave Thomas, author, The Pragmatic Programmer: From Journeyman to Master and Programming Ruby: A Pragmatic Programmer's Guide
  • Glenn Vanderburg, principal, Delphi Consultants
  • Maciej Zawadzki, president, Urbancode Software Development

See Resources for links to books.

Formality matters

As most of us have experienced in large trade shows, ballroom sessions with more than 1,000 people are one-way communication channels not much different from television broadcasts. The NFJS conference limits its attendance to 200 people, and the Austin conference had less. With four parallel sessions at any given time, the controlled attendance number ensures a high level of speaker-audience interaction not seen in most other conferences.

Breadth but not depth

The only way to master a technology or a tool is by actually using it. Conferences do not substitute advanced in-depth training. All NFJS sessions, including the three-hour tutorial sessions, provide introductory material and review simple code examples. The value of the conference is its breadth. For example, an entity EJB (Enterprise JavaBean) expert probably does not learn much from the EJB sessions. But she can go to a JDO (Java Data Object) session to learn a new perspective or an XDoclet session to learn how to deal with J2EE "descriptor hell."

Note: What is J2EE descriptor hell?
J2EE deployment descriptors separate application development and deployment processes. The same binary application can be customized for different deployment scenarios using descriptors. However, in the real world, descriptors are often abused. The J2EE specification and vendor-specific application servers require too many different descriptors. Even worse, much information redundancy is present across those files. Keeping those scattered information pieces in sync when we make changes proves difficult. The term descriptor hell borrows from the term DLL (dynamic link library) hell in the Windows world. It refers to the situation where the descriptors become unmaintainable by human developers. XDoclet tackles this problem by embedding meta information directly in Java source code comments and uses a post-processor to automatically generate all the correct descriptors during the build process.

Now, let's look at important topics covered in the conference.

New development paradigms

Many companies adopt requirement-driven, agile development methodologies to control software quality and improve productivity. But putting those methodologies in practice is easier said than done. Sharon Fay addressed the process management behind software development in her "Beyond Ad Hoc Reuse: New Visions for Java" presentation. She demonstrated that efficient reuse of software components requires a process that allows developers to quickly update requirements, build test cases, discover existing component assets, and collaborate on documentation.

While Fay focused on the managed approach in software development, James Duncan Davidson advocated the ad hoc open source model in his session "Collaborative Development." Davidson believes that tools, not methodologies nor processes, are the keys to collaborative development. He discussed open source collaboration tools such as CVS (Concurrent Versions Systems), Wiki, and blog. Using Wiki as a documentation tool especially interested me.

Mike Clark's "Test-Driven Development with JUnit" session and Erik Hatcher's "Applied Ant" session covered tools for agile development on the Java, especially J2EE, platform.

Post-OOP software development

Object-oriented programming (OOP) has been widely adopted in the past 10 years. But the basic OOP approach is showing its age for today's highly sophisticated software projects. New development paradigms improve upon OOP. The keywords for entering the post-OOP world are: design patterns and aspect-oriented programming (AOP).

Dave Thomas's "Decoupling Patterns" and Venkat Subramaniam's "Programming for Extensibility" sessions discussed best practices for reusable components. Thomas talked about the basics of static, dynamic, domain, and temporal coupling as well as the correct usages of interfaces and inheritance. For example, we all write code like customer.getLocation().getAddress().getLine1(). Thomas describes that practice as a "Java train wreck" because it couples each customer to only one location/address. A much better approach would directly express the caller's intent: customer.getMailingAddressLine1().

Glenn Vanderburg's "Introduction to Aspect-Oriented Programming and AspectJ" presentation covered the basic concepts of AOP and the AspectJ tool. AOP allows developers to weave crosscutting concerns, such as logging and security, into an existing class hierarchy. In many of today's applications, such as EJB containers, interceptors insert crosscutting concerns at runtime. Vanderburg gave a nice overview of the ongoing debate in the Java community about whether the Interceptor pattern is actually AOP.

Software for experts

Have you ever wondered why travel.yahoo.com cannot replace human travel agents? The answer lies deep in the design requirements of software systems for expert users versus systems for casual users. Thomas's thought-provoking "Naked Objects" session masterfully explained the philosophy and tools for a new design paradigm that offers maximum power and flexibility for expert users. The naked objects approach advocates behavioral completeness of objects: "All the behaviors associated with an object that are necessary to the application should be properties of that object and should not be implemented elsewhere in the system," says Thomas. That simple statement has powerful implications on UI (user interface) designs. For example, a travel reservation system should not force the user to follow any arbitrary script to go through the reservation process. Instead, it should allow the user to directly manipulate the underlying objects such as calendars, destinations, and reservation queues. Because those objects all have behavior completeness, the user can jump between them in no particular order.

The bitter anti-patterns

Inspired by Bruce Tate's best-selling book Bitter Java, the conference featured a series of talks that discussed developers' common mistakes, a.k.a., anti-patterns. With J2EE becoming mainstream business technology, this type of developer training is needed. The "Bitter Tunes," "Bitter Messages," (both by Clark) and "Bitter EJB" (by Tate) sessions covered anti-patterns in J2EE.

According to Tate, the biggest anti-pattern beginners often fall into is the "Golden Hammer" pattern: choosing the wrong tools for the job. The spirit of Java is the freedom of choice—for both OS platforms and tools. To approach any given problem, often, you can use more than one tool in more than one way. How do we know which approach is the best? That requires us to thoroughly understand the pros and cons of competing technologies.

Competing technologies

In his "JDO vs. EJB" session, Tate identified JDO as an important technology to watch. Tate nicely summarized the fundamental problems with entity EJB:

  • Lacks inheritance
  • Differs vastly from Java objects
  • Allows deployment-time query binding only

In fact, entity EJB is no longer considered a valid component model. JDO solves much of those problems and provides a much lighter alternative for object persistence. JDO is object-oriented (as opposed to component-oriented EJB) and transparent. However, I am concerned about JDO's byte-code enhancement approach, which post-processes Java class byte code to add in JDO functionalities. It could open the door for much abuse in the future.

Damon Clinkscales's "Object Persistence Approaches" presentation further compared JDO and EJB with WebObjects's Enterprise Objects Framework (EOF). EOF is a third-party object persistence framework library owned by Apple and provides the technology behind the Apple e-commerce Website. Since EOF is a pure Java library, it does not require complex containers (EJB) or byte code post-processors (JDO). EOF provides access to the generated raw SQL, and adaptors can provide access to nonrelational datastores. However, EOF is a nonstandard vendor-specific technology. It requires the developer to learn the proprietary API and creates vendor lock-in.

Open source is all the rage

The Apache Software Foundation and JBoss have come a long way in becoming primary J2EE vendors. Open source tools are secure, reliable, fast, and free. With improved support options, they are the driving force to commoditize J2EE application servers. In addition, open source projects have become great test grounds for emerging technologies.

For developers, skills with open source tools are portable. They are not tied to any specific application server or development tools. The NFJS conference featured a number of Apache project contributors and authors. Davidson, the original developer of Tomcat and Ant, gave a high-level "Open Source Explained" talk.

The conference adequately covered popular open source tools. Different levels of tutorial sessions were available for Ant, XDoclet, and Lucene (by Hatcher), Struts (by Ted Husted) and Castor XML/JDO (by Eitan Suez). All talks were highly informative. I especially enjoyed Suez's Castor talk, as it was packed with information and yet easy to digest. Despite its name, Castor JDO is not related to Sun Microsystems' JDO. Castor provides a set of powerful data binding tools to map and transfer relational tables and XML documents to Java objects, and vice versa. It addresses the real-world need to tie together the most popular data storage (database) and data transport (XML) with powerful data processors (Java applications).

Do not forget the basics

In his "Java Internals" presentation, Austin-based Java developer and author Norman Richards said, "Every programmer should thoroughly understand the layer they are working on and should have a solid understanding of the layer beneath them." This way, the quirky points in Java language specifications suddenly become clear when the underlying implementation is revealed. Richards also discussed a number of subtle points such as inner class security implications and the effectiveness of byte code obfuscation. It was an excellent low-level Java talk oriented toward high-level developers.

Important J2SE (Java 2 Platform, Standard Edition) features, especially new features and those related to enterprise development, were also covered in the conference. Maciej Zawadzki's two JAAS (Java Authentication and Authorization Service) talks ("Developing with JAAS" and "Beyond JAAS: Instance Based Security in Java") were nice introductions to the new pluggable security API for J2SE and J2EE applications.

1 2 Page 1
Page 1 of 2