Skip to content

LAMP & JVM: Chocolate & Peanut Butter, or Oil & Water?

If you’re setting out to create a shortlist of people within the industry who are qualified to speak credibly on the future of application development and dynamic languages, it’s pretty fair bet that Sun’s Tim Bray is going to be on it (the decision makers at Sun are well aware of this, for those that are curious). Forget that he’s behind one of the more important infrastructure enabling technologies of the present (XML); his appreciation and understanding of dynamic languages is second to none. Much like Adam Bosworth, Tim is one of a handful of EF Hutton technologists – when they talk, I listen. Closely. All the more so when he’s talking about something I’ve written.

The piece that started this dialogue dealt with my reactions to the Sun Analyst Conference. Distilled to its essence, my point was that while Sun’s righted the ship on multiple fronts – the Solaris operating system, their x86 business, etc – they remain heavily Java preoccupied in a world that is increasingly seeking alternatives. Which alternatives? I’d intended the piece as an argument on behalf of dynamic languages, despite the fact that he caught me – in error – using scripting communities interchangably, but he wants to expand the argument to the much broader LAMP stack. Makes perfect sense here.

Anyhow, Tim wins immediate points by avoiding the typical Java/.NET responses to questions of the LAMP stack – responses that typically attempt to characterize LAMP as intrinsically unsuitable for anything other than the most trivial implementations. Instead, he acknowledges that LAMP is both a credible and popular platform, saying:

So one way or another, there’s gonna be a lot of LAMP out there. Because people think they can get it done quicker, or because they know those P-languages better, or because they’re in love with Ruby, or because there’s some library they want to use that only PHP has, or, well, who cares, there are a lot of reasons. Nothing we at Sun can say will change this, nor should we want to.

With him so far. From there, he argues on behalf of Sun’s dynamic-languages-on-a-JVM stance on the basis of three main contentions:

  • First, that JVMs are common, maybe ubiquitous:
    It turns out that most software developers spend most of their time, not building new green-field projects, but enhancing or extending or fixing existing apps. And most of those apps are on the JVM.

    I’m not buying this entirely – more on that in a bit.

  • Second, an assertion that threading is increasingly important in application development:
    The next big wave of server CPUs (starting with our own Niagara) are going to be increasingly multithreaded and concurrent. There’s no choice, we can’t just go on turning up the clock rate, so if you want more performance, parallelism is the way to get it.

    Almost entirely agree with this; even laptops have dual cores these days. Plus, as I’ve argued before, scalability is more and more important. But is the need as universal as is implied here? Maybe not.

  • Third, that with respect to scaling, the dynamic languages are, if not poor, inexperienced when compared with Java.
    At the moment, the threading in Perl and Python and Ruby and PHP tends to be amateurish-to-absent. Java’s threading/concurrency machinery, on the other hand, has been excellent for years, and got a lot better in the 1.5 release. The dynamic-language guys will be working on this, but they’re starting from way behind.

    While I’d tend to defer to Tim’s greater experience in this area anyhow – threading was not one of my primary concerns as a developer – his comments mostly align with what I hear from both dynamic language and Java advocates.

Extrapolating from the above, Tim advocates a world that looks like this as opposed to this. A world, in other words, that leverages the JVM’s threading and concurrency skills and the dynamic languages’ productivity.

Personally, I’m not against this. Nor am I against Java. If you don’t buy that, I suggest you go read this piece I wrote a while back. But neither do I find the prospect of PHP, Python or Ruby on top of a JVM as compelling as Sun apparently does. There are a couple of reasons for this:

  1. Ubiquity:
    Bray contends, as do many Java advocates, that JVMs are virtually omnipresent in development environments. To the extent that we’re talking about purely corporate development, that’s more or less a reasonable assertion. Excepting pure Microsoft shops – which in my experience are rare – Java’s the clear development language of choice for most corporate development. PHP’s made gains inside the firewall, as the IBM and Oracle partnerships indicate, but to borrow Tim’s words – there’s gonna be a lot of Java out there.

    But I’m just as interested in what happens outside the firewall – the individual developers building blogs and wikis and forums and feed readers and a host of other ‘non-enterprise’ apps on borrowed or hosted infrastructure. And that, IMO, is an area where Java’s anything but ubiquitous. For example, I did a quick and utterly non-comprehensive (meaning – correct me where I’m wrong) survey of some of the larger web hosts out there (as qualified by Netcraft) and discovered that while all ran PHP, Java coverage was spotty. A quick rundown on which hosts support Java out of the box:

    • 1and1: No preinstalled Java

    • GoDaddy: A Google site search turns up some Tomcat related information, but it doesn’t appear to be mentioned in the functional description of any of the servers nor in the configuration process
    • Verio: Supports JSPs and servlets on Managed Private Servers only
    • Rackspace:No, the list of installed software is this:
      1. Apache

      2. BIND
      3. GCC
      4. MySQL
      5. OpenSSH
      6. OpenSSL
      7. Perl
      8. PHP
      9. PostgreSQL
      10. Python
      11. Sendmail
      12. Webmin
    • Interland: Yes, on their virtual private server package

    The point of all of this? That contrary to its first class status within the enterprise, for individual developers working off hardware that’s not their own, the simplest path forward is what’s universally present: one of the dynamic languages. Java may or may not be available, and when it is, usually only on the higher end $40-50/month on up packages.

    Many folks hosting their own blog infrastructure have faced this precise scenario; when contemplating a switch off of Movable Type the other day, Roller was suggested to me as a worthy alternative. But while I have the utmost respect for Dave Johnson and the rest of the Roller team, I have no intention of installing a JVM instance when PHP is already sitting right there for me.

    So while I don’t really buy Tim’s argument that there’s always going to be a JVM available, it depends heavily on the context of what kind of development we’re talking about. I tend to think of JVM’s vs PHP in the context of the analogy that Oracle sometimes uses against MySQL; Oracle’s a 747 to MySQL’s Toyota Corolla. The 747 is undoubtedly more functional, but there are a hell of a lot more Corollas then there will ever be 747s.

  2. It Looks Like A Dynamic Language, But Is It?:
    If we assume that Tim is right, however, and that JVM’s are both plentiful and a net benefit in their thread handling, would there be any reason at that point not to a JVM based dynamic language? I think so, and so – apparently – does one very bright developer. Here’s what Mr. Sequeira has to say on the matter:
    I’ve done a couple successful jython projects (Intraspect used it for it’s API), and it was definitely better than having to do low-level Java or suffer learning a proprietary scripting language.

    However, I became quite frusted with how running language A on runtime B broke a tool I rely on to be a productive programmer: google. You can no longer reliably use google to find source code examples for doing things like parsing XML, say, because you’re now using a strange language that needs to call non-native class libraries. The native libraries no longer work, so neither does google or that stack of O’Reilly books sitting behind you. That realization really tempered my enthusiasm for the J* languages (and the Iron* ones).

    Despite the best efforts of the folks behind JRuby, Jython and the like – it’s simply not the same as working natively. Can it be done? Certainly. Is it without its own set of issues? Doesn’t seem that way.

  3. Scalability?:
    It’s going to seem like I’m contradicting myself here because I’m going to argue that scalability – and the related technical issues like threading – are not a huge issue for lots of developers when I’m on the record as saying that it’s a big issue today. But again, it’s a matter of context. If I’m designing a public web application, for example, am I concerned with scalability? You bet. But let’s look at something like Movable Type. Is the threading model for it of particular – or indeed, any – importance to RedMonk? Not really. We use it to spit out a bunch of static HTML pages which serve pretty damn fast with no help from either PHP or Java (it would admittedly be different if we used the dynamic capabilities). And yes, BTW, we are paid users of the product.

    So the point is not that Tim doesn’t have a point – he clearly does – but rather that there are and will continue to be a great many development challenges that are not likely to benefit immensely from the JVM’s superior thread handling abilities.

What then do I conclude from all of the above? Well, despite my concerns about Sun’s policies in this area, I think Tim is mostly correct: there are an increasing number of scenarios in which having the ability to run a dynamic language on top of a JVM would be highly desirable.

What would concern me, however, if I worked for Sun – and they are a client of ours – is that competitors such as IBM and Oracle are not forcing their developer base to make that choice. They are instead supporting them in their native environment, with no JVM involved at all. This is important because it’d be my contention that Sequeira is far more representative of the average developer than the folks at Sun would like. In short, I’d recommend that Sun support both JVM and native execution of dynamic languages. I think it’ll take some organizational change to get there – organizational change that Bray would be very happy with, I believe – but I’ll talk more about that another time.

Disclaimer: Sun, as mentioned is a client, as is IBM. MySQL, Oracle and Six Apart (Movable Type) are not. We are, however, paying clients of Movable Type. Of the mentioned web hosts, we’re a paying client of 1and1, but have no relationship with any of the others.

Categories: Trends & Observations.

  • Danno

    If they present it as an option for Programmers in Enterprise scenarios to still keep their jobs while getting to program in a language that doesn't drain their soul, I think they're going to be very succesful.

    I mean, just today, working on a very simple project for a class, I spent, I dunno, at least an hour fighting the type casting system (and JUST the typecasting system, there was other time wasted because of annoying Java-itis).

    Here, let me show you one line of code that was very frustrating to me, coming from Ruby:

    String RString = Integer.valueOf((int)Math.round(((Double)RGBvals.get("R")).doubleValue())).toString();

    That right there is why Java as a language is losing mindshare. But it's got solid libraries and the work that went into that code would be foolish to toss away.

  • Dillon

    It might be worth pointing out that many small web hosts sell accounts on servers running hosting control panels, such as cPanel, DirectAdmin, Helm, Ensim, or Plesk. Those control panels (cPanel and Plesk for sure) have facilities to install the JRE, usually along with Tomcat or Resin for servlets on top of Apache. So Java is definitely present for the small-timers that you mentioned, but for reasons like the one Danno pointed out above, Java likely won't gain any momentum in that scenario. The scripting languages are just plain faster to use to create and test useful stuff quickly, and that's what counts.

  • James Governor

    lets be very clear that Oracle and DB2 are keen on scripting so far because they are selling databases… there is no immediate equivalent at Sun. there is still a LOT of jee and JVM religion at IBM. although the church is broad enough to support other views. i wonder if IGS has a PHP web dev practice? a view on RoR?

    lets see IBM really going full bore behind Sam Ruby and Rod Smith in terms of scripting and mashup before we're in a position to fully analyse their openness. IBM and LAMP – is hardly a shoe in….

    its not "forcing their dev community" to do anything – its about appealing to devs they otherwise wouldnt… same as DB2 working with Microsoft .NET VSIP program.

    all that aside- your points are good ones regarding java and Sun…

    just wanted to tweak the analysis.

  • Chris Maeda

    Back in Mar 04, I blogged that Java and .NET would be crushed by LAMP not only because of programmer productivity but also because LAMP has an order-of-magnitude advantage in deployment costs ( A LAMP-based startup can integrate large open source applications (eg shopping carts, forums, etc) and deploy their first site version on a $5/mo hosting account. The JVM (or CLR) is nowhere near as ubiquitous as PHP.

  • Jaime Cardoso

    When you give some examples to show that the JVM isn't *that* ubiquitous, you're actually showing services that don't claim support for a JVM. I realy doubt that, if you typed something like java -version in a shell, you wouldn't get a response.
    there is a significan difference between "There isn's a JVM available" and "we didn't test the JVM". while the first is connected with availability, the second is more related with the offer and demands. It's not that one is more important than another, they are different issues and, when Bray talks about ubiquity, he's mentioning the first one (IMHO).
    Another issue of scalability is the simple performance. Very few people tune or optimize code today, they just increase the specs of the hardware and, the T1 will be the only viable way to go in increasing systems performance in the near future. Developers will have two choices, starting to generate code more optimized or start to make massive multithreading as a design constrain of the software. If the trend of sloppy code continues, solutions that make simple to do Highly threaded software will be the only choice for several applications.

  • stephen o'grady

    Danno: i do believe that's called 'damning with faint praise' ;) but in all seriousness, i do believe you're absolutely correct – allowing developers to be productive with the language of their choice, on top of the JVM, is absolutely a plus. it just should not be, IMO, the only approach taken to supporting dynamic language advocates.

    Dillon: while i'm sure the control panels have the technical ability to add the JRE, i'm not sure how many use it. it's never been an option on any of the hosted accounts, and even our 1and1 managed server does not give me that capability. how hard would it be for me to add it? not very. but it's an extra step. point taken about ubiquity.

    James: agreed that the primary incentive for IBM and Oracle vis a vis the dynamic languages is database sales, and further that there's considerably Java bigotry on both sides. but at least in IBM's case, there are interesting undercurrents of PHP support floating around. the wiki Rod Smith and the emerging technologies gang demoed at the Zend Conference, for example, is something that they've implemented at customer sites. so there is at least some recognition that not getting Java involved isn't necessarily bad; do they need to commit to it more fully? you bet.

    Chris: i'm not sure i can go along w/ the order of magnitude comment, b/c in your entry you seem to be comparing PHP et al to J2EE, which isn't precisely fair. there are servlet based approaches that can be accomplished far more quickly and with far less overhead. that said, your basic point is well taken.

    Jaime: just ran java -version on our 1and1 dedicated box via ssh, and got 'command not found.' Java simply isn't there in a lot of environments; doesn't mean that you can't put it there, but it's not universal – not in the way that PHP is.

    we're agreed on the threaded code argument, however.

  • Neil Corlett

    There is a very large community of developers using LAMP. There is a commensurately large community of racked machines offering LAMP facilities. It is certainly large enough for analysts to opine about (:-), and for systems vendors to care about. Sun really ought to support the LAMP stack developers. It is known they care about Apache.

    As far as parallelism goes, many of these machines are provisioning "web host packages" to the SOHO/home user market. If you had 100's on a box (not unusual) then you have a high enough process count for a T1 CPU to become useful, even with a dynamic language.

    The issue with JRE for hosting was it's footprint. If you ran 100 little apps based on Java (and bet they will use a hodgepodge of versions) you could floor a machine easily. PHP was (and probably still is) more appropriate for the use case.

  • Jim

    The JVM support that hosting providers might offer doesn't really compete with PHP, it competes with .NET. Here's why I say that:
    Go to any major hosting provider. They offer shared hosting on either a linux or windows box at several levels. Usually the ~$5-10/month hosting includes PHP on the linux box, or "classic" ASP (e.g. vbscript) on the windows box. These are both dynamically typed languages which have been around for over 5 years, are well understood, simple to use (no IDE or compilation required) and have available lots of code examples, premade apps and stuff to help newbies and old hands alike. Plus, there's not this "fashionable framework/pattern of the month" thing that you see in the Java and .NET space. Spare me the "ASP sux becuz I hate M$" comments; it's been a workhorse for a long time: admit it.
    If you go one notch up in the hosting offerings (about $20/month range) you can get either a JVM (typically Tomcat, not an EJB container) on the linux box, or a .NET CLR on the windows box. Both statically typed compiled platforms, both require an IDE (with its own learning curve) to be truly productive (yeah, hypothetically you can use just a text editor and a command line compiler, but who really does?).
    The market is so saturated that they all must be on a pretty thin margin, trying to undercut each other, so the asking price is probably a good indicator of the real costs to offer the service. The reason that the JVM/CLR options cost more must be that they result in more overhead for the hosting provider (be it more hardware or more management). I don't think it's related to additional licensing costs, because both Tomcat and the .NET framework are offered for free on their respective platforms.
    In the JVM vs. CLR space, it looks like most hosting providers anticipate more demand for the .NET CLR than the JVM, based on how they present those choices on their pages. Most of the ones that showcase JVM support over CLR support seem to cost more, but that's just an impression, not backed by research. On the low-priced scripting side, the LAMP servers seem to dominate.
    So the two questions that a would-be webmaster/developer of a hosted site must answer is, should I use a scripted solution or a compiled solution, and do I want to host on a linux or windows box? (In which order those questions are asked might say a lot about that developer's views).

    But the key is that, in the first tier, it's PHP vs. ASP (pre .NET, "classic" ASP)
    In the next tier, it's JVM vs .NET CLR.


  • Pingback: People Over Process

  • Pingback: James Governor's MonkChips

  • Pingback: James Governor's MonkChips