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 product Quercus PHP - the port of a PHP interpreter along with libraries in Java. And now, once again looking at the almost ready architectural layout of my engine for browser-based online games, I noticed a detail that had escaped me. After all, I was going to use the popular and powerful Zend Framework framework , launching it, of course, on top of QuercusPHP (I’ll start to tell more about the architecture of the engine after the new year). And, as you know, it is quite demanding of various extensions and modules - in one project that I am doing now, using only Zend_Search_Lucene, I met with the need to connect previously unused extensions. This means that there may well be a situation that this platform will not support all the necessary functions for the operation of the Zend Framework. Browsing Google about compatibility did not give anything definite, so it was decided to devote a couple of hours to my own research.



First about Zend Framework. In the special section of the manual , all the necessary modules are listed and specific dependencies between the modules and classes of the framework are indicated. There are two types of dependencies - Hard, when some classes or the entire framework are heavily 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, it is emulated using a PHP code.



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



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

')

Using the PHP function get_defined_functions, I first obtained a complete list of implemented PHP functions, which turned out to be 1342 in Quercus, along with several service and specific ones for it, for example, Java and several with the prefix resin, as well as the Quercus module. By the way, it is similarly necessary to assemble 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 the modules (extensions) implemented in the environment, because manually matching the functions and modules is, let's say, the occupation is still that. The manual found a function, 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 on 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 realization of all the functions of each module; this will probably 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 (as long as I wrote, I decided to investigate the source code, the question is cleared - everything seems to be implemented there). It was pleasantly pleased that the APC cache was implemented “from the box”, however, this was especially emphasized on the site (I’m dreaming - I’d like to introduce support for serious cache, and even distributed and persistent, like EHCache or JBoss cache). The mb_string module is present, although its practical value, it seems to me, is only in API compatibility, because unlike conventional PHP, QuercusPHP has full support for UTF inside right now, in this case, what is expected in PHP 6 is already implemented. But to enable, you need to set options in the config (or rather, unicode.semantics and script-encoding). I was pleased that the list of modules contains the Memcached extension, however, the detailed view didn’t have a list of functions - it’s possible that the function of obtaining a list of implemented methods is strange because the API source code is present.



Now it remains to find out what is and what is missing from the list of dependencies for the Zend Framework. In the test script, I have two arrays, in one there is a list of modules that QuercusPHP has, 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 binary data operations. 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 implements the functionality itself. And in general - if you already have a Java platform, use native Java Lucene, it has more functionality, and there will be a significant gain in speed.
• The 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 important enough, without them, the attractiveness of ZF is generally greatly reduced. However, 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 gets the Dom object from SimpleXMLElement. But the SimpleXML module is fully implemented and supported. I think that manually writing this function on PHP will not be difficult, thus getting rid of dependence. Those who know Java can go even further and add this module to the engine itself, the benefit and the source text is and its structure is quite simple and understandable.
• The libxml library is already more complicated, it also depends on a number of system functions, the same Dom module and SimpleXML, although how it is implemented without this module is interesting. But there is a port of LibxmlJ , or use other parsers, writing a wrapper for the missing functions, especially since, apparently, everything is already there for working with XML, differing only in specific APIs. Oh, with what, and with XML, Java seems to have no problems. 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 data type from an HTTP request is required only by the Zend_Http_Client module, which is quite specific and, I think, is rarely seriously used. And in the module there is only one function, I think, it will be easy to write a wrapper using the sources of QuercusPHP.
• The posix module is required for Zend_Mail and probably the only thing that is difficult to transfer to java, however ... If you search well, then there are several projects that transfer the POSIX-API to Java (for example, this one or Easy Posix Toolkit ), especially since everything is not necessary, but only what Zend_Mail requires. Although, probably, the best option would be to rewrite the Zend_Mail module in order to get rid of the dependency or even just not use it at all. And, by the way, it is not so difficult to rewrite it - the dependency is only on the posix_getpid function, and there is a workaround code in the code if there is no such function.

And so, they proceed from all this, we can conclude that only Dom / libxml is a serious obstacle, the rest is either automatically managed by the framework itself, or it can simply be replaced by more advanced counterparts, 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, and even better, writing a component that implements the interface from ZF, and using Java Lucene internally. But this is serious work, sometimes it is better to use something like Solr.



In principle, there is nothing impossible to run any third-party applications and frameworks on QuercusPHP, even such powerful and complex ones like Zend Framework, but it requires a balanced approach and dependency analysis. Digging into the source code of QuercusPHP, even I, possessing mediocre knowledge of Java, concluded that, if necessary, it is quite simple to extend the API, 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 completeness of the functions and compare QuercusPHP and the binary version of PHP 5.2.8 with the same set of extensions.