adam bien's blog

Adam Bien: Hi John, please introduce yourself. What is your Java background? What was your first contact with Java?

John Clingan: I am the product manager (PM) for Java EE and GlassFish Server at Oracle and Sun Microsystems before that, beginning with Java EE 5 and GlassFish v2. In the last six months I have also picked up PM responsibilities for EclipseLink, the JPA reference implementation developed in the Eclipse community, and Project Avatar, a server-side JavaScript for the JVM that supports the Node programming model. While I truly enjoy being the PM for Java EE and GlassFish (7 years now), I am enjoying the new responsibilities as a change of pace. They all keep me very busy!

John Clingan: Well, in my humble (and biased ☺) opinion, GlassFish has always been and remains a high-quality product. Keep in mind that a significant portion of GlassFish source code was the result of open sourcing the Sun Java System Application Server (SJSAS). SJSAS was a mature and feature rich product in its own right, and was deployed in many business critical environments by well-known organizations. GlassFish did not have the same challenges that new open source projects typically have, like building up new features from scratch, both around core development features as well as manageability. With the exception of new Java EE 5 features in GlassFish v1, it was battle-tested from day one as an open source project.

Adam Bien: Oracle dropped the commercial support for GlassFish. Could you reveal any secrets about this decision? What was the motivation?

John Clingan: No secret agenda or ulterior motive. We have been transparent about the reasoning behind it. It was becoming increasingly difficult to justify supporting, patching, and developing production features for GlassFish when Oracle WebLogic Server already fills that need. It is not productive to invest in two products that address the same market. However, GlassFish and WebLogic Server do fill differentiated and very important roles. GlassFish continues to fulfill the role of the Java EE reference implementation and is the first to support the latest Java EE standard. This offers a means for developers to learn the latest standards until vendors follow with commercial implementations. Commercial implementations by their nature follow the Java EE standard by 6+ months due to their need to integrate with a vendors broader product portfolio. So, Oracle continues to invest in GlassFish to address the role of the reference implementation as well as a high quality and productive development environment. Oracle WebLogic Server is the preferred Oracle application server for production deployment.

Adam Bien: Nevertheless, GlassFish is still alive. Would you appreciate more community contribution, if yes in which areas?

John Clingan: Yes, contributions are always welcome and should be based on whatever developers are able contribute. As always, bug reports, bug fixes, etc are welcome. Supporting the community in the discussion forums and mailing lists is another great way to contribute. Since we are starting down the Java EE 8 path, Adopt-A-JSR will directly impact GlassFish as the RI and Java EE the standard. We also accept feature contributions.

Adam Bien: Would you appreciate commercial support from other ISVs? Could Oracle support such vendors with e.g. appearance on the homepage etc?

John Clingan: The great thing about GlassFish being developed in open source is that it encourages not only the kind of contributions mentioned earlier, but also choice. Up until GlassFish 3.1 the market felt that Oracle was providing great support for Oracle GlassFish Server so there was less demand for third party support. With the roadmap announcement, new vendors are starting to support GlassFish. I never really thought about having a 3rd party support page at glassfish.org since we have historically tried to separate community from commercial interests. It's not a bad idea and I'll add it to my list of things to think about.

Adam Bien: GlassFish is now "just" a Reference Implementation. Moving GlassFish to GitHub, BitBucket or similar could make GlassFish more interesting to the community. Any thoughts on modernizing the build and SCM environment?

John Clingan: I wouldn't characterize GlassFish as "just" a Reference Implementation (RI). RI's are not required to deliver the kind of features that GlassFish delivers, like saving session state on redeploy, feature rich CLI and Web Console, and so on. This are features that improve overall ease-of-use as well as make the product more manageable when deployed in production. However, GlassFish is undoubtedly now more developer focused than production focused from a historical perspective. Pushing the code externally causes quite a few problems for us. The amount of build and test infrastructure that we have built over the years is pretty impressive, and they all rely on our existing repository. Switching to an external repository would be a substantial effort. I do not see this happening in the near term, although this we can always consider this down the road.

Adam Bien: Any updates on GlassFish' future? When we can expect GlassFish 5.0?

John Clingan: We are working on a 2014 GlassFish 4.0.1 release right now which will include a large number of bug fixes and Java 8 support. We'll push out the details shortly. Look for an email to the GlassFish User's mailing list and post to The Aquarium blog. As for the next major release of GlassFish, we are currently planning that to align with Java EE 8 as the Reference Implementation. We haven't gone into detailed product planning for the release since we just finished requirements gathering for Java EE 8 and are looking at submitting new and updated JSRs. There will be Java EE 8 coverage at JavaOne 2014, so that will be a good time to see what features the next major GlassFish release will include. See also: GlassFish 4.0.1 Update blog post

Adam Bien: A common complain are the infrequent GlassFish releases. What are the reasons behind the infrequent releases? Do you plan to involve the community more in the release process?

John Clingan: Historically GlassFish delivered two releases a year. That was based more on pragmatic need than an official release cadence. As mentioned, we are planning a GlassFish 4.0.1 bug fix release for this year, so this is roughly a year after GlassFish 4.0. That being said, developers can always download the nightly builds to get the latest bug fixes. After GlassFish 4.0 we actually modified the nightly build process to run a more complete set of tests, so the nightly builds are likely higher quality than nightly builds for prior releases.

Adam Bien: You are also involved with Avatar.js. What is Avatar? What is your favorite feature?

John Clingan: I am going to spend a bit more time on this answer because Avatar as an open source project may be new to a lot of your readers. Avatar offers server-side JavaScript and the Node programming model on the JVM. I guess my favorite feature is the opportunities opened up by the JVM itself. First, Nashorn offers JavaScript compatibility along with the ability to call into native Java code. Calling Java code means that I get multi-threaded features if I want them, even though JavaScript is traditionally single-threaded. At a recent JUG meeting I showed Nashorn Java/JavaScript interoperability (below) by using Java 8 parallel streams (multi-threading) [1] and passed JavaScript functions into Java functional interfaces [2][3] instead of Java lambda expressions. The contrived JavaScript example below uses Java 8 streams to filter [2] strings from a Java List that contain "foo", replaces "foo" with "bar" [3], and then collects the list of modified strings into a JavaScript array [4]:

var list = new java.util.ArrayList();
var Collectors = java.util.stream.Collectors;

// Insert code here to read a large text file into the list

var results = 
   list.parallelStream()                          // [1]
      .filter(function(t) t.match("foo"))         // [2]
      .map(function(t) t.replace("foo", "bar"))   // [3]
      .collect(Collectors.toList();               // [4]

Project Avatar offers the Node programming model on top of Nashorn. Taking our threading use case a step further, Node applications use libraries that spawn processes as one means of scaling, and scalable Avatar applications spawn more efficient Java threads to scale. On top of that, Avatar has state management and message bus APIs where threads can pass messages between each other in a concurrency-safe manner, so we maintain the Node programming model.

Moving past threading, because Avatar runs on the JVM and Nashorn, JavaScript can call into EclipseLink for object to relational mapping (JPA) and leverage mature JDBC drivers across multiple databases, all hidden behind a JavaScript framework we are developing. Last but not least, with Avatar and JavaScript on the JVM, developers can develop Node applications that call into existing Java libraries that have been developed within their organization or in open source.

Adam Bien: Is Avatar related to GlassFish?

John Clingan: They are separate projects although we do have GlassFish builds that bundle Avatar so that developers can leverage Java EE features out of the box like JPA, JMS (client), and there are some additional opportunities for Java EE interoperability down the road.

John, thank you for the interview!

See also: GlassFish 4.0.1 Update