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. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
