Comparison of Java and PHP for Web Applications

No other language has been causing controversial discussions for a long time as PHP. The codecentric GmbH has specialized in Java, so we get some requests for migration of PHP applications.

This involves often the question of whether Java is better than PHP, which is actually not the main problem. Both in Java as well as in PHP, there are frameworks, designed to create Web applications. Frameworks can of course offset drawbacks of language, but also deny benefits of languages.

To understand the comparison of Java and PHP we must go back in time to about the year 2000. Java brought with Servlets and Struts first concepts for Web applications, but to create, configure and deploy them was very complicated. With the boom of the Internet, a new developer community grew, which quickly learned HTML. But pure HTML limits the possibility of interaction and CGI-Perl scripts were cumbersome and difficult. PHP, however, offered an elegant and simple way, if we wanted a date in a web page, we renamed “.html” to “.php” and inserted where wanted <?php echo date ()?> . On Apache Webserver, which already was prepared for PHP, the new file worked out of the box.

Although in Java Server Pages the ability to use scriptlets also did exist, this was frowned upon as unclean. Instead, the Java community advocated the use of components. In my opinion, a critical factor for the categorization of Java as “Enterprise”.

For Internet applications a beautiful design is more important than a functional, as it attracts more customers. While HTML built in Dreamweaver or Front Page by the designer could be easily expandable with dynamic functionality by PHP developers, Java component oriented frameworks could not really work with it. PHP could enrich design with functionality. In Java, however, one had to beautify the functionality.

But in recent years both sides improved. Java reduced the complexity, frameworks like Tapestry or GWT, permitted by templates created by designers. PHP learned with version 5 useful object orientation and frameworks such as Zend or symfony brought design concepts to PHP developers. Also additional libraries of Java found correlation to PHP. For example the PHP ORMs Propel and Doctrine.

From today’s point of view also offer Java and PHP similar functionality. Nevertheless, other aspects are to consider:

  • Stability
    PHP has in my opinion, significant weaknesses. The procedural backward compatibility, no real deprecation mechanism, a mess semi platform independent libraries and functionality are just some of the issues the PHP. PHP lacks a clean cut, which the PHP planned to do with version 6.
    Java, however, has a clean platform independence and a fairly well-defined number of core libraries with appropriate quality standards.
  • Performance
    While Java was formerly often described as slow, today’s JVMs are highly optimized for speed, while the script languages, including PHP, still struggle with this. For example a first usable garbage collector will be shipped with PHP 5.3. Also other optimizations were moving very slowly into PHP Runtimes. This might be due to the fact that PHP in contrast to Java restarts the VM after each request, which of course brings additional performance problems. For example for each request session data has to be read from disk. Although there are solutions in PHP (MemCache, APC) these are rarely and partly still heavily in development.
    Interestingly, this drawback makes scaling of PHP applications fairly simple. As completely separate requests can be processed, additional hardware results in relatively linear improvements in the capacity of the server. On the Web, the focus is rather on the number of requests, not directly on the exact duration of an individual requests.
  • Choice
    Ideally, you never will re-invent the wheel. It makes sense to look for already existing solutions. Both in PHP, as well as in Java, there is a lot of modular software, partly with free, partly with non-free licenses. However, PHP modules expose significantly more problems than those written in Java. For example, some PHP module developers invented own concepts (e.g. Zend Loader was created by Zend as a substitute for packages) or the modules are only optimized for a framework (like symfony plug-ins).
    Java is, especially through the “complicated concepts” such as Class Loading and packages, better prepared for modularization. Due to better tool support (Ant / Maven, Javadoc, JUnit) Java Frameworks have easier to install, better documented and tested artifacts. However PHP tools for these tasks are also on the rise (pake / phing, PHPDocumentor, PHPUnit / lime).
  • Integration
    Integration is certainly the strength of Java. On the one hand, Java itself is almost “Industry Standard”, on the other hand, there are many standards implementations in Java. If a PHP Web application should communicate with a specific protocol, the selection of libraries is rather limited. Even worse, implementations are either only partially implemented or very rudimentary (such as Zend OpenID). Integration of PHP applications with other services usually happens through the database layer.
  • Developer know-how
    Even 20 years ago, Frederic Brooks searched for the “Silver Bullet” and did not find it. In his article he came to the conclusion that software design, problem formulation and the capabilities of the developers are far more important than tools or languages. Therefore, it is certainly a good idea to implement a website by a designer with knowledge of PHP with a state of the art PHP Framework. If it would be a Web front-end of a Java EE backend application Java would be the obvious choice.

However developer knowledge should not hide the fact that some technological hurdles can be overcome only with certain technologies or other languages. So consulting an expert with specific skills makes much more sense than to give it a try with inadequate tools.

So I conclude that Java is still the better choice for many projects. For smaller projects that can be isolated scripting languages might reach the target faster. As a compromise you might give Groovy Grails a try?

  • Facebook
  • Delicious
  • Digg
  • StumbleUpon
  • Reddit
  • Blogger
  • LinkedIn
Fabian Lange

4 Responses to Comparison of Java and PHP for Web Applications

  1. Pingback: Medieval Programming

  2. pcdinh says:

    “Although there are solutions in PHP (MemCache, APC) these are rarely and partly still heavily in development.”

    You must be joking right? Java the same. Any software need evolution 😀 All you need is stable enough and actively developed program

    “However, PHP modules expose significantly more problems than those written in Java. For example, some PHP module developers invented own concepts (e.g. Zend Loader was created by Zend as a substitute for packages) or the modules are only optimized for a framework (like symfony plug-ins).”

    You seems to have little time with PHP so there are something you misunderstand. Zend_Loader is so extremely simple that even a newbie can understand. It is just a followup what has made PEAR. If you know PEAR then you can say: Zend_Loader is just like a coding convention in file naming. No more. The way Spring load Java classes is much more magic, right?

    Your comparison leads to nothing because it is too too basic and contains lot of misunderstanding. E.x: when you say Java has Maven, then you can think of its complexity. More tool, the better?. No. Steep learning curve, more engineers, more budget, more time, more bugs, more problems. That is why Java applications are so expensive and Java projects need a lot of engineers.

    PHP does not need tools like in Java because it is so powerful and simple that it does not require anything beyond PHP itself. Java needs more tools, even more and more advanced tool day by day because it creates more problems than what it can solve.

    “Java is still the better choice for many projects” Yes, so true. I use Java for my own corporate messaging applications. Java is more more powerful than PHP in system programming. However, Groovy Grails and Java are still locked into JVM which is not friendly enough when deploying applications on multi-core servers. Meanwhile Java threads are not efficient as many people think. The statefullness of JVM can not balance the Java power in web applications in comparison to PHP ones, which are cheaper to write, cheaper to customize and deployed.

  3. Belial says:

    Ich sag’ mal, egal wie stark sich das PHP-Team in die Weiterentwicklung von PHP rein hängt, egal wieviele Verbesserungen sie dort rein bingen, egal wieviele Sicherheitslücken sie Schliessen, PHP wird stets hinter Servlet-Containern und .NET-Frameworks herhinken, solange sich die Kollegen, welche dann in PHP entwickeln sich diese neuen Vorzüge nicht zu Nutze machen. Ich z.B. kenne keine einzige Web-Anwendung, bei welcher z.B. der “Safe-Mode” eingeschaltet sein darf. Zum zweiten: “register-globals” und ähnliche. Zwar halten sich inzwischen sehr viele professionelle Anwendungen an diese Konformität, jedoch gibt es immer noch zu viele unabhängige Modul-Enwickler für diese Anwendungen, die sich nicht dran halten, was das Wiedereinschalten von “register-globals” erforderlich macht. Aber okay. PHP mag ja für “Hinz und Kunz”-Anwendungen genügen, was man unschwer an dessen Verbreitung erkennen kann. Aber von Professionalität ist PHP meines Erachtens noch sehr sehr weit entfernt. Warum sind denn wohl JSP/Servlets und ASP/ASPX nicht so verbreitet und warum sind diese Anwendungen um ein vielfaches teurer? Liegts vllt. an dieser simplen “Friss oder Stirb”-Mentalität, welche sich bei PHP-Entwicklern unmerklich einbürgert, weil PHP aufgrund seiner Simplizität diese schlicht zulässt?

  4. Nice article. A good comparison between Java and PHP for deploying web applications.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>