Introducing nWP, the Java Counterpart of WordPress
At Numiton we've been exploring several options for hosting our blog on dedicated servers.
We wanted to stick with a Java Web container for several reasons including:
- our love for Java based technologies and the fact that our forum was already Java based
- avoiding the complexities of setting up another Web container
- use of a single monitoring console (LambdaProbe in our case)
We started by evaluating Apache Roller but it seemed too heavyweight for our needs. It was also difficult to configure. Then we found Pebble which was much closer to what we needed. So we settled for it for a few months.
But we knew about WordPress, a heavily used blogging engine, much more extensible and polished and with considerably better administrative features. We didn't want to code in PHP to fix bugs or implement new extensions, though. In case you're interested, I've already blogged about why open-source PHP projects are more popular in spite of what happens under the hood.
How did we actually perform the migration? We used our automated software migration tool. There are several challenges in implementing such a tool. The first one is to produce a functionally equivalent application in the migration target language (Java in this case). Once this is dealt with, the quality of the generated code comes into focus: transforming PHP code into good quality Java code and making use of the consacrated Java technologies. Both are difficult tasks and this is why you don't see automated software migrators too often, regardless of the source and target languages.
In doing the migration of nWP, we applied the usual nTile PtoJ optimization algorithms, including type inference, transformation of dynamic constructs, object extraction and variable scope optimization. Additionally, we used the Spring output flavor option to generate a Spring MVC based Web application.
From a functional point of view, nWP in its present state is quite satisfactory. However, the code quality of the original WordPress project wasn't that great to start with. It got improved by the migration process (we now have declared types, fewer dangerous dynamic constructs, variable scopes are narrowed etc.), but more can still be done.
This is what we have in mind:
- improve the code quality and enforce sanity checks using static analysis tools (like PMD, FindBugs)
- in particular, find a better alternative to the current inherited framework for defining and applying filters (dynamic function invocations) - OSGi services or Equinox extension points come to mind
- make better use of the Spring MVC features, especially by improving the page models
- modularize the engine - separate the user and administrator sections, maybe split the administrative section into smaller chunks with the option of adding new functionality by third-party plug-ins
- provide proper plug-in based extensibility for themes, plugins, languages etc. probably using an OSGi implementation like Equinox
- start migrating relevant existing WordPress extensions
So there's still quite some engineering work ahead to maximize the code quality. The good news though is that from an end-user's point of view, the application is fully functional. Moreover, the above enhancements are far more easy to perform using Java IDEs and tools - some of these are even out of the reach of PHP. The end-result will be a state-of-the-art component-based application.
I already used nWP on our blog and it's really more intuitive from an administrative point of view than Pebble is. Also, it is very easy to install and start your own blog with it (even simpler than the famous WordPress 5-minute install). But don't take my word for it, give it a try yourself. It's open-source and hosted at SourceForge.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)