PHP on Java: Best of Both Worlds?
There appears to be a convergence of events that is increasing the profile and relevancy of PHP in the Java/JEE development community. Both IBM and Coucho have been making significant investments in the PHP on Java architecture. Sun, Oracle, and BEA have also all announced PHP integrations and/or partnerships with Zend in the past 18 months. We spoke with Jerry Cuomo (WebSphere CTO at IBM) and Scott Ferguson (the man behind the Resin Java Application Server and more recently the Quercus PHP engine) to find out where they saw PHP fitting into the Java space. IBM's most visible investment so far in the Java/PHP hybrid stack is Project Zero, a new web framework that IBM is developing which supports both the Groovy and PHP scripting languages. When asked why IBM chose to support PHP in Project Zero, Jerry had the following to say:
Jerry: Three words... Agility, Content, Educated. Yes, PHP is our ACE.
- Agility. J2EE applications are optimized for "enduring value"... A.k.a. they are written to run forever. PHP scripts are optimized to "be running by this Friday". A.k.a., they allow code to be written quickly and compactly, which is fine for many situational applications that spring up.
- Content. We call it "programming by cut-and-paste". With PHP there are tons of assets available on the net. It is rare that you ever write something from scratch. Search, cut, paste and away you run... (This brings us back to Agile).
- Educated. It is really easy to self-Educate with PHP. It is easy for many people, even for people without formal computer science education, to write PHP scripts. For example, the complexities of Memory management and threading are not at the forefront of your mind when you are scripting in PHP. And back to my last point, much of the time you are modifying someone else's code.
Caucho's approach is different than IBM's. When looking at Project Zero, it feels like a Java/Groovy framework that also happens to support the PHP language. Quercus, on the other hand, is a full implementation of the PHP language that would compete with implementations like mod_php. It is an impressive implementation. The fact that the the PHP interpreter is written entirely in Java not only enables them to provide native Java/PHP integration, it also allowed them to leverage the power of the JVM to provide impressive levels of performance and security. Here is what Scott had to say about how Java enabled Quercus to stand out from and engineering standpoint:
Scott: The threading, caching, and pooling capabilities of the Java platform are critical to the success of Quercus. Most of the Quercus library implementations are wrappers around Java capabilities. For example, the database access is a wrapper around JDBC. Because the Java platform already provides a tremendous foundation, Quercus gets all those capabilities for free.
Also, the reflection, memory management, JDK 1.5 annotations, and dynamic compilation/classloading are needed to make Quercus work well. Although we can't use clever pointer programming like the C PHP uses, we could use clean OO design and rely on Java to handle the memory issues.
And profiling, of course. Quercus automatically gains the benefit of the JVM's cpu and heap profiling. Since the compiled Quercus functions are Java methods, we can see exactly which pieces are slow or consuming memory.
Rapid, lightweight web tier frameworks with broad adoption has been an elusive goal Java Platform, and we asked both Jerry and Scott if they were investing in PHP runtimes because they felt that the Java community had given up on using Java based frameworks for efficient web tier development and were instead moving towards dynamic scripting languages for that tier. They both thought that my question overstated the trend away from Java, and they described the balance between Java and PHP utilization this way:
Jerry: "Shifting a way" and "giving up" are a little too strong. I like to say we are "giving Java an Executive promotion". She has earned it. This is not a binary matter. In addition to its current role, I believe Java will be able to act as the "system programming" environment for these dynamic scripting languages. Akin to the relationship that Java has with C/C++. Now, Java (and the JVM) need to grow (and shrink) in interesting ways to support DSLs. For example, Today's Java is optimized to run long running applications and processes. DSLs are short lived, coming and going frequently.
Scott: We don't recommend abandoning Java entirely. Java is fantastic for the underlying infrastructure of a web application. Frameworks like Spring, JPA/Hibernate or tools like Coherence, and testing frameworks like JUnit are far superior to anything in the scripting world. In addition, the application-level caching, service, event, and threading code, stuff that's never made public, is far better done in Java. If you look at a PHP application like Mediawiki (wikipedia), it's obvious how the lower-level code could be better written in Java.
Where Quercus/PHP succeeds is in the presentation layer and as scripting for cases where more flexibility is required. None of the Java presentation frameworks like JSF, JSP/JSTL, Struts, Velocity, have the flexibility or library capabilities of a full scripting language. Many of the frameworks, like JSP/JSTL are partial language implementations. Why not just use a full scripting language, with a large library and which has been proven successful for huge numbers of sites.
So we think the combination of Java (for the backend, model and underlying service) and PHP/Quercus for the presentation layer and any scripting (e.g. replacing BPEL), is the best choice.
We also asked them to compare/contrast PHP with languages like Ruby and Groovy. We asked Scott to tell us why he wrote a PHP instead of a Ruby interpreter:
Scott: We wanted to choose a scripting language that had already proven itself in the web development community, and PHP is the dominant scripting language. Currently, Ruby is still an experimental language. There are a lot of things to like about the Ruby language, but there are some concerns too. Ruby uses a number of advanced language constructs like closures and continuations, and in that way resembles Scheme. Personally, I love those capabilities, but have learned the hard way that a large number of programmers are intimidated by them, which can harm the adoption. PHP is like BASIC, anyone can pick it up. I'm rooting for Ruby. I'd love to see it succeed, but when we're choosing how to spend our limited time, we just need to wait and see.
We asked Jerry if he thought that PHP would continue to grow going forward, especially in the face of Ruby on Rails. We also asked if the Object Orientation introduced in PHP5 made PHP more relevant for frameworks like Project Zero. Finally, since Project Zero supports both Groovy and PHP, we asked Jerry to recommend either Groovy or PHP for a new Project Zero developer that didn't know either language:
Jerry: PHP is not the dynamic scripting language that Ruby or Groovy are.. This much is true. However, these languages have a long way to go before the most popular applications in the world get written on them (think Wordpress, PHPBB, etc.). As long as there are extendable PHP applications, new people will be learning PHP. Given that most of the tools popular with collage students are written in PHP, there will continue to be a new breed of PHP programmers.
Now, with that said, it's not clear that PHP will actually grow... It's pretty big already and there are many other takers out there, with more syntactically cleaner and more compact languages. We will see.
But, this (i.e., the language features of PHP, w or w/out OO) is not why PHP is included in Project Zero. It's there because of ACE. ... If you are a Java engineer, Groovy is the way to start. Java engineers are longing for the agility charateristics that Project Zero provides. We want to say that you can have your "cake and eat it too". Or should I say, you can have your "Java and do Dynamic scripting too". However, if you don't have a strong Java background, and/or if you are looking to leverage pre-existing Content on the Web- PHP offers the means to create agile applications.
Resin solves a political problem, should we use php or java? Both!
One example we did is php (instead of jsp) talking to back end java ibatis.
The JVM is an excellent execution environment
And, a common runtime environment underneath all of them makes it possible for stuff like Terracotta to work underneath the language of your choice (e.g., php, ruby, groovy)
Perhaps between Caucho, IBM, BEA, and ???, we can set some defacto/standards/best-practices in this area.
There is more talk on the PHP, Zero, Java/DSLs topic on
my blog and projectzero.org.
what about PHP native libs
Re: what about PHP native libs
My understanding is that Quercus has re-implemented the PHP extensions in Java. Perhaps they had to write some new Java natives for functionality not already available in Java.
If you follow the links in Jerry's message above, you'll see the PHP interpreter for Project Zero is doing this as well. And we're trying something a bit new; calling out to the existing binary PHP extensions (after recompilation) from Java. The hope is to be able to reuse the functionality.
Both approaches have pros/cons, and both are worthy of exploration. Stay tuned to see how Zero progresses on the native side!
Re: what about PHP native libs
This is interesting . . .
I had put a part of my comparison and analysis on my blog at mytechrantings.blogspot.com/2007/06/php-vs-jsp....
Even after that project these discussions keep coming up again and again.
But reading this gave an entirely new perspective on the topic. PHP on Java! That is wonderful!!!
May be if we can mix and match the 2 in an application we can write even parts of the frontend in JSP and parts in PHP.
My only concern with PHP has always been maintainability of the project. With having major part in Java and the frontend in PHP should make things better.
Will give it a try whenever I get time to.
Ralph Winzinger Nov 25, 2014
John Krewson, Steve Ropa and Matt Badgley Nov 24, 2014