Migrating from the PHP/Java Bridge to the Zend Java Bridge

At work, I’ve been evaluating the Zend Java Bridge (part of the commercial Zend Platform) as an alternative to the open-source PHP/Java Bridge. Our theory is that the Zend version may be more production-class (i.e. stable, secure, supported, and such), but we still want to make our code operable with either bridge so our user community isn’t locked into a commercial product. So far, it’s promising. Zend Platform sits on top of Zend Core — which bundles PHP, Apache and MySQL — making installation a snap, and the Platform management interface is a breath of fresh air, no more sifting through four separate directories of log files to figure out what’s going wrong. When things do go wrong, the Platform will wrap up all necessary support artifacts for submission to Zend in a trouble ticket — and their technical support response time has been admirable so far (at least for the easy problems).

Our code is still interoperable, but there have been some sizable snags with Zend. Mostly it’s things I’ve gotten used to after two years of wrestling with the PHP/Java Bridge that aren’t available with Zend. I’ll document them here (and their workarounds, if possible) as I come upon them.

No way to dynamically load libraries

Sometimes, especially during development, you don’t have a fixed set of JARs to enshrine in a system variable. The PHP/Java Bridge lets you programatically load libraries with the java_require("jar1;jar2;jar3") command, or will automatically load all the JARs in a configurable “extra libraries” directory. Zend, on the other hand, makes you write out your classpath in full. On Linux, you can modify the script which starts your Java Bridge by adding the name of each extra JAR it should load. On Windows, you need to change the CLASSPATH environment variable. Neither way is particularly user-friendly.

On my Windows development box, I’ve cheated a bit, and copied all my JARs to the JRE’s \lib\ext\ directory. I figure that’s okay for the time being. On our production systems, the code will be stable, so we can use a formal classpathing method. In any case, the Zend folks have said that this month’s new release of the Java Bridge will allow dynamic library loading.

No language construct to access class objects

The PHP/Java Bridge has a simple new JavaClass("java.util.Arrays") command that returns a class object, rather than an object of the class (like new Java("...") does). Zend simply does not. The workaround I’ve developed seems to work fine:

function getJavaClass($classname) {
  $c = new Java("java.lang.Class");
  return $c->forName($classname);
}

Can’t instantiate a javax.xml.datatype.DatatypeFactory

I get a bizarre exception when I try to instantiate this class.

java.lang.IllegalAccessException: Class com.zend.javamw.q can not access a member of class javax.xml.datatype.DatatypeFactory with modifiers "protected"

The boys at Zend are still looking into this one. If they can’t resolve it, we’re back to square one.

Update - October 10: Zend has reproduced the problem and logged it as a bug.

Problems with iterators

I knew off the bat that the Zend Bridge wouldn’t handle iterators as nicely at the PHP/Java Bridge (which lets you use any java.util.List from within a PHP foreach), but for no apparent reason, Zend won’t even give me an iterator or let me use any other List method in certain circumstances. I was able to create a simple reproduction of the problem using a com.sun.xacml.PolicySet:

$uri = new Java("java.net.URI", "foobar");
$alg = new Java("com.sun.xacml.combine.DenyOverridesPolicyAlg");
$tar = new Java("com.sun.xacml.Target", null, null, null);
$policySet = new Java("com.sun.xacml.PolicySet", $uri, $alg, $tar);
$children = $policySet->getChildren();
$iterator = $children->iterator();

Here’s the error I get:

Fatal error:  Uncaught exception ‘JavaException’ with message ‘Java Exception java.lang.NoSuchMethodException: iterator
java.lang.NoSuchMethodException: iterator’ in java-test2.php:9
Stack trace:
#0 java-test2.php(9): java.util.Collections$EmptyList->iterator()
#1 {main}
  thrown in java-test2.php on line 9

It’s clear that I’m trying to access an EmptyList, which, despite being empty, is still a list, and should still have an iterator() method. (All other methods, like size(), are also inaccessible.)

Update - October 9: Zend support tried to blow me off, saying that my problem “goes out of the limits of Zend Products and PHP,” but I was able to narrow down the problem even more, without any of the XACML libraries:

$class = new Java('java.lang.Class');
$collections = $class->forName('java.util.Collections');
$empty = $collections->emptyList();
$iterator = $empty->iterator();

Same NoSuchMethodException as before.

Update - October 11: This has finally been acknowledged as a legitimate bug, and it turns out it’s probably caused by the same underlying issue with their Java Bridge Connector as with the DatatypeFactory bug above.

Sparse documentation

From the start, I found the PHP/Java Bridge’s documentation frustrating. It wasn’t always clear what information applied to which version of the bridge, and there was never enough detail to make me comfortable. Fortunately, the basics were there, and the bridge’s creator was always helpful over the support mailing list.

The entirety of Zend’s bridge documentation is fourteen very lightweight pages in the Zend Platform User Guide. Of course, the code examples they give make it clear why they don’t feel more detail is necessary: they expect their users to be accessing EJBs within their existing Java infrastructure… simple getting and setting.

It may be that what we’re doing is pushing the envelope of PHP/Java symbiosis, but if the open-source rival can satisfy our needs (programatically, at least), why can’t the heavy-duty commercial system? Stay tuned for updates.

This entry was posted on October 01st, 2007 and is filed under PHP. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response or Trackback from your own site.