Zend Framework and Quercus PHP Compatibility Study

I have long been interested in combining the world of Java and PHP, in particular, with the help of the wonderful Quercus PHP product - the port of the PHP interpreter along with libraries in Java. And so, once again looking at the almost ready-made architectural layout of my engine for browser-based online games, I noticed a detail that slipped away from me. After all, I was going to use the popular and powerful Zend Framework, launching it, of course, on top of QuercusPHP (in more detail about the architecture of the engine I will begin to talk after the new year). And he, as you know, is quite demanding on various extensions and modules - in one project, what I am doing now, using only Zend_Search_Lucene, I met with the need to connect previously unused extensions. So it may well be the situation that this platform will not support all the necessary functions for the Zend Framework to work. The Google review on compatibility didn’t give anything definite, so it was decided to devote a couple of hours to our own research.

First about the Zend Framework. In the special section of the manualall necessary modules are listed and specific dependencies between the modules and the framework classes are indicated. There are two types of dependencies: Hard, when some classes or the whole framework is strictly dependent on the extension and will not work without it, and Soft, when the extension is used only to increase performance, if functions are not available, they are emulated using the PHP code.

Having manually reviewed the entire list, I selected all the modules except the very exotic ones, such as Oracle database support, and put them into an array of test script.

Yes, to check for compatibility, I decided to use some test script, which, running in the QuercusPHP environment, collects all the information about the available functions and installed modules, and compares it with the list necessary for ZF.

Using the PHP get_defined_functions function , I first got a complete list of implemented PHP functions, which were 1342 in Quercus, along with several utility and specific ones, for example, Java and several with the resin prefix, as well as the Quercus module. By the way, in the same way, it would be necessary to collect PHP with the same modules and check the completeness of the implementation of all functions, but this is the task of the next test.

Next, it was necessary to get a list of exactly the modules (extensions) implemented in the environment, because manually matching functions and modules is, let’s say, something else to do. A function was found in the manual, get_loaded_extensions, which is similar to that described above, displays an array of modules available to scripts. It turned out that the list of extensions in QuercusPHP is quite large - 31 modules. Since the official documentation about the implemented extensions is written only in general terms, I will give a complete list (for the latest version, 3.2.1), it may be useful:

mcrypt, SPL, curl, gd, mysqli, mhash, gettext, json, apc, mbstring , tokenizer, pgsql, memcache, zip, standard, hash, XMLWriter, ctype, xml, bcmath, postgres, PDO, pcre, zlib, session, SimpleXML, Reflection, ereg, iconv, oci8, mysql

I have not yet conducted a detailed study on the degree of implementation of all the functions of each module, probably this will be the next test, but at first glance I was confused only by the SPL module, for which there are only five in the list of functions - spl_autoload, spl_autoload_register, spl_autoload_unregister, spl_autoload_extensions, spl_autoload_functions. So the question of the full implementation of this module remains open (while writing, I decided to investigate the source code, the question is removed - it seems like all the functionality is implemented there). It was pleasantly pleased that the APC cache was implemented “out of the box”, however it was especially emphasized on the site (I’d like to introduce support for a serious cache, even distributed and persistent one, such as EHCache or JBoss cache). The mb_string module is present, although its practical value, it seems to me, is only in the compatibility of the API, after all, unlike regular PHP, QuercusPHP initially has full support for UTF inside now, in this case it already implements what is expected in PHP 6. But to enable it, you need to set options in the config (more precisely - unicode.semantics and script- encoding). I was glad that the list of modules has a Memcached extension, but when I looked at it in detail, there wasn’t a list of functions - it’s possible that the very function of getting the list of implemented methods is strange because the API is present in the source code.

Now it remains to find out what is and what is missing from the list of dependencies for Zend Framework. In the test script, I have two arrays, in one - a list of modules that are in QuercusPHP, in the other - a list of those that are required for ZF. To compare their business is trivial, and at the output we get five modules that are missing:

• The bitset module , which is designed for bitwise operations on binary data. In fact, the loss of this module is not the worst, only Zend_Search_Lucene depends on it, and even Soft, that is, the class independently implements the functionality. Anyway - if you already have a Java platform, use the native Java Lucene, it has more functionality, and there will be a significant gain in speed.
• Dom module , on which many classes already depend, including very useful ones, for example, Zend_Feed, Zend_Rest_Server, Zend_XmlRpc and several Zend_Service modules. Here is the first difficulty, since all these modules are quite important, without them the attractiveness of ZF is generally greatly reduced. Together with the mode, there is a way out - judging by the link where the description of this module is, there is only one function, dom_import_simplexml , which receives the Dom object from SimpleXMLElement. But the SimpleXML module is fully implemented and supported. I think it’s not difficult to manually write this function on PHP, thus getting rid of the addiction. And those who know Java can go even further and add this module to the engine itself, since there is a good source code and its structure is quite simple and clear.
• The libxml library is already more complicated, a number of system functions depend on it, the same Dom module and SimpleXML, although how it is implemented without this module is interesting. But there is a LibxmlJ port , or use other parsers, writing a wrapper for the missing functions, especially since, apparently, everything for working with XML already exists, only the specific APIs differ. Already with something, but with XML in Java there seems to be no problem. But here some manual work and attraction of external libraries are already required. So the first module, which is really needed for ZF, but is missing, is detected.
• The mime_magic module for determining the MIME type of data from an HTTP request requires only the Zend_Http_Client module, which is quite specific and, I think, is rarely seriously used. Yes, and the module has only one function, I think writing a wrapper using QuercusPHP sources will be easy.
• Модуль posix требуется для Zend_Mail и, наверное, единственное, что сложно перенести в java, однако… Если хорошо поискать, то есть несколько проектов, переносящих POSIX-API в Java (например, вот этот или Easy Posix Toolkit), тем более, что нам не надо все, а только то, что требует Zend_Mail. Хотя, наверное, лучшим вариантом будет переписать модуль Zend_Mail для того, чтобы избавиться от зависимости или даже просто не использовать его вовсе. И, кстати, переписать его не так и сложно — зависимость там только от функции posix_getpid, да и в коде есть обходной код, если такой функции нет.

And so, proceeding from all this, we can conclude that of the serious obstacles we have only Dom / libxml, the rest is either automatically bypassed by the framework itself or simply can be replaced with more advanced analogues, since we have the opportunity to work directly with Java classes. First of all, I recommend throwing out Zend_Search_Lucene and using the API directly from Java Lucene, or even better, write a component that implements the interface from ZF and uses Java Lucene internally. But this is already a serious job, sometimes it is better to use something like Solr.

In principle, there is nothing impossible to run on QuercusPHP any third-party applications and frameworks, even powerful and complex ones like the Zend Framework, but it requires a balanced approach and dependency analysis. Rummaging through the QuercusPHP source code, even I, having mediocre knowledge in Java, came to the conclusion that, if necessary, expanding the API is quite simple, so in many cases, if you lack one or two, often trivial functions, it makes sense to write them yourself.

I think in the next study I will take a closer look at the full implementation of functions and compare QuercusPHP and the binary version of PHP 5.2.8 with the same set of extensions.