[clug] Why isn't Java popular on the Linux Desktop?

Francis James Whittle fudje at grapevine.net.au
Sun Jul 12 01:58:26 MDT 2009


On Sat, 2009-07-11 at 21:55 -0700, James Ring wrote:
> What do you mean by "lazy"? You mean, people who don't want to worry
> about differences between Solaris and Linux or Mac OS X? Where I work,
> if we all had to worry about this all the time, we just wouldn't get
> any work done. Raising the level of abstraction above the individual
> platform frees the developer to discover and solve more interesting
> problems and Java (and other languages) do this very well.

Of the people on this list I'd expect you to be able to pick my
hyperbole.  "Lazy" is really "people who wish to work more efficiently
than to address every case they might possibly need to target even if
they're not aware of it" and it was just, well, lazier to say "lazy."

Now, the examples you've chosen are not the best because at the
application level the system differences between Solaris, Linux and Mac
OS X are more or less elementary (after all, they're all largely POSIX
compatible), and levels below that are not where Java aims to tread.
User Interface wise, yes, there's differences, but there's other ways of
performing that abstraction that might be more efficient.  Things like
QT's platform support and the numerous projects to get native rendering
for GTK+ on platforms other than X11 are encouraging.  Things that are
more troubling are older versions of Mac OS (which no-one cares about
anymore anyway) and Windows (I really wish we didn't have to care about
this anymore).

The indirection I spoke of wasn't just about JVM either though.
Coming from a C/C++/Perl point of origin, one of my biggest gripes when
learning Java is that when people say it's "object orientated" they
really mean object CLASS orientated.
For an example of what I mean, take method pointers as an example.  Java
passes everything by reference, but you can't reference an external
method from a class.  Instead you have to abstract a class and install a
virtual or override method, and you end up with code snippets like:

static a1Option doPrime = new a1Option
      ("Prime Number Checker",
       "Enter an integer value: "){
         public void run(){
	   //Do stuff...
	 }
       }

This is great for class-wide callbacks where only the data changes (and
even when normally only the data changes), but sometimes you want a
different method for each object.  It's actually easier to perform this
in C, which also doesn't spam your build tree at compile time with files
named like interface$number.class *for every relevant object* that have
to be included in the distributed bundle.

I'm still perching on the edge of my seat with bated breath and drool
hanging out of my mouth for Perl 6 and Parrot which should combine the
best parts of these.

> I guess. If you are going to spend x hours writing software, wouldn't
> you want to maximise the number of platforms it runs on? Maybe it's
> just me. Anyway, there are many problems with targeting Linux as a
> platform for desktop applications beyond which language you choose to
> write the application in.

Believe me, I know the pain in maintaining cross-platform applications.
I was the one that made it possible to press the italics button in
Abiword on Linux with reckless abandon and no fear of it crashing the
entire application because you didn't have that variant of the
particular font you were using installed;  Most of the time I spent on
that was making sure what I did wasn't going to crash the Windows or
MacOS version instead.  Fortunately for me, the code base in question
turned out to be well separated into common and platform-specific code.

It's true that Java does make this kind of development a lot easier.

On the other hand it makes things like reading from files painful to my
file handle addled brain: First make an object that owns and refers to
the file handle.  You'll refer to THIS using another object that handles
buffering.  If you want any file position information, you'll need to
use a particular subclass of the buffer class that is capable of
retaining this information.  Why is this?  Why not just try anticipating
what people want from a file and implementing that in one class?



More information about the linux mailing list