Open Source software projects

Open Source is a way of developing software which does not keep secrets, but instead shares code and involvement with anyone who is interested. Most software developers use open source software every day. I am convinced that contributing back to the open source community is an important part of modern software development.

Over the years I have created and worked on a wide range of software projects, many of them developed and distributed as open source. Here are some of the main ones:

  • Friki Arguably my most popular software project, with thousands of downloads, and some high-profile, high-volume users such as the JavaRanch FAQ. Friki is a "Wiki", or editable web site, written in Java and easily deployable to any standard Java web container (Tomcat, JBoss, etc.)

    The first version of Friki was created in the late 1990s, and was very simple indeed. I wrote a series of articles in 2003 about the design and developpment approach which can be read in the Java Ranch Journal: ( part 1, part 2, part 3, part 4, part 5, part 6. ) The second version kept the acceptably simple approach to page storage and web app structure but addressed the main user complaints and suggestions. The overly-simple mechanism used to process and populate content into pages got a complete overhaul and is still one of the most flexible and powerful of any wiki. Unlike the great majority of wiki implementations, which hard-code the processing of their "wiki markup" into the application itself, Friki 2 dynamically builds a markup processing "pipeline" based on a config file. This allows maintainers to add new markup idioms, and even support wholly new markup languages, with no need to re-compile or re-build the aplication itself.

    The Friki software has now been in stable production use for several years. Source code and downloads available from Sourceforge ( http://sourceforge.net/projects/friki/ )

  • Stringtree Stringtree is a collection of Java APIs and components which together form a powerful and effective way to develop software. Wherever possible, the components which form the Stringtree collection may be used independently, but the biggest benefits come when they are used together. Stringtree is under active development, and has been used in both commercial and open source developments.

    The Stringtree components include:

    • Stringtree JSON - a small, neat and robust implementation of a reader, writer, and validator for the JSON (JavaScript Object Notation) data format. The reader and writer are one class each, with no dependencies at all. Even the full stringtree JSON jar with reader, writer, validator and some other useful classes weighs in at just 13kB!
    • Stringtree Templater - a fast and powerful template system for simply generating all kinds of textual output, commonly used for generating data formats such as CSV and TSV, XML for transfer of hierarchical information, and HTML or WML for the web.
    • Juicer - a hugely powerful and extensible text transformation "pipeline" which allows complete run-time configuration and management of the process. This component drives the core of the Wiki markup conversion in Friki
    • Fetchers and Finders - a way of assembling building blocks of associative storage to decouple your software from the details of storage. Works with files, classpath resources, URLs, environment vraibles, request attributes, and many more.
    • DatabaseWrapper - A solid yet simple way to read and write to any JDBC database, where you the developer have full control of SQL, Transactions and so on, but the DatabaseWrapper takes care of everything else.
    • Spec Files - an enhancement of the popular properties file format which supports objects way beyond the humble String.

    The Stringtree software is stable but under continuous development. More information is available at the Stringtree web site. Some older jar files are available at sourceforge, but source code for the latest version is available from github ( https://github.com/efficacy/stringtree )

  • Mojasef The most popular way of running Java programs on the World Wide Web is to use the Java Servlet API, part of the Java Enterprise Edition (JEE). Unfortunately, the Servlet API (and JEE in general) has a reputation for being cumbersome to configure and use. Worst of all there are a lot of "gotchas" which can make it difficult for inexperienced users, even those with a lot of Java experience, to produce effective server-side applications.

    At the same time, other web application frameworks, such as Ruby on Rails are receiving praise for their speed of starting development and the way their structure maps easily onto the natural Representational State Transfer (REST) design of the web.

    Despite the attractiveness of the Ruby language and the Rails web application framework, there are still many good reasons for wishing to write web applications in Java. The aim of the mojasef project is to produce a general-purpose server core in Java which has a specific set of defined benefits to developers and users. Application code should be:

    • quick to write, with a minimum of framework-specific code
    • simple to test, without needing to run a server or specialist test software
    • easy to configure and deploy
    • easy to reuse at all levels

    I don't want to be guilty of over-hyping Mojasef. So please don't assume that Mojasef does everything that Ruby on Rails does. Or that Zope or Plone do. Mojasef contains the following:

    • An "object publisher" that understands both HTTP and Java objects, and tries its best to map one to the other.
    • A powerful alternative to properties files and XML configurations which allows components and applications to be assembled from other components and applications without re-compilation.
    • A flexible page-templating system.
    • A collection of utility classes, used in the implementation of the server, and available to all application code.
    • The ability to use any of your favourite Java APIs and libraries.

    Mojasef is stable but under continuous development. More information is available at the Mojasef web site. Some older jar files are available at sourceforge, but source code for the latest version is available from github ( https://github.com/efficacy/mojasef )

  • Rack 4 Java In the world of dynamic language web development it is common for the interface between server, web framework, and application components to be simple and standard. Most have settled on a particular style. Ruby Rack, Python WSGI, perl PSGI and more, all have a lot in common.

    A request is represented as an associative array ("Map", "Hash", "Dictionary" etc.) populated with a standard set of named items, but able to contain others. A response is represented as a triplet of [response code, headers, body]

    This is extremely simple compared with the Java Servlet API (usually considered as the standard way to interface web applications with web servers.) This simplicty has many advantages:

    • it's much easier to implement, so lots of people can support it in their servers
    • it's much easier to work with, so both frameworks and raw applications can be simpler
    • it's much easier to mock/stub, so framework and application code is easier to test
    • it's much easier to use the "decorator" pattern, so applications can be much more modular

    The last point is particularly important. Ruby Rack has a vibrant ecosystem of "middleware" for all sorts of common tasks and processes, making application developmentmuch easier by simply combining and re-arranging pre-built blocks with no change to application code at all.

    Rack 4 Java is An ultra-lightweight Rack port for Java. The key goals of this project are:

    1. To produce a tiny Rack layer for Java, with no external dependencies
    2. To ensure that it works acceptably for all types of HTTP request and response
    3. To be as compatible as possible with the spirit of the original Rack specification
    4. To be as performant as possible within the constraints of the essential API

    All of these goals contribute to the overall aim of a very thin, agnostic layer to connect wildly different types of web servers, applications and third-party APIs. In particular this means no dependency on the Servlet API, (although a "wrapper" is available if you want to deploy Rack4java applications to a Servlet server. A simpler web API is also vital to bring the joy of Test-Driven development to all levels of java web software.