Articles / Editorial: Java on Linux

Editorial: Java on Linux

Since the LSB community is rarther calm these days, we hereby throw in an editorial dealing with a different topic. Ian Nandhra wrote an essay about Java on Linux. He reviews the past and current situation and states proposals about how further development should proceed.
Java for Linux, Duck!

Java? Nah! Be honest, who laughed at the last round of Java applications for Linux, or for that matter any other OS? Since the oh-so-sow Java of a few years ago which promised much, but only ran bug-free on a white-board, things have changed significantly.

There is much debate about Linux dominating the Desktop, the Server, the World(!) and the debates have become rather predictable. For Linux to suceed anywhere it needs high quality applications. Anyone writing high quality applications has a number of things at the very top of the agenda:

  1. Code Re-usability
  2. Deployment Maximisation
  3. Leveraging existing code (thats Other Peoples Code, or OPC for short).

Java promised the holy-grail for ISV's; write once, run anywhere, Extensibility of Libraries and OOD development. In practice, Java turned into a write once, run on any JDK-1.x.y where x.y are any permutation of what the OS and Hardware vendor chose to release and force you to use.

Java - they love to hate it!

OS vendors mostly hate Java, Hardware vendors (by and large) like Java. Why? Because the OS vendors want to lock the customers into their OS (be it Windows, Linux, FreeBSD, UNIX, BeOS) and the best way to do that is to lock the ISV's to a particular technology. No surprise that Microsoft is not exactly Java friendly, it has a vast Win32 API investment at risk. The Hardware vendors like anything that sells their hardware, and making it Application friendly is one way to go. No surprise that Javascript has not been universally adopted.

Java is still a no-brainer language for ISV development, we just have to be rational about its little problems;

  • Like speed.
    Java in its interpreted form is never going to compete with a native compiled language. There are some significant things that can be done to make things managable on the Desktop. Distributing the application, increasing CPU speed, reducing the usage of Strings and other coding tricks that really make things faster. The demise of the Java-chip does not reflect lack of interest in Java, rather that the regular PC chips are increasing in power so fast that a dedicated Java silicon seems a little pointless.

  • Like which JDK.
    It has not been ordained on stone tablets that you have to use the latest version of anything, so stick with the JDK that works for you and ship it with the application if you have to. Not perfect, but workable.

So whats the deal for Java and Linux? We all hear that Linux is opening up the server, but Java is not really a server product. Or is it? Enterprise Applications written in Java involve large numbers of class libraries and patterns, usually managed by a Factory on a network thus increasing network traffic and server overhead.

There are several ways to improve server performance. Install a cool SMP multiprocessing Linux kernel, or more flexibly, use a larger number of smaller servers. Called variously (depending on seemingly random conditions) Application Servers, Applet Dispensers and Pattern Factories, these servers can run on hardware costing from as little as $399 (this is not a typo). Very compeditively priced, the last thing we need to add is add an expensive OS such as NT (or UNIX). Enter Linux! The world of Linux based Application Dispensers and Pattern Factories is almost here.

Somewhere in the back-end will lurk a large database. As if by magic, the large database vendors seem to have Linux ports available for low cost or no cost (i.e. free). A database server that would have cost many tens of thousands for the hardware, OS and Database engine now costs a few thousand - probably less than $5K.

We now have most of the ingredients for a real Client/Server Java applications environment, at a price people can afford. All it needs are those applications. Enter IBM.

The quiet Revolution.

(get the flame throwers ready!) In all the excitement surrounding Linux, a quiet revolution has been going on in the Java world. The days when Java was slow, buggy and non-portable are not exactly gone, just less widely encountered.

Big Blue is back.

Had they gone anywhere? IBM have probably the largest Java development program in the world. The details really need to be the subject of another pitch (any chance Ed?) but they have been contributing Java code and products to the ISV and Java Communities for some considerable time. Java is a natural language for Networks and the Internet. With global Electronic Commerce valued at some $460Bn by the year 2000 (who makes up these numbers?) Java has some obvious attractions. 460 billion attractions :-)

So lets just speculate that the largest, most ISV friendly and Internet orientaed Java project on the planet is backed by really affordable Client hardware, highly configurable low cost servers and free database engines. What's missing? A free, scalable UNIX-like OS. Just add Linux and we are all set. Well, almost ;-)

The gory details will have to wait for another article, and I will end by backing Nick Petrely's recent observation about NC's. Based on what I have seen, the first winner of the Desktop battle is the NC and Java. From large strategic components to frantic development of Java class libraries ($460Bn is an awfully large incentive), the stage is set for a revolution in Client/Server computing with Linux threading through all of it.

The world just woke up to Java on Linux. This is going to be fun.

Till next time.

Ian Nandhra

Recent comments

04 Dec 2007 02:44 Avatar Dartshop

Re: Java on Linux


> This is going to be fun....

I wouldnt call it fun. We are just implementing a new platform and it is anything but fun.

10 Sep 2007 18:12 Avatar bogemot

Java on Linux
This is going to be fun....

24 May 2007 05:10 Avatar gianni_p

Linux
I am a new Linux user, therefore I must be concerned first with the whole program. I am strained, which wait difficulties for me.

06 Mar 2006 19:19 Avatar kevinhero

How to configure PPPoE client over IPv6?
I'am a new linux user.These days,I'am doing an experimentation about configuring PPPoE client and server.But I met some difficulties.If the server supports only IPv4,they correspond well with each other.But if the server supports only IPv6,the client can't send IPv6CP packets and can't establish a link with the server.Can anyone help me?

02 Nov 2004 09:20 Avatar gbtmud2

SPEED, dangit!
My main gripe with java-- as you mention-- is speed. In
order to create good-looking GUIs you use Swing, which is
probably the slowest GUI toolkit in widespread use. What
Java needs is a bytecode-to-machinecode converter.
Since all the JVM does is translate bytecode to native
machine code on the fly, throwing out the results after it's
done, why couldn't there be an option to save the
translation, so it could run faster in the future?
Since everyone running Java programs has a JVM anyway, if
the JVM came with a translator, one could simply distribute
the bytecode version and the end user could run the
translator and create a binary optimized for their machine.

Screenshot

Project Spotlight

Kigo Video Converter Ultimate for Mac

A tool for converting and editing videos.

Screenshot

Project Spotlight

Kid3

An efficient tagger for MP3, Ogg/Vorbis, and FLAC files.