JavaOne aftermath
Java developers happy using Drupal, mad about Scala
The jet lag is finally easing. And boy, how many hills I've walked last week.
From May 6 till May 8, Numiton has exhibited at JavaOne in San Francisco. We wanted to showcase nTile PtoJ and get some business our way, of course. But also to build awareness about two things: 1. the concept of automated software migration and 2. our plans in the open-source world.
Hopefully, the first target was achieved. Of the many people stopping by our booth, some were skeptic regarding the possibility of translating from such a quirky language as PHP (weakly and dynamically typed) into Java. But after being given technical details and looking at a few samples, they were more convinced that it's feasible. And automated software migration, generally speaking, was not met with reluctance.
Surprisingly enough, the second goal encountered a lukewarm support. Numiton has medium-term plans to translate more of the popular PHP open-source projects (Have you heard of Joomla, Drupal, WordPress? Bet you did. Now, name a Java equivalent. Hmm...) So we wanted to assess the level of interest for such an endeavor, since translation would be only a first step and then community would have to step in. But somehow, the audience did not get exceedingly enthusiastic. Our forum's voting section on this topic remained unused, and almost everybody seemed to be content with the status-quo.
(Or is it that people were simply being polite in both instances, and we did not manage to raise a real interest at all? Only time will tell.)
Well, for the time being it seems we have to reconsider our open-source plans. No point in investing energy in something few care about...
And this brings my thoughts to something about the whole show. A lack of enthusiasm. We were wide-eyed JavaOne rookies, but from what I'd read from previous years I had expected people to be more – passionate. Speaking of this to someone who had been there before, I was given a possible cause: “Java has become mainstream. And with this, using it has become simply a business; it's not a passion anymore”. While the explanation is logical, I can't help being a little dismayed.
The best discussions of a show happen at parties, so from other bar talks I found out that the interest of the public seems to veer in another direction. Groovy, JRuby, Scala, Jython – all these programming languages run in the JVM, but they're closer to the scripting paradigm than to Java. So is the idea of translating open-source projects towards Java obsolete? Is Java (as a language, not as a platform) “so yesterday”, as I was told after a beer or three? The fashion industry experiences new/old/new again shifts twice a year, are programming languages victims following fads as well? Or are all these people onto something?
From a business point of view, this should be good news for Numiton. Because we've built our translator in a modular fashion, it's relatively easy to add new source/target languages. So maybe we should start thinking about PHP to JRuby. Or even Java to Jython. After all the effort we put into type inference, translating towards a weakly-typed language should be a piece of cake.
From a theoretical point of view and from experience, however, I am still not convinced that ditching Java is a good idea. And somehow I've never learned to put business before personal convictions. Luckily, that affects only marketing and not implementation, so as long as Numiton keeps me away from potential “Java to Groovy” customers - things should be OK :-)
Open-source Web applications, PHP vs. Java (Part 2 of 2)
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.