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

[Ben Coughlan]

Overall I'd point out that it's not trying to do all those things on  
an OS scale.  I'd liken it more to application level plugins, only  
_all_ the bits of the application are plugins.  It's package  
management for a JVM.  Much like Java developers write code for the  
JVM, not a particular OS.

Coming back to the original question, I think Java gets a bad rap  
because people miss the idea that their applications will be running  
on the JVM not a particular OS.  They then complain about it when it  
doesn't do all the things their native libraries do, forgetting all  
the benefits of the JVM (which they were never paying attention to in  
the first place).  When one does accept Java for what it is, they  
suddenly realise that everything makes sense.

Having recently had a discussion with my Managing Director about  
weather or not our next project should use .NET after some MS reps  
offered piles of free stuff if we did, I'd like to point out that Sun  
never campaigned that hard to lock developers in to using their  
technologies.

Anyway,  I'm young and naive so I should probably stop trying to argue  
- the only thing I find more annoying than fanboys/girls is when I  
start acting like them myself.

Ben

On 11/07/2009, at 5:40 PM, Daniel Pittman wrote:

> 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
> --
> linux mailing list
> linux at lists.samba.org
> https://lists.samba.org/mailman/listinfo/linux