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
add).
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
code."
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
everywhere".
"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.
Cheers.
Reply to: