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

[Daniel Pittman]

Sam Couter <sam at couter.id.au> writes:
> Roppola, Antti - BRS <Antti.Roppola at daff.gov.au> wrote:
>> My $0.02 on possible reasons:
>> 
>>  - I suspect that there are still lingering perceptions of performance
>> (that may or may not be justified)
>
> Depending on your use case, they are sometimes justified. The Java VM has a
> huge start-up cost, and once it's running it demands quite a bit of memory
> compared to a native application.

The memory use is mostly because of the awful design of the Java standard
library, not something inherent to the platform.  I /hope/ that it has
improved in the years since I seriously looked at it, but back in the day it
had two key problems:

First, it encouraged memory waste through multiple layers of adapter classes
and type-casting methods, because many of the "generic" objects and data
stores were not generic enough; that lead to extra classes and, consequently,
extra memory used to support them.  /Hopefully/ the generics in newer Java
releases have addressed that.

Second, it was dreadful in terms of garbage generation: many of the methods
required the generation of garbage objects and/or temporaries to perform
common operations, leading to enormous wastage compared to a better designed
standard library.

Again, I hope that time has taken the rough edges off those issues and
improved things so that there is less distance between the Java code and
native code.  Certainly, in the Java applications I support there is little
distinguishable difference[1] in performance.


I guess that code sharing is also more limited than for native code, so
multiple disparate Java applications, each with their own VM, would cost more
than native code that can share read-only pages more effectively.

> The most popular Java GUI toolkit is Swing, which has a reputation for being
> unresponsive. It's much better than it used to be, but it can't yet match
> the snappiness of a well-coded native application. SWT promises to fix that,
> and Java bindings for the GTK toolkit exist.

*nod*  Again, this is poor library design on the part of the Java architects;
a number of their choices did, in my opinion, the platform no favours.


>>  - People still held fears about proprietary interests in the base
>> platform (like Mono)
>
> I don't think these fears are valid anymore, but there's a lot of inertia to
> overcome.

Also, as I noted elsewhere, there are distribution problems from the way the
platform has handled code compatibility.  This makes it harder to distribute
Java applications, which makes them less visible, which makes them ...

[...]

> Also, Java just isn't seen as a "cool" language. It's seen as a bulky,
> stodgy enterprise-only language that's no fun. Python and Perl get all the
> girls.

... less cool.  Plus, more work to set up. :)

Regards,
        Daniel

Footnotes: 
[1]  Well, except that most of the Java web servers *also* use an Apache front
     end, so now I have two complete web service stacks running, not just one.
     See also "bundle all your binary dependencies into the application."

-- 
✣ Daniel Pittman            ✉ daniel at rimspace.net            ☎ +61 401 155 707
               ♽ made with 100 percent post-consumer electrons