PHP on the JVM?

Bookmark Blog Post

	del.icio.us
	Digg
	DZone
	Furl
	Reddit

Gary Horen's Blog | February 13, 2007   2:40 PM | Comments (3)

We've seen a lot of interest in integrating PHP with WebLogic Server over the past few months. The option of using the Zend PHP engine, with one of the two available PHP-to-Java bridges has always been available (see my recent article on working with PHP Java bridge technology here). We think this is a good short term solution to the problem, but because the bridge is work to understand and configure, and presents some management challenges, we have spent some time working on a JVM based integration of a PHP engine.

That project involved experimenting with technology from a third party, with whom we failed reach an agreement about terms for distribution. We still remain excited, though, about a byte-code implementation of the PHP engine. Similar efforts are going on with other dynamic languages, e.g. JRuby, JavaScript, Groovy, and Visual Basic. The most glaring omission in that list is surely PHP, since it's the most popular dynamic language being used right now by Java EE developers.

What would the advantages of a JVM-based PHP engine be? At first glance there are several:

• Easier installation and configuration than the current PHP-Java Bridge solutions, and less moving parts for customers to manage.
• Reuse of the JEE Server infrastructure for management, clustering, failover, database connection pooling, etc.
• Performance: since the PHP source would be compiled to bytecode, the JIT compiler would be able to optimize it just like Java code. Furthermore, there would be reduced overhead with regard to inter-language communication with Java code, because no data would need to be marshaled across address spaces.
• The tuning capabilities offered by JRockit's deterministic garbage collection.
• Security: in a managed execution environment like the JVM, problems like buffer overruns don't exist.
• New possibilities for tooling: a JVM implementation would make it possible to create tools like a cross-language debugger that allowed breakpoints in both PHP and Java code in the same session. With a little tweaking, you could also use existing Java profiling tools with PHP code, and for profiling across languages.
• The JVM could serve eventually as a common integration point for a number of different languages, like the Microsoft CLR does: PHP, Java, Ruby, JavaScript, Python, etc.

Here is a glance at what a roadmap for such a feature might look like at the macro level:

• JVM-based PHP engine, with limited library support in the first release, but growing quickly over time. Library module support would be released piecemeal, since the new functionality would be additive (i.e. will involve no changes to the core engine).
• Workshop based tooling: cross-language debugging, based on the Eclipse PDT project, and profiling, taking advantage of the JRockit Mission Control Suite of tools.
• Further work integrating PHP with other dynamic languages.
• Possible further work integrating PHP better with JEE frameworks like Struts and ORM technologies.

Would any of you WLS customers be interested in being design partners for such a feature? It would be great to have you on board! Email me at ghoren@bea.com.

Comments

• I think they've made it less dependent on Resin - e.g. it runs on Glassfish. It's GPL, which may limit its appeal to some.

  Posted by: paulhh on June 25, 2007 at 3:11 PM

• Quercus is a proprietary implementation of PHP that is tied to internal implementation details of its associated app server. It's not possible to use it for this project because it can't be run on any other server.

  Posted by: gary.horen on February 14, 2007 at 2:01 PM

• What about Quercus?

  Posted by: headius on February 13, 2007 at 5:55 PM