Interesting that people keep coming back to this issue of PHP on the JVM: project zero, quercus, and likely others.
As someone who works in both PHP and Java, I see pros in both (and cons, of course). The couple of comments in the OP post makes me think he doesn't really 'get' PHP's strengths for what they are.
"You still can emulate the zend php working mode, when each request executes inside isolated environment + hot-reload"
No, it's not 'hot reload' - it's not even 'reload'. It's just 'load', because everything is gone at the end of the request (yes, you could call it reloading, but it's not reloading and replacing an existing internal thing, because that thing is gone).
Rethinking this... yeah, I know why some people use the term, and 'hot reloading' in Java is a 'thing', it ticks me off a bit that people push Java-land mentalities in to PHP to 'fix' things that aren't problems (and yes, there's plenty of problems with PHP, as with almost any language).
"You don’t need Apache or Ngnix to implement web apps on JPHP"
Technically you don't need to for PHP either - there's been a built-in web server for a few versions now, but... it's not marked for production. Given how many people put up nginx or apache front-ends on Java app servers... this doesn't seem to be an issue so much as a benefit - front-end caching/proxy servers provide more benefit than just serving the app directly.
> No, it's not 'hot reload' - it's not even 'reload'. It's just 'load', because everything is gone at the end of the request (yes, you could call it reloading, but it's not reloading and replacing an existing internal thing, because that thing is gone).
And it's not things are gone at the end of the request - it's more like each request has nothing until it acquires it. You have multiple requests in parallel in a modern setup.
This isn't an implementation of PHP, then. PHP strings are binary, and making them suddenly unicode would break much existing code unless there's some hacky workaround in use. Also, UTF-16 is horrible.
...so, it doesn't have PHP's standard set of functions, huh?
As noted below, this doesn't use PHP's normal request model, and apparently now it doesn't have PHP's standard library, or even have the same data types (Unicode strings). Is this really PHP?
Neat idea. I'm far more curious about seeing projects like this implemented on the Graal/Truffle tools when they're closer to ready.
However, I'd be surprised to see this in the wild. There are a bajillion choices today about ways to do web scripting, and IMO PHP is only an advantage if it's really convenient or if you have an existing codebase written in it. The only reason I've ever considered using PHP (or ever seen it used) is because it's conveniently already installed and configured on a server that needs to be used. If you have to set up a new toolchain or server to use it, then why wouldn't you just use a "better" language? If you have an existing project in PHP, and if you all of a sudden need performance or a desktop GUI, wouldn't your time be better spent porting it to a more performant/robust language, rather than adapting it to a new and unproven PHP runtime?
I'd think best use of effort would be getting this to support (and trivialize) writing PHP for Android apps. "Best use" meaning what would entice people to use it.
"Faster applications" won't entice most PHP devs to switch entire stacks/tools and deployment process to shave off a bit of execution time. PHP7 will offer a roughly 100% improvement already in a few months time - the "JVM will be faster" argument just doesn't hold enough weight on its own in 2016.
JPHP can be faster PHP7: http://d.hatena.ne.jp/hnw/20150117, also each version of the java virtual machine becomes faster than the previous 10-30% so and JPHP becomes faster. Thanks to Oracle and OpenJDK community.
I'm not saying it's not faster - I'd expect some (maybe many) JVM scenarios to be faster than PHP. But "PHP is slow" is just not a real world problem for most use cases of PHP in web applications.
Running your business 15-20% faster will not be enough of a compelling argument for people to switch to an entirely new toolchain and way of thinking. I give you Ruby and JRuby as one major example.
Using JPHP as a way to get PHP running on Android, if it's seamless and strong experience, would be something to focus more efforts on, imo.
Every single successive version of the JVM being 30% faster is simply not born out in the real world across the board. I ported JVM web apps from JDK 6 -> 7 -> 8, and didn't see anywhere near those performance increases. Does the JVM improve with each iteration? Sure. So does PHP, and PHP7 is going to be a huge across the board improvement, but I doubt we'll see this sort of doubling of performance from a single release any time soon after PHP7 release.
I have not tested the speed of JPHP on more complex tests. I only tried to test JPHP as a simple web server (via Apache Benchmark) that contains like "echo Hello World" and a few classes, the result was excellent, faster the Phalcon framework, about 3000 req/s. The results of this testing will publish later.
The other area where JPHP could come in handy is large scale hosting of multi-tenant services - wordpress, magento, etc.
If you can run that code well, and at a significant speed improvement to show savings at scale, there's something to be had there, but again, with PHP7 coming out, I think it'll be hard to get as much of a speed benefit as you'd need to make it marketable. But maybe that's not your purpose anyway.
If it sounds like I've been bashing you or the project, apologies; it's a neat idea - I like to see hacker projects like this, just not sure where it'll go long term.
As someone who works in both PHP and Java, I see pros in both (and cons, of course). The couple of comments in the OP post makes me think he doesn't really 'get' PHP's strengths for what they are.
"You still can emulate the zend php working mode, when each request executes inside isolated environment + hot-reload"
No, it's not 'hot reload' - it's not even 'reload'. It's just 'load', because everything is gone at the end of the request (yes, you could call it reloading, but it's not reloading and replacing an existing internal thing, because that thing is gone).
Rethinking this... yeah, I know why some people use the term, and 'hot reloading' in Java is a 'thing', it ticks me off a bit that people push Java-land mentalities in to PHP to 'fix' things that aren't problems (and yes, there's plenty of problems with PHP, as with almost any language).
"You don’t need Apache or Ngnix to implement web apps on JPHP"
Technically you don't need to for PHP either - there's been a built-in web server for a few versions now, but... it's not marked for production. Given how many people put up nginx or apache front-ends on Java app servers... this doesn't seem to be an issue so much as a benefit - front-end caching/proxy servers provide more benefit than just serving the app directly.