[HN Gopher] The Death of Java (Packages)
___________________________________________________________________
The Death of Java (Packages)
Author : xeeeeeeeeeeenu
Score : 17 points
Date : 2021-04-26 20:25 UTC (2 hours ago)
(HTM) web link (lists.fedoraproject.org)
(TXT) w3m dump (lists.fedoraproject.org)
| avmich wrote:
| 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.
| jjtheblunt wrote:
| 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.
| avmich wrote:
| 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.
| jjtheblunt wrote:
| 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.
| distances wrote:
| The author is not talking about death of Java in general. Only
| the Fedora packages.
| avmich wrote:
| 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.
| ysleepy wrote:
| 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.
| needusername wrote:
| 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.
___________________________________________________________________
(page generated 2021-04-26 23:02 UTC)