[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: The real problem with Java in Linux distros

Hi, Torsten:

On Friday 24 September 2010 23:50:03 Torsten Werner wrote:
> Hi,
> Thierry posted a nice article at
> <http://fnords.wordpress.com/2010/09/24/the-real-problem-with-java-in-linux
>-distros/> and it is mentioned by Linux Weekly News at
> <http://lwn.net/Articles/406884/> with quite a number of comments.

There's one thing those two articles have seen properly: they are their own 
ecosystem (and as such they suffer the "not invented here" syndrome, I should 

Basically, since it's not a technical problem, there's no technical solution.

From the article:

"The problem is that Java open source upstream projects do not really release 

In my opinion, that's doubly false.  Either they release the code (and quite a 
lot "Java projects" do that, so first false assertion) or it can't be "open 
source" (and that's second false assertion).

"Their main artifact is a complete binary distribution"

That's usually true, but as he himself states, it's an artifact, not their 
source (which they usually are glad to distribute nevertheless).

"If you take the Java project point of view, it makes sense: you pick versions 
of libraries that work for you, test that precise combination, and release 
the same bundle for all platforms."

That's, again, right, and "the Java crowd" can't be declared guilty of that 
since the main Java vision was from the beginning "compile once, run 

"That doesn’t play well with how Linux distributions package software."

It's obvious why.

"The Java upstream project consider libraries to be part of the software 
bundle they release. So they keep the libraries at a precise version they 
tested, and only update them when they really need to."

Not exactly my experience.  On one hand, yes, it's true they tend to consider 
third party libraries part of their "bundle"; on the other, my experience 
dictates that they choose third party versions not out of a deep thinking and 
knowledge but out of what their development tools choose or the easiest to 
install bundle comes with.

All of these points to my previously stated factor: the NIH syndrome.  Java 
people usually seem not to be interested on proper engineering practices 
developed through decades and the environment based on the "sandbox" concept 
doesn't help either.  In particular, they tend not to give a damn about API 
stability (that's why they don't pay attention on which versions of third 
party libraries they develop against) and they don't give a damn about the 
environments their work will be deployed onto (the sandbox concept 
pre-conditions them to think there won't be anything but their application on 
a given environment).  Note that this is problematic *even* within the  J2EE 
environment itself: it's not clear the library load order on application 
servers like JBoss; most of the time, despite of the fact of it being 
an "application server" you end up with an instance of the server to load a 
single application since it's the path of least resistance, specially in 
these days of "cheap" virtualized servers.

If that were only a Java problem, I would tend to say "damn with them", but 
being Java such a pervasive development environment (I could start on my 
opinion about how Java gained so much momentum in the enterprise scenario, 
but that's a different story), its bad practices have resulted quite 
contagious and now they are visibile on other environments like Ruby or 
Python development frameworks.

That's for my rant.  I would want to give a solution but ungladfully I don't 
have one.  It's not a technical but a social problem and the only approach I 
can give is social too: give proper value to knowledge and experience and 
give proper value to iniciatives like those from the "devops" group, so 
developers are nearer to sysadmins so they can have a hint about the problems 
their choices can bring down the road.  But once you teach and bring together 
developers and sysadmins is still up to the developers to do the proper thing 
or not.  And I'm afraid that neither the developers' "natural inclinations" 
nor their bussiness responsibles' will be up to the challenge.


Reply to: