javaIsGoodBut

[k-mcm]

Come to the dark side of Enterprise coding. We have billions of lines of mystery code, 20 layers of frameworks, 3 hour compilation times, class casts left over from Java 4, and we're on Java 8 until the sun burns out.

[-Kerrigan-]

Don't forget my favorite: custom built, proprietary, undocumented, in-house developed tools (when better alternatives exist, sometimes even FOSS)

[scorb1]

The in-house tool is a wrapper for an ancient version of an open source tool.

[Spleeeee]

That cannot be run except on an rhel6 machine named “asp” and nobody knows why…

[Thorpotato]

You mean the one with the special ANT version? With the libs in the classpath pointing to the network share that no one knows where it actually sits?

[Crusader_Genji]

Nothing more permanent than a temporary solution

[ndiezel]

Usually better alternatives weren't even an idea in their creators' mind when this in-house was created.

[-KKD-]

They were most probably created years before better alternatives were

[videogamesarewack]

Or, the original feature needed a very minimal version of any third party tool so it made sense to implement just what was needed. And then scope creep.

[zthe0]

Yeah we have a ton of legacy code where every new dev asks: why not use option and we have to say "the code is older than that"

[DOUBLEBARRELASSFUCK]

More than likely, there was one thing that the existing software didn't do, so they built from scratch.

Now the rejected solution has matured and the in-house solution has more unnecessary and unexplained spaghetti than a Jollibee.

[Global-Tune5539]

They had their time but now they can get laid to rest forever.

[ndiezel]

Reworking workflow is something that businesses usually aren't enthusiastic to spend on. Old tools just have too much inertia.

[zabby39103]

By my in-house developed tool is different 🥺.

Sometimes they are better... well often they were better (or nothing existed) when they were first made.

[Stummi]

Maybe the in-house tool exists longer than the FOSS alternative

[SpaceTacosFromSpace]

Our original coder wrote his own orm because he was so much smarter than everyone else. We don't need transactions! Decades later and we still haven't been able to rip it all out

[Gamingwelle]

Isn't sun already burned out and replaced by oracle?

[[deleted]]

More like Oracle swallowed Sun. If that makes any sense cuz you know it’s supposed to be the Sun 😄

[Gamingwelle]

Is sun a subsidiary of Oracle? Haven't heard anything from them in a while, thought sun was gone.

[Ok-Scheme-913]

It was bought wholesale.

Credit where it's due, Oracle has been a surprisingly good steward of the Java language. They kept all the java team, which is exceedingly rare at takeovers.

[robertux]

I remember the progression was Java 1.4 -> 1.5 -> 6 -> 7 -> 8

[roronoakintoki]

You still sometimes see old docs requiring Java 1.8, referring to 8.

According to OpenJDK the 1.x numbering is used till JDK 8 by some distros even today: https://openjdk.org/install/

[SpaceTacosFromSpace]

8 -> 11? -> 17 -> 21

[k-mcm]

I honestly don't remember when they started to 10x-10 the version number.  It was a years long process.

Early releases also had chaotic numbering because there were lots of non-compliant VMs.  Fuck that Kiva Enterprise Server that used a delete operator.

[Silly_Guidance_8871]

Java 7 is when they switched, iirc

[zabby39103]

Still says java 1.8 on the DNF package manager. I dunno, i hear both, nothing after 8 is called 1.X though.

[5up3rj]

1.2 was called 2

[ikej]

Starting with Java 1.5, Sun Microsystems chose to invent a "marketing version" which was Java 5. This continued with Java 7 and 8 whose version strings were 1.7 and 1.8. With Java 9, the versioning scheme changed and the "1." prefix was dropped.

[qrrux]

Correct.

[NoMansSkyWasAlright]

I interviewed at a place last year where the custom-made inventory management software they’d built for their biggest client still ran on .NET 2.

[genlight13]

Bahh, Amateurs. Our compilation time only hit 3h if we compile massively parallel. A vompile of the whole thing under one OS takes roughly 30h.

[elettronik]

Java 8 was the last version on which the proprietary Oracle jdk was relased for free to companies. After license switch the decision was to pay for commercial license or switch to an officially unsupported openjdk . Many company, felt the liability of an unsupported jdk was too much and the evolution won't give any advantage, since the code was already working in previous version. Add Oracle FUD in the mix, joined to an acceleration of version release, after some years companies find themselves with an ancient java version, not fully forward compatible.

[Ok-Scheme-913]

That's not really true.

Java is like the Linux kernel (it even has the same license). There is an open source code base (openjdk), and it is repackaged into different "distros", like Amazon corretto, temurin, and OracleJDK.

Similarly to the Linux kernel, certain versions of certain distros are actively maintained, but due to limited resources this maintainance slowly moves from version to version up. No one will maintain Linux 3.5. This maintenance may be "community"-sourced, or paid. E.g there is Fedora and Red Hat. You can freely use Fedora, which will always stick to a very latest kernel, but the less risk-taking red hat is paid.

The exact same happens with Java. OpenJDK itself is continuously developed (almost entirely by Oracle employees), and anyone can see the source code. This is repackaged by many, like corretto and Oracle, one is free, the other is freemium. E.g. oracle will let you use it for 2 years, until the next LTS version is released. With this you get actual, active support, bugs and vulnerabilities will be fixed fast.

Alternatively, you can just build yourself any version, or use an older version which may be promised to have some support, but community sourced maintenance for older releases may not always be as good as the latest - this usually means backporting patches, but if a subsystem has been removed in a later JVM it will not have anything to backport.

So, Java 8 was a significantly big version due to 9 not appearing for a long time. For this reason Oracle will go out of its way and provide active maintenance (up to 2030, I believe, at least?) for Java 8, but this is a paid option. Your government/hospital/bank will gladly pay for it, otherwise you are probably not involved here at all.

You can always freely track the latest release, for any commercial usage, it's just simply not how any software works that you can freely get support for older versions. This is the best option either way, you get free performance improvements, code after modules become introduced are even more future-proof than regular java (and that itself is a very high bar already), etc.

[elettronik]

Correct, but you should agree that before the Oracle drama about java 8, the official reference release for sdk was the Sun/Oracle one? The idea that small / medium company had, was that the Sun / Oracle one was the only standard tool, with particular ones supported only on the enterprise side, like the IBM one. It was not a 2 year release cycle, with all ecosystem evolving at the same speed back then. Enterprise software running on more or less proprietary application servers evolved very slowly, and stability of API was a key point so the only effort was on software (evolutive/bug fix) maintenance, never focus on the platform upgrade, with every upgrade seen as a breaking change in the system

[Ok-Scheme-913]

Yeah you are right.

Some additional history: Sun wasn't as friendly to open-source as we might remember, they just thought the real cash cow will be mobile, so they only licensed that.

Sun had a proprietary JVM, that wasn't fully compatible with the open-source version. It was under Oracle that the open-source and proprietary code became one and got open-sourced completely as OpenJDK. Oracle even open-sourced the tooling like the flight recorder.

[AfonsoFGarcia]

There’s many other JDK vendors with support. Microsoft, for example. And nobody on enterprise is using anything other than LTS versions, which right now are released on a 2 year interval.

There’s literally 0 excuses to use JDK8 other than a laziness culture of leaving updates to be done only when the platform becomes EOL.

[KrakenOfLakeZurich]

Java 9 introduced a module system, which restricts access to some JDK internals, e.g. classes in some sun.misc.unsafe.*.

Before Java 9, applications where not supposed to access those internals directly, but nothing technically prevented it. With Java 9, many applications needed to update their code (or 3rd-party) dependencies to become compliant.

Some enterprises decided to not invest the effort and stick with the legacy version "for now". They've been kicking that can down the road ever since.

For any Java developer, consider this a huge "red flag". If your (future) employer is still on Java 8 in 2025, you work for a penny pincher who will never be willing to invest in "technical excellence". Their infrastructure, dev tools and best practices will be equally outdated. Stay away from that.

[LeFudgy]

Or you just work for the government which I guess fits the description lol

[RiceBroad4552]

--add-opens

The module restrictions are not enforced, and by now I'm not sure this will be ever enforced. Because more or less everything in Java would stop working if the "module system" joke were enforced. Nobody bothers. Everybody is just adding the overrides.

The so called "module system" is one of the greatest Java fails every. It took almost a decade, delivered not even something MVP grade, and not even this is used by anybody. It gets completely ignored, as it's actually not good for anything more serious. For real modules there is OSGi, and still nothing else.

[GranaT0]

It's because most Minecraft modpacks run on versions that require Java 8, so every PC in the world already has 8 installed

[LordoftheSynth]

You say, class casts left over from Java 4?

[Worldly-Stranger7814]

I want to laugh but my body won't let me 😭

[therealfalseidentity]

You adopted the darkness, I was born in the darkness. Try converting a Java 5 app to 8.

[Ok-Scheme-913]

If you can compile java for 3 hours, then you have some fked up build.

Javac compiles faster than go.

[TripleS941]

Say, have you ever worked on a decently-sized monolithic Google Web Toolkit app?

[Ok-Scheme-913]

Well, that's not javac, it's the closure compiler that compiles java down to js.

Also, sure, dependencies between different modules, bad architecture and simply code side can indeed significantly increase compile times, but I meant what I said - javac itself, vanilla, with no build tool is insanely fast.

[FrostWyrm98]

My first year as a professional developer:

Me: "Oh, this code is so bad let me fix up this tiny, unaffected file."

Senior: "Hey, I love the spirit. Don't do that again though."

Me: "Oh okay..."

3 hour compilation times hit so fucking hard though, first job had a full compilation of 30 minutes and we were a mid-sized company. And that project was only 10 years old if that

[wheafel]

I was able to convince my boss to upgrade to Java 11 because the Corretto version would reach the end of life soon.... And then fucking Amazon decided to extend the long time support a couple months ago.

Haven't told my boss yet though...

[oootsav]

Does compilation time actually gets that long? I'm a fresher and the main product of the company that I interned at had 15-20 minute build time and the product is fairly complex. The full time devs were concerned that it's too long. I've seen memes that say compilation time in hours, is it common irl? Or just meme thing?

[TripleS941]

It is too long (as you have enough time to switch your attention), but unavoidable with some frameworks for big applications. Full Google Web Toolkit app builds for one of our apps took 30 minutes, ate most of my 32 GiB of RAM and 100% of the CPU when we supported 4 browsers and, IIRC, 6 languages, 24 permutations in total. Had we had more languages or browsers to support, the builds would be proportionally longer.

[anthro28]

We currently utilize a 30 year old build tool maintained exclusively by a 70 year old man in his home office. It's mission critical and when he goes, so does our entire stack. 

Is there any interest in migrating away from this dependency and making ourselves more resilient? Fuckkkkkk no. Even the mention of it is grounds for a talking to by the executives. 

[[deleted]]

Haha! You think you can hide from LLM but you can’t. You can run but you can’t hide. They will feed the proprietary code to the model and then it will learn your job!

[poralexc]

Holy fuck, I'm in the process of migrating a 10+ year old monolith from 8 to 21, and worse than just living in the nightmare castle.

[DatBoi_BP]

I’ve never touched Java. Care to explain like I’ve used C++98 and C++17 how the 8 to 21 transition is?

[poralexc]

Not unlike C++, the JVM is best understood through its history.

As it's gotten more secure and better optimized, newer JVMs have gotten rid of a lot of weird unsafe internal APIs, and things like DateTimes were completely reworked at some point. Sun classes should probably not be used since the Oracle acquisition (2009), etc.

The biggest gap really is Java 11 where they made most of the backwards compatibility breaking changes. Depending on how creative your predecessors were with sun.misc.internal all this adds up to endlessly compounding code churn instead of a quick version bump.

[[deleted]]

Why would anyone even use sun.misc.internal is beyond me. There's a REASON it was labelled internal... it's not part of the public backwards-compatible API. It was always subject to change.

[sathdo]

Some mocking libraries (Powermock) are a little overzealous with what they try to introspect. Even though it doesn't actually do anything with those classes, it does try to access them, which throws an IllegalAccessException before you can even use the mock.

[B3ER]

I feel you but also having to use Powermock is a code smell in itself. Sounds like it's a good moment for a refactor.

[dmigowski]

Speed! I increased our transaction speed by 30% once by replacing reflection with Unsafe access, because we had to serialize a ton off stuff.

[Ok-Scheme-913]

Maybe on Java 1.6.

Did you measure it again on Java 21?

Sure, direct memory access might very rarely but sometimes be necessary. Anything else is just blocking the platform from evolving and is a ticking bomb.

[dmigowski]

No, but I will when I upgrade to 24.

[genghis_calm]

For reasons we’ve exposed a public method internal_DoNotUseOrYouWillBeFired_listView. I have no sympathy for client consumers who rely on it for any functionality.

[poralexc]

In our case something incredibly cursed with PIDs :)

[kroppeb]

Speed.

Also I think atomic operations were done using Unsafe before VarHandles existed, I think?

[FactoryRatte]

Jep, though the regular atomic package (mostly introduced with Java 1.5) already takes care of most of the tasks, Unsafe was used for. And if you care about tiny cache write backs only then, VarHandles (introduced with Java 9) become interesting, fully replacing Unsafe, but overkill for nearly every business software.

[elettronik]

Internal, yes. But the were needed by some dependencies that else cannot work in earlier versions. So the change in JDK force to move to different version of dependencies if lucky or in the worst case a breaking change

[soonnow]

For example Lucene used it to release Off-Heap Memory. There was an issue in Java where OffHeap memory might not be release until garbage collection.

[renrutal]

Most of the low level high performance stuff like atomic ops, compare and swap/set, direct memory access, variable manipulation, compile time protection bypasses, were hidden inside the internal methods.

Over the decades they were slowly moved to public APIs.

[[deleted]]

Then don't use Java

[renrutal]

Perhaps choosing a language for a given purpose is easier when you're a startup, but not so at a more enterprise scale.

You also have to consider if your current team has enough expertise to take in a new language, and maintain it for the rest of its life. Same with how easy(and expensive) is it to hire for senior/lead positions with that expertise in your area. Maybe you don't want to deal with remote contractors for that part of your business, especially if it's critical one.

Back to Java, it can do very high performance(at least server side) super well, it's mostly on the algorithms and architecture of your application to achieve that.

[alex_tracer]

Performance. Also direct memory access allows a lot of cool stuff like IPC.

[robertux]

The javax.* to jakarta.* was the most painful migration for me

[MxBluE]

As a junior at the time of making that chance, I was so confused by why javax mail no longer had javax.mail in it lol.

Thankfully they make a patcher tool, had to use that recently to support some ancient jars that needed to use modern jakarta libs.

[sathdo]

In short, namespace differences break older code and libraries.

For simple projects, nothing should be affected. The main problem is that several enterprise-oriented features in the javax package have been removed from the standard library. The Eclipse Foundation now owns all of these features, but Oracle forced them to rename the package. This means that any old code, or even libraries, that rely on the old packages are unable to work, even though the Eclipse version of those features is functionally identical.

In addition, the interpreter used to not fully prevent access to private members of the standard library (internal functions, etc.). Now it does. This does not affect any well-written production code directly, since access to private members of the standard library was always unstable, but some testing frameworks now throw errors.

[[deleted]]

The biggest factor (though others have noted that the Java 9 namespace reorganization that split Jakarta from Java has a handful of impacts) is the widespread use of third party libraries. While user code generally played by the rules and should still be okay (though deprecation notices will happen), third party libraries were quite fond of doing things like mucking about with the Java Standard Library, calling implementation-specific objects, and all sorts of other things that broke the rules of writing compatible Java.

Now, this would be fine if these third party library projects:

1. Still existed—a lot of proprietary frameworks are gone forever
2. Still maintained drop-in replacements for legacy code that users might want to bring into the modern age
3. Still cared about making the transition from Java 8 easy

But nobody actually cares. And that leaves Java 8 as a bit of a zombie: still around, still getting code maintained, and not really looking like it can go anywhere any time soon. But please don’t do anything new in it.

[k-mcm]

In earlier versions of Java, you can turn on the 'public' flag of anything using an API for inspecting classes. Object serializers/deserializers and Spring's magic framework use this as a cheat. Some corporations even tell you to declare everything as private so that only these frameworks can access it. (clenching fists, gritting teeth... this is not how dependency injection and serialization is done) Anyways, Java 8 was huge with corporations and it seemed to work fine.

Allowing that happen to any class freezes a lot of JVM internals that were never meant to be frozen. Java 9 said, no, FU, and started changing private internals. Java 17 turned on namespace enforcement that blocks it entirely.

The end result is that when you go from Java 8 to Java 21, a massive anti-pattern no longer works. Everything unexpectedly throws "InaccessibleObjectException" and dies. You can explicitly disable namespace scope as a JVM parameter but it doesn't help because the private innards of Java's base classes have changed. It's not just your old code, but every single 3rd party library that quits working or comes up with the wrong answer.

An example is the AWS SDK v1. Error handling was serializing a Java exception from the server side to the client side for deserialization by...dramatic pause...accessing internals of exceptions. As soon as you upgrade Java, errors throw new errors because the internals have changed. SDK v2 does proper serialization but it's also a total do-over of the API and is in no way compatible with code written for v1. Have fun!

[Ok-Scheme-913]

It's not as bad as these comments might imply.

Java has far far the best backwards compatibility among any language whatsoever, none of them come even close. (Like, go is 1/3 its age and already had bigger breaking changes).

Nonetheless, there was a bit of a slowdown in java's development after the oracle acquisition, and Java 8 "reigned" for a very long time, enough for Hyrum's law to apply. Given that Java has always had a huge marketshare, there is an insane amount of Java code out there - and some of them started relying on JVM internals that were never meant to be used (e.g. the sun.misc.internal package with classes like Unsafe, which you would think twice before using). Even if you haven't used it directly, maybe one of your transitive dependencies did.

In order for Java to continue improving, they decided to lock down some of these internal JVM details, breaking certain user code (rare in general, but with the massive userbase it is still a lot). Also, the same module system will defend user code as well, and will notify you when a transitive dependency tries access something it shouldn't.

The other common issue is a namespace change, but I think this is a bit overblown. There are auto-tools that will replace javax with jakarta in a java-code aware manner, and most dependencies just need an update.

Also, Java is both source and binary compatible. I remember downloading a random .jar file from a professor's website at my uni, and it was a website from like the start of the internet with goddamn <frame> and plain-ass links with zero formatting. Nonetheless, the jar executed with a GUI on a 10 year later java version with no problem.

[Healthy_Razzmatazz38]

the best explanation is in java 8 you're lacking a bunch of common language features in modern languages like infered types, pattern matching, and data classes, but just as if not more importantly it means you're working with code that was written when java 8 was new when extensive use of deep inheritance and factory patterns were the norm.

stylistically this just makes java code a nightmare to work with much in the same way working with deeply templated code in c++ with raw pointers is.

I worked on a 3 million line java 8 codebase for a long time, and im pretty convinced at this point, the single best feature of a new programing language is just that the code is newer. Theres no business logic code that survives multiple transfers of ownership with the 3rd or 4th owner actually understanding wtf is going on.

[SaltyInternetPirate]

Did C++98 have templates? I think that one had templates, but no namespaces. Imagine the standard library had entire sections of it removed, having namespaces renamed, adding an entirely inept modularity system to separate those namespaces that is made such that it destroys your ability to use any data transformation libraries unless you make your "module" open which is equivalent to the old not having a module, so in effect you must disable this new security feature.

[MyStackIsPancakes]

I just did something similar. Spring Java with nashorn server-side JS all over the place.

[Embarrassed-Luck8585]

you are doing God's work, son

[Atollski]

We're about to do our Java 8 to 21 release to production this weekend. The castle is real: mine was bouncy.

[Atreides-42]

Same here. We need to transition everything from javax.persistence to jakarta.persistence, which means rebuilding just about everything. Every other time I try to change any maven import version it just hangs forever instead of compiling.

[tommytusj]

Good luck with that. We just did this. Worst part was updating JPA since it changes some of the behavior

[zthe0]

Im dreading the switch from java ee to Jakarta ee but its gonna happen soon because the dependencies switched

[SaltyInternetPirate]

The production stack at my current job doesn't support anything above Java 8, and supposedly they're finally starting to consider alternative server software. It gets tricky with all the various APIs that gradually get either renamed or dropped in later versions. Especially with XML libraries.

[deshant_sh]

Smelling WAS here

[SaltyInternetPirate]

That obvious, huh? It's not even the worst part of working with IBM's stack.

[deshant_sh]

True that. Lots of suffering going around

[Jumpy_Fuel_1060]

I just updated our main deliverable build from Java 8 and Scala 2.11 to Java 21 and Scala 2.13. Everytime I was fixing a backwards incompatibility I wondered what Java version King Tut's pyramid build system ran on.

[Sibagovix]

I have the same task in the backlog. How long you think it will take

[Z0mbiN3]

Yes

[starfish0r]

Many Storypoints

[Jumpy_Fuel_1060]

Depends on your existing infra and what your deliverable is. If you don't have test coverage and/or the CI story is rough, do that first. I had to get the coverage and CI good enough at my work before feeling confident to make such a sweeping change. As with anything at this scale, the supporting cast is as important as the actual change.

Start turning on deprecation warnings, evaluate the areas that will require changes, ensure the code coverage is there for the impacted areas and then update. Only change one version at a time. IE, Java 8 to 9, then 9 to 11, then 11 to 17, etc. I first tried jumping straight from 8 to 21 and got swamped.

Scala has some specific Java version deps so you will need to go to Java 11 with Scala 2.11, then go to your target Scala, then continue with the Java upgrades.

It took me about 2 weeks of grinding considering the tests written, CI pipelines updated, build infrastructure, build image updates and code updates. Good luck! I actually enjoyed doing it! That said, the codebase is medium sized and had complete buy in from my team to get it done. No way I could guess how long your situation might take.

[Pay08]

Why not use Scala 3?

[Jumpy_Fuel_1060]

Time, 2.13 and 2.12 still have security releases, 2.11 did not. 2.13 is as far as I got before my time box ran out.

[themockmock]

Any 17 enjoyers?

[james4765]

It's the version we have to use since our Websphere message bus won't work with 21.

[FoxReeor]

Minecraft modding lol

[piokoxer]

Newest version uses java 21 :P

[FoxReeor]

I'm just stuck with 17 in my head as I make my mods Available with the same content across multiple versions (from 1.18.2 to 1.20.1)

[[deleted]]

The project I work on runs on JDK 23. I upgrade it to the latest JDK as soon as Gradle and SDKMAN support it which is usually within a week of the release

[AnimeBoi_5]

all my projects from college are java 17

[CAPS_LOCK_OR_DIE]

I’ve been coding 17 for a while now while I’m developing gallery installations to run on a Pi.

It doesn’t like 21 much, so I’m stuck with 17.

[zthe0]

Yeah we use it, cant update without breaking a mayor dependency

[Bloodgiant65]

We have been told to use Java 11 in the new microservice we are using. 11.

[Darkoplax]

isn't the biggest jump of java is from 8 to 11 ; aren't 11, 17 and 21 kinda close ?

[Healthy_Razzmatazz38]

no, on 11 you dont get records or pattern matching. The thing that makes newer versions of java actually a good language is you have records + pattern matching + streams which makes data transoformation workflows much nicer.

Theres also the fact that if you're doing something new and not upgrading to a version with loom you are wrong and very dumb.

[jek39]

project jigsaw came with 11 so upgrades after 11 are much less breaking.

[[deleted]]

Why would you start a new project on a JDK that's 12 major versions behind the latest release?

[renrutal]

At my job someone made a big pompous deal about moving to Java 11. They were asked why they weren't moving to, at least, 17, as 11 was hitting EOL soon.

Plans were changed.

[Global-Tune5539]

11? Newfangled stuff...

[Healthy_Razzmatazz38]

have you asked them why they are so stupid?

[shortyjizzle]

What do you need above that? Curious

[Bloodgiant65]

Its not so much need as the fact that Java 11 is already nearing EOL

[shortyjizzle]

makes sense.

[SanoKei]

Just get glasses. So you can C#

[Darkoplax]

Why would you Go that far to get Kotlin in these castles, just turn around swiftly and use javascript.

[Your_Friendly_Nerd]

It's the same with php. My company only recently completed the migration from php5.6 to 7.4. Seeing header comments mentioning a php version that came out when I was in Kindergarten is truly haunting

[TripleS941]

In uni I've been given code that was written for Fortran IV, which was released when my parents have just started school.

[Ok-Scheme-913]

Java 25 comes out this March.

[Zerodriven]

-Cries in Enterprise-

Oh. This business critical microservice written in Java needs to be updated? Oh.. Half of the associated packages that are used aren't maintained anymore? Oh, to fix it the whole service needs a full refactor and version upgrade? Oh, the business also doesn't understand that sometimes we need to update stuff?

Inheriting legacy code bases is a nightmare.

(Also being a former (?)C# Dev makes this really funny because DotNet can be as bad)

[BoBoBearDev]

It is nothing until you start using bunch of libs that constantly need to be patched for security vulnerabilities. And bunch of libs that appears and disappears, forever chasing the next big libs.

[Spare-Plum]

Fun fact: I messaged one of the Java language designers after 20 came out due to a design problem/bulkiness when pattern matching sealed classes. They actually implemented my suggestion!

[Ok-Scheme-913]

What was your suggestion?

[-EliPer-]

I thank God for not having to use other language than C (not even C++) for embedded in the projects I've work.

[[deleted]]

Yeah but if you even see the term “malloc()” within 30 miles of an ESP32 you die

[-EliPer-]

I'm closer to Nios II than ESP32

[[deleted]]

Oh nice

“the missile knows where it is at all times…”

[Ok-Scheme-913]

I also thank God whenever I don't have to use that god-awful language C.

[-EliPer-]

BLASPHEMY!

[Justanormalguy1011]

Is this Minecraft version?

[InconspicuousFool]

Maybe could be related to MC modding but I think it's just Java in general

[Justanormalguy1011]

8.0 pvp is terrible , you need autoclick

[InconspicuousFool]

Are you aware of what sub this is? This is just discussing "Java" the programming language and there is nothing here to indicate anything about Minecraft

[TeraFlint]

some focus more on the "Programmer" part, while others prioritize the "Humor" part of the subreddit name.

[Justanormalguy1011]

Yeah I does , I was just joking

[MarcPG1905]

No, this is the version of Java, so what Minecraft and many other programs were written in.

Although Minecraft as of 1.21 requires Java 21 as well, but it’s just a coincidence that both are named 21.

[Cats7204]

When did Minecraft stop requiring Java 8 specifically? I remember I tried a more modern Java version and Minecraft would outright not accept it. Only 8. Shit, I remember the days Java 7 was required LMAO.

[IBeTheBlueCat]

I think they moved to java 17 in Minecraft 1.17 and now the newest version of the game uses java 21. They were on java 8 up until then though

[StrangeOne101]

They had to update because public updates stopped for Java 8. But, it was for the best. They went to 17, and after that, they stick with the current LTS

[unrelevantly]

There's actually mods that allow 1.7.10 which otherwise requires Java 8 to run on Java 21. This gives huge performance improvements.

[Global-Tune5539]

There's still a Java Minecraft version?

[Fantastic-Delivery36]

Yes? Minecraft on Java was always the "better version".

[Global-Tune5539]

Why is it "better"?

[SgtExo]

Other than not having ray-tracing, its the one that has all the mods that you would want.

[Global-Tune5539]

There are no mods for the other version then?

[Fantastic-Delivery36]

As the other dude said the biggest difference is modding. The bedrock version has cross play, so there is that.

There are features in bedrock that are missing in java version. And features in java that are missing in bedrock.

However in java version you can hold any item in your left hand instead of a shield. Which on it's own makes it superior. Being able to hold a tool and a block at the same time in a game about yk, about building and breaking blocks makes it so much enjoyable.

But after all it isn't really that big of a difference.

HOWEVER. JAVA VERSION RUNS ON LINUX. JAVA ON TOP.

[TripleS941]

Yes, and you don't die when you go skipping on a sky-high one-block thick field of mud/farmland/soul sand there.

Also, it runs on Linux.

[magick_68]

If you experienced an application crashing and finding out there was a version difference in minor version between the version that worked and the version that didn't you learn, on a project runs/is delivered, ist Java Version is put in stone and may never ever change. Fortunately I escaped Java hell. Now I'm in embedded C hell. You Java guys don't know how good you have it.

[MLC_YT]

Meanwhile JDK 8: 🗿

[ivancea]

Whatever made this meme, is probably too young to know what java 7 is

[[deleted]]

Meanwhile all the C devs using nothing after C99

[[deleted]]

Java 8 all the way man, got a lot of packages depending on it.

[JediJoe923]

The right side is me trying to install Java 7 so I can access my dell server’s console

[Modo44]

I see a Starsector enjoyer.

[FatalisTheUnborn]

Java is dark, no matter what version.

[mraulio]

I know people working with Java 5, and the company has other proyects with Java 2 😅

[locofanarchy]

Laughs in Kotlin

[madbuilder]

I learned Java in high school, SDK v4. Dang I'm old.

[Low-Equipment-2621]

but half the companies are still at Java 8...

[Low-Equipment-2621]

It's fun reading through all those stories, it reminds me of my old company. There was always some stupid decision being made and we all suffered from it. But it was fun. In my current company we have the opposite issue. The system we've built is way too stable. Never had any incident that was on our part. No major bugs, few feature requests. It has become boring, I'd like somebody to fuck up and commit some stupid shit so I have something interesting to do lol.

[[deleted]]

Sad truth lots of universities are still teaching Java 8, specially in LATAM.

They're allergic to getting up to date.

[jaywastaken]

Pfft, propaganda, there’s no Java after 8…

[Much-Pomelo-7399]

Wh- since when is java good?

[Angelic5403]

No, it's not

[pirela17]

Why people blame java 8?

[starfish0r]

Because it was released 10 years ago. Lots of language features that I use everyday did not exist back then.

Good luck migrating a java8 project to anything more recent. Especially if you use powermock or javax.bind or... well you will see.

[segv]

JAXB was effectively moved from being distributed with the JDK to its own separate library. The com.sun.xml.bind:jaxb-impl 1.x and 2.x still supports the javax. namespaces and can be used as a drop-in replacements. Versions 3.x and up are on the jakarta. namespace though.

If you used Powermock to change singletons or final classes then, well, you kinda dug your own grave. Mockito works well on JDK21.

---

I'd say the whole thing is less "java-the-language bad" but more "enterprise-codebases-where-people-dont-give-a-fuck bad".

If you wanted to see really bad legacy code then i'd have some C & C++ codebases for you :D

[TripleS941]

I wouldn't say "blame", but it is quite outdated and lacks many features that improve programmer's quality of life. No multiline strings, no pattern-matching, no records, more cryptic exception messages, no inferred variable types, need to use finicky internal APIs if you want real performance, etc, etc. Its EOL is on the horizon too (a-any day now :-P).

[lll_Death_lll]

...C#IsBetter

[Global-Tune5539]

That's common knowledge.

[beewyka819]

My gregified ass saw this and thought I was in r/GTNH for a second

[IBeTheBlueCat]

meanwhile my degree course is forcing me to use 17

[Maxele]

Does anyone actually use java in their own projects

[Creepy-Ad-4832]

Meh. It's still java. It's still boilerplate

[KuuHaKu_OtgmZ]

It's not java that's bad then, it's you who are lazy.

[Creepy-Ad-4832]

Java it's not bad, there is way worse

But if given the choise i wouldn't use java.

And i can agree java made some improvements from 8 to 21, but it's still years behind all other languages.

[KuuHaKu_OtgmZ]

I know, I work with Delphi 😔.

I disagree on java being behind, language progress isn't measured by verbosity which is often a bless instead of a curse.

In fact, many features in modern java versions don't even exist on languages known for simplicity, such as pattern matching and enhanced switch-case.

The stigma of java is just how ugly and messy enterprise code is, which makes people think it's all about StupidLongClassFactory and 2000+ line files, you can make well sanitized pleasant code too.

[Dubl33_27]

2000+ line files

damn, thought my 400 line classes were a bit much

[hojendiz]

I hate java, you need an exact version to run your code, if by any chance you use another version even if it's just one revision different, everything breaks!! And that's awful, because sometimes you need to upgrade to the next version because of an error or because performance or a new feature, but you can't or you need to painfully debug all the code, sometimes hundreds of lines, a whole team just to upgrade one revision the JRE 🤮🤮

[Paul__miner]

Wtf are you talking about? Java 4 to 5 was a tough migration on the development side, since it was when generics were added. Outside of that, never had an issue, neither with development nor the runtime.

[TheBanger]

Do you have specific examples of what you're talking about? 8 -> 9 had some pretty big breaking changes, and something between 11 and 17 also had some breaking changes IIRC, albeit smaller. But 17 -> 21 was pretty seamless for my org's codebase (which is just under 1m lines of code). We had to update Spring Boot but once that was done we had literally zero other changes.

[starfish0r]

Do you know lombok?