The Java community may never see a Scala or Spring standard

The Java community may never see a Scala or Spring standard

The Java community may never see a Scala or Spring standard

By Cameron McKenzie

TheServerSide.com

Standardization and compliance with the Java Community Process (JCP) is more than a nicety or act of nobility. When managers and JavaEE architects choose the technologies that will be used to develop enterprise applications, they expect technologies and application programming interfaces (APIs) that have been certified by the community. As a result, no Java developer worth his salt would ever think of connecting to a database by using something other than standard JDBC APIs, or performing transactions without using the Java Transaction Service (JTS) and the corresponding standard set of APIs (JTA).

In light of the importance of complying with standards, and using standard technologies certified by the JCP, it is worth noting that some of the most popular frameworks like Spring, and increasingly popular JVM languages like Clojure and Scala, have never so much as submitted a Java Specification Request (JSR) for review. It makes one wonder if there will ever be a Spring standard certified by the JCP.

To understand the implications of this lack of standardization, it’s important to first understand a little bit about the standardization process used by the Java community. When a new technology arises for doing something like messaging (standardized through the Java Messaging Service) or building Web components (long since standardized through the Servlet and JSP API) or even developing a new version of the Java Runtime Environment (JRE), a JSR is generated.

The JSR that gets submitted to the JCP essentially consists of two key pieces, one of which is simply a design document which describes the specification and the set of associated APIs that comprise the various classes, methods and properties that developers will be able to use when they write their code. The second piece of the puzzle is the reference implementation, which actually uses the specification to do something.

The design document describes what a given specification does and explains how it is supposed to be done. The reference implementation provides a working model for observers to interact with. With a reference implementation, other vendors, developers and prospective contributors have something to work with in order to get a tactile experience of the way the whole JSR is meant to work.

“The reference implementation provides an example of how a particular standard should be implemented. It’s usually working software that you can run and say ‘ok, this is how this thing should behave.’ Ideally it’s open source,” Says Reza Rahman, Caucho's Community Outreach Advocate and author of EJB 3 in Action, about the process.

Some real world reference implementations include the Oracle maintained Mojarra project, which is the reference implementation for JavaServer Faces, and Weld, which is the JBoss maintained reference implementation of JSR-299, the standard for dependency injection and contextual lifecycle management.

Perhaps the most important part of this whole standardization equation is the TCK or the Technology Compatibility Kit, which tests the extent to which individual implementations conform to a set standard. For example, each application server on the market allows for transactional database connectivity. If every application server, be it WebSphere, JBoss, Resin or WebLogic did database access differently and in non-standard ways, portability of enterprise Java applications would be a nightmare.

By having a JDBC standard and a standard transaction service (JTS) and  API (JTA), we can expect and experience common behavior out of all of the different vendors. If an implementation passes all of the TCK tests, then we can be confident that it is compliant with the standard.

Standardization, as a general concept, makes various components interoperable, which only becomes necessary when multiple separate parties are implementing those components.

Let's think about this process for a second: the idea is to make sure common behavior and consistency is achieved when different parties implement a given specification. If this is the case, why would technologies like Rod Johnson’s Spring framework need to be standardized? After all, only SpringSource provides the Spring framework. This also explains why we don’t see JSRs or attempts to standardize alternate JVM languages like Scala or Closure.

“It’s just a lot of work.” says James Strachan, Software Fellow at FuseSource and the inventor of Groovy who did actually try to create a JSR for the language. “I even got an award at JavaOne for the most innovative JSR, but I don’t think it ever got finished. But do you really need to standardize if there is only ever one implementation of something?” 

To further the point, Winnipeg’s Scala expert Craig Tataryn asserts that “standardization only makes sense if there is more than one vendor.” When there is only one vendor of record, and there will only ever be one vendor of record, standardization simply doesn’t make sense. ”

But there’s still more to the process of standardizing your Java based technology that goes beyond passing the TCK test. When standardizing, an implementation is developed, you test your implementation against the TCK, and if the implementation you created passes the Technology Compatibility Kit test, you know the implementation is correct.

But, says Reza Rahman, "that's not the end of the process, though. Once you pass the TCK you then have to get certified." You submit your implementation to the JCP or Oracle and they will say "yes, we also ran the TCK against this piece of software and yes indeed it does pass, we are certifying that it is standards compliant." Now here’s the other wrinkle. Certification is not free, so you need to pay something to get your certification. Not only is certification a load of work, and not only is it a time consuming process, but it also means money that needs to be paid out of pocket for certification, which is something startups and aspiring framework developers simply don’t have in abundance.

The originators of specialized frameworks like Spring and alternative JVM languages like Groovy have precious little motivation to submit a JSR for JCP approval. As James Strachan recalls, it’s a heck of a lot of work. As Reza Rahman mentioned, it’s costly. As Craig Tataryn says, standardization really doesn’t make sense if there is, and will only ever be, one vendor producing that technology. In addition, if the technology is good, such as the Scala programming language, and so long as the Java community trusts the vendor as it does with SpringSource and their flagship Spring framework, the fact that the technology in question hasn’t gone through the JCP process does not present an obstacle to the technology's adoption.

 

Follow Cameron McKenzie on Twitter (@potemcam)

Recommended Titles

Josh Suereth's Scala in Depth on Amazon.com
Martin Odersky Programming in Scala
Cay S. Horstmann's Scala for the Impatient
Martijn Verburg's The Well-Grounded Java Developer

08 Mar 2012

Related Content

Related Resources