Java 8 still widely used | Hacker News Reader

Java 8 still widely used

jetbrains.com

63 pointswhack78 comments

The reason is obviously Java 9 which broke compatibility in many areas https://www.oracle.com/java/technologies/javase/9-relnotes.h...

The mistake of python 3 must never be forgot.

It was painful, but most of the community doesn't consider it a mistake.

"Mistake"? There was 2to3, a clear timeline, and a migration path. Compatibility forever drags along tech debt the way Microsoft did. On the other extreme, Apple is guilty of breaking things too aggressively without enduring compatibility. Major version incompatibilities with clear advantages is righteous churn, so it's a narrow path that must balance competing concerns.

Perl 5 -> Perl 6 is the oddball without a migration path because they're totally different.

2to3 was a bungle. Python 3 was dead until six came out, which had an actual plan for upgrading that works (forward compatibility) instead of automatic rewriting, which does not work.

> On the other extreme, Apple is guilty of breaking things too aggressively without enduring compatibility.

Apple views that as a good thing.

That's Apple's arrogance.

The mistake was the way it was handled. I'm not sure Python trod that narrow path well - not all the breaking changes in Python3 were clear advantages, especially in the pre-3.5 days, the migration path was harder than necessary as a result, and the timeline was clearly too aggressive with hindsight.

Python got very lucky with their strong community support. Millions of hours were invested into upgrading Python2 code to Python3, essentially on trust in the early years (2009-2013).

Without the strong community support Python could have gone the way PHP did in the 5 -> 7 -> 8 era

It's interesting to compare these with languages that never did the breaking change to clear out their tech debt. Back in the day, Javascript was nearly universally hated (The Good Parts was very controversial!), and it nearly splintered into multiple languages, but managed to consolidate under ES5 and then explode in popularity without ever having a Python2-3 moment.

https://www.jetbrains.com/lp/python-developers-survey-2020/

Scroll down to Python Versions

They clearly did something better than Java. 94% vs 6% (and that was 2020!)

You're comparing 12 year old Python 3 (as of 2020) with 6 year old Java >=9 (as of 2023).

6 percent of people in 2020 were using Python 2, 12+ years after Python 3 was released. 12 year old Java right now is Java 7, which is only used by 2 percent of people in this link.

Keeping Python 2 for long was a mistake, it had too many inconsistencies.

Yeah, there's a gigantic pile of XML enterprise stuff that all needs to run in its own sandboxed containers now because of this. Not blaming Java or anything. That crap shouldn't really even exist, but even if we could find the original vendors, the costs would be in geosynchronous orbit. The Overlords would spit their Frappuccino in our faces, Mugatu-style, if we came to them with a quote.

You use a Mac.

You search for java.

You click the first result and go to java.com.

You click Download Java.

You are given Java 8.

You are now somehow a mystery.

https://www.java.com/en/download/

They are not lying...

brew install java

export PATH="/opt/homebrew/opt/openjdk/bin:$PATH"

java -version

openjdk version "21.0.1" 2023-10-17

The instructions change a bit over time, with macOS upgrades and changes re: brew itself, but in my experience brew has a superb track record of making sure the `brew info` instructions are an exact match for what you need to do for your setup.

One macOS Sonoma 14.1.1 just now:

   $ brew info java
   ...
   For the system Java wrappers to find this JDK, symlink it with
   sudo ln -sfn /usr/local/opt/openjdk/libexec/openjdk.jdk /Library/Java/JavaVirtualMachines/openjdk.jdk

   openjdk is keg-only, which means it was not symlinked into /usr/local,
   because macOS provides similar software and installing this software in
   parallel can cause all kinds of trouble.

   If you need to have openjdk first in your PATH, run:
   echo 'export PATH="/usr/local/opt/openjdk/bin:$PATH"' >> /Users/[username]/.bash_profile

   For compilers to find openjdk you may need to set:
   export CPPFLAGS="-I/usr/local/opt/openjdk/include"
   ...

.Net has the same problem[0] 45% still "regularly use" .Net Framework because, like Java 8, .Net Core broke compatibility and even in spite of Microsoft's efforts to offer upgrade routes, it is still a hugely painful experience. Particularly for those stuck on libraries like Asp.Net.

Their current best solution is to put a modern version wrapper around .Net Framework and to map between them, but that isn't exactly ideal either (since you wind up with a giant mess).

[0] https://www.jetbrains.com/lp/devecosystem-2023/csharp/

I actually prefer using .NET Framework for even fresh projects of mine if they are going to run on Windows anyways: Microsoft provides security fixes for new .NET LTS versions for only three years, so your application bitrots rapidly.

Meanwhile, .NET Framework 4.8 is several years old and will almost certainly still be getting security updates ten years from today. To be clear, Microsoft provides better support today for Visual Basic 6 than it does many versions of the modern .NET.

Modern open-source .NET feels like a totally different community and ecosystem compared to .NET Framework. The Ballmer era focus on Windows, versus Nadella embracing cross-platform software.

The old stuff will stick around for basically the same reasons that people still write C/C++ software using Win32.

> The old stuff will stick around for basically the same reasons that people still write C/C++ software using Win32.

Because the resulting applications are much better?

With my C# codes not heavily tied to specific .Net frameworks, it's not really affected by breaking compatibilities. However I avoid the latest IDE (VS 2022) which come with the latest frameworks as the IDE is often noticeably slower.

I feel for Java. Everytime I've used it, I've been pleasantly surprised by the language. It has some truly amazing features (steams where very cool).

Then I get to the tooling and it's just such a pain, if it's working we don't touch it. Our repository was checked in "eclipse format". Tried to move it to jetbrains. No dice. it too, me a few days to get it so i could compile and run under eclipse. I'm not an expert but I don't want to touch it for fear of breaking. New projects aren't done in Java. Php perl and python have a better dependency story, though slower.

They key is to use a build system like Maven, ant etc. such that the IDE does not matter. On most java projects you would add ide specific files to the git ignore list. Eg your ide project and settings are for you and you only.

This - I remember Eclipse putting me off Java for years. IntelliJ is so much better, and if you use Maven or Gradle, the IDE really does just figure it out for you.

Just use maven like everyone else and you will have better portability than most languages manage to offer, and freedom of IDE (if you want to use one).

> Php perl and python have a better dependency story

none of those have a better dependency manager than java's maven. The fact that the project you had to work on didn't use maven isn't evidence that java's tooling is bad!

of all the current industry wide languages, java is the one with the best tooling, including IDEs, profiling and tracing, deployment options, and debugging and logging etc.

> The fact that the project you had to work on didn't use maven isn't evidence that java's tooling is bad!

It can be simultaneously true that some Java tooling is excellent and some of it is subpar. This is a problem when both kinds have been historically popular.

Who can forget Jelly?

https://commons.apache.org/proper/commons-jelly/

> The fact that the project you had to work on didn't use maven isn't evidence that java's tooling is bad!

Indeed, that's amateur hour. Says more about the developers that checked in that code than about the language or tools. I have a love hate relation ship with maven and gradle. They are convoluted and over engineered. But they do work reliably once you get over that.

Python dependencies are messy. That mostly relates to the fact that a lot of python needs native stuff which is just not that portable. This is why things like conda exist; so people can use native dependencies that otherwise would be hard to install on platforms like windows. There was a nice article on this on HN a few weeks ago I think. There seems to be no standard way to install stuff for python but about four or five competing ways to do this. With pip3 being the miserable baseline that the other ones are trying to improve on. I've tried several of those in the last year.

Php actually has a decent dependency manager these days. I'm not necessarily a fan of the language but the php community has done a decent job modernizing their tools and language over the years. Things like Wordpress make it look worse than it really is.

Java and Jvm tooling is indeed awesome. Best in class tooling has been a decades long tradition with the language. And of course Jetbrains is a big part of that. But Eclipse and IBM actually laid the groundwork for that when they bootstrapped out of the Smalltalk community in the nineties. Around that time other time other IDE builders of note were also providing tools for Java. Most of those are long forgotten by now.

But the smalltalk refactoring browser was where it all started in IBM. And a lot of those people ended up working on enterprise Java. Eclipse as a tool is a direct descendent from that stuff (via IBM's Visual Age, which came out of their smalltalk tools). It was the first proper Java IDE with lots of refactoring options. Jetbrains followed with intellij.

These days, there are many things you can do inside intellij with Java and Kotlin that few IDEs for others come close to being capable of. Even renames (of any symbols) are science fiction in some IDEs. And that was a standard feature in the very first version of eclipse.

Stuff like this requires decent tools that work on abstract syntax trees. That tends to be hard for dynamically typed languages. But languages like Go, Rust and a few other modern languages don't have that excuse. And yet none of those have anything better to offer than what Jetbrains provides for those languages. Which while nice just isn't the full feature set that Java or Kotlin developers would expect. Good tools are hard.

I’m not a java developer and don’t know maven deep but once I’ve tried to perform a simple task and abandoned it after a couple hours of googling and experimenting: I’ve tried to remove from pom.xml dependencies which are listed there but not used in the source code and it was surprisingly hard to do. In Go it is as easy as running goimports and go mod tidy and one doesn’t have to be a Go expert to use them.

> I’ve tried to remove from pom.xml dependencies which are listed there but not used in the source code and it was surprisingly hard to do.

You probably already know this, but since Java has dynamic loading of code, even if the dependency is not used in the source code, it does not mean the dependency will not be used when running the code. Either through direct use of reflection ("Class.forName()"), or a drop-in file used through ServiceLoader, or even a magic resource file which makes the code go through a different path when present. Carelessly removing a dependency might make your application break, possibly only when the specific functionality which dynamically needs the removed dependency is called. So yeah, you kind of have to be an expert on all the frameworks your application uses before you can start trying to remove unused dependencies in Java, and a tool cannot help you much.

This is just bizarre.

In my 20+ years of professional Java dev I have never seen an organization that would employ proprietary eclipse or jetbrains repos. Maven is king and always has been.

Concur.

Another data point. Our open source JWT library[0] and Java client library[1] both target Java 8 because that is widely used.

0: https://github.com/FusionAuth/fusionauth-jwt

1: https://github.com/FusionAuth/fusionauth-java-client

Might have something to do with the $30 per seat license cost of Java v9+

And the fact that you have to rename everything to Jakarta and rebuild dependencies

This is the biggest issue.

No issues with licensing - openjdk and others are perfect for production use for the vast majority (imo). Some supermassive projects excluded but they are always outliers.

The migration path after 8 is just a pain, As you mentioned, package. The name changes are for no benefit to developers or end users.

I use Java 11 (actually Eclipse Temurin/Adoptium, formerly known as AdoptOpenJDk) with bits of Java EE 8, it works fine. (Not using the whole EE stack, just select components such as servlets and JAX-RS.) Tried upgrading to Jakarta EE, got hit by needing to upgrade dozens of random open source libraries to newer versions with Jakarta EE support, some of which had breaking changes which have nothing actually to do with Jakarta EE. I’m sure it will get finished eventually.

I recently joined an AI team (platform/infrastructure/apps rather than the actual data science proper) and since then I’m trying to do less and less in Java and more and more in Python-so that mess may be left for someone else to resolve. But Python contains dependency hells of its own

THIS is the real problem. For _most_ projects upgrading from 8 to 9 meant just adding a few packages that were removed from default JDK with Jigsaw. That part is generally fine, even with OSGi hell.

The Javax -> Jakarta changes for validation, EE, XML, etc. are a damn nightmare!

And if you're using microservices it's either a total migration (a no go for anyone minimizing bugs and outages), or a slow one-by-one trudge, if you use some commons between them that commons will need to support both javax and jakarta together, superbly fun

You just described my last 6 weeks…

There is a gradle plugin that can rewrite jar dependencies class files to be jakarta packages from javax. This makes updating your code the major issue versus also figuring out every dependency at once.

Would you happen to know the name of this plug in? It would be a great help

Shout out to Quarkus which uses OpenRewrite recipes to automatically modify your source files for you. Upgrading to the latest Jakarta EE was basically a single command.

That is fantastic news Thank you for posting.

Oracle's new "Universal Subscription" pricing structure is even more ridiculous at $180/yr per employee in your company.

How does that not turn into making a technically-separate legal entity with just the product as an asset and no employees that's wholly owned by a parent company that it also buys development contracts for the product from?

Great point! For one, this is not something the Government can do - which I'm sure is a large Java customer.

Isn't OpenJDK provides the same functionality and is FOSS?

For context on possible sampling error:

    - 50% use Java 8
    - 72% use Spring
    - 74T use Maven
    - 78% use IntelliJ
    - 38% develop web site

If it works, don't touch it.

Tomcat is underrated as a web server. One of the most reliable I’ve ever used. one relatively low traffic tomcat instance has been up for over three years consecutively

if this tomcat shipped with the recently found log4j vulnerability, you might have not had the chance to make an upgrade!

Is that really Tomcats fault though? Probably 75% of all Java programs use log4j

Adoptium OpenJDK is the way to go.

Azul Zulu. Much lower probability of GC pauses. :]

Corretto

C4 GC > Amazon non-upstreamed fixes

http://www.azul.com/wp-content/uploads/c4_paper_acm.pdf

Java 8 (maybe 9) is the last version I wrote code for. Having looked at recent new Java features it looks like a completely different language now. I also see a lot less new projects written in Java, at least in the OSS sphere. Just anecdotal.

Another anecdotal factoid ... Not a single LLM based example on GitHub seems to be using Java.

How well can you access graphics drivers and cuda cores for doing any kind of local large language model stuff using java? I know that there is a project called MLC for machine learning compilation that is meant to be written in Python and then transcribed using machine learning to a native language for the platform so that you can use mobile processors and laptops and stuff more efficiently for small language models.

Java has the Java native interface where you can interface with c/c++ written code

JNI is kind of a hassle. If most of the heavy lifting is being done by native code then using Java becomes pointless. Might as well just go with Python which makes calling native code a bit easier.

Project Panama is meant to make this a lot nicer, and they often explicitly mention trying to stay competitive in machine learning as a key impetus for it. But yeah, JNI is so awful even the language architects are compelled to trash it and apologize for how bad it is.

I cant argue with you there, but Java isn’t that much slower than c++ now a-days. especially on an X86 platform where there’s been lots of time to tune the JVM.

Sure, Java performance is good but again if most of the real work is being done in native code then it doesn't really matter.

This feels hard to verify. The LLM tag, filtered by Java repos [0] returns some results. This only includes repos that tagged their repos which definitely is not all of them.

How are you measuring this? Anecdotal factoid is a bit of an oxymoron

[0] https://github.com/topics/llm?l=java

> Anecdotal factoid is a bit of an oxymoron

Obnoxious pedant mode: it's actually not, because GP misused the word "factoid".

From Wikipedia[1]: "A factoid is either an invented or assumed statement presented as a fact,[1][2] or a true but brief or trivial item of news or information."

[1]: https://en.wikipedia.org/wiki/Factoid

Heheh, I’ll take obnoxious pedantry over an anecdotal factoid any day!

Ninite.com lists the following Java installs:

    64-bit Java Runtime (JRE) 8u392-b08
    32-bit Java Runtime (JRE) 8u392-b08
    64-bit Java Runtime (JRE) 11.0.21
    64-bit Java Runtime (JRE) 17.0.9
    64-bit Java Runtime (JRE) 21.0.1

How is the average person to know which one is best for them and why?

Whichever runs Minecraft of course. I think that's Java 8

IIRC, latest Minecraft uses Java 17, and won't run on Java 8; on the other hand, IIRC older Minecraft versions (which are still popular) require Java 8, and won't run on anything newer.

The ASF world is finally moving forward. Java 11 is pretty much ubiquitous, and I'd expect latest LTS versions to be supported by default going forward.

Basically, pick an LTS version and stick to it for a given use.

Legacy is going to pick 8 (or maybe 6 or 7 for very old stuff), green field may opt for 21, and others should select 11 or 17 depending on vendor recommendations and support.

Indeed, many ASF projects are finally using newer Java releases as a baseline. Even Commons projects are getting updated!

The Java I encountered at work didn't even use Java 8's features. People balked when I suggested using vavr to get some functional programming goodness.

The culture around Java is conservative; it has a lot of inertia. That's why I support Kotlin; it forces project contributors to leave their dated habits behind. Java libraries still work, of course.

This is unfortunate considering how far the language has come since then. Local variable type inference (i.e. the `var` keyword) is very difficult to give up once you’ve gotten used to this being table-stakes in basically every other modern statically typed language.

Java 8 is the best Java.

Cobol is still widely used as well, so what?

Reply on news.ycombinator.com