Thursday, April 15, 2010

Java versus PHP

If you exclude C and its child C++, the most popular programming languages in the world are Java and PHP, which power most of the dynamic web. I have working experience with PHP and for academical purposes I am deepening my knowledge of Java, thus I'd like to point out similarities and key differences between these two languages. Every language has its pros and cons, so there's no absolute winner here.

Java was originally developed at Sun Microsystems in 1995, as part of the Java platform. Java applications are compiled to an intermediate bytecode which is run by a virtual machine. While originally intended for client software and in-browser applets (with the motto write once, run everywhere), Java is now a key infrastructure for many web applications.
PHP was born in the same year, and it was instead specifically created for the web, as a server-side scripting language to embed in html pages. It has evolved through 5 major versions to became one of the most popular web programming languages, thanks also to shared hosting services, which are particularly simple to set up for PHP applications and drive down their operational costs.

Java is built over static typing: variables must have a declared (possibly polymorphic) type. Thus, it is commonly judged as verbose, although the verbosity isn't necessarily linked to static typing.
PHP uses dynamic typing instead: variables assume the type of the value currently contained in them, and can change their type to satisfy implicit casts and conversions. This approach is prone to errors which would be detected by a compiler, but unit tests are a wonderful substitute for compile-time checks in dynamic languages.
Note that both languages have primitive types: Java because of the performance problems of wrapping integer and character variables in objects at the time of its creation in 1995, and PHP because it wasn't originally thought as an object-oriented language.

Object-oriented programming
PHP 5 borrowed its object-oriented paradigm from Java, which is the standard implementation of an object-oriented language today. After the release of PHP 5, a key point in the introduction of a serious object paradigm, PHP is evolving towards oop and has borrowed more from Java products: Doctrine 2 is an object-relational mapper inspired by Hibernate and JPA; phpDocumentor is built on the example of Javadoc; PHPUnit is one of the xUnit products, which derive from the original JUnit.

Execution model
PHP classes, functions and data structures, when they do not employ external infrastructure like caches or databases, are created in a script and they are garbage-collected at the end of the request. Java applications are instead kept in memory between requests, and the architecture of these two kinds of applications if fundamentally different - though, I would not say one model is superior to the other one. PHP pulls in execution only what it needs, and it pays back with the inability to run periodical tasks such as cron. Java applications can start multiple threads, but their management is much more complex, from the compiling phase to the deployment which includes servlets reloading.

Infrastructure and web
PHP is simple to deploy in its basic form (.php scripts), but this means that increasingly often the average developer has to use frameworks which builds standard infrastructure features over the simple PHP interpreter. Ironically, these framework are similar to Java ones; for example Zend Framework's controllers are the equivalent of servlets: classes with a standard constructor that extend a common base class and act on a request object to produce a response one.
Java has less native features built in the language, as it is not strictly oriented to the web, but it has them in frameworks which adhere to a standard, the servlet containers. PHP capabilities are hindered by the absence of standards.
For instance, the web.xml file in WAR packages, which represent a web application, define routes to map urls to servlets. Imagine if PHP had a standard for defining routes that Zend Framework, Symfony and their siblings respected: that seems science fiction.


e.s.t said...

What is Sci-fi for PHP community, for others may be reality ( I wish PHP ecosystem would evolve in this direction...

Giorgio said...

Well, a merge between frameworks is not a standard - if Symfony and Zend Framework were merged, we would have one fewer framework, not a standard for interoperability. At least the autoloading scheme is fairly standard and will become natively supported by SPL.