5 things that PHP envies Java for

PHP and Java have somewhat different models of execution, contrapposing shared-nothing processes to resident JVMs. But they have also many similarities, like their object-oriented model.

I've seen many programmers starting to think that Java is old and verbose, and trying to jump on the bandwagon of scripting languages such as PHP and Ruby. But it's not so simple, as these languages are late to the party in many areas. Here are the 5 things that as a PHP programmer I started envy Java for.

Hibernate

PHP models, the M of the overly famous MVC paradigm, are still tied to the databases they use for persistence. It was common, in the first generation of PHP frameworks and ORMs, to only work with Active Records inside of controllers. Even association entities (classes like UserGroup, or ArticleCategory), which exist only for the purpose of mirroring a database table, were spreaded over PHP applications codebases.

The situation has widely improved now: Doctrine 2, which borrows an Api from Hibernate, is catching up. It hides the association tables and the unnecessary association directions for example, simplifying PHP classes where it counts. Impressively, it is the first PHP ORM that does not force your entities to extend a base class.

But we're still runners-up: for example, Doctrine 2 lacks support for mapping of Value Objects in the current version. Doctrine 2 entities are not really tied to database, but the relational model the mapping produces is just a mirror of the object model.

At least, we have now the abstraction of an in-memory Domain Model to work on. Another example of what we do not envy anymore is the PreparedStatement class. Once upon a time we worked with mysql_query() and SQL composed by concatenation, but now we have PDO. PDO is an equivalent of JDBC, with a common Api for each database vendor.

Generics

PHP envies a bit Java generics, but it works very well anyway as a dynamic language.

Anytime we manipulate an array with PHP, we forgot any type checking on keys and values. It's simply an array: it may have 4 MyClass objects and then the 5 is a string.

Java has generics, but often this type system gets in the way: you may want to pass around simply arrays or a DTO-like data structure in a "generic" layer like the application or presentation one, and you're forced to do casts. Where we would need generics, we just omit strict type checking:

<?php
function printList(array $listOfObjects)
{
    foreach ($listOfObjects as $object) {
        // $object could be anything, and getName() may not exist on it. It can even be TRUE or 0
        echo (string) $object->getName(), "\n";
    }
}

It's not really an issue, and in dynamic languages there is usually no type checking anyway. But, every once in a while, $object will be NULL and the script will die emitting a Fatal Error.

Keeping objects in memory between requests

Keeping objects in memory is easy in Java, although both in PHP and Java session variables are serialized, you can keep objects from the database in memory as long as they are out of Servlets, even between HTTP requests (feel free to add a comment on this.)

For example, Roman Borschel (who started Doctrine 2) said he harmlessly keep an EntityManager (Facade of Hibernate) open between requests, only to commit a permanent modification to the database on the last HTTP request. That's a bit out of the stateless paradigm of HTTP, but it is definitely handy when you have an action comsisting of multiple steps and requests.

Java Collection Framework

We need a Set, a List, a Map. I can't tell you how many times I have wrapped an array() in a class.

The associative array, the bread and butter (and glue) of PHP code, is kind of a Map but allows only scalar for keys. The same array construct is also a List when used with numerical keys, but without a contains() method, or any method at all since it is not an object. There is no equivalent of Set built into the language.

Doctrine2, our leader orm, even gets to provide a Collection class by itself in the Doctrine\Common package.

Asynchronous processing

Let's say you want to execute an action, like a heavy UPDATE query on the database, at 14:00 every day. In PHP, we need cron, an external program, to tell us to start that task at the right time. Due to the popularity of shared hosting, where programmer do not have access to the shared crontab, workaround were invented like Poormanscron, which checks at every request if it's the right time to do some work.

Asynchronous processing is simply outside of the picture of PHP, although there are some that use PHP without terminating scripts, like PHP-GTK. But on a website,your PHP script will be executed only if someone calls them, being it a browser or cron.

Conclusions

The resident Java processes are a real advantage in some use cases, although the shared-nothing model is very easy and cheap to run, solving many complications. Some other issues with PHP are due to its late arrival on the object-oriented paradigm.

In the next article, we will look at what Java envies PHP instead. I'm sure some of you will say nothing, but I hope to convince you that on the contrary, PHP is easier to use in many scenarios that runs from development and testing to deployment.