Robert has several years of professional experience and a PhD in the field of automated software migrations. He is the co-founder and CEO of Numition Ltd., a start-up company specialized in developing software migrators. Robert is a DZone MVB and is not an employee of DZone and has posted 10 posts at DZone. You can read more from them at their website. View Full User Profile

Open-source Web applications, PHP vs. Java (Part 2 of 2)

05.01.2008
| 14268 views |
  • submit to reddit

The first part of this article reviewed some relevant open-source Web applications in both the PHP and Java worlds. The conclusion was that there are massively popular PHP projects and somewhat popular if not obscure Java counterparts. I'm a Java fan and it pains me to discover this reality. The user comments also underlined this feeling.

Is it the technical merits of PHP?

In my experience, the technical merits of PHP are below those of Java as a language and as a runtime environment (standard API, virtual machine).

Compared to Java, the code quality of PHP projects has a faster decreasing rate as the codebase size grows. The root cause is that PHP was created to solve small size problems and this makes it difficult to manage larger projects.

PHP 3 and 4 had basic object-oriented features, while PHP 5 improved them considerably, both at the language and the runtime level. There are several PHP MVC frameworks to ease the structuring of larger projects, but these are most effective when running on PHP 5. Most popular open-source PHP projects still run on PHP 4 and tend not to use MVC frameworks at all.

Looking at the staggering number of plugins available for the popular PHP open-source projects, one could conclude that their code is easily understandable and that PHP has well-rounded application extension mechanisms. Well, not exactly true.

The typical PHP extension mechanism is procedural and works like this:

  • list the subdirectories of the extensions directory,
  • analyze the predefined directory structure for each extension,
  • execute some predefined PHP files that should auto-register their resources and actions.

The greatest concern – no protection of the core code. All the important internal structures of the PHP runtime are map-like data structures to which the PHP code has full access: the global variables map, the functions map, the classes map etc.

As a long-time Java developer, I see these as drawbacks. But they don't seem to reflect as such on these popular projects with very large user and developer communities. But if it's not the language, what is it?

The execution models

Compared to Java, developing and hosting PHP projects is dead-simple because of the execution model.

In a typical setup, each request to a PHP application is handled by a separate Apache process that uses its own instance of the PHP interpreter. After handling the request, the process is killed with no garbage left behind. This sounds inefficient for high-concurrency usage, but works great in a shared hosting environment. If a hosted application has no active requests, it doesn't use memory at all. Development-wise, each PHP script is written like every script instance (process) is the only one running.

The Java Web application model uses servlets and multiple threads to handle requests. It scales upwards very well, hence its success in the enterprise space. Problems arise if you want to host many smaller and less frequently used applications inside the same Web container, precisely because of the threads. Developers have to be careful about concurrency issues.

The process control mechanisms available at the OS level are vastly superior than those available for Java threads. The result is that a hosting provider has strict control over the resources used by each PHP request. On the other hand, a Java thread backing a request is an object that you cannot control once started: it stops when it wants to, it uses as much system resources as it pleases. The Web containers only have mechanisms for controlling the pool of threads.

The end result is that there are technical limitations in setting up a competitively priced reliable Java hosting solution. This brings us to two fundamental questions: do we need successful open-source Java Web projects suitable for non-enterprise use? Can Java survive without such projects?

Java can probably survive, but survival and flourishing are two different things. If the average present-day college student or hobbyist finds pleasure in using and extending open-source PHP (and generally non-Java) Web applications, I believe that it is only a matter of time until the effects are felt in the enterprise space: less enthusiastic Java specialists, less innovation, decreasing quality of products and so on. Some say that the effects are already present – what do you think?

Instead, wouldn't you like to run your blog on a Java-based highly extensible engine? Wouldn't you like to build complex sites using a Java-based CMS with many high quality, readily available, easy to develop modules? Something that can be as small or as large as you want. I would.

Building successful open-source Java Web applications – your input is needed

In my opinion, there are three important premises for an open-source Web project to succeed:

  • the intrinsic value of the project,
  • the enthusiasm of its community (both developers and users),
  • easy hosting.

If Java presence is to increase in the area of open-source Web applications, all three are needed. The first two items are crucial because valuable projects and enthusiastic communities can even help improve the existing entry-level hosting options.

The fastest way to obtain Java projects with the same functionality as PHP ones is by automated software translation. The company I co-founded has developed technology that allows translating PHP applications to Java. I have already talked about this while presenting the nBB2 project, the Java equivalent of phpBB 2. The migration algorithms can be customized to produce various output flavors, ranging from plain servlets and JSP pages to Web frameworks like Struts or Spring MVC.

We would like to translate more open-source PHP projects to Java, but this would be just a first step. The Java community would then have to step in by using and extending them.

The projects I see as the most useful are from two categories: a CMS (like Joomla or Drupal) and a blog engine (probably WordPress). We have opened a forum topic with a poll, as a discussion starting point: http://www.numiton.com/vote. Before we start such an undertaking, we want to make sure it makes sense. What do you think?

In the comments following the first part of this article it has been suggested that Sun act and sponsor key open-source Java Web projects. I my opinion, Sun already provides the Java platform and an open-source stack to support such endeavors. It is up to the Java community to make proper use of the technologies at hand. I look forward to hearing your thoughts on this topic, both online and in person. Next week I'll be at JavaOne, so if you are around feel free to pass by the Numiton booth 1224-8 in the startup row.

References
Published at DZone with permission of Robert Enyedi, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Roland Carlsson replied on Fri, 2008/05/02 - 1:08am

The largest problem is hosting. We need to write a webserver that is as cheep and easy as PHP to host for the small to medium sized project. 

MyJavaServer could perhaps be packaged as an application with hooks to a linux-server for user management and ftp-access etc? Or is the approach of MyJavaServer flawed? 

 

 

Stefan Koopmanschap replied on Fri, 2008/05/02 - 2:40am

Being a full-time professional PHP developer, I am somewhat offended by your quick conclusions.

The root cause is that PHP was created to solve small size problems and this makes it difficult to manage larger projects.

Yes, PHP was initially (we're talking the first, second and maybe third version of PHP here) meant to solve small size problems. From 4, the first steps to have a more structural language in place were set and these changes continue with PHP 5. The problem that you're seeing here is not that it is difficult to manage larger projects, it is because (unfortunately) the skills of the average PHP programmer are much lower than those of the average Java programmer. This is not surprising, since PHP has a much lower entry point: Everybody is able to get a simple PHP script up and running where for Java you need to have quite some knowledge before you can dive in and do something.

Most popular open-source PHP projects still run on PHP 4 and tend not to use MVC frameworks at all.

 Yes, this is definitely a problem. PHP5 is now out for over three years and still a lot of people are on PHP4, because a lot of hosting providers still only offer PHP4. But this is more of a marketing/adoption thing, and is not necessarily something the projects choose to do. They're just limited because when they move to PHP5, they may lose a big userbase that is still at those ignorant hosting providers.

The greatest concern – no protection of the core code.

Again, this is not something that is wrong with the language, but with the developers using the language. If you set things up well, in PHP you will also have objects which hold data as private properties and only expose those parts that plugin developers should have access to.

Aside from these two quick conclusions, I think your article sums up the "problems" for Java open source application pretty well.

Marco Patania replied on Fri, 2008/05/02 - 4:01am

I'm php dev and I wanted to ask to java dev:

in php if I must modify some project file I can make it in ssh, ftp or svn without need to touch other.

In java I can make the same things on the server without restart web container or redeploy to every modification?

thnx

Stefan Koopmanschap replied on Fri, 2008/05/02 - 4:21am

Marco: And this is the difference between good developers and normal developers in a PHP environment.

 A good developer knows that you should *never ever* modify your code on the production environment. Proper procedures should be in place.

 Having said that, still for PHP you need not restart any services. You just deploy your changes to production and it's working. If I understand Java correctly, some processes need to be restarted for new deployments to take effect.

Marco Patania replied on Fri, 2008/05/02 - 5:42am in response to: Stefan Koopmanschap

I didn't say "production environment." 

With a company I have developed some modules for Spring MVC and every time I had to redeploy in order to test (they did not use the JUnit). I wanted to know if is normal or if they did not know other solutions?

Stefan Koopmanschap replied on Fri, 2008/05/02 - 6:22am

Apologies for misreading Marco

Edvin Syse replied on Fri, 2008/05/02 - 6:56am

When programming JSP, you get a similar execution model to PHP, where changes are reloaded on the fly.

To take full advantage of what Java has to offer for web-developers however, you would use a framework or a method that deals with Java-code that only to some extent can be reloaded on the fly. In your dev-enviroment, when running in debug-mode, some, but not all types of code can be reloaded on the fly. There are work under way to make even more code hot-replacable, though.

To some degree this is annoying when debugging an UI-issue for example, but for the most part you can afford a reload that only takes a few seconds and is a keystroke away after you have programmed for ten minutes and wants to see the results :)

I use Apache Wicket as a web framework, and the small amount of time I use waiting for server reloads is easily gained by ease and speed of development and robustity of the end result :)

-- Edvin

Alex Duderino replied on Fri, 2008/05/02 - 7:51am

About the shared hosting problem (apps using resources even though they aren't getting any requests): Ruby on Rails had a similar issue where you needed "mongrels" running all the time, with a predetermined number of processes per web application. This has been solved beautifully by mod_rails / passenger; it keeps the Rails framework in memory, and "spins up" application instances as requests come in. It keeps the instance running until no requests have been made for a configurable period, with a configurable quota on the maximum number of instances. So no requests: no memory consumption.

Of course this approach is currently framework specific (only works with Rails), but java web deployment already has a standard mechanism (deploying WARs), so maybe a dynamic deploy/undeploy based on requests could be a nice solution. With this approach, the startup time of java web applications would of course have to be as low as possible so the visitor doesn't get a long delay when an undeployed application needs to be spun up.

Dmitry Namiot replied on Mon, 2008/05/05 - 12:20am in response to: Marco Patania

yes, you can.

Dmitry Namiot replied on Mon, 2008/05/05 - 12:22am

I think Java hosting is actually a big problem. It is simply more expensive. Plus PHP hostings preinstall  a lot of components for clients.

 

 

Steven Baker replied on Mon, 2008/05/05 - 10:31pm

java hosting is more expensive because the apps that typically on them are heavier and use more resources than php services.

i think the main reason theyre like that is because theyre bloated with far too much junk that comes "out of the box" with them.

cut this back and we've got a light weight easy to deploy service! 

Edvin Syse replied on Tue, 2008/05/06 - 4:29am

With PHP, you get the provider's precompiled set of utilities and libraries bundled with PHP. This seems like a good thing at first, because you don't need to upload all your library dependencies yourself. But if you need a spesific version of say an XML parser, you might not see this as such a good thing, as your provider in most cases will be unwilling to update jus to satisfy your need.

When you buy a Java hosting solution, you can/must upload your own dependencies, I guess this is what you refer to as bloat. This gives you the opertunity to run with EXACTLY the same versions of your libraries both in local dev and in deployment. This is a HUGE advantage, and you don't need to waste time with adapting/bughunting because of version skews and API breaks etc.

With tools like Ant, Maven and Ivy, dependency management is easy and straight forward, and the extra upload sice really is not relevant, both because "everyone" have fast connections, and you don't need to upload your dependencies everytime you change your code :)

A Java process will ofcourse use more concurrent resources, as the the process is ALIVE all the time. This gives you incredible opertunities as a programmer, compared to a language where everything is parsed on every request - talk about wasting resources :) In our system, we see about 18MB usage for every new PHP process spawned (using suPHP), whereas every request to an already started Java container just uses the minimal memory needed to deal with the business-aspect of each request :) 

 

Robert Enyedi replied on Tue, 2008/05/06 - 5:43am in response to: Edvin Syse

[quote=edvin@sysedata.no]

With PHP, you get the provider's precompiled set of utilities and libraries bundled with PHP. This seems like a good thing at first, because you don't need to upload all your library dependencies yourself. But if you need a spesific version of say an XML parser, you might not see this as such a good thing, as your provider in most cases will be unwilling to update jus to satisfy your need.

[/quote]

Good point. Actually some Java shared hosting providers do provide preloaded libraries, but in JAR format so that you get one version available to you. Java already has a solution to this issue with OSGi bundles/plugins where you can have as many versions as you like and from the descriptors one can declare dependencies to specific library versions. There are most certainly solutions to this. It's just that Java shared hosting did not reach a critical point yet.

[quote=edvin@sysedata.no]

When you buy a Java hosting solution, you can/must upload your own dependencies, I guess this is what you refer to as bloat. This gives you the opertunity to run with EXACTLY the same versions of your libraries both in local dev and in deployment. This is a HUGE advantage, and you don't need to waste time with adapting/bughunting because of version skews and API breaks etc.

[/quote]

Well, technically this is bloat if you want to host something small. There should be a way for non-technical people to be able to host Java apps just as easily as PHP ones. Maybe it would be worth experimenting.

I would be willing to throw in a dedicated server and attempt to set up a killer Java shared hosting solution (probably with OSGi and Jetty) just to show that it can be done effectively. It would have limited availability and would be free or extremely cheap - profits are irrelevant, I only want to prove things. All configuration details could then be made public so that others could follow. I think that would be a first for Java at least. Anyone interested in collaborating or using such a service?

Robert Enyedi replied on Tue, 2008/05/06 - 6:03am in response to: Steven Baker

[quote=zynasis]

java hosting is more expensive because the apps that typically on them are heavier and use more resources than php services.

i think the main reason theyre like that is because theyre bloated with far too much junk that comes "out of the box" with them.

cut this back and we've got a light weight easy to deploy service!

[/quote]

I used to think the same. I did set up a pretty thorough test though (see this post) with phpBB 2 and nBB2 (its direct Java equivalent). The result was that even lightweight Java apps do have serious hosting issues. The cheapest hosting option for Java was around 15$ with a private JVM having 32 MB max heap, but it already started to outperform the PHP option at 10 concurrent users.

I do think that a proper shared hosting solution coupled with some lightweight Java projects (migrated from PHP) can outperform PHP in both quality and costs.

Edvin Syse replied on Tue, 2008/05/06 - 6:00am in response to: Robert Enyedi

I agree it can be cumbersome when you just want "something small", but again - writing a few lines in pom.xml really isn't that big a deal, and as you mention - most providers have some kind of a base package that would be comparable to the stuff you get with PHP (atleast if you are writing JSP). I know that some users will still feel that way, and I absolutely think your approach with OSGi and Jetty seems very interesting.

As a service provider I'd be willing to join in to experiment around this :) I believe the key to success is actually not just on the serverside - but on the client side as well, concerning deployment of the OSGi bundle. Most tools for creating jars and wars are rather dismal, and when you throw in the extra manifest info you need in the OSGi bundle, it is imperative that the end user experience is smooth for this to be successful.

I could set up a Solaris Zone to play around with the concept if you/others would like to join in :)

Robert Enyedi replied on Wed, 2008/05/07 - 9:14am in response to: Edvin Syse

[quote=edvin@sysedata.no]

I agree it can be cumbersome when you just want "something small", but again - writing a few lines in pom.xml really isn't that big a deal, and as you mention - most providers have some kind of a base package that would be comparable to the stuff you get with PHP (atleast if you are writing JSP). I know that some users will still feel that way, and I absolutely think your approach with OSGi and Jetty seems very interesting.

[/quote]

We're exhibiting at JavaOne and our booth is near the Jetty guys. Today I'll drop by and have a talk with them regarding this issue.

[quote=edvin@sysedata.no]

As a service provider I'd be willing to join in to experiment around this :) I believe the key to success is actually not just on the serverside - but on the client side as well, concerning deployment of the OSGi bundle. Most tools for creating jars and wars are rather dismal, and when you throw in the extra manifest info you need in the OSGi bundle, it is imperative that the end user experience is smooth for this to be successful.

[/quote]

If you need tools for creating OSGi bundles in general I think that Eclipse offers you the best support. With those you can work both on Equinox and pure OSGi bundles. We should not focus on these right now though. Instead, cheap and easy deployment of already bundled smaller Web projects should be our target.

[quote=edvin@sysedata.no]

I could set up a Solaris Zone to play around with the concept if you/others would like to join in :)

[/quote]

Sounds cool. What exactly do you mean by a Solaris Zone?

Maybe it would be the best if we moved this discussion off the article comments. I set up a dedicated forum on small-scale Java hosting on the Numiton forums (registration required): http://www.numiton.com/forum/viewforum.php?f=7.

stefan soriga replied on Fri, 2008/07/25 - 5:06am

"I believe that it is only a matter of time until the effects are felt in the enterprise space: less enthusiastic Java specialists, less innovation, decreasing quality of products and so on. Some say that the effects are already present – what do you think?"

This implies that PHP stays still, but maybe PHP will evolve faster and surpass JAVA programming enviroment in next years. Who knows?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.