This move has several major advantages. The first is that you can now use GitHub’s “social coding” features to fork and modify the Stringtree and Mojasef code (and I’m always happy to discuss changes and improvements). The second advantage, and the one which tipped me over, is the ability to use git’s clever “submodule” support to include up-to-date Stringtree and Mojasef source code in other projects.

In the short term I will also be keeping the svn repositories up to date with significant changes. For now they are also the best place to find example code which uses Stringtree and/or Mojasef, but I plan to move all the examples over to GitHub in time.

Please let me know if you have any issues or questions about this move.

This is an interesting challenge to my own pure-Java Mojasef framework, which offers several similarities with the approach taken by Sinatra. Sinatra wins on documentation, though

A good guide to getting started with Sinatra and Warbler can be found at Sinatra on Java | Coreguardian.

There are several commercial workflow engines available, and a whole bunch of open source ones. Here’s a list of workflow engines written in Java, for example.

Boris Lublinsky has written an article at InfoQ expressing the strong opinion that writing your own workflow engine should not be an option.

I’m not sure I completely agree. For me the most telling part of the article appears near the end:

People today rarely implement their own database or O/R mapper or application server. Why is it often that people think that they should write their own workflow engine?

As it happens, I have implemented my own database, O/R mapper and application server, and found the experience invaluable in understanding the challenges and important features of such software. Writing a workflow engine would presumably be a similarly valuable lesson.

Since then I have progressively realized that I may have been a bit optimistic. A few odd bugs have been found in the 1.4 code, and a few key improvements have been made to the Java 5 code which by rights should also be implemented for 1.4. So I have decided to try and fix the situation.

As of today, the tag “1.4-final” in both Stringtree and Mojasef should be considered as deprecated, and any code which used to use that tagged version should instead use the branches (“Stringtree for Java 1.4″ and “Mojasef for Java 1.4″) I have just created. Initially, the code is identical, but the plan is to go through and apply known bug fixes and fully-backward-compatible internal improvements to the branched versions.

JSON Schema Proposal

Apparently, Java 1.4 will officially reach its end of service life (EOSL) at the end of October 2008. That of itself does not imply that nobody will continue to use it, but it does help third-party providers such as myself decide when to stop active support.

So, this is my decision. Some time after the start of November I will make a branch of the final Java 1.4-compatible version of all my public projects. Any future changes will no longer guarantee Java 1.4 support.

This does not imply, of course, that all my public code will suddenly be rewritten; dripping with annotations and generics and so on. The process will be incremental and progressive. The main point is that I will no longer be ensuring Java 1.4 compatibility in future releases.

As an aside – if you are still using Java 1.4 and would like to suggest a change to any of my software, please ensure that you get in touch in time for me to include it before November!

It all started with an innocuous question in a comment on my Punchbarrel blog. I had posted asking for opinions on a move to Java 5, potentially abandoning Java 1.4, for the core Stringtree codebase. The question in the comment was about skipping Java 5 and moving directly to Java 6. This would normally be too big a leap, but I replied that I would endeavour to continue my policy of ensuring my code works with as wide a range of Java versions as possible.

Then I actually tried to do it, and that’s what made me cross. The more I attempted to produce code which would compile and run on Java 1.4, Java 5 and Java 6, the more impossible it began to seem.

I was already aware of the first hurdle. Sun have added new methods to a lot of key JDBC interfaces by tagging them with the new javax.sql.Wrapper interface. This is actually relatively easy to fix in a compatible way. Just add two new methods to each class which implements one of the affected JDBC interfaces:

    public boolean isWrapperFor(Class clz) {
        return false;
    }
 
    public Object unwrap(Class clz) throws SQLException {
        throw new SQLException("Not a Wrapper for " + clz);
    }

The actual method signatures in the Java 6 Wrapper interface are phrased in terms of Generics, but the above stripped version compiles fine using Java 1.4, Java 5 and Java 6 compiler and libraries.

However, even after adding these arguably pointless methods to all my concrete implementations of affected JDBC interfaces, I still had a bunch of compilation errors when using Java 6 libraries. And this is where Sun have really screwed up.

Several other key JDBC interfaces have also been extended. But this time it has not been done by anything as simple as tagging with a new interface. These interfaces have all gained extra method themselves. This should not be a deal-breaker. It should be feasible to just add implementations of these methods to the existing Java 1.4-compatible code. After all, any class is free to define any methods it likes, not just those from an interface.

Nope.

It is simply impossible to add these new methods to a class and have that class still compile in a Java 1.4 or Java 5 environment.

The reason is that these methods are themselves defined in terms of classes and interfaces which do not exist in earlier Java versions. For example, the java.sql.Connection interface gains methods referring to new interfaces NClob and SQLXML

There is no answer to this. Sun have broken backward and forward compatibility of JDBC in Java 6. It is no longer possible to write an implementation of several key JDBC interfaces in a way which compiles under all the most popular Java versions.

Once again, Sun completely misunderstands the real world. Not everyone is free to upgrade every deployment to the very latest Java version immediately it is released. Even within those who do manage to update all their machines in one go, not everyone can immediately drop real work to spend time messing with old code which should still work to bring it into line with a new fashion.

As I wrote at the start of this rant. I’m cross.

Grrr.

For a long time I interpreted this goal as implying that all Stringtree code should run on all Java versions from Java 1.2 onwards. Java 1.4, however, introduced some compelling new features including built-in regular-expression handling. For a few years I still tried to ensure that most code was still 1.2-compatible (for example by using Ant to swap in a third-party regular-expression library while building a jar file), while also providing a Java 1.4 version. Eventually, use of Java versions prior to 1.4 declined enough that I felt comfortable removing the complicated pre-1.4 version.

For the last few years I have been very careful to keep all my Stringtree code compatible with all versions of Java from 1.4 upwards. Now, however, the pressure is building again to move over to Java 5. In my day-to-day coding I develop with Java 5 and make increasing use of Java 5 features such as the enhanced for loop, the Iterable interface, enums, generics, autoboxing, varargs and so on. It would be very nice to be able to update the Stringtree codebase to use these features too.

Occasionally a Java 5-specific detail has crept in to a Stringtree library, and I have soon received comments or emails pointing this out. I haven’t noticed this for a while, which might indicate either that I have been especially careful, or that I there are no longer any/many people developing with Stringtree code who are still limited to Java 1.4.

If you are reading this and you still require Java 1.4 support, please let me know. Likewise, if you have thrown off the shackles of 1.4 within the last year or so or are desperately hoping for a Java 5 Stringtree that would be good to know too.

Is it time for Java 5 yet?

If you need a simple and fast parser for textual data, then this should be all you need. For XML documents containing opaque binary data in a CDATA block, this may not be ideal. Currently CDATA blocks are loaded as String objects, and this can lead to incorrect data for bytes which do not represent valid characters in the current character set.

I am currently planning for the next version of the Stringtree XMLReader to offer the option of extracting a CDATA block as an unprocessed byte array.

Recently, however, one of my users has been bugging me to make the Stringtree and Mojasef classes and sources available in a Maven-style repository, for easier integration with Maven (or Maven-like) build tools and workflows. So I have done it. The current versions of key Stringtree and Mojasef files are now available from the Stringtree repository at the following URLs:

• http://stringtree.org/repository/org/stringtree/stringtree/2.0.10/stringtree-2.0.10-sources.jar
• http://stringtree.org/repository/org/stringtree/stringtree/2.0.10/stringtree-2.0.10.jar
• http://stringtree.org/repository/org/stringtree/stringtree/2.0.10/stringtree-httpclient-2.0.10.jar
• http://stringtree.org/repository/org/stringtree/stringtree/2.0.10/stringtree-json-2.0.10.jar
• http://stringtree.org/repository/org/stringtree/mojasef/2.0.b1/mojasef-2.0.b1-sources.jar
• http://stringtree.org/repository/org/stringtree/mojasef/2.0.b1/mojasef-2.0.b1-withdependencies-sources.jar
• http://stringtree.org/repository/org/stringtree/mojasef/2.0.b1/mojasef-2.0.b1-withdependencies.jar
• http://stringtree.org/repository/org/stringtree/mojasef/2.0.b1/mojasef-2.0.b1.jar

The Stringtree and Mojasef build scripts now include a “publish” target which uploads such artefacts to appropriate places in the repository, so future versions should continue to be available.

This is the first time I have done this, so I would welcome comments from any readers who actually use Maven (or buildr, or anything else which supports this repository format). In particular, I am interested in opinions on whether it is OK to simply replace artefacts with the same names and locations for minor tweaks and bug-fixes, or whether even the smallest change should result in the generation and upload of a new version with a new name and location.