Carrez: The real problem with Java in Linux distros

This is a common misdirection by Java people.

All the distribution packaging tools have pretty much the same requirements. This is so true the commented article was written by an Ubuntu person (ie .deb), and the people commenting there had no problem saying the same in rpm terms. You'll see the same comments and complains in all the Linux Java forums, be it Fedora, Debian, Gentoo, etc side.

Python, Perl, etc have no problems being packaged because they have actually tried to build a functional module systems and there are not so many ways to make one that works, so the result maps directly to rpm/deb/etc

Those packaging requirements are so generic SUN/Oracle are pretty much taking them as-is to implement the Java module system planned for Java 8.

The problem with Java and Linux is not that Linux packaging is too foreign, it's that Java people never tried to build a working module system before, and instead of listening to people who did, have been busy ignoring them and re-making the mistakes that rpm/deb solved years ago.

You know what they say about ignoring Unix only to reinvent it? Linux/BSD packaging is the next stage of Unix. I happened a decade ago.

Thing with rpm (and anything like that) is that you need CONVENTIONS. You know, how you name things, etc. The reason apt/dpkg work so well is because all the distros that use it also use the debian naming conventions.

rpm is a pig because the second major adopter of it (SuSE) is actually *older* than Red Hat, and has (had?) a very different naming convention (SuSE is, iirc, a Slackware derivative originally). So the naming convention for rpm was broken very early on.

That's why LSB is so important, and why I'm a bit disappointed in LSB, because it hasn't really addressed that problem as seriously as I think it should (although I'd be one of the first to admit it's a very hard problem, both practically and politically).

Cheers,
Wol

I think Brocade at least has written their HBA management tools in Java (even under Linux), so they have the same GUI feel no matter the OS used

For this kind of setup (pile of java libs and jvms) testing does *not* require very qualified people, only enough people to exercise all the components till the editor is reasonably sure there is no obvious problem.

Knowing the environment is a complete joke when you just pile up *different* versions of the same jvm/java libs that all have different bugs and you only worry about not hitting them.

Why should I take that personally ?
I described a mode of development I don't agree with (piling up components with random versions and minimal code tracking and then using many testers to try identify the exposed bugs and fix them before the customer notices).

And if you don't think that's how most big Java projects are "qualified", you've never looked below the shiny presentation veneer. They rely heavily on brute-force testing (either cheap testers or the same simulated via loadrunner and friends). That works to limit the number of obvious problems (and customer complains) on the exact configuration tested. But that's never been a good way to validate a design is solid enough to withstand the test of time, and can evolve later when requirements change. As soon as the environment changes, even minimally, everything needs to be redone (write once, run once, not everywhere)

Euh.. I've seen many java-based webapplications of which the developer says, I need this particular version, don't change it, the application might break otherwise.

This problem is very real, but how bad it is depends a lot on what types of things you are doing on your linux box.

Unfortunantly, the desktop application space is the worst area, and the "Desktop Environment" projects (as opposed to just applications that run on the desktop and will work on just about any desktop) are espcially bad. They seem to think that they dictate the entire system and nobody ever has any reason not to do things the way (with the specific software and version) that they prefer.

> but in practice the applications depend on each other way too much, can't easily downgrade/upgrade a single application.

Usually they depend on the same libraries, not each other. I know KDE has a stable ABI; why they choose to update everything at once probably has an explanation... I can't think of any right now.

> The soname changes. That has nothing to do with packaging, sloppy or
> otherwise. The runtime linker assumes that libfoo.so.18 and libfoo.so.19
> have different ABIs since the _whole point_ of the soname versioning is to
> manage this ABI compatibility.

Copied from stackoverflow.com (I couldn't find a HOWTO for some reason):

> The way you're supposed to form the x.y.z version is like this:
>
> 1. The first number (x) is the interface version of the library.
> Whenever you change the public interface, this number goes up.
> 2. The second number (y) is the revision number of the current
> interface. Whenever you make an internal change without changing the
> public interface, this number goes up.
> 3. The third number (z) is not a build number, it is the
> backwards-compatability count. This tells you how many previous interfaces
> are supported. So for example if interface version 4 is strictly a
> superset of interfaces 3 and 2, but totally incompatible with 1, then z=2
> (4-2 = 2, the lowest interface number supported)

So if the developer bumped the major version number from libfoo.18.0.0 to libfoo.19.0.0, he basically waved a big red flag saying "ABI change!" In theory, at least.

It is part of the DRM.

If I recall correctly, I read a long time ago a thread on doom9.org where people were reverse-engineering the VM used by BD+ (one of the several parts of the Blu-ray specification written to make copying harder). They found out it was a heavily-obfuscated variant of the DLX architecture, and reverse-engineered most of the system calls programs written on it could use. An open-source emulator was written which could emulate the programs from the discs they had.

However, they had a problem with newer discs, because one of the system calls on the code found in these newer discs called into the Java code, which they did not emulate. I do not know how or even if they worked around it; I did not follow the developments or even the thread (I just read it once).

You can probably read more about it on some thread linked to by http://en.wikipedia.org/wiki/BD%2B .

Disc menus, online content, various other things. Occasionally, updating the AACS keys or player firmware image.

It is obviously always possible to do stupid things in any language. But Java makes that harder. Just like a good road system saves lives.

Java also allows incredibly powerful IDEs, which not just allow poor developers to make a living but also allow senior developers to quickly pinpoint and fix/refactor stupid things.

Java limitations are frustrating for good developers. But it rocks for the real world outside LWN.

void removeEvenNumbers(ArrayList<Integer> l) {
    for(int i = 0; i < l.size(); ++i)
        if (l.get(i) % 2 == 0)
            l.remove(i);
}

void removeEvenNumbers(ArrayList<Integer> l) {
    int j = 0;
    for(int i = 0; i < l.size(); ++i) 
        if (l.get(i) % 2 != 0)
            l.set(j++, l.get(i))
    l.removeRange(j, l.size()
}

filter(new Predicate<Integer>() { public boolean doIt(Integer i) { return i % 2 == 0; } }, someArrayList);

Since space is cheap, they can provide a file with the source code and another file with all the libraries bundled together.

I personally like Pidgin's versioning scheme: http://developer.pidgin.im/wiki/PidginCommunity#Whatwillt... which I (among others) proposed. Every once in a while people do get confused about how a change would affect version numbers, but once people get the feel of it it's been going pretty smoothly. It takes work to define a versioning policy (and maintain that policy) but most projects that interact with others need to have one. Even if you were just an external contributor, watching the commit mailing list and raise concerns when something breaks ABI shouldn't take that much time. One may even be able to script this and diff only the .h files on release so the amount of manual work is reduced.

> I also presume there's no Linux distribution which doesn't have pulseaudio but has Firefox 3.5+ - you can't have this in Linux easily, but I can install Firefox 3.5 on the 9 years old Windows XP.

Gentoo, Arch, CrunchBang, Slackware, ...

> I also presume there's no Linux distribution which doesn't have pulseaudio but has Firefox 3.5+ - you can't have this in Linux easily, but I can install Firefox 3.5 on the 9 years old Windows XP.

Try installing Win98 audio subsystem to replace Windows XP's and see how far you get.

I know that in Linux-think it's hard to separate between applications and operating systems. We all have a tendency to want to think of them in a unified item... which is good in one way, but bad in another.

-------------------------------

The problem is that in Linux there is no real separation between what is 'applications' and what is the 'OS'.

I am sure that we all agree to the concept of 'do one thing right and do it well' and the concept of 'layers'.

That a complex system should have layers were you can work on improvements at one layer without disturbing the upper layers very much.

Like: Oh, I can upgrade my wireless drivers without breaking the browser.

Right? That makes sense.

That is why with the Linux kernel they make a clear distinction between 'No Internal API or ABI!!!!' and 'We support external API/ABI compatibility as a high priority!!!'.

The idea is that:

* 'Well we want the freedom to hack the kernel anyway we want. If we depend on internal ABI/API compatibility then that will hold us ransom to popular proprietary-only companies that will use their popularity to control us while contributing nothing!'

* 'Well, but we still want people to us our software. So we need to make sure that we can upgrade and change the kernel but not piss all the users off and break everything.'.

So, right: LAYERS.

So the API and ABI for Linux kernel takes the form of various IOCTLs, Posix file systems, Posix IPC, sockets, semephores, /dev directory, /proc, sysfs, etc etc etc. That is Linux kernel's API and they generally do a good job at preserving compatibility between different versions. Not 100%, but pretty decent all things considered.

But here is how things look from a distro perspective right now:

{Linux kernel}(Linux ext. API) --- > {OMG USERSPACE!!!!!1111oneoneoneo}

Everything above the kernel is a mush. A mixture of a hundred different things that people simply slap together and get working in whatever fashion pleases them.

For the most part I can build my own kernel and slap a Linux distro on top of that and it'll probably function decently. Sometimes I can break stuff, but it's going to be relatively minor. I can even quite happily use a Redhat kernel with Debian and probably things will work fine.

But compared to that installing a Debian packaged software on Redhat then all hell breaks loose and it's going to be just about as shitastic as it can get.

I can compile my own software and it'll work with pretty much complete disregard to the package system. I can also do binary downloads of many pieces of software... like Firefox or Chrome or Blender3D and as long as I do not try to work with the package management software then it'll usually work out very well regardless of the distro.

Even with proprietary software like Opera that uses C++ and QT, which I am told is going to be shit because of ABI issues and whatnot.... the binaries they provide are compiled the same completely regardless of what distro they are installed on.

Go and look at the different packages that Opera offers... They have a dozen different packages to work with a dozen different distros, but they only have a couple actually different binaries they provide. Last time I looked they would provide the same exact binaries for fedora, debian, ubuntu, etc etc... with the only significant difference being that they supported a old version of Ubuntu that was built using GCC 3.xx or something like that were (I am guessing) they did actually run into C++ ABI issues.

All the incompatibility exists in the package management systems. And it's just stupid stuff like 'were to stuff the documentation' or crap like that.

So Linux and distros are already doing something right. They just are not aware of it on a higher level or something like that.

"The problem is that the Linux users can only get the version that is in that version of the distribution, they can't have an older or newer one."

some distributions like fedora/rhel have policies that specify only one version of a lib, but there is nothing in the package manager that keeps you from having multiple separate packages with different versions of a lib. I know that debian does this a lot with libfoo and libfoo12, etc. it just has more maintenance overhead to have another package to keep updated.

> The problem is that the Linux users can only get the version that is in
> that version of the distribution, they can't have an older or newer one.

I guess you've never paid for Linux then? RHEL (and I'd assume all distros. people actually pay for) has every version ever released available, just a simple "yum downgrade" (on RHEL-5) away. There are also the minor releases too, like 5.3.z, where you'll just never even see some newer versions of packages.

The big problem with bundling libraries is security. But for that, it'd be quite reasonable to let apps bundle everything from zlib to their own versions of Webkit.

The problem is that when a security problem arises, you have to find every copy of every library in every app, all different versions, and make sure they're properly patched.

Maybe if there was a reasonable, nearly universal way to declare that your app bundles these versions of these libraries, with tools that automatically manage the bundled sources, it'd be ok. But what happens instead is that each bundling app integrates the bundled libraries into its own funky build system and often starts patching them in odd ways. you can almost never just drop in fresh upstream sources.

At least Maven helps with this - you may declare dependencies on specific versions, but you don't pull them into your source tree. They're only bundled (optionally) at build-time.

> I saw firefox and chrome get their share of ire for forking libraries into their source tree not long ago.

After the libpng bug in June, I don't blame the distros for being unhappy.

>> With the java way a user of 100 java apps will have 100 versions

> But every one of those 100 apps probably works with respect to the
> features that the app developer tested. Nobody else has gone in and
> changed something and screwed it up.

And what happens when the app needs to be updated to add new customer-requested features? It can't because the local fork of Java deps is missing the features that were added in the real upstream version. So everything needs to be re-done.

The Java way does not solve anything it just delays the payback (That's one reason big Java apps cost astronomical prices, and have slow release cycles. The language is nice and should enable cheaper/faster development, but the abysmal release practices add up in multiple ways in the long term)