Slashdot Mirror

There's Quercus a java implementation of PHP. Saw it, bookmarked it, never done anything with it.

Why go through all this effort when they could simply used one of the C-like strongly typed languages is beyond me.

Because they already have a huge PHP codebase. That said, Twitter moved from Ruby to Scala for their back-end; it seems it can be done. I suspect Facebook have more of a lots-of-programmers problem: they all know PHP, and they might not all know, say, Scala.

to creating a PHP-to-Java converter or something along those lines.

You mean take PHP source and translate it into readable, maintainable Java source? That's all but impossible. They're very different languages, and source-to-source translators tend to produce pretty unreadable code when faced with that kind of task. A human wouldn't design a PHP program the same way she'd design the same program in Java. Without some terribly impressive AI, there's really no way around this.

They could have translated PHP into totally-unreadable Java and then (run that through javac and) run the result on the JVM, sure, but then you're really just creating a rival PHP implementation. (Look like two separate projects have done just that, though, and apparently had pretty good results, outperforming the official PHP interpreter. All that says is that the official PHP interpreter is crap, which I think we all knew anyway.)

Many of the problems with PHP are from the crappy language implementation. I recently came across a Java implementation of the language. It's been around forever, but as I hadn't heard of it, I figure many people reading this thread haven't either. It's Quercus. It's certainly worth a look as a Zend alternative.

Why don't they use (invest in) Quercus on Java instead? Compiles PHP to Java classes (like JSP) and works blazingly fast: http://caucho.com/resin-3.1/doc/quercus.xtp#compiling

I wonder why we don't here more about Quercus in the PHP world...

A more secure PHP option, Quercus.

Here is the URL in case people are interested in checking this out - http://www.caucho.com/resin-4.0/doc/quercus.xtp .
In summary:
It is OpenSource, 100% Java and it brings all the advantages of using a JVM to PHP - performance (JIT), Safety, Scalability (clustering/load balancing), quality tools (Development, Profilers). One can use most of the Java technologies in PHP to ease development even further - XA Transactions, JNDI, Connection pooling, object caching for example.

Besides, improving performance of this pure Java PHP implementation ought to be easier than improving the PHP runtime. (Java6 onwards the available tools to debug and optimize Java applications have made significant progress. jmap/jhat , easy heap dumps on OutOfMemory, Object Query Language etc. already come bundled with the JVM and then there are Eclipse and NetBeans GUI profilers.)

Also worth checking out Dr. Cliff Click's extensive Java vs. C performance blog post - http://blogs.azulsystems.com/cliff/2009/09/java-vs-c-performance-again.html .

No kidding. And if you really want to play around with cool web server technologies slightly off the beaten path there are plenty of more interesting options like Resin (open source java/php servlet).

Honestly I've got to question anyone who wants to run Windows server for any kind of performance-oriented or scalable solution, which would make this an ad?

I believe Hessian has a C++ port. I'm not sure if this is what you want, though.

Done. http://www.caucho.com/resin-3.1/doc/quercus.xtp

And I was trying for a bare-bones comparison, because anything beyond bare-bones is equally unpredictable; what do you want to test - database access ? How can you possibly tell what it is you're waiting for ? Well, in my experience, you're waiting for network latency, no matter what you program your client in. I want the bare-bones comparison precisely because it tells me what I can expect in terms of primary throughput from a webserver.

Maybe you should look at an actual benchmark instead of assuming servlets would be slow. Yes, it depends on the platform, JDK, and servlet container. Resin with the IBM JDK did 510 'Hello, world' pages per second while mod_perl/Apache did only 324. The 'Hello, world' servlet even been mod_php on Apache's static page rate of 497 requests per second. With a 'Hello, world' implementation, you really have to look at the web server overhead. Where did you think the overhead was going to be in writing to a stream? What made you assume a servlet would be slower? It really depends on how the web server performs.

You mean, things like Ruby, Python or PHP running on an open-source JVM ?

> What on earth will they do to PHP? Assimilate it into .NET?

Quite possibly. It's already been assimilated into Java

Harsh words, sounds like there is some personal conflict involved. Or maybe he just got tired and wanted to move on to something different. Best wishes to all involved anyways.

Unfortunate for the Zend team, but I'm sure it won't be the death of PHP. There are many other developers, and you can still run PHP sites with other engines, for instance, the Quercus engine in Cauchos Resin I'm sure there are similar modules available in the mono/.Net world and others.

> PHP has arrived in the enterprise market. That's a fact. Yes, I know, Java has been there for 8 years

And the two of them together are even better.

It is already being worked on, and you can download and try it out today (though it's not finished yet). It's called Quercus, from the guys who do the Resin open-source app server. (Which is a fabulous piece of work, I might add.) It compiles PHP to Java bytecode, which can then be JIT-compiled to native code.

It is already being worked on, and you can download and try it out today (though it's not finished yet). It's called Quercus, from the guys who do the Resin open-source app server. (Which is a fabulous piece of work, I might add.) It compiles PHP to Java bytecode, which can then be JIT-compiled to native code.

At least in an application server: http://wiki.caucho.com/Quercus

Quercus already runs large PHP applications like Drupal and MediaWiki unmodified.

"No", who would run PHP on Java anyway? Why? Why would open-sourcing it help?

Hellooooo, Caucho Quercus already implements PHP in Java.

Caucho has been working on PHP compilation called Quercus inside their application server Resin. This is fairly new, but they already have some fairly complicated applications like Drupal and Mediawiki working in it.

Caucho has been working on PHP compilation called Quercus inside their application server Resin. This is fairly new, but they already have some fairly complicated applications like Drupal and Mediawiki working in it.

Regarding the AppServer issue you mention, I disagree, there are really good professionnal J2EE servers available for free:
  - Apache Tomcat (http://tomcat.apache.org/)
Combined mod-jk and Apache HTTPD (and specially with the new 2.2) it really does its job perfectly well for large scale site (lots of our clients use this architecture for very frequented web sites)

  - Caucho Resin (http://www.caucho.com/)
Useful for developpment and debugging purpose as it recompiles classes on changes and provides detail information on exception. (though with tools such as Eclipse and MyEclipse, I don't use it anymore)

JBoss is an abomination. It really is. I don't kwow how the word "lightweight" got in there for the original posting. The JMX framework which they have developed may well be lightweight, but in actual use it is hideous, poorly documented, obscure, and generally unpleasant. I have found Caucho Resin -- now GPL'd! -- http://www.caucho.com/ is far preferable. Good luck with whatever you go with, but remember, less(1) is more(1).

bc

Long as we're throwing out links, let's bring up my personal favorite, Resin (now licensed under GPL!). The GPL version doesn't have any clustering support, but that's it. You can even get the full source for the commercial version, and that full version is still free-beer for any noncommercial usage.

But aside from the license stuff, it's lean, reasonably featureful for 80% of commonly-used features (if you really need lots of features, stick with jboss), and boy howdy it's fast. It's nice to have not only my jsp's, but all my servlets and even EJBs (though I stopped using EJB long ago) automatically recompiled (with jikes) upon a change.

"p.s. I know squat"

We have a winner!

Installing a JVM and an application server is about 99% less time consuming, and easier, than a comparable PHP installation.

Check Resin Quickstart

There is nothing in your list that doesn't come with a halfway decent Java application server, like Resin. "Built-in object database". Uh, yeah, java was OO last I checked. "Built-in http server". Check. "Ability to integrate with other http servers". Check. "Built-in scripting/application language". Java/JSP, or JSTL for those of you who aren't programmers. "Built-in ability to connect to traditional databases" - seriously, this is one of your selling points? You're kidding, right? "WEBDAV compliant". So is Apache. "Built-in support for XML" (xerces) "HTML" (holy cow, really?) "Buzzword, buzzword, and buzzword" "Ability to extend the environment by building modules that become integral to the site". You just described a jar file. "If you can reach it from the network, you can develop and administer it." Like any other web application. "A large stable of free/open source modules that can be loaded". Check. "Built-in ability to cluster a site across multiple machines". Check. Look, I'm happy that you're using Python to develop new and supposedly interesting applications, but let's face it, your environment is nothing new.

I think money can still be made with something like Caucho's developer source license.

It's not BSD or GPL, but it does allow you a lot more freedom than completely closed source solutions do. The only caveat I see is that, unless you work for the company, you aren't getting CVS access.

However, it allows the people who work on the software to be compensated.

This page seems to imply there is no JNDI in the GPL version... how can you do ejbs and all that stuff with no JNDI ?

have a look here: http://caucho.com/index.xtp

Under " Resin® Professional" it explicitly says "JNDI" support, hinting that the GPL version doesn't include it.

Can someone confirm/deny this?

http://www.caucho.com/resin-3.0/features/jspvsperl php.xtp

Keep this in mind when reading those benchmarks:

The server is a 266 Mhz Pentium II running RedHat 6.0 with 64 meg of ram. The client is a 300 Mhz Celeron also running RedHat 6.0 with 32 meg. The two machines are connected with a 100bT ethernet connection.

I'm considering deploying this on my person webserver now.

We have replaced several Java apps at my job with Perl. It runs faster, uses less resources, and is simple to modify (no compilation needed).

Actually, all three points are probably misinformed.

First, java is faster than perl according to nearly every benchmark I've ever seen. For example:
http://www.caucho.com/articles/benchmark.xtp
http://shootout.alioth.debian.org/craps.php

Second, you obviously aren't using Ant to automate your java buid and deploy process. If you were, the version control, compile, test, document, and deploy steps are a single click. Instead, you make it sound like you are making ad hoc changes to your production code. Bad. Oh, and finding bugs at build time instead of "in the field" is a good thing, not a bad thing.

You've got to be kidding when you say java isn't good for web applications. What exactly is wrong with JSP and servlets? There are several dozen very high quality application server components written in java over at the Apache Jakarta project. I suppose that all the people out there using Oracle and IBM tools to run their intranet enterprise apps on web based java platforms don't know what they are doing?

You seem to be thinking of java development as applet development. That is 7 years out of date. Go check out the following pages to see java in action on the web:
http://www.homedepot.com/prel80/HDUS/EN_US/pg_inde x.jsp
http://www.delta.com/home/index.jsp

First, an initial startup of a JVM does take up a larger memory footprint. But subsequent calls to the JVM do not... it's that initial runtime environment that needs resources. So if you're running several Java apps at a time (such as NetBeans, ConsultComm, Resin and other fun stuff memory and resource allocation is still much more conservative than apps that would exist outside of a runtime environment.

The original abstract windowing toolkit was kludgy, but the advent of the Swing API and the native look-and-feel within Java make things run and look like native apps. And with NetBeans GUI editor I can build windows and forms faster than a VB app in Visual Studio. Plus things are nicely skinnable by using GTK themes, QT themes or a combination of the two.

Plus let's not forget JDBC, something that I just can't live without anymore. Take a single file, drop it into your classpath, and you have instant access to whatever database you want. Want to change your database? No prob. Just drop in a different JAR file as your JDBC driver and tweak your SQL as needed. No connection recoding necessary. Much, much, much better than installing new ODBC drivers.

And system independence isn't to be taken for granted, either. I like being able to just create one package and have it run on my Linux box, then hand it to a WinXP user without recompilation. Keeps my apps easily cross-platform.

I'd hardly call Resin free. Have you seen this or this?

Unless of course you're talking about some sort of bizarre tree/java server combo that I'm not aware of...

I'd hardly call Resin free. Have you seen this or this?

Unless of course you're talking about some sort of bizarre tree/java server combo that I'm not aware of...

> Except for speed. :)

Go grab a copy of Resin and set it up to use Jikes for the autocompilation, and then you can tell me Java is slow. Hell, with Resin it's not even all that cumbersome -- except of course for the Java language itself.

Obviously the NFS solution would not scale very well horizontally. "Imagine a beowulf cluster of these" all wanting a lock on the same NFS file at the same time. A database session driver might scale somewhat better, but couldn't you do the same thing with Java?

The best solution is to eschew the whole "session" model as much as possible. The article seemed to imply that PHP encouraged this, but I'm not convinced. I think I've seen plenty of PHP tutorials encouraging session variables unnecessarily.

And why would you want to do such a thing?

For failover if you loose a node in the cluster.

Application servers like Resin support the synchronisation of these in memory sessions with failover when a node dies/is taken out of service etc.

So should we all use JBOSS now?
Or probably something faster than JBOSS?

So should we all use JBOSS now?
Or probably something faster than JBOSS?

1) lots of performance optimizations - there's plenty of room for performance gains in Java. Java performance varies widely from platform to platform. More eyeballs on the code is a good thing.

2) lots of bug fixes - that lame-assed bug that's driving you crazy on one of the platform implementations? fix it and submit a patch. Security holes could be identified and fixed. More eyeballs on the code is a good thing.

3) ports of Java to new platforms - I would imagine that being able to install Java on legacy OS's would be a huge boon to Sun. They would get more Java penetration into the enterprise market. I'm sure there's some Commodore 64 freak out there who desperately wants to write Java apps for his antique. :)

Also, no one around here seems to understand that Open Source does not necessarily equal FREE. There are many fine commercial products out there with restrictive licenses that are open source e.g. Resin. Sun could open source Java without giving up their licensing rights.

I also don't buy the argument that Java would fragment from too much forking. Smart engineers stick to standards because deviating from standards almost always ends in huge amounts of pain and suffering.

Probably you shouldn't judge java only by its reference implementation of a servlet engine (tomcat). There are much faster beasts available that also do away with the load problems your tomcat might be expiriencing.

And expensive crypto-computation should ofcourse be done in native code but that doesn't imply that your whole app must be native. Maybe a bit more evaluation could have saved you a lot of time.

This is good news. Tomcat is the reference Servlet implementation. So if it works on Tomcat it _should_ work on other servlet engines. So people that may have held off deploying or even developing Servlet 2.4/JSP 2.0 application may now start down that trail.

Also, let's not forget there are a couple of other great choices out there: Resin with Servlet 2.4 and JSP 2.0 and the alpha Jetty 5.0 the Servlet 2.4.

Linux VPS Based Java Hosting - Now with Tomcat 5 if you want it

Basically they say that Resin isn't that fast. I think this has started with Tomcat 4.

Tomcat is pretty slow in general. Why don't you try Resin?

(Every time I post this sort of message, I get +5. I hate karma whoring like this, but once again it's time for some education.) "Amazon is hiring Perl programmers" leads the reader to believe that Amazon is running Perl in some major shape or form. They aren't. They are running Java servlets under... Weblogic, I believe. "Slashdot...runs on Perl." leads the reader to believe that Slashdot is a complicated website. It isn't. Incidentally, have you clicked on the "Friends" tab on your user page lately? What an incredibly slow response (and that isn't a bandwidth issue). None of the technologies you listed (mod_perl, Python, PHP, etc) handle any type of failure well at all. Show me a PHP-based site, hosted on multiple machines, that provides load-balanced and automatic failover of in-memory session data. I'll give you a clue: you won't find one, because it is impossible to do shared memory over a cluster of machines in PHP, mod_perl, Python, etc etc. On the other hand, I can list off a whole slew of Java app servers that can do clustered, load-balanced, full-failover shared memory without even blinking. Resin is an awesome example of an extremely inexpensive application server that currently does nearly everything you need an app server to do. Want to know a little secret? The PHP team is moving more towards an application-server architecture, because they know that the native compiled-in mod to Apache/iPlanet/etc is kludgy. They're cooperating with Sun and others on JSF so PHP will be able to speak with Java applications in a more efficient way. mod_perl I won't even bother with. The MVC model simply won't work under mod_perl. Good luck with an implementation team of more than, say, 5 people.

Here, let me rewrite that for you:

Business Logic Java - Good
PHP - Bad.

Presentation Layer (Web)
Java/JSP - OK
PHP - OK

There, that's more in keeping with what I know of both languages. Now, Java is superior to PHP for business logic, as you picked out, but Java has JSP/Tomcat, which is functionally just as good as PHP, at least according to benchmarks I saw recently.

Now.. given the choice of Java over PHP for your presentation, why would anyone choose PHP when they can get the same results with JSP, but have the added upshot of keeping everything together in the same basic syntactic setup? Java code is easier to create and maintain than PHP code, and it's faster.

There's no real need to use a different system unless you get a benefit from it. You claim the benefit is in using PHP for presentation in web applications. Fine, but I don't see it. Now, if you suggested something along the lines of Zope's Page Templates, I might agree. But if you're at the point of using Zope for your presentation, there's no reason to use a different platform for the logic, as Zope is written in Python, and Python is an outstanding programming language, easily heads and shoulders above Java in every respect except raw number-crunching performance and IDE availabilty. At least, IMO. :)

But the question is Java vs. PHP. In that case, the answer is Java.

What platforms do you use for development?

What Dbs do you use?

What web server?

Why?

Well here's one that says JSP is faster.
But, then it is from a servlet container vendor.

Uh, none of those links work, however here is a *recent* comparison of JSP and PHP using several different containers for JSP and PHP. It seems that the server setup has a great deal to do with the speed of the application (duh).

It's interesting that people like to make comparisons to JSP and ASP all the time but don't remark on what platform they run on. Obviously JSP running on tomcat/apache through with mod_jk will be slower than with just plain Resin.

And open should note that a statement like ' Kiss and say goodbye to Java language!!' almost sounds like a troll, when you consider Java is used for a great deal more than web applications, indeed the servlet functionality that JSP relies on is a *very* small portion of the overall tools that Java supplies to developers.

But whatever, use the right tool for the job and try to remember it's technology, not religion. The more options the better IMO.....

Caucho's resin application clusters are a great way to get load balacing and distributed sessions into your appserver farm. Cost is around $1k per server, so real enterprise jocks will laugh at it, but unlike some of the "three engineers per server" solutions, it really works without having to spend all your time troubleshooting and hand-coding things.

After reading the article, it looks like it does affect someone trying to sell their software to government agencies - even if they provide the source. The article reads "free software", not simply open source.

Open source != free. There are plenty of vendors who provide their source code freely, but require licenses to actually use it in production (i.e. Caucho Resin). Under this decision, Brazil could not use this software even though it is open source.

It looks to me like the decision was more based on cost-cutting, and consequently promoting faster adoption of technology, rather than a conscious affirmation of open source. What it really comes down to is economics, not ideals.

-j

Resin includes a full-featured HTTP/1.1 web server dedicated to serving fast Java dynamic content. While Resin is tuned for dynamic content, its static file performance matches or beats Apache's static performance.