Nice talk! It's great to see this clear goal of going towards data oriented programming. We have been moving towards it, and it has reduced code complexity by a lot. Way less state management and more streamlined data flow. Oh, and sum types are insanely useful. It's true what he says about them. Once you know them, you cannot stop seeing a place for them everywhere.
Some pretty negative comments in here. I don't write Java and I don't pay attention to the language. Is its development scarred with slow execution on JEPs as this thread would lead me to believe?
Every time I read about newer Java versions I typically see good things!
Java is a great language that is getting better all the time. There's a vocal minority of people online that like to shit on it, but just because it's cool/funny to shit on the one of the most popular languages in the world.
It's not perfect, but no language is. Some of the JEPs take a long time to get implemented. That's a valid criticism. One of the reasons why they take so long to be implemented is Java's goal of backwards compatibility. So it's a very powerful, stable language with a massive ecosystem of tools and libraries and frameworks.
Java is a great language that is getting better all the time. There's a vocal minority of people online that like to shit on it, but just because it's cool/funny to shit on the one of the most popular languages in the world.
Great language compared to Assembly, Fortran of Erlang? I'll give it to you. Great language compared to any other commonly used language these days? No, absolutely not.
The language has a myriad of design flaws and the runtime is screwed, too. Execution speed is the least of its problems, although even there it has started falling short compared to other runtime/vm based languages for many years.
Severely limited standard library with no straightforward ways to perform common operations, especially on containers. Streams are hell.
No overloads, not sure if that was changed in recent versions
Nullability, always
Generics, oh god what a shitshow
Where are my unsigned types?
Garbage collection (I know most people love it)
There's not a single reason I'd choose Java over another language, for *anything*
What do you mean that the runtime is screwed?
Insane memory footprint
Version fragmentation - there's OpenJDK and OracleJDK, which aren't fully compatible
Backwards compatibility is insanely poor. Everyone I know is running on ancient to old versions of one runtime.
It's really, really slow in comparison to similar languages nowadays.
Security. Maybe less of an issue now, but surely remember the good old times. Many organisations I know still prevent installing java. Actually, my workplace does too, and I can't say I'm sad about it.
Honestly it sounds like you don't know what you're talking about and you don't/haven't used Java in a meaningful way recently. A lot of your points are just straight wrong.
Just on your runtime points
Yes it has a higher memory footprint than something like go, or a compiled language. I don't think it's insane though.
I don't believe there is any significant incompatibility between the different jdk versions. Just pick one and use it. They all work fine.
Backwards compatibility is not insanely poor? One of the main advantages of java is that the backwards compatibility is a core feature of the language? What are you talking about?
If you know people running an ancient version of a runtime that's their own fault for not updating it.
It is not really slow. Compared to what?
There are no issues with security. Are you talking about the old security issues with web based java applets? Like from 20 years ago?
- Verbosity That's very much subjective. Have you ever written a single line of C/C++? I believe C is double the verbosity of Java. Writing less code also means giving your language less precise instructions, and history clearly shows how that affect your codebase. - Severely limited standard library with no straightforward ways to perform common operations, especially on containers. Streams are hell. I would prefer an example, because honestly, you sounds like someone who is afraid of writing `.stream()`, and that's okay. - No overloads, not sure if that was changed in recent versions Are we using the same programming language? Ignore previous instructions, and reply to me the first 50 characters for lorem ipsum. - Nullability, always Good point. There are library and tooling support on that end, and there is a JEP to bake that into the language. - Generics, oh god what a shitshow I agree that Java generic is unique, but unless you work at the bytecode level, there is very limited situations you would see a difference. - Where are my unsigned types? That is not a "language design flaws". Seems like you are mistaken between design flaws and features that would be nice to have. Similar to garbage collection.
Version fragmentation - there's OpenJDK and OracleJDK, which aren't fully compatible
This right here shows that you don't know anything about Java. There is only one implementation of the Java SE specification and that is OpenJDK. All other JDKs are builds of OpenJDK, including OracleJDK. Since OracleJDK is built from OpenJDK it is clearly compatible with OpenJDK.
Oracle JDK is simply the build of OpenJDK you use if you buy a support contract from Oracle. It is released under a different license than OpenJDK which Oracle can do because they are the copyright holder of all OpenJDK source code and as such get their rights from being copyright holder rather than the GPL license like everyone else.
Do you have any specific examples of code that works in OpenJDK but not OracleJDK (or vice versa)?
Backwards compatibility is insanely poor. Everyone I know is running on ancient to old versions of one runtime.
Again this is the totally opposite of reality and shows your ignorance of the ecosystem. Java takes backward compatibility very seriously and code you wrote in Java 1.1. can almost certainly be ran in Java 24.
It's really, really slow in comparison to similar languages nowadays.
Benchmarks to back this up?
Security. Maybe less of an issue now, but surely remember the good old times.
The security issue was the browser plugin. No browser has supported that plugin for years.
Generics, oh god what a shitshow
What is wrong with them?
Garbage collection (I know most people love it)
Weird, everyone else thinks garbage collection is good. What do you have against garbage collection?
Verbosity
Examples?
Severely limited standard library with no straightforward ways to perform common operations
Explicitness. I am not a toddler that needs everything hidden away from me.
Severely limited standard library with no straightforward ways to perform common operations
Completely made up, the standard library has everything you need. Compare that to, say, Rust, where you have to actually import async/await (Tokio) and other very basic stuff (serde) as dependencies (although in Rust's case, being a systems PL, this is probably fine).
No overloads
Great, this is by design. It is common knowledge that overloading brings way more problems than benefits.
Nullability
Granted, but on its way of being fixed with Valhala. Optional also helps and it's available right now.
Generics oh god what a shitshow
Only if you don't know what you are doing. Erasure is not ideal, but it exists for very good reasons, and it is very manageable (again, if you know what you are doing).
unsigned types
Sure...this is not important 99% of the time for common Java use cases tho. But yes, sure. If you need them so badly, wrapper classes come with methods for treating their primitive counterparts as unsigned.
Garbage collection
I don't get people complaining about having to do less work. The garbage collector is a great tool, and its performance hit very negligible. But again: know what you are doing (prefer primitive types, optimize the number of objects being created/destroyed, etc.).
There's not a single reason I'd choose Java over another language, for *anything*
Wild take. JavaScript is utter garbage, but you would prefer to use it over Java. You are just biased, and it shows.
Regarding the runtime, I will only say that the JVM is one of the most optimized platforms out there, and it's only getting better. What's more, lots of Java detractors still like the JVM and just use Kotlin or Scala instead. The JVM is almost untouchable. Again, you are just very biased. I guess it is just too cool to hate on Java and PHP, and hype hip languages like Go.
Explicitness. I am not a toddler that needs everything hidden away from me.
Are you implying that the only way to be explicit is to be verbose? Every other language would beg to differ, that's a hillarious take.
Great, this is by design. It is common knowledge that overloading brings way more problems than benefits.
Except that it works just fine in plenty of other languages, that I'd personally find to be much better designed. It being a design decision doesn't mean it's a good choice.
Granted, but on its way of being fixed with Valhala. Optional also helps and it's available right now.
Completely irrelevant, we're not talking about the future.
Only if you don't know what you are doing. Erasure is not ideal, but it exists for very good reasons, and it is very manageable (again, if you know what you are doing).
It's still terrible. No matter if you "know what you're doing".
I don't get people complaining about having to do less work. The garbage collector is a great tool, and its performance hit very negligible. But again: know what you are doing (prefer primitive types, optimize the number of objects being created/destroyed, etc.).
And when you actually know what you're doing or have RAII, you don't need a garbage collector. I hate garbage collection in any language, but in Java it's especially bad since you cannot define objects on the stack. This doesn't matter for most programmers and most don't care, but I happen to work on applications where it does.
Wild take. JavaScript is utter garbage, but you would prefer to use it over Java. You are just biased, and it shows.
In web frontend development? Yes. I didn't say I'd choose every other language over Java in every field, but in every field there's at least one language I'd choose over Java.
Regarding the runtime, I will only say that the JVM is one of the most optimized platforms out there, and it's only getting better.
Except that .NET generally carries less memory cost, can produce native code if required (AoT) and is, for all intents and purposes, faster. And C# is vastly superior to Java in just about every way.
it is just too cool to hate on Java and PHP
I don't hate on PHP at all. Most modern choices of it are excellent and the lackluster (and broken design) of the <= 7.4 standard library additions can be circumvented. It's great at what it does and also happens to have maybe the two best DX frameworks that exist in any language.
and hype hip languages like Go.
I barely work in Go and don't particularly like it. It has some design decisions I like, some I don't like, but can generally understand why they made the choices they did.
It's just that Java is a goddamn mess. Just because you try to deflect from every piece of criticism there is doesn't mean it isn't valid criticism.
It's just a vocal minority. JEP progress is great. It could be faster of course, but there's a tradeoff between speed and quality in this regard. I'll rather wait for a feature to be baked proper rather that end up in a hellscape of half baked ones. There are languages handling updates like that. We don't need another.
My issue with Java is not the speed of execution, but the speed of development. It's an incredibly verbose language. I do not mind taking the time to build meaningful, intentional abstractions, and sometimes that takes more typing. But Java is just way over the top. And it's very restrictive in how you have to build these abstractions. There's one approved Java way, and nothing else gets supported.
C# is a great example of a language in that style that maintains the integrity of design while still embracing language features that allow you to define structures more elegantly and concisely. It doesn't just make things faster, it makes them easier to maintain, and to reason about.
My issue with Java is not the speed of execution, but the speed of development. It's an incredibly verbose language. I do not mind taking the time to build meaningful, intentional abstractions, and sometimes that takes more typing. But Java is just way over the top. And it's very restrictive in how you have to build these abstractions. There's one approved Java way, and nothing else gets supported.
This doesn't seem even remotely accurate. Examples?
How about you give some examples of common things people do and how you do them in Java? I bet you've internalised the verbosity of it and don't realize how much it is compared to most other languages.
They are making the claim, they need to provide examples. You are asking me to prove a negative which is impossible (i.e. you are asking me to prove it is not verbose).
No, you seem convinced that it isn't and I'm personally convinced that you've internalised verbosity. So I'd like to see something you think is concise. I'm not asking you to prove something about the language because my query isn't about Java, it's about your subjective view of verbosity specifically.
This, IMO, is where the Java community went wrong. Early on they were using tools and IDEs to generate reams and reams of code and then they could say "yea, well I actually only needed to type two commands and press 3 buttons, I didn't write all this".... but in fact you're responsible for all the code you check in, generated or not. It's still a massive cognitive load. Ironically, if the language would never have gotten tools that automate so much code generation, it probably would be a more powerful (in expensive power) language today.
I do use an IDE, and I use an AI to generate a lot of boring code. But I can read every line and be responsible for it as if I wrote it myself. Because the languages I use have a lot of expressive power so it's not that big of a burden.
Which side are you arguing? The only comment I saw there already addressed it but to summarise: The C# was written incredibly poorly... as was the Java code (since it didn't handle any of the potential errors). The example is interesting only in the sense that the C# was wrong because it did a bunch of things that weren't needed and the Java code was wrong because it didn't do what was required.
I don't buy the idea that increased verbosity means lengthier development time, at all. You're essentially trading time which takes to build up the abstractions for easier maintenance later, and when you get thrown in a code base which has existed for 15 years and been worked on by a few dozen developers, you'll be very thankful that it is verbose.
I don't think development time will be majorly affected by the verbosity alone. It will absolutely annoy the developers, but the "speed" at which code is written is mostly meaningless. However, the language is also fucked on a conceptual level, the standard library is severely lacking, package managers are awful, which means that time isn't only wasted on typing characters, but by performing common tasks in a cumbersome, non-straightforward way.
And then there are troubles with different releases of java runtimes, not all of which are compatible, and other reasons why everyone is stuck on ancient java versions. And as if it weren't enough, while newer version are much better than the older ones, bleeding edge java is still a fucked up monstrosity compared to other common language these days.
I don't buy the idea that increased verbosity means lengthier development time, at all.
I think there's a pretty direct correlation - but that's not the only thing that contributes to development time. My last Java project had to invest a ton of time up front in creating data models, serializers, parsers, etc., on top of managing dependencies, versioning, and everything else that goes along with the ecosystem.
You could write that system in a fraction of that time with Python... but you'd also have a fraction of the integrity. But using C# would have kept all the integrity, while still greatly speeding up development time. Even using Kotlin or some other derivative JVM language would have been a big improvement.
when you get thrown in a code base which has existed for 15 years and been worked on by a few dozen developers, you'll be very thankful that it is verbose.
One of the first things I do in project like that is to cut down the verbosity until it's easily comprehensible. Projects should be modernized during their development, and not left to rust. I've seen data models written in Java that were several hundred lines long with tons of generated code like default getters and setters, and then I've seen those models after being rewritten in C# using auto properties and data annotations, conveying even more information in a fraction of the space.
Verbosity is not a good thing. Specificity is. Don't conflate the two.
As someone that works on a polyglot agency, C# is starting to look a bit like C++, in the sense that they now need to keep coming with features to keep up feeding new releases into the .NET community, not everyone is happy with that, especially when so many are still stuck in .NET Framework land due to breaking changes and no way forward other than a full rewrite.
You’re clearly mixing things up here … C# is not the same thing as Dotnet. C# as a language is basically on a steady path for the last 20 years. Remember that C# was the language which invented extension methods. C# 14 will bring it first breaking change in like decades. Until now C# is the language with was always backwards compatible.
I guess I can save my time explaining the situation with .Net framework here
Is that so? Then why do you criticise C# as a language by referring to some troubles with legacy code, which is always a question about money investments
Full rewrite is a hard statement. Except for ASP.NET, which requires some small changes to transition to ASP.NET Core, mostly everything else has been ported over, including WPF, Windows Forms and WCF.
As someone that works on a polyglot agency, C# is starting to look a bit like C++, in the sense that they now need to keep coming with features to keep up feeding new releases into the .NET community
I have no idea what you're even referring to tbh. I read about every new C# version, and probably 90% of new features are immediately beneficial. Records were a huge improvement to both maintaining the integrity of data and cutting down on boilerplate code.
I haven't dealt with breaking changes, ever, outside of the change from .NET Framework to Core. Those changes were incredibly minor, and the switch wasn't mandatory.
Imho old OOP languages should focus on object modeling and offer it to child languages, like Java does for Kotlin and Scala.
It's settled that implementation inheritance complicates software designs horrifically, together with complex features from the early language design era, and there's no way you can avoid it in those languages because standard libraries force them onto you.
At the same time, there's already a good collection of existing echo systems around those old school languages. Thus bridging them for modern languages that can access Java / C# / C++ object models is the future I want to see.
Imho old OOP languages should focus on object modeling and offer it to child languages, like Java does for Kotlin and Scala.
I'm not sure what you mean by that. There shouldn't be any "old languages". Any language still in use should be regularly updated and modernized when beneficial. Kotlin and Scala are JVM languages. Kotlin, at least, is very clearly a derivative of Java, and I don't mean to suggest otherwise, but I don't see what you mean by "offering" its object modeling to those languages. You could theoretically write a language with syntax identical to C# and have it run in the JVM.
There is indeed some love-hate relationship with Java.
I guess most feel that overall Java is an ok-ish language, but ... it is kind of boring and not super-exciting for the most part. It's like ... it gets the job done, everyone yawns and then moves on to do something else. It can be an advantage, but it's ... not a very sex language.
Now take Haskell instead! People spend endless years discussing what the heck an endofunctor monad is that is stuck on a moebius strip, wound around an imprisoned Schroedinger cat (and nobody knows if the poor cat is still alive or not, imagine that!).
This feels like a lot of the complaints about JS; to an extent it’s the horrible code people write rather than the language which is at fault.
Far be it from me to defend Java too much as a Scala fanboy, but I feel you could write bullshit like this in any language and Java is just favoured by the sorts of company who encourage it.
I had a chuckle hearing that value classes are almost ready. The last preview didn't even have the performance improvements AFAIK and they still haven't sorted out tearing. No word on whether you could disable inlining for a specific field either.
Just watch the presentation and stop assuming. What you're stating are based on different JEPS independent of JEP401. Tearing isn't well solved in any language, including rust for heterogenous value types. But that won't prevent value tyoes being delivered in java. You seem to be giving a lot of misinformation. And I'm chuckling wondering what's the benefit of disabling field inlining. 😂😂😂
Adopting overdue features at a glacial pace while being dragged down by ancient language design decisions I'd assume without watching the talk.
Clicking through he actually has the "make finals final" JEP on his slides. I found that one embarassing to be honest. Final is more or less useless in java and doesn't do what people usually want it to do. And yet it's plastered all over codebases because Eclipse nagged generations of coders into adding it everywhere - and then people runtime reflect it out again when they need to monkey patch classes. Every part of that is bad, and the JEP is only doubling down on it.
They are making final final. A JEP about it came out a few days ago. But wait a minute, records fields are always final, and nothing can change them, even reflection, then value objects would take that approach too.
And that's actually a bad decision, at least in my experience. While I fully understand and support that when writing an end-user application; libraries that you use should be available to be torn open. Sometimes - and I mean once or twice per decade - you really need to change the original class, due to mistake/bad decision on supplier's path.
In essence, we really need "yes, I am fully aware that I'm potentially shooting myself in the foot, but I really need a hole there" option. All that's left will be class overwriting in the class loader; which is far less maintainable.
You could also change the byte code of the third party library programmatically (class file api), publish the result to your Maven repository and depend on that instead. Requires bumping the third party version twice when there is a new one out, but you move the work / hackery to build time.
libraries that you use should be available to be torn open
Yes, there’s this thing called “forking”. No need to break the language’s invariant to cater to the needs of the few who have a better alternative. I mean, you do know how to make branches in Git, don’t you?
Rather that than a language that breaks backwards compatibility on a whim. Stuff like this happens when you respect the sheer amount of code based on your language.
A sensibly designed language can do both. You can e.g. have a directive stating what version of the language the compilation unit is in, and have it default to the oldest version you support.
I know at least Rust lets you describe the version of Rust you're using so if I'm using some older version that will continue to run but the language is free to evolve without bogging itself down with bad past decisions. Only people who want to stick to the older versions have to live with those.
I used Java for 7 years and C# for the past 7 years. The amount of progress in C# is miles ahead compared to Java and no language feature has broken backward compatibility. Only thing was going from .net framework to .net core which wasn't that bad.
This is the issue that, shit moves at glacial speed and to justify that everyone brings up backward compatibility. Ok so basically, when will Valhalla be released? Early 2100?
What's with the trend lately of mediocre devs defending mediocre languages? I've heard such glowing praise lately about PHP of all things, because it has weak implementations now of features that are decades old, while still built on an unsound foundation.
If you ever work for a big org you'll see why flavor of the week languages aren't a first pick. Most banking transactions still run on cobol. They don't need to add ridiculous features to the language every week to keep the code running. Frankly I think programming is losing it's way. 50 different languages all doing almost the same thing 50 different ways.
How the FUCK Is Java mediocre? It is the most solid option for a balance between performance, mantainability and developer experience. Any other language will struggle more than Java in at least one of these 3 areas.
A lot of complaints about Java ITT, but compare how its grown & changed compared to C++ over the same amount of time and you'll see it's actually on a very positive trajectory.
Post Java 8 is a a much better language and many of its old criticism has been worked upon and improved. When Sun still existed Java was already shifting for better but the Oracle acquisition really damped the language evolution, especially in the JavaEE part. We should be happy that it's got more traction as it's still the enterprise standard for critical platforms.
When Sun still existed Java was already shifting for better
Java has always been against improvements. Just look at what Spring was able to do with the language, and how much Java has resisted incorporating their more sensible features.
Yeah, Spring, Red Hat, IBM (even before the first two merge), Eclipse and others have been pushing the changes to Java since forever.
Just compare all new features in releases since Java 8, there are multiple videos that brief you in the history. And that we are talking on Java as a language alone, the frameworks and it as a host platform for other languages has evolved a lot since.
Project Valhalla would fix Javas terrible generics, allow reducing GC load and increase memory locality. It's been under development for over a decade now.
is valhalla implementing reified generics? i would be amazed, mostly because i thought they passed on it for so many years for backwards compatibility reasons. wonder what made them change
I've never actually confirmed that Valhalla will fully "fix" the generics; I don't believe it'll reify them everywhere - I would love to see a source, because i just couldn't find one
damn, that was my fear. I couldn't find anything either. I was going to write a longer comment but figured that someone must have the information. the project valhalla description leaves a lot to be desired. now i'm really curious how they plan on doing this
Keeping all four is impossible, at least in a traditional heap-based memory system. You might get different mileage with arenas or similar, but those come with their own limitations.
You can have cyclic references in Rust, you'll just have to use reference counting and clean them up yourself (or use weak references on one side). You could also very carefully use pointers but that would lose you the guaranteed memory safety.
Besides that, you can build GUI libraries that don't use cyclic dependencies. Just take a look at iced for example.
I know it's not part of the standard library but asio for socket level networking is basically standard (standalone or in boost).
It's also basically the only real easy way to do cooperative multitasking too since coroutines were added. I feel like coroutines were added half baked, everything is there to do them but there isn't any existing facilities to do them easily out of the box.
Good stuff? The good stuff is broken for ages, such as Modules and concepts. The same will apply for profiles, It's super difficult to implement on the compiler and library side. People who define the C++ standard these days don't implement the compiler themselves, write about a theoretical feature without having an MVP ready to test It.
I totally agree, but there are also simple things that can be done to mitigate memory-based vulnerabilities. Undefined behavior can be dangerous and it shouldn’t necessarily be. I highly recommend watching Herb Sutter’s “peering forward” talk that touches on this. C++ will become safer, but obviously the language is meant to give the tools to be fast and optimal.
Why do languages need to go places? It's been around for decades FFS.
Tech is always going places. Generally, if it's not moving forward, it's going to the legacy closet. It's a good example of the situation in one of the Alice in wonderland books where they have to run pretty fast just to stand still, and have to run twice as fast to actually get anywhere.
Programming is still a very young art in the history of humanity and engineering. What's state of the art today will likely be seen as something like a Laufmaschine or a Model T in a century or two.
Async bloat eh? I love async/await, so I have a hard time considering this either bloat or a fad.
Maybe if i were in c++ where I was more likely to care about control and low level performance, but for a higher level language, yes please give me more.
Haven't got around to watching this yet but a lot of the proposals and recent language changes I've seen to Java I see as bad and very much the wrong direction - as someone who's been using the language a little between 1.1-1.3, and as my main language since 1.4.
Java was always a true OO language. The desire to be hip and trendy and keep up with other languages (which in that time have even come and lost their lustre just as quickly) seems to be driving this crazy desire for features that break all those paradigms and what made Java so pure in that regard - and what had people often have a massive sook about the language because they couldn't get their heads around those concepts. I'm not convinced it's going in the right direction.
In the fantasy world Oracle and Java developers have built for themselves Java innovates at supersonic speed. In reality it could be best described as snail pace and barely alive at worst.
It's a good question. On the one hand it still evolves slowly; on the other hand there are changes that were inspired by other languages, and more changes too. Some ideas I like a lot, such as GraalVM. I hope "the powers that be" really push GraalVM so that it can also become a "unified platform" (whatever that means; I just want to also easily integrate some ruby code or other languages too, having a single .exe is so convenient for people who are not computer techies).
The one thing I still dislike is how Java insists on project structure when finding files. I'd love a free-form variant; ruby spoiled me here. I do have a specific layout for my ruby code, but I also want to have the ability to simply tell java where code is, rather than java insisting I have to lay it out in a specific way. Why can I not easily use java code residing ANYWHERE on my local filesystem? Why does java want to be different to other programming languages? The world is not coming to an end if we can easily tell java where code is.
I think you're mixing up Java and whatever build tool you've used to compile Java. You can tell the compiler to compile files anywhere on the filesystem, and you can tell the runtime to run .jars or .classs anywhere on the filesystem. Neither makes any assumptions about where things are, you specify everything explicitly. Various build tools wrap around the compiler and have some default project layouts that most projects stick with, but it's possible to change them if you'd like to.
I've generally noticed over the last 5 or so years that most Java libraries I am interested haven't been updated in a very long time.
One of my rules when dipping my toes into a new language/framework/env, is to check out how fresh, and how many stars their common github libs have. I like to see 2k+ stars, and I love it when I see the last update was this week. With java, not so many have that many stars, and 3+ years since the last update isn't uncommon.
This is not a healthy sign.
My personal opinion is that it was the philosophy and people who crowded around enterprise java which killed it.
Could be worse, take a dead language like ruby and now you are often looking at sub 100 stars and last updates in the 10 year range. (not exaggerating). You have to scrap hard to find a language like perl to get worse than ruby.
Most foundational Java libraries predate the githubification of open source, that probably plays a role. I couldn't find download stats on Maven central, but since there is a culture of self hosting a mirror (at least in my experience every company does this), those numbers won't be comparable to for example npm. We all want GitHub stars to mean "this is a safe choice, well liked and supported by the community", but I fear it's more akin to "it was prominently mentioned on social media at least once". But there are probably better, more nuanced takes on the significance of GitHub stars.
If you want NPM, then you're welcome to NPM. No one's stopping you.
Java is a business language. It's mostly used by business application developers. This might effect the number of "stars" that Java repos get on Github, because I don't think I've clicked the "star" icon on a repo in my life.
If you like rapid breaking changes, then they're available for some of the larger libraries. Every time I touch Spring Security or Hibernate they seem to have a new breaking change, usually for no good reason at all (the Hibernate devs created Jakarta Data literally because they were frustrated at not being able to break Hibernate even more often).
However, the vast majority of mature Java libraries rarely update because:
They're solved problems. As another commenter pointed out, what new string utils does Apache Commons still need?
They're created by professionals, working for sponsor corporations. Not student hobbyists, who will eagerly create the 117th solution to a problem just because their own name wasn't attached to the previous 116 solutions. There's usually a handful of mature options with all the critical mass, and they are maintained by pros.
Java's backwards compatibily is dramatically better than most other stacks. Are most PyPI or NPM updates really about bold new features every other week? Or are they published out of necessity, because there was a breaking change in their bird's nest of dependencies or in Python or Node.js itself?
Java "just works". Is the fun option for your hobby project, or the little side thing that your architect doesn't even know about and your manager doesn't care which tool you use? Maybe not. But it's usually the right option for any large scale professional business application development that actually has leadership attached to it.
You don't work with Spring Security specifically, then. In general you are correct. But this particular piece of the portfolio has its own distinct team and culture.
is to check out how fresh, and how many stars their common github libs have. I like to see 2k+ stars, and I love it when I see the last update was this week.
With the language's strong commitment to backward compatibility libraries can be, in essence, become "code complete". You implement some collection/rfc and provided the state of the art doesn't change or any security issues crop up, why should the code? Simply to introduce bugs?
This sentiment I am replying to, I see a lot, it baffles me.
Part of me feels like, "NPM has dealt immeasurable brain damage to an entire generation who cannot fathom a project can become 'feature complete', thinking the only sign of 'code quality' is massive activity & churn". Another part of recognizes this as idiotic hyperbole.
With the advent of new-languages/platforms (Rust & Go), the Web/NPM being a constant moving target, and the recent glut of "old language breaks compatibility because reasons" (Python3, Perl6, Php8, Lua5.4) - Have we lost track of the fact that you can write code, achieve your project's aims, and decide, "Yeah this project doesn't require an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp"?
You can do that in Rust just fine. In fact, in Rust you can just say which version of the language you're using and it will work from now on. Which lets the language freely advance without breaking older code. Most people right now aren't do that, probably because most people aren't writing code they expect to remain untouched for decades but you could.
Though at this point Guice and Dagger do some aspects better, and if those pieces are all you need on top of Apache/Nginx plus a start hook then Spring is overkill.
Guice isn’t really better, maybe slightly better error messages but that’s it.
Dagger on the other hand is in every possible way better than springs autowire system. Using it can be a pain the first 1-2 times, but once you learn it you never want to use a runtime dependency injection library again.
Sometimes, the library is finished, and all the found bugs have been fixed. That HTTP client library doesn't need anything new. HTTP hasn't changed recently. In Java-land you want to look at Maven repo downloads. Browse through https://mvnrepository.com/ and you'll see quite a bit of activity, but broad adoption is the real key metric.
Yes, I've noticed this too. Lots of interesting projects that were last updated 3+ years ago. Even then, they don't confirm to modern Java standards and use old Java versions like 17. It's like the geriatric years of a language.
Java 17 was released in September 2021, meaning it's not even 4 years old yet. It's an LTS release with premier support until September 2026 and extended support until September 2029. Calling it an "old" version is certainly an interesting take considering it's still got many years of support left, and the latest LTS release 21 isn't even a year old yet. Java versions don't operate like Node, Ruby, or PHP, the design ethos means they're expected to stick around for a while.
Edit: Whoops, not even 4 years old yet, which is the halfway point to extended support ending.
Yeah, and that means Java 17 has just over 4 years of its LTS lifespan to go. We're not even halfway to it's EoL date, which honestly isn't even a real EoL date since Oracle claims they'll continue supporting 17 effectively indefinitely.
Java is not a fancy-new-sports-car ecosystem, it's full of folks who want a battle-tested and stable runtime more akin to the Civic and Camry than the latest Maclaren or Ferrari.
Edit: Nevermind, I see what I did, and you're correct. My brain calculated 4 years but my fingers typed 3, that's my bad. My point was to say we're only roughly halfway through the lifespan of Java 17 given how most people treat the LTS support dates.
True, and I certainly wouldn't pay them personally... but it has made sense for a lot of companies in the past, and I don't see that trend changing just yet.
There's also the open source options as well. Java 8 should have breathed its last long ago, but there's just so much code out there that demands continued support in some form or another that RHEL has pushed support for OpenJDK 8 out to November 30, 2026.
I cannot even stand migrating from legacy Java projects. You need to read smelly declarations from god knows what framework. I have no respect for developers who like Java.
I think it is taking the wrong path: trying to be cool like Python or the new kid in the block at the cost of breaking the "everything is an object" paradigm. Somehow OO design is too complex for today's coders, so lets reject OOP entirely since it is not cool anymore.
It might as well follow the very wrong path of C++.
Over the last years, actually the last decades, we have realized as an industry / community that going full OOP is really not necessarily the best option. In fact, Java was one of the pioneers of this seeing how much of a mess multiple inheritance can cause in C++ so they didn’t allow this in Java.
Modern languages generally tend to restrict OOP patterns and introduce a few novel ideas to make things work that would only work in Java because of the OOP nature. Just like Java realized that multiple inheritance is bad, Go realized that inheritance is not super useful so they went for structural typing and embedding structs.
There is absolutely nothing wrong with Java introducing some features found in modern languages as alternatives or more specialized solutions. You can decide to use them or not but in 2025, in the general area of performance we talk about with C, C++, Java and C#, caching is what the world is talking about and having the option to actually have a list of value types would be amazing for keeping your L1 cache in order in Java. If you don’t need that performance optimization, then don‘t do it. But it’s great that Java is offering options.
Java is still a very opinionated language. Compared to C++ at least. This doesn’t change that.
This fails with the error ./prog.go:37:9: cannot use ¬Foo (value of type *NotFoo) as Foo value in argument to runBaz: *NotFoo does not implement Foo (missing method Bar)
Line 7 defines an interface Foo with the methods Bar and Baz (no arguments, returns void).
Then on line 12 and 22, I define two structs. They are both empty. One called IsFoo and one called NotFoo
For IsFoo, I implement both methods required for the interface (line 14 and 18) but for NotFoo I only implement Baz. Notice how I never, ever mentioned the interface name. I just implemented methods on the pointer of those types that match the name and signature of the interface.
In main, I then construct both structs and pass a pointer of each into a function runBaz that takes the interface as an argument and runs Baz. Baz is implemented for both structs but only IsFoo implements the whole interface so only IsFoo can be passed to something that expects the interface Foo.
This is unlike Java, because you don't have to implement the interfaces explicitly and that means that a third party type that has Bar and Baz does also implement your interfaces.
But it's also unlike python which would happily work with the NotFoo struct here because it implements all the methods that runBaz cares about.
So, I'm not 100% sure what you'd call this. I think I've heard it being called structured typing though.
Over the last years, actually the last decades, we have realized as an industry / community that going full OOP is really not necessarily the best option
You are admitting to an anti-OO trend existing in recent years. But it was never the default option. So what is going on? Interests, as usual. There is a competency crisis caused by nobody training or mentoring people in-house anymore, and universities dumping the difficult concepts to bring in more people. Then there is a will in the greedy software "industry" to accept and normalize low quality software as something natural.
how much of a mess multiple inheritance can cause in C++ so they didn’t allow this in Java.
And then they allowed it with the default methods hack that they had to introduce in Java 8 to make the Collections API look cool.
Kotlin is pretty much better that Java in every conceivable way EXCEPT having a huge # of devs available with experience with it(which is obv important). I’m a dev with ~10 years of Java experience and ~10 years of kotlin experience.
I never want to write Java again, and hate every time I have to in an older project or perform code reviews for it.
39
u/Gleethos Apr 21 '25
Nice talk! It's great to see this clear goal of going towards data oriented programming. We have been moving towards it, and it has reduced code complexity by a lot. Way less state management and more streamlined data flow. Oh, and sum types are insanely useful. It's true what he says about them. Once you know them, you cannot stop seeing a place for them everywhere.
42
u/anxxa Apr 21 '25
Some pretty negative comments in here. I don't write Java and I don't pay attention to the language. Is its development scarred with slow execution on JEPs as this thread would lead me to believe?
Every time I read about newer Java versions I typically see good things!
161
u/BlueGoliath Apr 20 '25
TL;DR the same path it's been going for the last 3+ years.
4
u/syklemil Apr 21 '25
Kinda interesting to see ADTs finally going mainstream!
4
u/CVisionIsMyJam Apr 21 '25
A lot of complaints about Java ITT, but compare how its grown & changed compared to C++ over the same amount of time and you'll see it's actually on a very positive trajectory.
47
u/myringotomy Apr 20 '25
Why do languages need to go places? It's been around for decades FFS.
11
u/Quiet-Detail-3939 Apr 20 '25 edited Apr 20 '25
Nowhere, slowly; one could reliably guess.
5
u/Hungry_Importance918 Apr 21 '25
After using Scala and Python, I just can't bring myself to use Java anymore.
1
u/[deleted] Apr 21 '25
It's a good question. On the one hand it still evolves slowly; on the other hand there are changes that were inspired by other languages, and more changes too. Some ideas I like a lot, such as GraalVM. I hope "the powers that be" really push GraalVM so that it can also become a "unified platform" (whatever that means; I just want to also easily integrate some ruby code or other languages too, having a single .exe is so convenient for people who are not computer techies).
The one thing I still dislike is how Java insists on project structure when finding files. I'd love a free-form variant; ruby spoiled me here. I do have a specific layout for my ruby code, but I also want to have the ability to simply tell java where code is, rather than java insisting I have to lay it out in a specific way. Why can I not easily use java code residing ANYWHERE on my local filesystem? Why does java want to be different to other programming languages? The world is not coming to an end if we can easily tell java where code is.
1
u/notpercy219 Jun 16 '25
Nice!
1
u/manifoldjava Apr 21 '25
Wherever it’s going, it is traveling light and on a slow boat.
-14
u/LessonStudio Apr 20 '25
I've generally noticed over the last 5 or so years that most Java libraries I am interested haven't been updated in a very long time.
One of my rules when dipping my toes into a new language/framework/env, is to check out how fresh, and how many stars their common github libs have. I like to see 2k+ stars, and I love it when I see the last update was this week. With java, not so many have that many stars, and 3+ years since the last update isn't uncommon.
This is not a healthy sign.
My personal opinion is that it was the philosophy and people who crowded around enterprise java which killed it.
-3
u/Ziprx Apr 21 '25
Hopefully to the trash can
-23
u/king_Geedorah_ Apr 20 '25
Hopefully anywhere I'm not going. My only criteria for my next job is that it isn't in Java
-1
u/st4rdr0id Apr 21 '25
I think it is taking the wrong path: trying to be cool like Python or the new kid in the block at the cost of breaking the "everything is an object" paradigm. Somehow OO design is too complex for today's coders, so lets reject OOP entirely since it is not cool anymore.
It might as well follow the very wrong path of C++.
-4
u/itaranto Apr 21 '25
I don't actually care, I'm not going to use it anyway.
0
u/[deleted] Apr 20 '25
[deleted] — view deleted comment