3 ms·

JPHP – an implementation of the PHP language and runtime

26 points by dim-s 12y ago

mgkimsal 12y ago
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.
- TazeTSchnitzel 12y ago
  > 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.
jtreminio 12y ago
> when you plan to support web sockets in your app, you forced to use something else http://socketo.me/ http://socketo.me/ https://github.com/varspool/Wrench https://github.com/varspool/Wrench
mgkimsal 12y ago
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.
- dim-s 12y ago
  JPHP can be faster PHP7: http://d.hatena.ne.jp/hnw/20150117 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.
  - TazeTSchnitzel 12y ago
    Being faster than PHP 7 for a few functions from bench.php isn't very convincing.
    - dim-s 12y ago
      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.
      - mgkimsal 12y ago
        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.
TazeTSchnitzel 12y ago
The features page is interesting: https://github.com/jphp-compiler/jphp/wiki/Features https://github.com/jphp-compiler/jphp/wiki/Features > Unicode for strings (UTF-16, like in Java) 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. > What JPHP does not yet support? > Importing namespaced functions (php 5.6) Surely that's not the only thing unsupported? Then I see this: https://github.com/jphp-compiler/jphp/wiki/Core-Extension https://github.com/jphp-compiler/jphp/wiki/Core-Extension ...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? Edit: oh, I see, it also has standard PHP stuff here (though a lot is missing): https://github.com/jphp-compiler/jphp/wiki/PHP-standard https://github.com/jphp-compiler/jphp/wiki/PHP-standard
- dim-s 12y ago
  JPHP supports binary strings. You are right about zend php runtime functions and classes. One of goals of the project is "replacing the ugly runtime library of Zend PHP with a better runtime library". JPHP is not a replacement for the Zend PHP engine.
dikaiosune 12y ago
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?
pan69 12y ago
Reminds me of Quercus [1]. I tried this many years ago and at the time it seemed to work pretty well. [1] http://quercus.caucho.com/quercus-3.1/doc/quercus.xtp http://quercus.caucho.com/quercus-3.1/doc/quercus.xtp

26 points by dim-s 12y ago

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.

TazeTSchnitzel 12y ago
> 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.

jtreminio 12y ago

> when you plan to support web sockets in your app, you forced to use something else http://socketo.me/ http://socketo.me/ https://github.com/varspool/Wrench https://github.com/varspool/Wrench

mgkimsal 12y ago

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.

dim-s 12y ago
JPHP can be faster PHP7: http://d.hatena.ne.jp/hnw/20150117 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.
- TazeTSchnitzel 12y ago
  Being faster than PHP 7 for a few functions from bench.php isn't very convincing.
  - dim-s 12y ago
    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.
    - mgkimsal 12y ago
      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.

TazeTSchnitzel 12y ago

The features page is interesting: https://github.com/jphp-compiler/jphp/wiki/Features https://github.com/jphp-compiler/jphp/wiki/Features > Unicode for strings (UTF-16, like in Java) 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. > What JPHP does not yet support? > Importing namespaced functions (php 5.6) Surely that's not the only thing unsupported? Then I see this: https://github.com/jphp-compiler/jphp/wiki/Core-Extension https://github.com/jphp-compiler/jphp/wiki/Core-Extension ...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? Edit: oh, I see, it also has standard PHP stuff here (though a lot is missing): https://github.com/jphp-compiler/jphp/wiki/PHP-standard https://github.com/jphp-compiler/jphp/wiki/PHP-standard

dim-s 12y ago
JPHP supports binary strings. You are right about zend php runtime functions and classes. One of goals of the project is "replacing the ugly runtime library of Zend PHP with a better runtime library". JPHP is not a replacement for the Zend PHP engine.

dikaiosune 12y ago

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?

pan69 12y ago

Reminds me of Quercus [1]. I tried this many years ago and at the time it seemed to work pretty well. [1] http://quercus.caucho.com/quercus-3.1/doc/quercus.xtp http://quercus.caucho.com/quercus-3.1/doc/quercus.xtp