JavaOne 2010: Choosing the Right NoSQL Database

Tobias Ivarsson presented "Choosing the Right NoSQL Database" at JavaOne 2010.  He works at Neo Technology, who provides the Neo4j graph database. He stated that his approach to this presentation would be to look at various hypothetical problems with storage requirements and determine which approach works best for that particular set of storage requirements.  He stated that his examples would focus on implementations of Graph Databases (Neo4j specifically), Document Databases (MongoDB specifically), and Column Family Databases (Apache Cassandra specifically)

Neo4j is a JVM-based graph database, storing nodes and the relationships between nodes. There are numerous graph databases out there. Other graph databases listed in the presentation: Sones GraphDB, InfiniteGraph, AllegroGraph, Hypergraph, InfoGrid, DEX, VertexDB, and FlockDB.

Document Databases store their data as structured documents and collections of documents.  They tend to store JSON-based documents in their databases.  Examples of document databases include MongoDB, Riak, Apache CouchDB, and SimpleDB (Amazon internal).  The speaker commented that Lucene is structured like a document database.

The ColumnFamily databases are inspired by Google's internally-used BigTable. Other examples include Cassandra, HBase (Hadoop's database), and Hypertable.  Cassandra is the implementation used in this presentation for demonstration purposes.

The first hypothetical example used was that of a blog system. The blog system would need to support arbitrary number of posts and comments as well as ability to query and filter blog posts by data and possibly by tag.  The speaker led us through design decisions to store posts as documents and to store comments as nested documents within the post documents. A Document Database seemed obvious at this point, so he showed some code for creating a blog post using MongoDB. This code example demonstrated using MongoDB classes Mongo, DB, DBCollection, DBObject, and BasicDBObject. Ivarsson also showed code necessary to retrieve blog posts from the MongoDB. The MongoDB APIs seem straightforward to apply, but the obvious drawback is its lack of standardization - it is very MongoDB specific.

The second hypothetical example was a Twitter clone. In this case, each post is very small, but needs to be visible to all followers. There is a high load, especially for the high write load. The application should also retrieve all posts by a specific user ordered by date as well as all followers by date.  Cassandra is designed for handling large load of writes and is a good fit here. It makes it even easier for this presentation's demonstration to use the Cassandra-provided Twissandra.

Ivarsson called it "amazing" that Cassandra scales linearly for writes, but pointed out that as with any tactics for performance gain, there are trade-offs. In this case, developers take on more responsibility for maintaining data consistency.

The first example of a blog post was large documents with less traffic and the Twitter clone example covered smaller documents with high traffic.  The third example in Ivarsson's request for "world domination" is to build a social network like Facebook.  For this example application, a graph database will be used.

Individual people are represented by Nodes in the graph database for the social networking application.  Groups are also represented by Nodes and friendship is represented by Relationships. A slide showed "a small social graph example" based on The Matrix movie characters (I insist that there was only one Matrix movie!) and their relationships with one another and with their ship.

The social networking example was implemented with Neo4j and its API looked similarly easy to use, but again is proprietary/non-standard.


Ivarsson summarized the lessons gleaned from his presentation of the different example applications implemented with different types of NoSQL databases.  He stated that Document Databases are often best when dealing with collections of similar entities (but the entities do not need to be perfectly alike). He stated that ColumnFamily Databases are best when scalability (particularly write scalability) is the main issue. The cost is that developers must write more complicated code to do somethings explicitly. Graph Databases are often best when deep traversals are important or for complex domains or in cases where "how entities are related" is very important.


One of the things that I was impressed with in Ivarsson's presentation was his willingness to cover multiple types of NoSQL databases and even talk briefly about Graph Databases other than Neo4j.  I was further impressed when he had a slide talking about when NoSQL may not be the most appropriate.


Ivarsson stated that RDBMS is better at some things, particularly reporting. There is a large ecosystem of reporting tools built around RDBMS. Working system with RDBMS should also be left alone.  However, he added this important bullet: "But please don't use a Relational database for persisting objects." He also asserted verbally: "Object-relational mappers are the worst abomination I have seen in years."

I liked Ivarsson's use of the term "Polygot Persistence." He recommended what should be the obvious: use right tool for each job. He then asked, "Why limit self to one database? He suggested, as examples, possible combinations of  RDBMS for structured data with Graph database for storing relationships between entries or using Graph database for domain model with Document Database for large data chunks. I do think it's best to be able to use the correct persistence approach for the job or even use more than one together when the costs of multiple approaches are justified by the benefits.

I definitely got what I wanted out of this presentation: an overview of the NoSQL landscape with some ideas on what's available and how to select the best tool for the job.

JavaOne 2010: Code Generation on the JVM

My earliest start of JavaOne 2010 so far was on Tuesday morning to attend Hamlet D'Arcy's "Code Generation on the JVM" presentation. Several attendees arrived late, indicating the early hour was a surprise for a few. One of Hamlet's colleagues (Andres Almiray I believe) presented in his place.  He started by saying that Groovy would be used during the presentation (one of the reasons I wanted to attend!) and asked if anyone didn't know what Groovy is.  No one in this relatively full room raised their hand.

The speaker listed some longer term examples of code generation: CORBA stub generation, bean generation, and WSDL artifacts generation.  He mentioned modern code generation tools such as Groovy, Project Lombok, Boo (.NET), Spring Roo, and LISP.

The first code generation product covered in detail was Project Lombok.  This library has been featured by the Java Posse and is used to reduce JavaBean boilerplate code.  Lombok can be used with Eclipse IDE, but can also be used in conjunction with command-line javac.  Lombok works with the javac compiler to modify byte code.  The speaker demonstrated the generated JavaBean boilerplate methods (such as "get" and "set" methods) using javap -p (-p to show private fields).

The speaker moved from Project Lombok to Groovy.  He showed how little code is needed to create a basic class in Groovy.  He showed the equivalent Java code.  He then moved onto even more advanced examples, demonstrating Groovy's AST Transformation-based @Delegate annotation, @Lazy annotation (lazy initalization), @Immutable annotation (immutable objects), @Newify (new object without new keyword), @Category (new methods at runtime), @PackageScope (use of protected modifier for Groovy), @Grab (specify dependencies' locations).  "One of Hamlet's babies" (@Log) should be available with Groovy 1.8. Other Groovy 1.8 AST Transformation annotations include @Synchronized.

The gcontract project works in Groovy and supports design by contract and uses annotations to specify expected conditions and results.  An attendee asked what the difference between this approach and asserts is.  The speaker responded that this does use asserts, but I must admit that I think the annotations are more readable and less invasive than using the assertions directly in the code.  I prefer to have the annotations regarding method entry and exit contract outside of (before) the actual method itself.  The speaker stated that this uses Groovy's 1.7 Power Asserts. Interestingly, this same power assert concept was discussed by Mark Reinhold in conjunction with traditional Java's future in Reinhold's presentation JDK 7 and Java SE 7.

CodeNarc was described as a type of FindBugs for Groovy.  The Groovy-based testing and specification framework Spock was introduced. A slide appropriately titled "Java Perversions" demonstrated using Spock to create a Groovy method with a name that includes spaces (a similar example is on the main Spock page).  Because it's Groovy, it can be used to analyze/test Groovy and Java applications. Spock assumes assert statements.  All of this is possible thanks to Groovy's AST Transformations.

The speaker recommended that AST Transformation not be written by hand. He also differentiated between Local AST Transformations (require annotation to tell compiler) and Global AST Transformations (apply to all). He demonstrated the "Groovy AST Browser" that is part of the Groovy Console. [Note: There is also a web version of AST Browser.]

The ANTLR parser generator was discussed and its use in Groovy was described.  See D'Arcy's Groovy ANTLR Plugins for Better DSLs for details.

The original author of the slides and the speaker who delivered the slides both inserted humor into this presentation. For example, I liked the speaker's great quote, "I hope you're not afraid of simple text editors like vi, the only powerful text editor you need."  I do like my IDEs, but I also find myself in vim or derivative quite often for certain tasks.  I also appreciated the visual reference to the classic Atari 2600 Pitfall game when describing Groovy AST Transformation pitfalls.  That was a nice piece of nostalgia for me that served as a great memory device for the subject at hand. I couldn't help but wonder, however, how many of the attendees are too young to be aware of that game.

This was an excellent presentation.  If he had not told us, it would have been difficult to realize that the speaker wasn't the presentation's author. This is an advantage of having an experienced speaker as a substitute. The mix of strong content, humor, stories, and cultural photographs made it an engaging and informative experience. This presentation was recorded, so it is likely that it will be available in the near future for viewing.

JavaOne 2010 Opening Keynote

I know that I'm completely biased, but I thought that tonight's JavaOne Opening Keynote was significantly more interesting than last night's Oracle OpenWorld Opening Keynote.  The first real day of JavaOne 2010 was great and this was a nice keynote to cap it off.

Oracle Executive Vice President of Product Development Thomas Kurian had several guests cover demonstrations displaying Oracle's vision for Java in the enterprise, on mobile devices, on the web browser, and on the desktop.  Sun always seemed to announce grandiose visions at JavaOne and some (like Enterprise Java) seemed to work out better than others.  I'm hoping that Oracle is able to deliver on even a significant percentage of their announced plans.  If they are able to do so, Java will have a very bright future.

The JRockit Flight Recorder demonstration showcased JMX (MBean) as part of its analysis capability. It was stated (and I agree) that the intermittent problems make for an even more useful use case for this tool than static problems. The tool will also be available for HotSpot as part of the effort to converge the two Oracle JVMs. It is available for preview in the Demo booth.

Kurian stated that Oracle is committed to delivering Java 7 in 2011 and Java 8 in 2012. He also said that Oracle is committed to delivering the best JVM and to delivering OpenJDK.  This essentially reiterates what we heard from Mark Reinhold in this morning's JDK 7 and Java SE 7 presentation.

Related to his slide on "Design Objectives," Kurian said it is time for Java developers to have the toolkit to build the best user interfaces for various platforms. He described the envisioned Java programming model that combines the "power of Java" with the "ease of JavaFX." This programming model will include native interoperability between Java, JavaScript, and HTML5. The plan, as shown in the "Java: Client Architecture" slide, is to provide a single programming model. Oracle envisions common programming model across browser and native applications.

The "ease of JavaFX" is planned to be provided via JavaFX controls and APIs. Kurian said that these controls will be available in open source. The runtime components "do the heavy lifting." Anyone familiar with Java should be able to use this model. There will be Java programmatic access to HTML 5 tags from within Java code. The plan is to also make it possible to manipulate Java Scenegraph from JavaScript.

The "high-performance graphics engine" called Prism (and used with JavaFX and discussed at last year's JavaOne) will be made available. It renders 2D objects today, but will eventually support 3D objects. It will support new hardware Accelerated 2D and 3D Graphics Pipeline. This will be made available in open source via NetBeans.

It was stated that the demonstrations shown this evening will be able to be written in standard Java with standard Java APIs without needing to learn new scripting language (I read "without JavaFX Script necessarily" here and others call it dead already), but will be available for invocation from any language on the JVM (Groovy, JRuby, Scala).  My read of this is that one of the biggest complaints about JavaFX might be addressed now: true integration between Java (specifically Swing) with JavaFX APIs. All demonstrations shown tonight used vector graphics and media and without use of images.  They were impressive and my only complaint was that they used the movie Scott Pilgrim versus the World; I'd rather have seen Ironman 2 clips.

The graphics/media demonstration also included describing how consecutive application of simple effects makes impressive shapes and colors. The demonstrated steaming coffee cup based on Bessian curves was impressive as well. The air hockey game does not use a static image and it was commented that SceneGraph makes it easy to attach nodes to native multitouch events via JNI.

The 3D and Media demonstrations included 160 individual screens on a Media Wall. Accessing metadata for each screen was also demonstrated. HotSpot JVM and Accelerated Hardware Pipeline make this performant. The Java client team plans to deliver this "in feature and function" next year. Tooling will be delivered via NetBeans (which has seen a twenty percent increase in NetBeans in last six months) in two releases in 2011. All JavaFX UI controls and components will be available to developers in open source this coming year. The detailed feature roadmap is available at netbeans.org/community/releases/roadmap.html. Kurian stated (roughly paraphased): We want the 9 million Java developers worldwide to never again have to choose a non-Java framework to deliver impressive user interfaces.

Oracle plans to make application servers more modular through dependency injection. The newly provided lightweight web profile for web applications allows developers to not need to use EJBs. POJO programming is now much easier for Java developers. Will focus even on EE level with scripting interaction.  The Enterprise Java roadmap is available at glassfish.dev.java.net/roadmap and there are two planned releases of GlassFish for 2011.

After talking about deskptop and enterprise, Kurian discussed plans for Java Mobile.  He stated that it is Oracle's goal to deliver Java applications to ALL mobile devices going forward. Plan to modernize Java to work better on mobile devices and to integrate web technologies in mobile devices. Their goal includes delivery of new device APIs to access features of hardware and operating system.

The demonstration for the mobile devices/web was Star Wars the Old Republic (Star Wars + Bioware). Bioware uses GlassFish and Oracle Coherence to support online gaming. Java is used in many other aspects of their online games as well. They combine social networking features with role playing games features. All of the revenue-generating aspects are Java-supported.

I'm again roughly paraphrasing, but Kurian stated something along these lines: We're really excited about Java and we're committed to giving you the world's best programming language, the world's most popular deployment platform, and the ability to deploy amazing clients in Java regardless of target platform.  He ended his keynote with this quote, "The future of Java is not about Oracle or any one company. It is about you, the Java developers who create great applications with it."

Overall, I think this keynote provided hope for Java developers regarding the future of Java.  The real question is to what degree Oracle can deliver on these grand visions.  However, it is refreshing to see great plans for all aspects of the Java world and it definitely feels that Oracle has made commitments tonight to Java and to the Java community.

I enjoyed the entire presentation, felt like I got a large percentage of what I wanted from it, and particularly enjoyed the greater decisiveness and clarity on a vision for the future of Java client technologies.  In my opinion, Oracle's plans for client side Java (or at least my interpretation of those plans) are right on the money.   I never thought it a good idea to force Java developers to learn an entirely new language when Java and other JVM languages were already available.  By providing standard Java APIs, Java developers and developers who prefer alternate JVM languages (and many of us fall in both categories) can apply the APIs more easily.  The common ground and common approach has to benefit adoption.

I really enjoyed my first day of JavaOne 2010 alternating back and forth between the Hilton and Parc 55 (back and forth for all five sessions) and then attending a keynote that was a pleasant surprise.  I had worried about the timing getting between JavaOne hotels, but it has turned out that I have enjoyed the opportunity to go outside to go between sessions.  Today has been a great first day of JavaOne 2010.

JavaOne 2010: Java Persistence API (JPA) 2.0 with EclipseLink

EclipseLink Project co-lead Doug Clarke presented the session "Java Persistence API (JPA) 2.0 with EclipseLink" presentation today at JavaOne 2010. I am a big fan of JPA, but I'm not going to be able to get to all of the JPA-related presentations due to competing sessions and I wanted to get a wide breadth of topics covered at this year's JavaOne. Clarke started his presentation by saying that he works on the reference implementation of JPA 2.0 (EclipseLink) and that this session will talk about some things EclipseLink provides outside of the specification.

The thing EclipseLink is known most for is its object-relational support, but Clarke pointed out that EclipseLink also supports Java/XML binding with JAXB and MOXy, Service Data Objects, and database web services (scrape data out of database and generate JAX-WS web service for web deployment).  Clarke described the various ways to access Eclipse Link (direct download, with GlassFish, and with Spring Framework were just some of the examples).

Clarke had a slide called "Understanding JPA" in which he showed the three pieces of JPA he commonly thinks of with "caching" joining them together.  He said they spend much of their time working on the caching.

Clarke said that he used annotations in the slides because they make it easier to see the obvious fields being mapped.  However, he also stated that significantly improved tooling has led many of his customers to return configuration back to XML.



Clarke introduced basics of JPA and then briefly introduced new features of JPA 2.0. He quickly moved onto EclipseLink custom annotations and other functionality beyond standard JPA. The idea, according to Clarke, is to allow people using these EclipseLink extensions to remain generally in the JPA space and they provide a eclipselink-orm.xml file for EclipseLink-specific configuration.


One extension EclipseLink provides is dynamic persistence that involves no Java classes, but instead relies solely on XML.  Clarke says that Oracle has used this with the Oracle ESB because they have no way of knowing in that context what object will need to be saved.


In talking about JPA mapping, Clarke reminded the audience that JPA uses the "configuration by exception" approach to mapping Java objects to relational database tables. In his example of a JPA entity class, he demonstrated the @Convert and @Converter annotations that are specific to EclipseLink.  He also mentioned the @PrivateOwned annotation.

When he talked about JPA querying, Clarke recommended using JPA named queries pattern and keeping named queries all in one place.  The argument is that any changes to objects can all be reflected in one place rather than needing to be found when scattered among the code.

EclipseLink offers extensions to JPA for querying.  This includes ability to query for read-only entities to improve performance and stored procedure/function support (including PL/SQL).  EclipseLink also does have some specific extensions to JPQL: FUNC for direct database function, TREAT AS downcasts child classes in inheritance hierarchy, and query keys can be defined.  EclipseLink extensions are also available to improve performance via explicit optimizations. EclipseLink provides query hints (an advertised "extension point" in the JPA specification) with the QueryHints class including QueryHints.FETCH (attribute joining) and QueryHints.BATCH.  Clarke showed different slides that demonstrated how to take advantage of these query hints to reduce 3N+1 (301) queries to 1, 2, or 4 queries for his 100 purchase order example.

Clarke introduced "partial entities with attribute groups" as a new feature in JPA 2.1. Attribute Grouping allows the developer to define what happens to each field in an object and not just relationships.  JPA has had FetchGroups for a while, but they are enhanced with JPA 2.1.  EclipseLink offers "two level loading": everything you specify in the FetchGroup and anything else needed later in that same thread.

EclipseLink simplifies stored procedure usage with @NamedStorageProcedureQuery and @NamedStoredProcedureQueries annotations. The only place this EclipseLink-specific knowledge is captured is in the configuration.

JPA 2.0 adds the Cache interface to have some control over shared cache. The interface allows the JPA community to start working with the vendor-specific caching mechanisms that cannot be brought together yet. The @Cacheable annotation can be used to set shared-cache-mode property (ALL, NONE, ENABLE_SELECTIVE, DISABLE_SELECTIVE, ).  EclipseLink has a default of cache set on.  EclipseLink has two-layer caching approach in which EntityManager has a transaction cache and the EntityManagerFactory has a shared cache.  EclipseLink's own @Cache annotation is used on a class level and configures shared cache handling of that entity; this does override the standard JPA caching setting.  @Cache allows cache type based on Java reference types: FULL, WEAK, SOFT/HARD WEAK, and NONE.  Can also specify cache size and expiration and disable shared caching with the @Cache annotation.

Clarke briefly mentioned EclipseLink's weaving. He introduced the @ChangeTracking annotation and its possible range of values.  Several EclipseLink interfaces allow for finer grain control of how sessions are serialized and cached.

Clarke began wrapping up his session with a slide titled "Performance Tuning Summary."

I am generally mostly interested in sticking to a specification's standard approaches as much as possible because that is, after all, one of the big reasons for using a specification-based product.  That being stated, there are times when for performance or other reasons, deviations must be used.  JPA has been designed to allow for extensions with reduced effect on the standard parts and EclipseLink's design seems to have kept this approach in mind as well.  Clarke's presentation was definitely focused on what EclipseLink provides as extensions to JPA (as he said it would at the beginning), but he also covered JPA basics and new features well in an effort to explain the EclipseLink extensions.

JavaOne 2010: Unit Testing That's Not So Bad: Small Things That Make a Big Difference

I knew that the JavaOne 2010 presentation "Unit Testing That's Not That Bad: Small Things That Make a Big Difference" would be popular and so I signed up for it early and made sure I got there in the time period in which early access seating applied.  We were told that there was a line of at least seventy people waiting to get in when there appeared to be only about 15-20 seats left so I was glad that I had signed up early.

Neal Ford began the presentation by calling his own presentation the "worst named presentation at JavaOne." He went on to say that he wanted to call this updated version of his 2009 JavaOne presentation on unit tests the same name he used last year: Unit Testing That Sucks Less: Small Things Make a Big Difference.  The name was changed on him when it was placed in the schedule information.

Ford talked about how Hamcrest makes it easier to write fluent unit tests.  He also discussed Infinitest and stated that it attempts to provide near instantaneous feedback in the IDE for unit test semantics that the IDE provides for compile time checking.  Infinitest is available as a plug-in for both Eclipse and IntelliJ, but apparently not for NetBeans or JDeveloper.  The main page for Infinitest refers to this tool as "a continuous test runner for Java."

Ford introduced Unitils and called it a "Swiss army chainsaw."  He discussed its support for various popular Java frameworks. The Unitils Summary page has a similar description: "Unitils provides general assertion utilities, support for database testing, support for testing with mock objects and offers integration with Spring, Hibernate and the Java Persistence API (JPA)."  Ford talked about Unitils's reflection assertions and lenient assertions.

Ford also discussed dbUnit support for database testing with Unitils and managing data state appropriately during the tests. I agree with Ford's assertion that using a database in a unit test can be easy to start with, but scales linearly as tests get more involved.  This approach simplifies things, but there are still performance issues with getting and releasing connections that could slow tests down significantly.

Ford covered Unitils's mocking support. He stated that it's not necessarily better or worse than other Java mocking libraries, but might be of special interest to those using Unitils for other things anyway.

In introducing JTestR, Ford stated that one of the biggest points he is making in this presentation is that in 2010 a Java developer does not need to write Java tests in Java.  He specifically mentioned using JRuby and Groovy for the unit tests. Ford stated (and I agree) that Groovy is the best suited of the two languages for Java integration. However, Ford said that the best testing tools and frameworks "on Earth" are in the Ruby community and JRuby would give access to those Ruby-based testing frameworks.  As Java + Ruby, JRuby is the obvious choice if one is testing Java code with Ruby tools.

JtestR is specifically designed for testing of Java code with Ruby-based test tools.  The main JtestR page describes JtestR this way:

JtestR is a tool that will make it easier to test Java code with state of the art Ruby tools. The main project is a collection of Ruby libraries bundled together with JRuby integration so that running tests is totally painless to set up. The project also includes a background server so that the startup cost of JRuby can be avoided. Examples of Ruby libraries included are RSpec, dust,Test/Unit, mocha and ActiveSupport.

RSpec is a behavior driven development framework modeled after JBehave.

As part of his discussion of behavior driven development, Ford talked about Ruby-based Cucumber. He talked of Cucumber reaching a level of community popularity such that other projects are being built around it.

Ford broached the subject of testing private methods. He stated that people who argue that you only test the public methods that call private methods are assuming that you don't use test-driven development. A work-around is to make all methods public or package scope, but that has its own undesirable aspects. Another approach is to use reflection.  Ford covered some of the disadvantages of using reflection in this way (significant checked exception handling and other issues that occur when you "touch Java in a sensitive place").  He used this as the segue into how Groovy makes this approach easier.

Ford pointed out that Groovy essentially turns all exceptions into runtime/unchecked exceptions.  This makes for friendlier unit test code that uses reflection.  Ford pointed out that Groovy's dirty little secret is that it ignores private and so you can access the private parts directly and avoid the reflection complexity.  Ford states that this is "technically a bug" that "they've been in no hurry to fix because it's insanely useful."

Ford showed a slide with jmock syntax and said, "This really sucks."  He then showed another slide with Groovy's Java-like syntax and its support of name/value hash pairs to make it easier to mock via hash and closure code blocks.

Ford ended with some "relatively bold statements."  He called it "professionally irresponsible to ignore software testing." He stated that it is "our [software engineering] professional rigor." He also stated that it is professional irresponsible to use the most cumbersome testing tools.  He finished with the quip and slide that writing software without unit testing is like trying to barbecue and swim at the same time.

I quoted Ford directly several times because he is good at keeping his audience engaged.  This is more challenging with a large audience like this one, but he pulled it off with humor.  I also appreciated the bold statements.  Even if there may have been a little hyperbole, such enthusiasm and quotable assertions generally make for a more memorable presentation.  There weren't many people who left this session early.

JavaOne 2010: Advanced Java API for RESTful Web Services (JAX-RS)

The JavaOne 2010 presentation "Advanced Java API for RESTful Web Services (JAX-RS)" was advertised as "Full" and that turned out to be the case.  Some attendees arrived as late as ten to fifteen minutes after the start, which was obviously not a good idea for such a popular session.  It was standing-room-only for this presentation. Paul Sandoz and Roberto Chinnici alternated in presenting.  I'll refer to them interchangeably here as "they" to avoid the likely mixing up of their names.

JAX-RS is the next release in the JSR-311 specification.  JAX-RS 1.1 is part of Java EE 6, but is not (seemingly inexplicably) part of the Web profile.  The main purpose of JAX-RS 1.1 is to integrate with other Java EE 6 technologies.  They listed seven implementations of JAX-RS: Jersey (reference implementation), Apache CXF, Apache Wink, eXo, RESTEasy, Restlet, Triaxrs.

After a brief "bootstrap" review of JAX-RS, they went into runtime resource resolution.

A section of this presentation was devoted to integration with CDI (JSR 299). When using EJBs with CDI, the general rule is to "annotate with @Path to convert class of a managed component into a root resource."  The presenters also had a bullet emphasizing that "Root resource classes need to be annotated with CDI scope to become CDI managed." This step is necessary due to slightly different models between CDI and JAX-RS. They demonstrated the steps necessary to convert to a CDI resource, including use of the @Inject annotation.  Normal JAX-RS classes may not work properly with CDI; need to use the steps they outlined instead.

Another topic covered in this presentation was runtime content negotiation.  A convenient approach for this in JAX-RS uses the Variant builder class.

One of the sections of this presentation that I found most interesting was that which covered handling of generic type erasure.  The speakers and their slides apologized many times for JAX-RS's and Java's erasure of generic parameterized types.  They showed that type is retained when returned in collection directly, but is lost inside a Response object. The work-around is to use GenericEntity with a method-less implementation. There is talk of JAX-RS 2 providing a JResponse, but will still need to use verbose syntax like JResponse.<List<bean>>. This is probably the best that can be done until we have Java runtime generics reification.

The presenters discussed one of my favorite things about JAX-RS: its elegant handling of exception mapping. They demonstrated that, without mapping, the web container provides a 500 HTTP status code for runtime exceptions. They pointed out that a web application's error page can be used to handle these. Checked exceptions also propagate through, but are wrapped in ServletExcepton. They showed how the exceptions can be mapped to specific HTTP status codes and associated descriptive text instead of the normal Java stack trace.

Before ending this post, I have some general observations. I was not surprised to see the speakers use Curl as a command-line demonstrator in some of their JAX-RS demonstrations.  I was also not surprised that this was a popular session with a waiting line and was almost completely filled to capacity.  The presentation included a lot of code and demonstrations.  Although I had read about and even used several of the covered topics, it was nice to see them all presented again in an organized fashion and to hear from people who live this stuff.  I was especially happy to see that someone else was as bothered by lack of Java runtime generic reification as I am.

JavaOne 2010: Groovy to Infinity and Beyond

The second JavaOne 2010 session that I attended was in Parc 55.  Fellow SpringSource employee Jeff Brown presented in place of Guillaume Laforge, who was not feeling well.  Brown stated that he works on Grails and thus works quite a bit with Groovy. The session was in a smaller room, but it was pretty close to full capacity and the majority of attendees raised their hands when Brown asked who was already using Groovy for development.

Brown began Laforge's presentation by introducing features that were new with Groovy 1.6.  These include multiple assignment, return being optional in more cases (this has never been particularly useful to me, especially because its not always optional), compile-time changeable code via AST (Abstract Syntax Tree) Transformations (performance benefits because at compile time rather than runtime), Grape, metaprogramming additions (ExpandoMetaClass DSL and runtime mixins).

Brown introduced the section of his presentation on Groovy 1.7 by stating that Groovy 1.7.5 was released just a few days ago.  Groovy now supports anonymous inner classes with same syntax as used in Java.  This can be an issue for Groovy code written with constructors that accept a closure because that mechanism is now used for the Groovy anonymous inner class support.  The anonymous inner class support was added to allow for greater copy-and-paste capabilities from Java to Groovy, but Brown does not recommend that approach (copying and pasting from Java into Groovy) in general.  You can also coerce a closure into an instance of a specified interface. Groovy's support for nested classes now looks like Java's syntax for nested classes.

Unlike Java, Groovy allows a developer to annotate an import statement or a package statement. This can be useful for indicating dependencies and where to acquire dependencies. The @Grab annotation allows specification of dependency details (especially useful with Grape).

Groovy's "power asserts" provide more information when an assert statement fails. The AST Viewer is another useful tool in the Groovy development cycle that was introduced recently.

Brown also cited Groovy's significant JDBC enhancements that include explicit support for batch SQL.  He also demonstrated how a developer can now override "Groovy truth" for his or her object simply by implementing the asBoolean() method on that class.

Brown stated that most of the Groovy 1.8 features he is starting to talk about are already on the 1.8 development branch.  He covered features coming in Groovy 1.8 such as closure composition, improved DSL support (fewer parentheses and commas), etc.

Brown reiterated how easy it is for Java developers to learn and start using Groovy.  This has been my own experience and my experience observing fellow Java developers first exposed to Groovy and watching how quickly they pick up Groovy.  Brown also stated in his summary that Groovy is more than a language; "it's a very rich and active ecosystem" (Grails [web], Griffon [desktop/Swing], Gradle [build system], GPars [concurrency], Spock [testing], Gaelyk [Google App Engine]).

One of the questions asked during the question and answer period was regarding Groovy performance.  Brown explained that Groovy has to do significantly more than Java does for method dispatch to support all the dynamic features in Groovy that are so popular.  However, he also stated that he and others at SpringSource had worked with customers developing significant applications based on Groovy and Grails and had not seen any significant performance problems in those applications.

I think Jeff Brown did a good job of covering for Laforge and wasn't disappointed that I attended this session.