Tags: OpenJDK
I have
some web sites that I publish for myself. There's some history to this, but last year I chose the Drupal content management system. It has a great featureset and a large community surrounding it. It is written using PHP and works pretty well.
So... Caucho (the makers of Resin) recently came out with PHP support, and I just ran it through a quick test. Caucho provides a couple tiny examples that show, yup, trivial PHP scripts run. But I wondered whether it would run a serious PHP application, like Drupal.
It works. I made a copy of the PHP for one of my sites, configured the site/default/settings.inc to point to the database for that site, and fired up resin. After a couple issues, I was pleasantly surprised to see it working really well.
First, the MySQL support in PHP doesn't work out of the box. Instead you have to follow
these instructions to install the MySQL Connector/J support in Resins lib directory. Then you set up a WEB-INF/web.xml file to set up a couple connections.
The second issue is that, to make clean URL's, Drupal uses Apache's mod_rewrite engine. But it's unique to Apache, and of course Resin doesn't support mod_rewrite. So the URL's are a bit ugly. Actually I think this is a failing of the Drupal implementation, since they should produce clean URL's out of the box rather than rely on a strange thing like mod_rewrite.
This is an interesting trick ... but does it add anything important?
I guess one consideration is whether this is a better way to run PHP than the interpreter from
php.net? That remains to be seen, and I certainly haven't tested this deeply. It's certainly possible this will be better, since we (Sun) have spent a lot of man-years optimizing the Java VM, and Resin turns PHP scripts into class files. This means that Resin, running PHP, ought to take advantage of that optimization we've done. But the various PHP accelerators can make a similar performance enhancement claim. The flip side to this is, apparently, Caucho's PHP implementation is incomplete.
The big consideration I see is architectural freedom on the part of web application developers.
The one criticism I have of Drupal is its implementation is more than a little screwy. The drupal community is really proud of their "clean architecture", so I know I'm risking treading on the toes of those people. In my opinion they have serious architectural issues.
Application architecture tends to work better when your core "business logic" is a series of modules with clean interfaces, and your user interface makes calls to those clean interfaces. In the case of Drupal it would be really clean if, e.g., there were a "user" object that had functional methods for operating on the user object, similarly the node object and so on. Instead in Drupal you have the "user" or "node" modules and there's a bunch of functions you call that aren't cleanly defined functional methods. There are a number of fairly cleanly defined "hook" methods, but the style is akin to what you'd do in a large C program to stay sane. In other words it's a coding convention.
What's been in my mind for awhile is the potential win that could come from refactoring Drupal's code ... the refactoring would have a core object model written as Java classes, and the PHP part would be a thin presentation layer.
In any case that's what I suggest as the potential big win of using a PHP implementation written in Java.
If you think about it -- the core business logic in a large application probably has a slow rate of change, while the user interface has a rapid rate of change. This distinction really plays to the strengths of both languages. The presentation layer of a web app could be in PHP, allowing for rapid rework etc. The core logic could be in Java, drawing on the rich range of libraries, persistence engines, scalability and so forth that comes along with the Java ecosystem.
Of course the java-php-bridge offers similar potential. Its advantage is it executes the real PHP interpreter, with a hook that allows it to call Java classes. Again, this posting is not a deep analysis.
Source:
weblogs.java.net
