Java + LAMP Hosting:Stallmanned

I just finished an all day seminar on BIRT the partially Open Source report writing package available from Actuate[the Core is open, the extended services are closed and the two packages are, according to Actuate people, moving in different directions – More on this in a later posting]. BIRT software is impressive especially with its strong connectivity to a wide range of database connectors and services coupled with good charting, reportwriting and multiple output capabilities coupled to desktop and web designer tools. Also the ability to link in easily to JavaScript and Flash make it attractive for creating Web 2.0 mashables. A Web developers dream….

NOT SO, WHOA, Hold Your Horses.

Through the wiz-dumm-headedness of Richard Stallman [aided and abated by Eric Raymond], Java was declared not pure enough for inclusion on Open Source software distributions – so to this day most LAMP distributions do not include any Java code and/or servers[Microsoft is still laughing all the way to ever greater Server market share due to this “oversight”]. So BIRT [nor JasperSoft nor Pentaho] wont run on 5 different LAMP hosting services that half a dozen client use. My own hosting services, 1and1 and ICDSoft, have also given the Nix to Java and any availability of the JVM – except if one wants to buy a dedicated server at roughly 5 to 8 times the price of a shared server. My primarily small business clients look incredulously at me when a)I even suggest a move from their current hosting services and b)scoff at the price increase.

Ditto Doom for Alfresco, Jaspersoft, Swing, Pentaho and dozens of other great Java applications despite all that Sun has done to make Java Open Source. It all goes to prove that who needs enemies like Microsoft when you have friends like Richard Stallman who remained curiously mum when Sun’s Java was attacked by Microsoft ‘s forever obsolete JVM on Windows. Such a Chumpion for free and fair software practices.

So Now What To Do

This is not the first observation of Java and LAMP not mixing well together. See 3 years ago the prophetic note here . And so I very likely I am not the only one looking for Java+LAMP hosting services that charge less than $15US/month for shared server configurations in North America. There are several smaller services in Europe but they appear to be developer shops that offer clients hosting as required. If anybody has some recommendations please post a comment below. Thanks.

5 thoughts on “Java + LAMP Hosting:Stallmanned”

  1. You’re joking, right? You do know there was a time when Sun wouldn’t allow Linux distros to distribute the Java runtime and SDK, right?
    ===================Admin Direct Comment=======================
    As a Linux user for over ten years I find this one hard to believe since I use Linux as a primary Java development platform. Here are two major references to availability of Java on Linux from 2001:
    J2ME on Linux joins Java 2 Platform, Standard Edition (J2SE(TM)) and Java 2 Platform, Enterprise Edition (J2EE(TM))
    to provide expanded Java technology support on Linux. With the union of the Java 2 platform and Linux, end users can run thousands of Java technology based applications and Java technology developers can write and deploy applications based upon the most advanced Java platform on the Linux operating system.

    2)How to install Java development tools on Linux
    Both references are from 2001.
    Can you provide two or more similar links/references to back up your claim? admin

  2. Its not Stallman’s fault, its because Java technology is not well suited running under a shared hosting service.

    LAMP works well under shared hosting because every request is a separate lightweight process, and state is not maintained in memory on the web server, but is offloaded to a database or filesystem or something like that. The Java Virtual Machine, on the other hand, is heavy, and not well suited to sharing. While possible, its not really a good idea to share multiple applications on a single JVM, because if one of those applications misbehaves (for example, if it has infinite loop or a memory leak), it will bring down the whole raft of applications on that server. If I was a LAMP shared hosting provider, thats not an issue I’d want to deal with either.

    Thus, the only sensible way to provide shared hosting of Java apps is for each customer to have their own JVM. But, like I said, JVMs are heavy, not like LAMP processes, and need (for a decent installation) at least 512 MB of memory set aside for each one of them. And if you want those kind of resources, its going to cost more than the typical el cheapo shared hosting LAMP solution.

    1. Spike – I will concede the following: JVMs still cannot match the speed of compiled C and C++ apps on most OS environs be they Linux , Mac/OS, Solaris or Windows. They are roughly 40-50% slower than the best C-code but within 65% of the best C++ code – see the benchmarks here. However, I will not concede that JVMs are poor for shared hosting environs.

      First, my LAMP [XAMPP] comes in at slightly less than 200k with simple WordPress app while my JVM+Tomcat comes in at slightly more than 250K for some basic web graphics display program. This is negligible given that my hosting provider pledges a dedicated 2GB of memory. In addition, with much improved memory and thread managements over the past 5 years- JVMs are becoming much more efficient in sharing resources.

      Finally Stallman was not alone, Eric Raymond also held out for an ultra pure Java allowing ASP and Windows to take market share away from LAMP as seen here. Thanks guys.

  3. It’s worth remembering that at the time he wrote the article, Java was indeed proprietary software. While free compilers for Java did exist, the standard libraries for Java were still proprietary.

    Thankfully, this problem is no longer an issue, and Sun and now Oracle, is continuing to free Java.

    1. Matt – Java was for all practical purposes Open Source in comparison to say Apple’s app tools and stack or Microsoft’s whole Windows and .NET stacks. Sun’s Java Community Process was light years ahead of Apple and Microsoft . And the reason that Sun kept the Community Process on was the actions of Microsoft and IBM who were only too anxious to proprietize and/or influence Java’s development to their own ends – witness the dropping of all Java development at Redmond followed by perpetuating an obsolete JVM [for which Microsoft had to pay Sun $2B in fines] and the non-standard GUI extensions in Eclipse by IBM.

      However,I suspect that if Richard Stallman and Eric Raymond had spoken out just as forcefully against the creation of an obsolete JVM by Microsoft – poisoning the well of all development, then Sun would have been more inclined to open up Java in a GPL which they eventually did in 2006.

      However, I suspect that Richard Stallman was to an extent “protecting his GNU Linux, C/C++ et alia” from a Java incursion. Its the only reason I can see for his a)no help for Java against Microsoft and b)late 2004 attack against Java when Sun was clearly opening up.

      Net result: development community suffers the consequences as a)Microsoft scuttles broad adoption of both Java and Web DHTML [remember from 2002 til 2007, Microsoft stopped all upgrades to IE other than security fixes. This left promises to meet CSS, HTML, JavaScript and DOM standards not only unfulfilled but all W3C standards work stalled – just go and see the dates on progress notes at W3C site]., b)apps become further proprietary and silo-ed because all key developers are able to protect their turf; and c)

      Congratulations Richard Stallman [and Eric Raymond], in being over zealously “open”. You have sabotaged and scuttled open development such that Bill Gates and company continue get to walk to the bank with huge monopoly profits, deliver software travesties like Vista, and Linux, except for the Google Android variations on Mobile phones and maybe Netbooks, languishes deeply last with 2% ormore likely less of the PC marketplace.

Comments are closed.

Pin It on Pinterest