

JPHP – an implementation of the PHP language and runtime - dim-s
http://jphp.develnext.org/archives/20

======
mgkimsal
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
> 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.

------
TazeTSchnitzel
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
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
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?

------
mgkimsal
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
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.

~~~
mgkimsal
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.

~~~
thawkins
PHP already runs on android, there at least half a dozen PHP runtimes in the
play store. Its just standard PHP recompiled to run on ARM.

------
jtreminio
> 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)

------
pan69
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)

