Wednesday Sep 22, 2010

JavaOne presentatons available

Advanced Java API for RESTful Web Services (JAX-RS) and examples

Building Powerful WebSocket, Comet, and RESTful Applications Using Atmosphere

What's Next for Java API for RESTful Web Services (JAX-RS)

Thanks to all the those who attended the presentations.

I also moderated the ScriptBowl session, standing in for Rags at the last minute, with Clojure, JRuby, Scala and Groovy represented by Rich Hickey, Nick Sieger, Dick Wall and Graeme Rocher respectively. Roberto Chinnici was the judge. Congratulations to Groovy that won, by the loudest clapometry reading from the audience, with Scala a close second. JRuby was at a slight disadvantage since the ScriptBowl clashed with a JRuby session but i hope the EngineYard developers got lots of attendance at their JRuby event last night.

For me though Scala was the winner with Clojure a close second. The REPL support in the Scala console is getting really good and gives the feel of a dynamic language, and the tooling is also getting good taking advantage of the static typing features of Scala. Scala and Clojure are i think the only languages that are really attempting to correctly tackle immutability and state change. Clojure is disruptive and i expect some of it's innovations to feed through into other languages, as is already the case with Scala, efficient persistent collections, and the Scala-based Akka framework.

Wednesday Jun 30, 2010

JavaOne session schedule

All done in the first half of the week (unless a repeat is requested), i like that :-)

D#: S313265
Title: Advanced Java API for RESTful Web Services (JAX-RS)
Track: Enterprise Service Architectures and the Cloud
Date: 20-SEP-10
Time: 13:00 - 14:00
Venue: Hilton San Francisco
Room: Golden Gate 6/7

ID#: S313035
Title: Building Powerful WebSocket, Comet, and RESTful Applications Using Atmosphere
Track: Java EE Web Profile and Platform Technologies
Date: 21-SEP-10
Time: 11:30 - 12:30
Venue: Hilton San Francisco
Room: Yosemite C

ID#: S313266
Title: What's Next for Java API for RESTful Web Services (JAX-RS)
Track: Enterprise Service Architectures and the Cloud
Date: 21-SEP-10
Time: 20:00 - 20:45
Venue: Hilton San Francisco
Room: Yosemite B 

Friday Aug 28, 2009

Guice 2.0 is almost there, but not quite

Guice 2.0 is a clean and well-thought-out framework for modularization and dependency injection. It is really good, but it could be really really good with a couple of tweaks.

James Strachan created GuiceyFruit in an effort to move Guice from "really good" to "really really good", or say from 95% there to 99% there. Some patches from GuiceFruit got accepted in Guice 2.0 but some are still pending so GuiceyFruit maintains a patched version of Guice 2.0 for it's own needs.

Jersey depends on GuiceyFruit and the patched Guice 2.0 for it's Guice support (although it is possible to use "native" Guice if you are not using any GuiceyFruit features).

Currently with Guice 2.0 i cannot integrate support for the binding of JAX-RS types and annotations. I would like to be able to do the the following with Guice/Jersey/JAX-RS:

public class MyResource {
  private final String q;

  public class MyResource(@DefaultValue("foo") @QueryParam("q") String q) {
    this.q = q;


But, currently as far as i am aware, it is not possible for two reasons:

  1. a provider binding does not have any context to what it is providing to; and
  2. an annotation that is not meta-annotated with @BindingAnnotation cannot be utilized as a binding annotation.

A good example of the complexity that results due to lack of support for 1) is presented in the section on Custom Injections of the Guice User's Guide. This section presents an example of how to support injection of a org.apache,log4j.Logger instance with fields annotated with the custom annotation @InjectLogger. The logger instance is initiated with the declaring class of the field.

The developer is required to implement a TypeListener that iterates through the fields of the class to find an appropriate field to inject a Logger, and a MembersInjector that injects the instance of the Logger onto the appropriate field.

While these interfaces are useful they are over-complex for such a use-case and the developer cannot use @Inject with Logger for constructor, method and field injection.

The injection of Logger can be reduced to a provider method of a module if Guice could support the injection of InjectionPoint:

 public Logger providerLogger(InjectionPoint ip) {
   return Logger.getLogger(ip.getMember().getDeclaringClass());

With respect to the JAX-RS example a provider of the String type annotated with @QueryParam requires access to the annotations declared on the constructor parameter and the annotations declared on the defining class (it does not appear possible to get access to the former with InjectionPoint so that would require some tweaks as well).

Moving on to reason 2). If Guice supported the following binding in a module:


then it would be possible for Jersey to supply a Jersey-specific Guice module that supported all the Jersey and JAX-RS annotations in addition to enabling developers to easily add their own providers for such annotations.

If Guice could do that it would be 99% there IMHO and would be a really really good dependency injection framework.

Thursday Jul 16, 2009

The course of true love never did run smooth

Thursday Jun 04, 2009

JavaOne slides for JAX-RS and Jersey

Here are the slides for the JAX-RS technical session Marc and I presented on Wednesday.

Here are the slides for the Jersey BOF @ 7.30pm on Thursday.

Wednesday Apr 01, 2009

JavaOne and CommunityOne sessions and BOFs

Where will YOU be June 2?

Thankfully JavaOne 2009 is a little later this year, 2nd to 5th of June. Which gives my co-speakers and I more time to prepare (or at least more time to leave things until something needs to be done!).

Three talks have been accepted:

  • Technical session TS-4875.
    Developing RESTful Web Services with the Java™ API for RESTful Web Services (JAX-RS). Marc Hadley, Paul Sandoz.
  • BOF-4878.
    Developing RESTful Web Services with Jersey and Java™ API for RESTful Web Services (JAX-RS). Craig McClanahan, Jakub Podlesak, Paul Sandoz.
  • BOF-5009.
    Atmosphere: Comet for Everyone, Everywhere. Jean-François Arcand, Paul Sandoz.

For BOF-4878 Craig will provide some interesting details on how Jersey is being utilized in Sun's Cloud offerings.

Atmosphere, although a young project, is already starting to get some good adoption. Atmosphere provides portable ease of use APIs to support Comet-style interactions. BOF-5009 will introduce Atmosphere and we will demonstrate using Atmosphere combined with Jersey.

If you plan to attend JavaOne and any of these sessions please contact me at Paul.Sandoz@Sun.Com and i can send you a special priority code you can utilize when registering.

For CommunityOne West one session has been accepted:

This session will be a combination of the JavaOne technical session TS-4875 and the BOF-4878.

Thursday Nov 06, 2008

Prelude for GlassFish in v3-sharp major with Jersey

The application-server market dances to a different tune from this day with the release GlassFish v3 Prelude.

An ensemble of technologies harmonize with the key signature of the GlassFish OSGi-based microkernel. You can get it here, or directly from here. Details of support and service can be found here.

Jersey 1.0, the production quality Reference Implementation of JAX-RS, is part of that ensemble and is available from the GlassFish Update Center. The developers guide gives more details including installation instructions via the Glassfish Update center.

Tuesday Oct 30, 2007

Annotated Scala, Groovy, JRuby, Rhino, Jython ...

Java runtime annotations are stored in Java bytecode using attributes, as specified by the Java virtual machine specification. So one can use toolkits like the ASM toolkit for creating and reading annotations in addition to using the Java reflection API for reading annotations.

Implementations of languages that compile to Java bytecode can also leverage runtime annotations and it can make for really smooth integration between classes/objects written in the language and frameworks, such as Jersey (JAX-RS), Metro (JAX-WS, JAXB), JUnit and Spring etc. written in Java, that process annotations.

So what's the support for runtime annotations like out there for some common JVM-based language implementations?


Scala has by far the most robust support for annotations. The annotation syntax is very similar to Java. JAX-RS and Jersey specify support for runtime annotations on classes, fields, methods and method parameters. I can annotate Scala classes using JAX-RS annotations and the Jersey runtime correctly processes the thoses classes (as shown here). In fact since the integration between Java and Scala is so smooth and Scala being such a pleasurable language to code in i could not resist including in the Jersey distribution an example written in Scala.


Groovy 1.1 supports runtime annotations and like Scala the syntax is very similar to Java. Originally i played around with Jersey and Groovy 1.1 Beta. This version supported annotations on classes, method and field but not on method parameters. Recently downloaded Groovy 1.1 RC 1 and this version supports annotations on method parameters. So i can annotate Groovy classes and support all the Jersey features as i can in Scala (Groovy 1.1 is not yet final where as Scala 2.6 is so Scala's support is considered more robust). Since Groovy requires no compile step i can script Jersey resources (more on this later in another blog).

JRuby (Ruby)

Now things start to get a little fuzzy. My understanding is Ruby does not currently support annotations but that it is very easy to do so because of Ruby's meta-programming capability, as shown here. Charles Nutter (one of the JRuby leads) says here:

"JRuby doesn't support annotations because Ruby doesn't support annotations. So what! We can extend Ruby..."

and further says "I've planted the seed here and on the JRuby dev list...let's see if it germinates.", but i don't know if that seed has taken root...

Rhino (JavaScript)

JavaScript is in a similar position to JRuby, annotations can be added to JavaScript using meta-programming techniques, as shown here.

Rhino has the ability to integrate with Java such that a JavaScript object can implement one or more Java-based interfaces or extend a Java class. However, it does not seem possible to implement a (plain old) JavaScript object and pass it over to the Java side as a (plain old) Java object. Intuitively this would seem possible given the existing support. It looks like the Rhino source code is still being worked on even though the last release (1.6R7) was over a year ago. That's good. So i took a look at the code, specifically the JavaAdaptor and ClassFileWriter classes.

Now i may not know what i am getting into here, i could be pulling on a thread connected to a really big hair ball, it appears "tricky but doable". Once that is done it is just a simple matter of mapping the annotations declared in the JavaScript to equivalent byte code... anyone up for a challenge?

Jython (Python)

Python has function decorators in Python 2.4, function annotations and class decorators implemented in the subversion repository of python 3.0 (or Python 3000, it says here that it will go final in August 2008). So perhaps Python 3000, when it is ready, would be the right place to start any Java-based annotation support.

The latest stable release of Jython is version 2.2.1 supporting Python 2.2. From the roadmap Jython 2.5 is next (no date given) and this release will target Python 2.5. It says the core developers will be:

"concentrating on making a clean 2.5, while improving the java integration"

So maybe something specific to Jython w.r.t. to annotation support could be implemented. Although the Jython roadmap looks on the right track i suspect the 2.5 release won't be happening any time soon and the 3.0 release is way over the horizon. However, the competition between language implementations is in rude health so perhaps things will zip along faster than I expect.

Tuesday May 15, 2007

JavaOne brain dump

Probably the best talk i attended was the BOF on Hudson presented by Kohsuke. It was an amusing history of creating a successful grassroots project, scavenging and building hardware, and encouraging others to join the project. IMHO such a talk would make a great technical session.

JavaFX (p.k.a F3) looks kind of interesting. It is very SVG like but has a nice language feature to avoid the spaghetti  that results from using the listener pattern. However, what does this mean for being on the Web? Web sites that are created in flash are essentially devoid of information that can be grokked by a search engine, or bookmarked, or annotated etc. A combination of HTML and SVG retains visible links while still giving a flash like-experience if required.

The talk on the Google checkout API was a bit disappointing. I was hoping for more detailed information on the protocol to see if it was a RESTful design or not (i guess i will 'check' it out in more detail) and how it was implemented for scalability. A member of the audience asked a poignant question about if/when Google will provide a feature so that checkout does not redirect to the Google site, because they loose customers as they do not go back to the original site. They will not and for good reason (think advertising revenue).

Mark Hapner's talk on "Wire"-Centric integration was interesting. It is worth listening very carefully to what Mark says as there is a lot of good advice compressed into his sentences. The focus of the talk was very much on the developer of a service being aware of the implications of what is going on the wire (which is rather different to our current programming models) and being aware that simplicity is important for a successful service to be consumed (in ways that the developer of the service may never expect). IMHO what goes on the wire is very important but even more important is how that which is on the wire is identified (which was only discussed in passing). If there is a uniform way of identifying what is on the wire, a uniform way of accessing what is on the wire, and an agreed convention for transitioning from states (correlations) then what do we have :-)

Jerome Dochez gave an interesting talk on the modular architecture of Glassfish V3. In combination with talk on comparing EE 5, Ruby on Rails and Grails by Tom Daly and Damien Cooke it made it clear to me that Glassfish V3 is well positioned to become a rock solid container for hosting Web applications, whatever the framework or language. With the likes of Ruby, Groovy and JavaScript languages running on the JVM it makes a lot of sense to reuse all that EE experience and infrastructure for managing and scaling to deploy JRuby on Rails, Grails, Phobos and EE applications.

I enjoyed Ludovic Champenois and Robert Chinnici's talk on Phobos. Phobos's sweet spot is being able to use Javascript on the service-side and client-side. The database demo was interesting and in debug mode was very dyanmic (Roberto mentioned in passing that it was possible to dynamically generate all the Javascript for the controllers and views without the developer even seeing it). I need investigate Phobos more closely. Maybe there is a nice integration point between the REST API and Phobos where a POJO matching an HTTP request is a controller and can be access as a bean by the view.

The talk i wanted to attend but never got around to? The one on DTrace by Adam Leventhal. Oh well... maybe next year. 

Monday May 15, 2006

XML processing sessions at JavaOne

Here is the list of XML processing sessions that have attracted my interest at JavaOne:

01:30 PM - 02:30 PM TS-3441
Integrating XML into the Java™ Programming Language
Mark Reinhold, Sun Microsystems IncMoscone Center
Gateway 102/103
BOF-0443 Integrating XML Into the Java™ Programming Language: Q&A Birds-of-a-Feather  Wednesday
08:30 PM - 09:20 PM
Moscone Center
Hall E 133
BOF-2655 XML Processing With RAX-J Birds-of-a-Feather  Wednesday
10:30 PM - 11:20 PM
Moscone Center
Hall E 135

11:00 AM - 12:00 PM TS-1607
Deep Dive into JAXB 2.0
Kohsuke Kawaguchi, Sun Microsystems Inc; Sekhar Vajjhala, Sun Microsystems Inc; Hans Hrasna, Sun Microsystems IncMoscone Center
Esplanade 307-310

03:45 PM - 04:45 PM TS-8339
XJ: Facilitating XML Processing in Java™ Technology
Mukund Raghavachari, IBMMoscone Center
Gateway 102/103

Tuesday May 09, 2006

XML Stream Buffer is now in the maven repository

As part of the push to move Glassfish jars to the the Maven repository i have just pushed XMLStreamBuffer.

Tuesday Apr 11, 2006

Push me pull me?

Given an unrestricted choice between using a push or pull model for low-level parsing of XML i will always go for the pull model. In Java the push model corresponds to the SAX API and the pull model corresponds to the StAX API, or JSR 173, submitted to the JCP by BEA, which is implemented by Sun (see the Sun Java Streaming XML Parser (SJSXP) FCS version 1.0) and others (see WoodStox).

As a Java developer i find that the StAX API is just so much more intuitive to use as there is less mental juggling to manage parsing state. In terms of development this translates into much clearer code that is easier to maintain and as a consequence is likely to be more efficient. Furthermore, because application-based parsing state and behaviour is often kept "localized" there is more scope for optimization by the JVM, which can translate into further efficiency. Although it might be observed that raw SAX and StAX parsing performance is comparable i would assert that when application-level parsing code is taken into account that pull model will likely win. (Note that there are some nifty optimizations for pull implementations since the pull model allows skipping of information whereas with the push model all information is reported.)

The StAX API is not just suited for XML implementations. It is equally suited to parsing and serializing other representations of the XML Information Set. Two such examples are the StAX-based Fast Infoset implementation and the StAX-based XML Stream Buffer implementations. The former, Fast Infoset, is a binary encoding of the XML Information Set and the latter, XML Stream Buffer, efficiently buffers XML infoset in memory for replay.

Overall i think the StAX API represents a great improvement for the processing of XML in Java, and i think it possible to make it even better! The following is a wish list of improvements i would really like to see:
  • closer correspondence between parsing and serializing, so that it is easier to connect a XMLStreamReader to a XMLStreamWriter.
  • namespace management. Iterate over the in-scope namespaces.
  • the choice to buffer attribtues or iterate over attributes. Buffering attributes is an unecessary performance hit for some applications.
  • accessing text content or attribute values as "primitive" Java types. The binding of say a sequence of UTF-8 encoded characters to an integer value can be performed more efficiently if the implementation can combine the layer of parsing and data binding.

Tuesday Jan 10, 2006

Preview of JWSDP 2.0

A preview of the JWSDP 2.0 was released right at the end of last year.

I think JWSDP 2.0 represents a major improvement for Web services in Java. JAX-WS 2.0 (previously JAX-RPC) now makes use of JAXB 2.0 for data binding, JAX-WS 2.0 has much better support for REST-based Web services (see sample), and there are many security features enhanced security features with XWSS 2.0. True to the spirit of the JWSDP it includes an experimental release of Java API for XML Web  Services Addressing.

Oh, i nearly forgot! JAX-WS 2.0 also supports Fast Infoset, but for some reason the manual link from the release notes is not valid (enabling Fast Infoset JAX-WS is very similar to JAX-RPC but the property names have changed).  I will try to get that changed.

[Updated: 19 Jan 2006]
A temporary link to manual can be found here. It should be updated on the web site fairly soon i hope.



« July 2016