Introducing nWP, the Java counterpart of WordPress

Discussions

News: Introducing nWP, the Java counterpart of WordPress

  1. 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 Blogger 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. I've 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.

    Threaded Messages (11)

  2. The project is pretty much a showcase of (admittably impressive) PHP-to-Java migration technology. The code looks relatively OK (I expected much worse), largely because it's based on the Quercus PHP standard library implementation for Java. However I'm almost 100% sure that you lose a lot of the extensibility of WordPress, which makes it such a powerful platform (you can't override the functions, as they are no longer in the global namespace). I can't imagine why anyone would want to deploy WordPress on Java instead of PHP and not use Quercus, but as a showcase of Numiton tech it's OK. I just wish they'd actually present it as such.
  3. I can't imagine why anyone would want to deploy WordPress on Java instead of PHP ..
    Then re-read the original post.
  4. Broken Links[ Go to top ]

    www.lambdaprobe.org Did not work on your dzone post either.
  5. Re: Broken Links[ Go to top ]

    Thanks for pointing this out, but I can't find a way to edit the initial post.
  6. The code looks relatively OK (I expected much worse), largely because it's based on the Quercus PHP standard library implementation for Java.
    We do have our own runtime implementation which is simpler and more Java like than what Quercus provides. This is due the execution model of the output application which is compiled rather than interpreted. Only for a select number of runtime functions used by nWP (like the regular expression ones) we are using the Quercus library for convenience reasons. For instance, in the case of regular expression, for regular migration projects we adjust the regular expressions to be Java compliant and use the java.util.regexp library in the migrated code. This did not happen yet for nWP, but it will at some point. Additionally, there are 2 or 3 places in the code where still some small PHP code blocks are evaluated using Quercus - a functionality inherited from the original PHP code. Again, the usual way of dealing with this is the rewrite of those chunks to pure Java - automated translation cannot address such cases.
    However I'm almost 100% sure that you lose a lot of the extensibility of WordPress, which makes it such a powerful platform (you can't override the functions, as they are no longer in the global namespace).
    From our point of view, the only relevant extensibility points we did lose are the plugins and themes. But I already mentioned that we want to replace these with OSGi bundles. The physical overriding of functions the PHP way and similar practices aren't really something that we would like to allow in nWP.
    I can't imagine why anyone would want to deploy WordPress on Java instead of PHP and not use Quercus, but as a showcase of Numiton tech it's OK. I just wish they'd actually present it as such.
    Conceptually, we don't see nWP as a fork of WordPress. We cannot compete directly with WordPress due to a simple reason: cheap Java hosting is still much more troublesome (shared Web container) and more expensive than the cheap PHP hosting options. That's why nWP needs the attention of Java enthusiast who are willing to use it in a dedicated hosting environment and possibly contribute to its development.
  7. What about the module and theme API? Does it provide the same API as wordpress? is it possible to migrate existing modules and themes also? SS jsptube.com
  8. What about the module and theme API? Does it provide the same API as wordpress? is it possible to migrate existing modules and themes also?
    WordPress features the typical PHP API: the code is the API. There's no enforced access point to the data structures and operations mainly because of the limitations of the PHP language. In this respect, at this point nWP has the same API as WordPress, but we plan to change this. Once the nWP extensions API gets finalized, we plan to migrate selected WordPress plugins and themes to nWP. But until we get there, we could use everyone's input about which of these to migrate. I already started a topic for this on the development forum: http://www.numiton.com/forum/viewtopic.num?t=33 so please feel free to share your opinions.
  9. I can see the use[ Go to top ]

    Nice job - I can see the use of it when perhaps someone wants to integrate inside a blogging engine their own Java app.
  10. Re: I can see the use[ Go to top ]

    Nice job - I can see the use of it when perhaps someone wants to integrate inside a blogging engine their own Java app.
    Unfortunately tight integration with a third-party application can only be achieved if the application's license is GPL compatible. nWP is distributed under the GPL license because it is a derivative work of WordPress (also GPL licensed).
  11. database[ Go to top ]

    I see from the nWP web site, that you mention MySQL as required. I have not reviewed the code nor do I know PHP that well, but does it have a DAO layer, thus we can 'build' a module for say SQL Server and/or Oracle?
  12. Re: database[ Go to top ]

    I see from the nWP web site, that you mention MySQL as required. I have not reviewed the code nor do I know PHP that well, but does it have a DAO layer, thus we can 'build' a module for say SQL Server and/or Oracle?
    A valid point indeed since nWP is tighly coupled with MySQL. I started out by filing some feature requests in the SourceForge tracker: - Extract the data layer - Add support for Oracle databases - Add support for SQL Server databases - and, optionally: Use an object-relational mapping framework I think that in the comments section of these feature requests would be the best to continue these discussions.