The Death of Java (Packages) | Hacker News Reader

The Death of Java (Packages)

lists.fedoraproject.org

Good. I don't think anybody should use them and I hope nobody actually uses them.

If over a decade of doing Java on Linux has taught me anything then it is to avoid using anything Java related from any Linux distribution and instead "install" (unzip or untar) what you need yourself.

I don't see why Fedora needs to build their own versions of JARs instead of using the ones the projects builds. The only answer I heard is "this is how we roll". It seems like they have this one process built for C system libraries and try to use it for everything whether it makes sense or not.

The only exception I can think of is if you're on RHEL and want to use the RHEL Java because of the support contract.

The "competing pkg-manager" issue is still unsolved.

Rarely does it makes sense to manage libraries centrally in a distro if all the developers of the language ecosystem use their own package manager.

I develop java and I never even had the idea to get dependencies through my distro. If there is zero buy in from the devs, all the work of integrating the central managed lib classpath is on the port/package maintainer.

I think most of npm/mvncentral/cargo/pypi/go+git/cpan/rubyforge don't have distro packages.

The work is very valuable for the user facing applications, but I have trouble seeing it continue apart from essentially treating it like statically linked binaries and automate more based on that.

I don't want to have to manage N different package managers. I want one that keeps all the packages up to date and applies security updates.

Not the mention the problem that some packages depend on multiple language ecosystems, and the separate "managers" can't even begin to cope with that.

The problem is Java packages are converged around the Maven central repository which is not compatible with the RPM way of doing things. (it's a packaging mess somewhat halfway between RPM and NodeJS...)

Since most Java developers use something other than an RPM based packaging system (hey, it runs anywhere ;) they simply don't care about it which pushes the impossible job of creating native packages for 2,5 million Maven central packages to a maintainer. You don't need a maintainer to fix that mess, you need an army or accept sometimes it's more opportunistic to use soms non-native technology.

....quietly reminding the "good, Java sucks anyway" crowd that a vast amount of actually-quite-important commercial software has the JRE as a dep.

Like, ok at my end, I kind of shelled out for a license for JetBrains DataGrip, and I'll be really pissed when it stops working on my laptop.

Oh, right, and what if I need to use Gephi? I mean, it pisses me off regularly, but for some stuff it's, like, the only sane way to proceed. Is that just another oops?

Suddenly my Linux desktop is looking a lot less appetizing.

I've been complaining about this problem for two decades: FOSS has a boring-work problem: most maintenance jobs are not exciting, and yield minimal recognition while taking up enormous amounts of time. It's simply irrational to do them.

Commercial software manages this by paying people to do boring work, compensating people with dollars for their otherwise-irrational decision (making it rational.) The pot can be sweetened as need be to keep 'bums in seats'.

But because we compensate one another in attention and reputation (in a manner that is surprisingly reminiscent of the Artworld), we can't just collectively decide to find e.g. maintaining a critical part of the past twenty years of computing patrimony is as hot as greenfielding "X, but in Rust." (and I say this as a burgeoning Rust dev -- it's a beautiful language and ecosystem, no offense meant.)

I mean, we can work on a cultural shift, but we'd best get started as it will take years.

There's nothing preventing you from running Java based applications on Linux. Probably there's already a JRE bundled with the commercial applications you're using.

The problem here is some people thought it would be a great idea to use their distribution package manager to also manage Java libraries. Since those are normally bundled with applications you have to manage a lot of incompatible versions and dependencies requiring you to package the entire ecosystem which is a herculean task. That's not a question of boring work but of not being able to scale because you want the whole ecosystem on your terms while not providing value to end users. (and quite a lot of negative value since all packages including the base JDK have been out of date on average the last 15 years)

FWIW, the article now has an update clarifying that it's not the OpenJDK (or JRE) packages that are being orphaned, nor suffering from poor maintenance, but "software written in Java". I suppose that would mean libraries or applications.

The JRE and JDK should continue working fine, as should any third-party software that just requires one of those.

Citations, or rather, arguments needed.

I wouldn't claim Java is the best language, but I don't see obvious deficiencies in JVM, in comparison (good, well thought-out comparison) with alternatives. Same for language - not only Java runs a hard task of strong backward compatibility for the third decade, it actually managed to implement some afterthought additions tolerably.

So - while in the end the author might still be correct - arguments needed.

the lack of bit intrinsics and unsigned integers was a show-stopping pain for a cancer genomics startup I worked at, where losing even a single bit here and there has huge performance cost in Apache Spark at the scale of genomic analyses over large datasets.

Would be glad to hear details.

From APL point of view C could be conidered below "barely tolerable", which doesn't prevent its, C, widespread use. It's hard to have a language convenient for all kinds of problems, so I'd like to learn details in your case.

the problem we were trying to solve included loading thousands of full human genome sequences into an Apache Spark distributed array, which means, behind the scenes, there's a collection of Linux hosts each with a JVM and those JVMs are running Apache Spark code, which shuffles around subsections of the virtual array among Linux (and thus JVM) instances, as the mathematical operators operate on them.

For the genomic data of a single human, we would model our sequencing data as one of (if i remember how i did it) 5 values, for each position in the roughly 3 billion bases we tracked. So the representation of a genome was required roughly 3 billion instances of 3 bits each, but this wasn't how Apache Spark was written to calculate, you end up wasting 2 bits per byte in any semi fast packing scheme, but every byte is being shuttled around endlessly over the network.

We fiddled around with various representation schemes but were always forced into wasting bits that we had no fast means (via processor intrinsics) of moving around.

That's somewhat vague, but hopefully conveys the essence of the frustration.

The author is not talking about death of Java in general. Only the Fedora packages.

I'm referring to this - "I don't like Java or any other languages targeting the JVM, and don't get me started on the horrid Java ecosystem." Well, personal preferences can differ, but I'd like to see arguments why Java&Co. can be described like this.

Google for "Enterprise FizzBuzz". And that one doesn't even use Spring. Yes it's a joke, but quite illustrative of why many dislike the Java culture and its ecosystem.

One doesn't need to use those traditions which are counterproductive. Java is flexible enough to allow for different styles regarding this approach. However I do see the point of criticism; it's just not enough, in my opinion, to dismiss the language and infrastructure altogether.

It can be difficult to avoid the culture/practices though. Every dependency you use, is code that you are ultimately responsible for. At a minimum you will need to learn how to use them; and you may need to debug and fix them. This is why it applies to other JVM languages too.

Reply on news.ycombinator.com