Thursday Jan 27, 2011

301 Moved Permanently

HTTP/1.1 301 Moved Permanently 
Cache-Control: public
Content-Type: text/plain
Date: Thu, 27 Jan 2011 15:43:59 GM
Content-Length: 807

My last day at Oracle will be the 14h of February. I will be moving on to do
some exciting new stuff, more details on that date at the new location.

After that date I will no longer be actively engaged in leading JAX-RS and 

Given my public involvement in both projects I feel it appropriate to
communicate this earlier than normally anticipated, especially now that the
JAX-RS 2.0 ballot has passed (yes!) and the expert group formation can start.

JAX-RS leadership and Jersey will still be in the very capable hands of the
GlassFish and Jersey teams, specifically Dianne, Jakub, Jon, Marek, Martin,
Pavel and Roberto

Jakub will take over responsibility for leading Jersey 1.x. Marek, who is new 
to the Jersey team, will take over responsibility for being the JAX-RS co-spec 
lead with Roberto.

Tuesday Apr 27, 2010


 My three year subscription of the Economist has ended. Are they trying to tell me something?

Wednesday Dec 09, 2009

Spin Spin Spin

In this article Steve Mills of IBM is to have said:

Oracle’s proposed acquisition of Sun Microsystems did not raise any significant antitrust issues and was likely to close soon in spite of objections raised in Brussels, according to Steve Mills, head of IBM’s software division and one of Oracle’s biggest rivals.

Then the some spinmeister is to have said:

An opponent of the deal said IBM’s comments were an indication that competition concerns were well founded.

LOL. Do you feel the cognitive dissonance :-)

The spin against Eben Moglen was, to some, more disgusting:

Isn't that disgusting? Blow his own horn much? Moglen "unimportant in a GPL context"? 

The best definition of spin i have seen was proposed by Dan Dennett. The "Cannons of good spin":

  1. It is not a bare-faced lie.
  2. You have to be able to say it with a straight face
  3. It has to relieve skepticism without arousing curiosity
  4. It should seem profound
Of course the more spin that is spun the more likely one might get caught out.

Saturday Sep 05, 2009

Naming, buying and reading

The title of this blog may be misconstrued as a pithy philosophical statement about life, the universe and everything.

Naming things can be tricky and inspiration comes from many sources.

While pondering a name for this blog a reoccurring thought distracted my consciousness yet again: "I must buy and read Earthly Powers by Anthony Burgess!". Free association did the rest, and the title would serve a duel purpose as a memento.

This week my copy of Earthly Powers arrived in the post.

Now i have to remind myself to read it, and an opportunity presents itself. I am on holiday from the 8th September for 2 weeks. This is a big tome, 650 pages of small print, requiring sustained concentration and time, both of which are a scarce commodity when an energetic toddler demands a 100% of both. So... we shall see...

Thursday Nov 01, 2007

Concurrency with Scala (was Concurrency with Erlang)

Steve Vinosky has written some really interesting articles on Erlang concurrency and Erlang reliability. I think i am going to buy that book on Erlang he recommends.

After i read his article on concurrency i wondered if the same (contrived but instructive) example he presents could be written in Scala and how it would compare, if anything it is a good exercise in learning.

Here is the simple non-concurrent (tail call) recursive pow function in Scala:

def pow(n: int, m: int): BigInt = {
    def _pow(m: int, acc: BigInt): BigInt  = m match {
        case 0 => acc
        case _ => _pow(m - 1, acc \* n)
     _pow(m, 1)

and here is the concurrent cpow function using Scala's event-based actors:

def cpow(n: int, m: int): BigInt = {
    val actors = for (_ <- List.range(0, m)) yield
actor { react { case x: int => sender ! x } }
    actors foreach ( a => a ! n )
    (actors foldLeft BigInt(1)) { (t , a) => self ? match { case x: int => t \* x } }

The value actors, which is a list of m actors, is obtained using list comprehension. As in Steve's example each actor just pings back the value it receives from the sender. Then a message is sent to each actor with the value of n. Finally all the values received from the actors are multipled together (as BigInt types) using the foldLeft function. Rather elegant! and similar in size to the Erlang code.

I measured the time it took for both functions to calculate 502000 on my Acer Ferrari 3400 laptop running Solaris, Java SE 5, and Scala 2.6.0. The pow function took 17.86 ms and the cpow function took 81.28 ms.

Below I re-iterate one of Steve's final points with a slight modification:

..., many developers are comfortable with OO programming. I’d like to advise such developers not to let Erlang’s or Scala's functional nature scare you away, ...

Given that Scala is a hybrid object-oriented and functional programming language it can enable developers to smoothly transition between the imperative and functional programming styles in  small manageable steps i.e. Scala is less scary than it might initially appear.

Friday Jun 08, 2007

Skittr cloning Twitter

Skittr is a clone of Twitter written by David Pollak in 884 lines of Scala. It uses the lift web framework. What caught my eye was the following:

It can handle 1M+ users on a two Intel Core 2 Duo boxes (one as the web front end and the other as the message broker.) With a weeks of full-time coding, it could be modified to scale linearly with the number of boxes in the system.

Impressive scalability in conjunction with the Java VM and a Servlet engine.

A side question: can functional programming languages help programmers better develop scalable applications for multi-core chips? Cause at the moment there is an issue that is nicely expressed by Sean McGrath:

The processor will stop doubling in speed and halving in cost. Instead, you will find more and more processors shipping in each computer.

This is the future because the hardware people are creating it that way. The software people need to realize that fact and start figuring out how to use all the processors. This future does not just involve just re-compiling your software. It involves turning it on its head in most cases.

Monday Mar 05, 2007

Web of Services for Enterprise Computing workshop

I attended, with Marc, the Web of Services for Enterprise Computing workshop. It was a useful two days hearing various positions put forward.

WADL was very well received, I think it is gaining some traction. It would be fair to say that WSDL 2.0 was not so well received in the context of being Web friendly.

What surprised me was the general acceptance of the Web, and REST architectural style, as a good thing for building Web applications. I guess i was expecting a little more heat from opposing sides! My impression was that the main opposing positions were 'please stop doing more specs and maintain what we have' and 'we need more specs'. It is clear that there is a general need for interoperable protocols in the enterprise but some were questioning whether this should be something the W3C should really be involved with.

My personal view is that the W3C should concentrate WS-\* interoperability on what we have (limit new specifications), encourage good and best practices for applications that are exposed on the Web using the REST architectural style, fix the pain points for Web interoperability and bridge the gap between Web and WS-\* where it makes sense.

With respect to the last view i think Atom and the Atom Publishing Protocol (APP) has the potential to make in-roads into the enterprise where real-time requirements are less demanding. An Atom service combined with something like the Post Once Exactly (and PUT too?) pattern of use may provide reliable services in a manner quite different to that of traditional enterprise publish and subscribe technologies but yet be Web friendly. For instance, imagine an APP facade over a JMS queue or topic.

Monday Jan 08, 2007

ITU-T Recommendations are freely available

The ITU-T has started the new year with a great gesture of good will.

All published ITU-T Recommendations are currently freely available from here. The ITU-T also offers such Recommendations in languages other than English, such as French/Spanish and Chinese/Arabic for more recent Recommendations . In my experience the editors at the ITU-T  do a great service providing high-quality Recommendations and ITU-T's commitment to multiple languages is truly commendable.

The free access will last at least until the next ITU Council meeting (the beginning of September 2007).

Unfortunately Fast Infoset (X.891) is still in the pre-published state so it is not possible to get it directly for free (but one can download it using for free using the 3 free Recommendation option). Fast Web Services (X.892) is available. It is interesting looking at a specification i helped write in Arabic!

Friday Aug 25, 2006

Merging of Japex configuration files

I recently added a new feature to Japex for the supporting of merging configuration files. This was a feature required for a large benchmark to make it easier to handle the testing of multiple groups of tests cases without having to create a new configuration file for each group of test cases. ( This benchmark has been used to produce results for the W3C Efficient XML Interchange Working Group.)

Now you can pass more than one configuration file as arguments to japex when the '-merge' option is present, for example: -merge <file_1> ... <file_n>

and Japex will merge each file to produce one test suite configuration. For example, there could be one configuration file consisting of parameters and drivers and one or more configuration files consisting of test cases and Japex could be used like this: -merge configWithDrivers.xml testCasesGroup1.xml

I modified the Japex configuration schema so that param, driver, testCase and groups of are all root elements. This means that a group of test cases is a valid standalone Japex configuration file and it allows JAXB to easily unmarshall such configuration files.

In fact JAXB made it really easy to merge the configuration files since it was simply a matter of copying information from one JAXB bean to another one.  Now JAXB is also used to create the configuration file that is stored with the Japex reports: it is just a simple marshal of the JAXB bean representing the test suite.

Monday Jun 05, 2006

A ramble on characters in XML documents

When I was rookie XML 1.0 user i was not aware that there were restrictions in the characters that are allowed in element/attribute tag names, text content and attribute values. It caused some mild eyebrow raises when i found out and looked more closely at the W3C XML 1.0 Recommendation! XML's foundation is Unicode characters, right? so why the subset?

Take for example the specified character range of a character that is allowed as part of text content:

Char   ::=   #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]

So that means no 'control' characters, like 'NULL' or 'BELL' (see here for  good description of the issues , which may explain the reasons why, for XML 1.0, control characters were disallowed).  A character code of  '0' is not allowed as part of text content of an XML document, i think this makes sense from the perspective C/C++ since '0' is used as terminator for strings, and allowing '0' would cause all sorts of issues.
Note: bnux, an interesting binary encoding of the XML infoset, cleverly takes advantage of this fact to terminate a sequence of UTF-8 encoded characters using a '0' instead of length prefixing.

So the following XML document is not well-formed:


For more information on this I highly recommend looking at Tim Bray's most excellent annotated XML 1.0.

Having said that, the W3C XML 1.1 Recommendation opened the door for 'control' characters!, the character range of a character is now:

Char   ::=   [#x1-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]

The 'NULL' character code is still disallowed. I think XML 1.1 is an improvement on XML 1.0 since XML 1.0 restricted the characters codes that were allowed in element/attribute tag names. Now more languages can utilize markup for element/attribute names.

Note: The subtle difference between XML 1.0 and XML 1.1 can cause some interesting edge case issues. Take for example the W3C xml:id Recommendation. The value of an xml:id attribute is specified to be an NCName. If you need to correctly implement xml:id on top of an existing parser that does not support xml:id, for example as a SAX XMLFilter, then that filter will need to check the version number of XML and perform the correct NCName character validation based on the XML version. This is the case with Norm's nifty xml:id implementation at Obviously the ideal solution would be that the parsers implement xml:id.

Monday May 15, 2006

Example of a plugable transport in JAX-WS

The rearchitectured JAX-WS RI supports plugable transport components, so it is possible to transmit SOAP messages over transports other than HTTP, for example JMS, SMTP or TCP/IP.

One such example explored in more detail is a plugable JMS transport. Alexey Stashok has created a example JMS Web service transport component at This simple example is specifically designed to show how transports can be easily developed.

If you are interested in developing transports for JAX-WS check this out!

Monday Mar 13, 2006

Grouping of test cases in Japex

I mentioned to Santiago that it would be useful to group test cases in Japex so that they could share common parameters instead of having to repeat common parameters per test case. A day later he implemented it!

So now you can do the following (which is an actual fragment from a real test case we use for measuring XML and JAXB performance):

    <!-- This param applies to all test cases in this group -->
    <param name="contextPath" value="com.sun.xmltest.genjaxb"/>    


    <testCase name="inv5K.xml">
        <param name="japex.inputFile"
    <testCase name="inv13K.xml">
        <param name="japex.inputFile"
    <testCase name="inv96K.xml">
        <param name="japex.inputFile"

Before being able to group tests it was necessary set the contextPath parameter on each test case (this parameter is passed to a JAXBContext).

On the subject of reuse a useful tip when using Japex is to separate the test cases from the configuration file (with the drivers) by using entities. The following is an example Japex configuration file used by the XMLStreamBuffer project (see here) for measuring the performance of creating a buffer compared to creating a DOM:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE project [
<!ENTITY testCases SYSTEM "testcases.xml">
<testSuite name="parse" xmlns="">

    <param name="japex.warmupTime" value="5"/>
    <param name="japex.runTime" value="5"/>
    <param name="japex.resultUnit" value="ms"/>

    <driver name="XercesJAXPSAXDriver" normal="true">
        <param name="japex.driverClass"
        <param name="jdsl.doNotReportSize" value="true"/>
    <driver name="JAXPSAXParserCreatorDriver">
        <param name="japex.driverClass"
    <driver name="XercesJAXPDOMParser">
        <param name="japex.driverClass"
        <param name="jdsl.deferNodeExpansion" value="false"/>
        <param name="jdsl.doNotReportSize" value="true"/>



When the XML document is parsed the parser will substitute &testCases for the contents of the file testcases.xml.

In fact now that test groups are supported Japex is much more friendly to such composibility using XML Include.

Wednesday Feb 15, 2006

Optimizations to JAX-WS

Kohsuke writes how he is neck deep in JAX-WS rearchitecturing the JAX-WS RI. He deinfintely is, as are others working on JAX-WS, but they are having no problems holding their heads above water!

There are some good improvements here on architecture and implementation which i think will make it very competetive in terms of performance and features with other Web service stacks.

I have looked at netbeans profiler traces (obtained from using Japex configured for a simple Web service micro-benchmark called WSpex) of the old and new and I could see an immediate improvement in the stack of calls. It was also much easier to identify hotspots where performance can be improved. There is still work to do but early results obtained using Japex indicate we are off to a very promising start.

One area which i have been trying to help out in is the area of efficiently buffering infoset for efficient replay. The XMLStreamBuffer project enables the buffering of infoset produced from stream-based XML APIs (like SAX or StAX) for replay using stream-based XML APIs.

XMLStreamBuffer is being used in JAX-WS to buffer the SOAP header blocks of a SOAP message. Each SOAP header block is marked in the buffer and can be replayed using a XMLStreamReader or easily bound to a JAXB object. This offers an efficient alternative (in terms of memory and processing performance) to buffering the header blocks using DOM.

Another area in JAX-WS where XMLStreamBuffer is currently being used is in the area of processing documents (e.g. WSDL, XSD, etc.) associated with services. Buffers of documents are created and consequently they may be efficiently processed concurrently.

I think this calls for another blog on XMLStreamBuffer explaining features and presenting some examples...

Monday Jan 02, 2006

Japex has moved

Japex, the performance monitoring framework, has found a new home and a cool logo for new year.

It was previously part of the Fast Infoset project and Santiago moved it and created the nice new home.



« July 2016