Introducing nWP, the Java counterpart of WordPress
October 4th, 2008 by Robert EnyediAt 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.
With all these in mind, we decided to use our own technology and migrate WordPress 2.5.1 to Java. The result is the nWordPress project (or, in short, nWP), a pure Java blogging engine.
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.
This is the first post I’m writing with nWP 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.
Tags: blog, Java, open-source, PHP, software migration
October 4th, 2008 at 9:58 pm
Why SpringMVC. No freaking framework war right here yet you also state that complexity of development is the reason java loses versus php in web stuff.
I never needed to try Spring, yet from what I glanced over is no easy ride. Do I need to learn a complex framework, set up stinking maven just to start developing for nWP? NOWAY!
You’re dead on arrival. For what you need, something like the mindless Click framework should be enough.
No, but the curse of every java programmer is to over, and over engineer everything and build flexibility even in a toilet handle.
You know what, flush your spring.
October 4th, 2008 at 11:34 pm
@Florin: The Spring MVC framework is highly respected in the industry because it brings a more meaningful approach to Web development.
Although your post is a little harsh, you do raise some valid points.
The tendency of Java developers to over-engineer just for the sake of it is one such point. The second point is related to the complexity of the Spring MVC framework.
In the case of nWP we specifically wanted to avoid these and we tried to produce a migration output to only use Spring features that make the application easier to understand and develop.
October 6th, 2008 at 3:03 am
Spring is awesome because it allows for easy testing. rather than hard-coding which classes an object needs to be tested, you pass them in. you can pass in test objects just as easily as “real” ones and … it just makes things easier.
that alone is enough reason to use spring.
October 6th, 2008 at 9:23 am
Excellent choice for Spring MVC. I imagine that translating WordPress to a more complex framework like JSF would’ve been 10 times more difficult and the learning curve for nWP even higher. Translating to a lower level framework like Spring MVC gives you enough flexibility to ease the translation and also the framework is simple enough for others to understand.
Does your translation process generates command objects?
October 6th, 2008 at 9:55 am
Is nWordPress a demonstration of your technology, or an actual product you will continue to develop? Why WP 2.5.1, the current version is 2.6.2?
October 6th, 2008 at 12:52 pm
The installation doc (http://nwordpress.cvs.sourceforge.net/nwordpress/nWordPress/README?view=markup) says nWordPress only depends on Java 1.5. But this Tomcat startup log speaks otherwise:
java.lang.UnsupportedClassVersionError: Bad version number in .class file
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:185
2)
at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:876)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1329)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1208)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at com.numiton.generic.NumitonContextListener.logParameters(NumitonContextListener.java:235)
at com.numiton.generic.NumitonContextListener.contextInitialized(NumitonContextListener.java
:63)
Running Tomcat with the 1.6 JDK everything went well.
October 6th, 2008 at 2:38 pm
@jakob: Thanks for pointing out this problem. It seems that somehow nWP 0.9.3 got built with a Java 6 compiler. I reported the bug (https://sourceforge.net/tracker/index.php?func=detail&aid=2149423&group_id=214436&atid=1029673) and I’ll try to update the package on SourceForge.
But until then, at least it runs on JDK 1.6 :-)
October 6th, 2008 at 2:58 pm
@OliBlogger: nWP is more than a case study for us. We do want to continue its development. In fact we are its first user :-)
One of the first things to consider is to provide an extensibility mechanism for nWP (see this feature request: https://sourceforge.net/tracker/index.php?func=detail&aid=2149364&group_id=214436&atid=1029676) and start migrating some relevant WordPress extensions to nWP.
The reason why WordPress 2.5.1 is the baseline version for our migration is that the migration started some time ago. It did take unusually long due to several factors: manual interventions were required on the generated Java codebase, some of the required 300+ runtime functions needed to be implemented in Java (manual work) and all these were done as a side-project along with our commercial migration work (we are a startup).
Regarding nWP, right now our main concern is architectural especially because our resource are limited. The input code was sub-optimal and it needs improvement work to sort out the mess. But once this gets done, the nWP team should be able to add some really interesting features. Especially because when the code gets cleaned up, it will be much easier for potential contributors to understand the code of the engine itself and start working on it or on extensions.
October 7th, 2008 at 10:42 am
@Marius: Translating WordPress to Java with JSF as a framework would have meant two major steps: 1. migrate from PHP to Java and 2. migrating from a document based user interface (HTML) to a component based one.
Step 1 is what we already did. It’s a language migration.
Step 2 would mean transformations on the HTML and JavaScript code in a way that visual components would be extracted from a plain HTML document. This is a software re-engineering - http://www.numiton.com/knowledge-base/software-translation/software-re-engineering.html .
This second step is actually much harder even than it sounds because we are not even talking about static HTML content with JavaScript attached, but rather a dynamically generated one. To answer your question, we aren’t sure yet if this even would have been possible automatically. Maybe semi-automatically, combining the input of the migration tool’s user with specialized algorithms.
Related to your question about the usage of command objects. No, we don’t use them. It’s not something that PtoJ is able to extract from the PHP code at this point.
October 7th, 2008 at 12:33 pm
Does it support having multiple blogs on the same server?
October 7th, 2008 at 1:45 pm
@DL: This is the migration of the regular WordPress version and not Wordpress MU - http://mu.wordpress.org/. This means that a single installation does not support multiple blogs.
October 8th, 2008 at 2:50 am
This was on the cards. Good work. Just wanted to check is this an advetisement of the tool that you guys have to migrate from PHP to JAVA. I would have loved if this came 4 months back . My clients would have been happier.
October 9th, 2008 at 12:09 pm
@Abhinao: We see a real potential in the nWP project and it definitely isn’t just an advertisement. The next step will be to pave the road for extensions, many of which we will be able to migrate from those of WordPress.