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

[Daniel Pittman]

Ben Coughlan <ben.coughlan at gmail.com> writes:

> I've recently done a lot of work with OSGi framework, which no one I ask has
> ever heard of.  So in a nutshell an OSGi framework provides support for
> modular Java applications (life cycle management, dependency resolution,
> dynamic classpath generation, etc.)

Interesting.  I took a look at that, at the "executive summary" level[1], and
it looks like it is more or less an ABI version management and ...

> Combine that with the repository concept native to Maven, you have a pretty
> fantastic deployment mechanism.

... distribution mechanism.  Which is nice and all, but ...

> The OSGi Bundle Repository is a small app that runs inside an OSGi framework
> (inside a JVM) that behaves exactly like apt.

... now I have apt, which works like apt, and OSGi/Maven, which works like
apt, except where it doesn't.  It doesn't work with my apt browsing, or get
updated through apt.

> It allows lookup of OSGi bundles and gathers all their dependencies when
> they are deployed.
>
> The best thing is that all that can be accessed by an application.

It also doesn't play nice with the rest of my infrastructure: I can't use the
existing Debian package repository we have to carefully control software
promotion to our infrastructure.  I can't use the existing build tools that
handle Debian package construction and testing, or version management.

Now, none of that is intractable: I can deal with building a second set of
infrastructure to manage that, just like I can to handle Debian/Ubuntu
divergence, or Debian/RHEL, or even Debian/Win32 or Debian/MacOSX divergence.


Every time I have to introduce one of those, though, I have more work to do:
I have to make sure I can trust the upstream to handle security sensibly, to
build the automation and repositories, to understand the integration, and so
forth.


Being available to the application is also ... fun.  Does this mean I /also/
need to audit every OSGi application to make sure it doesn't point at a random
Internet accessible repository of software managed by someone random?

> My most recent desktop application was written completely in Java and runs
> in an OSGi framework.  Unfortunately we made the switch halfway through
> development which lead to some teething problems...
>
> To summarise, I find OSGi fixes most of the problems discussed in this
> thread so far.  It has been around for 10 years now, but is only just
> starting to come into mainstream use (fingers crossed).

So, how does it address the issue that there are often ABI-incompatible
releases of software outside the OSGi certified stack?

How does it address the desire to have Debian (and RedHat, and SuSE, and
Windows) native packages of the system libraries — and as few of those as
possible, because every library needs security support as well as runtime
support?


Within the scope of the stack it works, but "OSGi lives in a universe parallel
to the distribution" is not a /solution/ to the management problems I have,
but indeed, is a large part *of* the problem. :)

Regards,
        Daniel

That said, it looks like the deployment stuff is, indeed, cool, and a lot of
the OSGi bits and pieces are good at addressing other, very real, issues.

Footnotes: 
[1]  Because, hey, if it is light enough for an executive even I can probably
     make sense of it. :)

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