Just a short note on how the (automated) laravel conversion is progressing. It took several months to upgrade the converter to the point where laravel would compile, and then begins the process of fixing runtime bugs. It is important to remember that this work is adding to the supported features and unit-tests so that these new features are available to every conversion. The end goal is an instant conversion of both laravel and other projects, and the converter is rapidly getting there.
After fixing several minor issues, we have encountered a small hurdle in converting the SPL iterators to Java. Normally, the runtime library can access PHP classes using a special bridge between Java and PHP, but iterators in PHP are handled separately than classes and functions. Additionally, some iterators such as RecursiveIteratorIterator and FilterIterator classes rely on the ability to call into user-space code. It is a hard rule for the Runtime Converter Library that any class or function that needs access to user-space code must be implemented in Java. Porting a function or class from PHP's source code (or documentation) to Java is not hard and in theory needs to be done anyways.
RecursiveIteratorIterator Java Implementation
The RecursiveIteratorIterator class was quite a challenge to implement. We first implemented it from PHP code we found and ran through the converter (recursiveiteratoriterator.inc). That code was full of bugs (from the PHP source, not from Java), but it was fixed into something usable. Ultimately, though, we needed 100% accuracy for this code due to the needs of our new "Tracer" project. To do that, we abandoned all the work that was done for the first version and ported the code directly from PHP-SRC (spl_iterators.c). It is a continual surprise what a reliable path it is to convert code from a language like C to Java.
Runtime Converter Tracer
The "Tracer" project is something new for the runtime converter. When we converted the PHPUnit project, we relied mostly on stacktraces to fix runtime bugs, but sometimes the stacktraces were secondary effects and in any case, they eventually disappeared entirely. For those cases, we relied on Xdebug and IntelliJ to manually step through the PHP code and the Java code at the same time. This was sufficient to find bugs and get the successful PHPUnit test we blogged about.
Instead of manually using the debugger, we have come up with the "Tracer" project which uses Java instrumentation to trace the control flow of the converted application while reading from a trace.xt file produced by PHP's Xdebug extension. We check the stacktrace, argument count, argument types (including string + array lengths), and return type. It was not easy, but it has proved reliable and has led to the repair of many bugs and to the SPL iterators project. The script that we are currently testing contains 11,000 function calls and we have sofar validated about 1,400 function calls.