Zend Framework and Quercus PHP Compatibility Study

caucho-white I have long been interested in joining the world of Java and PHP, in particular, with the help of the wonderful Quercus PHP caucho-white product - the port of the PHP interpreter along with libraries in Java. And now, once again looking at the almost ready-made architectural layout of my engine for browser-based online games, I noticed a detail that had 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 (I’ll start talking about the engine architecture in more detail 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 manual all the 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, it is 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 get_defined_functions PHP 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 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. There was a function in the manual, get_loaded_extensions , which, similarly to the one 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 come in handy:

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 carried out 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 has been 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, this 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 was no list of functions - it is 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. 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 , 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. Along 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 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 addiction. And those who know Java can go even further and add this module to the engine itself, since there is good source code and its structure is quite simple and clear.
    • The libxml
    • library is already more complicated, and 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 you can 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 that 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.
    • Module posix required for Zend_Mail and probably the only thing that is difficult to move in java, but ... If you search well, there are several projects that carry POSIX-API in Java (for example, this one or the Easy the Posix Toolkit ), the more that we not everything, 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, rewriting it is not so difficult - it depends only on the posix_getpid function, and there is a workaround in the code if there is no such function.

    And so, based on 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 inside uses Java Lucene. But this is serious work, 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 such powerful and complex as the Zend Framework, but it requires a balanced approach and dependency analysis. Having rummaged in QuercusPHP source codes, 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.