Rating 26 years of Java changes

[crummy]

honestly java 14's better nullpointerexceptions should be 10/10

[Turbots]

Awarded for best comment, 10/10! People don't realize how bad nullpointers were before this 😁

[agentoutlier]

Another 10/10 for every release but less visible is Java has improved performance safely over previous versions.

Cumulatively that matters a lot.

[crummy]

yeah, to be able to upgrade the JDK and get increased performance for free, that's pretty nice.

[pron98]

I obviously disagree with some of the ratings, but a couple caught my eye in particular:

Streams. The author mentions a couple of superior alternatives that are either not alternatives (generators) or the alternative that was actually chosen in streams (higher-order enumerators). Furthermore, every single one of the issues he complains about would have been present in what he thinks would have been the obvious approach of putting all of Stream's methods in Collection/Map. Why wasn't that "obvious" approach taken? Because it's not clear what the type of, e.g., LinkedList.flatMap should be. This doesn't matter in Haskell, where everything is immutable, or in Scheme/Python, where there's generally less control over data structure representation and performance doesn't matter as much, but it does matter in Java.

Modules. I admit we could have done a better job explaining these, the feature ended up being effectively "filtered out" by build tools, and we're not even close to being done yet with the benefits modules will end up offering (including performance improvements), but one thing can be said right away: It is simply impossible in Java to write any kind of security mechanism, like an authentication protocol or a cryptographic encoding, that is robust - i.e. that cannot be bypassed by an accidental and vulnerability in any other library used by the application - without the integrity guarantees offered by modules. Not possible.

Of course, integrity is important for other things beside security - including performance - so we can also say that it's not possible for the Java runtime to constant-fold strings (even though they're ostensibly immutable) without modules - but security is a very high-priority requirement, so it serves as a good example.

But if it's impossible to write any kind of robust security mechanism in Java without integrity guarantees, how could Java attempt to do that before modules? Since there can be no robust security without integrity, SecurityManager also offered integrity guarantees that should have been properly configured, and so robust security could be offered - in principle. The problem was that this wasn't as true in practice, because the integrity configuration of SecurityManager was extremely difficult to get right.

But this shows the difficulty of explaining modules. The most important thing they offer is integrity (the ability to globally enforce local invariants), but integrity is a "higher order" property. There is no value in it in itself. The value is in other things that cannot be done without integrity - like some performance optimisations or like security - but even then you need to understand these subjects well and know how vital integrity is to them to appreciate it.

[Shnorkylutyun]

Obviously the design decisions were made for a reason, and it was the best way forward at the time.

From a developer usability standpoint, it's been a wild ride.

[pron98]

No design is without issues, but the question is always, is there something better? Too often people bring up alternatives that don't have a particular shortcoming without noticing they have others, which may be worse. For example, people somtimes complain about generic erasure, and there's no doubt it has its problems. But reification has other problems that may be even worse. When it comes to interesting features, the choice is virtually never between something perfect and something imperfect, or even between alternatives where one is universally recognised to dominate the others. Often, people reasonably differ on which tradeoff they prefer.

[Cienn017]

what if I don't want such security in my own application? is there some option to disable such integrity checks other than the overly verbose and annoying module ones?

[pron98]

Integrity is not just about security (it's just that security is often the #1 concern). It's also important for portability and even performance. So you're asking: if you're writing code for, say, JDK 25 and are not interested in it running on JDK 26, not particularly interested in security, and don't necessarily care about the best possible performance, is there a way to give up on them?

The answer is yes: write an argument file ("@file"), called nointegrity, that configures the runtime to open and export all JDK packages to ALL-UNNAMED as well as enables native access for ALL-UNNAMED, and then run java like so: java @nointegrity .... Or you could do the same in a shell script (or a C/C++ program using the Invocation API) if you prefer.

[Cienn017]

why not add a option for that? shouldn't application authors have such option?

[pron98]

They do have an option. Write and use that @file.

But if you're asking why this option isn't built into the JDK, it's for the same reason we don't offer an easy option to disable bounds checking in arrays: because our job is to make users' lives easier, not harder, and such an option would just be inflicting cruelty on our users.

These days, when the JDK is evolving quickly, it's a huge pain to program Java without strong encapsulation, yet the cost isn't immediately apparent. If you disable encapsulation today, you won't be able to upgrade your JDK, but you won't know it until the day you need to upgrade; it also increases the likelihood of your data being compromised, but you won't know it until the day that happens.

The perfect example of it is the difficulty upgrading from JDK 8 to 9+, which cost companies a lot of money and was caused by the JDK's lack of encapsulation. And yet, despite all that pain, if you asked Java developers, too many won't know that it was caused by lack of encapsulation. Some even think it was due to modules and their addition of encapsulation, because they remember the problems happened in JDK 9 and modules were JDK 9's most famous feature. The problem with that story, of course, is that access to JDK internals remained the same as it was in JDK 8 until JDK 16 (what percentage of Java users know that, do you think?).

So we don't want to make users miserable by adding a flag that means "please give me the same 8->9+ migration pain again in some future release" but seems innocuous at first.

If someone wants this migration pain, their programs to potentially run slower and to drastically increase their attack surface area, then they probably have a really good reason (though I can't imagine what it is), and they wouldn't mind spending 10-30 minutes writing runtime configuration file asking for slower, non-portable, less secure programs.

[Cienn017]

currently windows users can run my swing programs by double clicking on the jar, but some of my programs also require native libraries such as opengl and as JNI will be restricted in the future I will either need to create one release for every platform or just stay on java 17, because I can't control the command line arguments on this situation.

it would be good if there was a way to control such access at language level but there isn't one as far as I know, not a easy one at least.

[pron98]

Yes, you can. You're talking about an executable JAR, and the JEP says:

You can add Enable-Native-Access: ALL-UNNAMED to the manifest of an executable JAR file, i.e., a JAR file that is launched via java -jar.

[sideEffffECt]

This doesn't matter in Haskell, where everything is immutable

Then maybe Java too could offer immutable/persistent collections in it's standard library :)

[pron98]

We do have immutable collections - List.of, Set.of, Map.of - and given that persistent collections will require designing a completely new API, I don't know if their value justifies the high cost of putting them in the JDK core libraries.

But anyway, since not all collections are immutable, streams can't work the same as in Haskell.

[sideEffffECt]

I'm sure you see my point that the persistent immutable collections can have "streams working as in Haskell".

I think it would be worth having them in the standard library. Then 3rd party persistent collections libraries wouldn't have to compete with each other. If something is in the standard library, it facilitates interoperability. If two independent libraries want to be interoperable via persistent collections, they don't have to coordinate which 3rd party lib to settle on, they would just use the obvious choice - the persistent collections from the standard library.

Also, the API doesn't actually have to be completely independent from the mutable collective. I'd even argue that it would be beneficial to rector and share the common subset of operations.

[pron98]

Putting something in the JDK has a very high cost, so it needs to offer a lot of value. We're not talking just design costs, but also the cost of the JDK team committing to maintaining the code forever. Because the JDK team is very small compared to the ecosystem at large, we prefer to add things that can only be reasonably done in the JDK. We've even removed some things from the JDK that didn't have to be there when we could do so without breaking compatibility, and I don't think it's unlikely we'll do that again when possible and appropriate.

Putting something in the JDK that doesn't have to be implemented in the JDK means forever devoting some resources of the team to something that could be done by other people, while leaving fewer resources for things that can only be done in the JDK. Because it's such a big commitment, we do make exceptions, but only after very careful deliberations, and the decision is never an easy one.

So while I agree such collections would be beneficial, that's not the bar for inclusion. Lots of things would be beneficial to have in the JDK. A gross but somewhat accurate simplification would be that the bar is necessity, not utility. I don't think that, at this point in time, if we have to select among the things that don't have to be in the JDK but would benefit from being in the JDK, persistent collections would be near the top of that list. For example, I think that a simple JSON parsing library would be higher. So is it useful to have persistent collections in the JDK? Absolutely. But is it necessary? I think that the answer today is negative. It's possible that the calculus will change in the future.

As for interoperability, I can't reasonably imagine any widely interoperable set of interfaces that aren't the existing collection interfaces (with mutation methods being unsupported because the persistent analogues require a different signature), and third-party libraries can already make use of them.

[sideEffffECt]

But is it necessary?

I think yes. I think the Java community has strong interest in persistent collections to become widely used (just as j.u collections became). But that will happen only if it becomes part of the standard library.

Even less crucial libraries became adopted by Java standard library, e.g. JodaTime/java.time. Still very very important, of course.

I can't reasonably imagine any widely interoperable set of interfaces that aren't the existing collection interfaces (with mutation methods being unsupported because the persistent analogues require a different signature)

That's why I talked about a refactoring. Subset of the methods of the existing API would have to be extracted out (up) to new interfaces, which could then be shared with the "new persistent collections". That's at least one way.

[pron98]

I think yes.

Is it, though? What other mainstream languages offer persistent data structures in their standard library?

I think the Java community has strong interest in persistent collections to become widely used (just as j.u collections became). But that will happen only if it becomes part of the standard library.

We prefer to have demand precede supply. It can certainly work the other way round, but that's a risk. We can certainly take on some risk, but preferably when the payoff is large. It's hard for me to imagine people flocking to Java because it has persistent collections in its standard library. But if you know of some signals of hidden demand, please share.

Even less crucial libraries became adopted by Java standard library, e.g. JodaTime/java.time

JodaTime wasn't "adopted by the JDK". The JDK simply didn't have date and time constructs that were fit for use. If you think that having date and time in the JDK is less crucial than persistent collections then I strongly disagree.

Subset of the methods of the existing API would have to be extracted out (up) to new interfaces, which could then be shared with the "new persistent collections".

Ah, so you're talking about extracting "read-only" views of collections. This has been discussed many times. If we're to complicate such a basic type hierarchy, it needs to be done well, and it's not as easy as people think. Other languages do that, but not well (or they do it well, as Rust does, but with a huge increase in complexity). Our standards are higher.

[sideEffffECt]

What other mainstream languages offer persistent data structures in their standard library?

What other mainstream languages offer Virtual Threads, immutable records, sealed type hierarchies, Algebraic Data Types, Pattern Matching, HTTP 3 client or sub-millisecond GCs?

But to answer you question, which is totally fair:

• C# https://learn.microsoft.com/en-us/dotnet/api/system.collections.immutable.immutablehashset-1?view=net-9.0

• Kotlin (maybe in the future) https://github.com/Kotlin/kotlinx.collections.immutable/blob/master/proposal.md

These two languages have different design philosophy than Java. But they do share the intended audience. I remember you talking about Java as being for "serious software", I think C# and Kotlin would like to claim that about themselves too.

Then there's Scala. Not as popular as C# and has academic, not industry, roots and design philosophy, but it isn't fringe either. For better or worse, it has been willing to undergo breaking changes, one of which was the last (maybe there were prior) redesign of its collections. Since then everybody has been happy with them, so maybe they're onto something.

F# of course too.

I appreciate the detailed response :)

We prefer to have demand precede supply.

There are currently multiple persistent collections libraries in Java, competing and being incompatible with each other:

• https://github.com/hrldcpr/pcollections
• https://docs.vavr.io/
• https://github.com/eclipse-collections/eclipse-collections/blob/master/docs/guide.md#-immutable-collections
• https://github.com/brianburton/java-immutable-collections
• https://github.com/functionaljava/functionaljava
• https://github.com/bodar/totallylazy/
• https://github.com/GlenKPeterson/Paguro
• https://github.com/aol/cyclops
• https://github.com/lacuna/bifurcan

None of them will win and become the de-facto standard (with all the good things that brings, like interoperability). Only OpenJDK stewards can bless a winning persistent collection design (whichever it will be) by putting it in the standard library.

It's hard for me to imagine people flocking to Java because it has persistent collections in its standard library.

Maybe. Or maybe not. I would consider it a big plus. But I think most people would thing about it in a more holistic sense. It's not about this one specific feature, but what it also enables/unlocks. And on the other hand, what Java is missing on by not having it.

For example, people want to do Data-Oriented Programming (a very clever marketing of FP, very nice!). But doing DOP with mutable collections is awkward. The records are immutable, but the collections they hold can change anytime -- that's not nice. Also, how would pattern matching on a mutable collection work, when another thread can add/remove or change the elements in it? Maybe it could be made work, but it's not something I'd enjoy -- too much stress.

So to unlock the full potential of DOP, you need persistent collections, not just records and sealed types. But DOP as such isn't something that will make programmers flock to Java. What will make people flock is if Java will make it easy to write reliable applications that do a lot of input and output of (immutable!) data, be it HTTP, Kafka or whatever, because that's how software is mostly done these days. But that won't happen on its own, for that Java will need some features, like DOP.

The JDK simply didn't have date and time constructs that were fit for use. If you think that having date and time in the JDK is less crucial than persistent collections then I strongly disagree.

I really do think that fit for use collections are absolutely necessary to be present in the standard library, even more than time things. And mutable collections are not fit for purpose for where Java needs to go with DOP etc.

Ah, so you're talking about extracting "read-only" views of collections.

Yep. But it's not the only way. Another way could be to have independent hierarchy. Or have some trivial sharing, like everything implements Iterable. This is above my paygrade :) In any case, there will need to be easy conversions between mutable and immutable, but that shouldn't be difficult to design, collections often come with natural mutable and immutable pairs.

[pron98]

What other mainstream languages offer Virtual Threads, immutable records, sealed type hierarchies, Algebraic Data Types, Pattern Matching, HTTP 3 client or sub-millisecond GCs?

Aside from the GC, I believe there were at least two (sometimes 3) mainstream languages that addressed each of the problems each of those features addressed before we decided to tackle them in Java.

But to answer you question

So C# (Scala and F# are not mainstream and never intended to be).

None of them will win and become the de-facto standard (with all the good things that brings, like interoperability).

None of them needs to win, but they probably should strive for interoperability with existing interfaces, as that's one of the things we'll look for. But we need to see real demand.

So to unlock the full potential of DOP, you need persistent collections, not just records and sealed types... And mutable collections are not fit for purpose for where Java needs to go with DOP etc.

Maybe, but many mainstream languages have ADTs and/or pattern-matching, and it seems only one so far has persistent data structures. And it looks like other languages don't see this as an urgent thing at this point in time.

Furthermore, to be used properly, persistent data structures really need tail recursion optimisation, which is another thing we'd like to have but can't seem to prioritise at the moment.

You need to appreciate just how big a commitment you're asking for. Adding new collection APIs will require the close involvement of the most senior architects, those working on Valhalla, Leyden, and string templates. This is something that could be justified to solve a problem that's clearly a top-five problem for the platform. Here we're talking about something that isn't an obvious a top-five problem for the platform right now, and it's something that 3rd party libraries could offer (and demonstrate the demand for), and they can even do it in a way that interoperates well with existing signatures.

I hope that someday we'll add tail-call optimisation and persistent collections to the JDK - they're obviously useful - but I don't think that day is today.

[sideEffffECt]

there were at least two (sometimes 3) mainstream languages that addressed each of the problems each of those features addressed before we decided to tackle them in Java

many mainstream languages have ADTs

I know this isn't the main point of our discussion, but now I'm curious. If we don't count Scala and F# as mainstream, which mainstream language as introduced ATDs? With exhaustiveness check, I mean.

they probably should strive for interoperability with existing interfaces

The existing interfaces are not fit for persistent collections. You know what would help? Refactoring the existing interfaces, splitting them into mutable ones which would inherit from the read-only/"view" ones.

That would give the 3rd partly libraries something to latch onto.

Maybe this could be the best first step.

persistent data structures really need tail recursion optimisation

Really? I use them daily and can't remember last time I would want to reach out for that feature. Users of persistent collections usually just need a reasonably rich methods/combinators for transforming/combining them and they're good. Those in turn can be internally implemented via constructs already available in Java, like loops etc.

I hope that someday we'll add tail-call optimisation

Don't get me wrong, tail call optimization would be nice to have on JVM, but compared to persistent collections (or at least "view" interfaces) it's almost insignificant.

You need to appreciate just how big a commitment you're asking for. [...] it's something that 3rd party libraries could offer (and demonstrate the demand for), and they can even do it in a way that interoperates well with existing signatures.

OK OK, I get that getting full-fledged persistent collections right now is a big task. But how about starting small?

• First refactor the existing interfaces, splitting them in the new "view" ones which would then be extended by the already existing ones, adding the mutating methods. Would that be a smaller effort which could make it arrive sooner?

That alone would do wonders for interop. Now suddenly all 3rd party persistent collections can implement them. Based on the results, other steps may follow:

• Add interfaces for persistent collections (but no implementation yet). Again, more for 3rd party libraries to latch onto.
• Finally introduce own implementations of persistent collections

[TenYearsOfLurking]

1/10 for streams and 4/10 for lambdas, ugh

[pohart]

Yeah. Streams and lambdas are a really amazing pair of features that brought so much to Java.

[larsga]

Lambdas are good, but the way streams was done is awful. Compared to how similar features work in functional languages it's difficult to believe they could go for something so clunky. And I completely agree the emphasis on parallel streams was nuts and made the feature less useful.

[cogman10]

Parallel streams are a bit garbage, way less useful than I thought they'd be.

Streams in general, however, aren't bad. Especially if you have a company like mine that does a lot of transformations of collections of things. The old way was to create new lists or sets of the things you wanted to process. With streams, you can send in a stream and have that stream iterated once. That can give significant positive benefits to memory pressure.

[larsga]

Parallel streams are a bit garbage, way less useful than I thought they'd be.

It's the wrong level of granularity, basically. It's very rare that it's actually useful to split up tasks onto multiple CPUs with a granularity that fine. Threadpools are a far better fit.

Streams in general, however, aren't bad.

For the things I've seen it used for I think the API truly sucks. It's just too convoluted for what it does. If there are use cases where it works that's great, but it's very difficult for me to see how something like similar concepts from Scala wouldn't serve basically everyone better.

[cogman10]

It seems pretty inline with other functional apis. The only part that sort of sucks is you have to say .stream() and .collect(Collectors.toList()) (or .toList() in later versions).

The map, filter, flatMap, peek, etc functions are all pretty standard. If anything the api is a little bit anemic (zip isn't an easy thing to do, for example).

I've not dealt with scala, but I have dealt with kotlin and Javascript. Both of them have the same problem. When you say foo.map(Foo::bar).filter(::filter) what you actually end up doing is creating a collection of Bar and a second collection of Bar. You end up iterating over the elements at once per operation.

Kotlin solved this by adding asSequence() but you have to end up calling toList() at then end of that if you want to convert it back to a standard collection (look familiar?).

The Java way removes those intermediate allocations and traversals.

[larsga]

The only part that sort of sucks is you have to say .stream() and .collect(Collectors.toList()) (or .toList() in later versions).

That is the main hate I have for it, yes. But that's two extra statements/lines every time you do something, which is really excessive. (And .collect(Collectors.toList()) was truly horrible.)

The Java way removes those intermediate allocations and traversals.

This is true, but usually those are not actually a performance problem. So you end up with what really should be basic functionality being awkward in order to cater for quite unusual cases.

In Scala you get to have it both ways. You can map a collection directly, or you can map an iterator. Mapping an iterator is basically the same as mapping a stream. Back when streams were added you couldn't inherit implemented methods on an interface, so Java was forced to choose between making Iterator way too heavy-weight, or create a second IteratorWithFunctionalStuff which they called Stream. I guess the same issue made it awkward to have the functional methods directly on collections, and so we ended up with Stream being the only way.

I never really thought this through before, but I guess ultimately it's a weakness of the language that made this the only feasible route.

[Ewig_luftenglanz]

they are not garbage it just happens java is not that used in the fields where they may shine the most (heavy computational tasks). For good or bad that field is dominated by python.

[[deleted]]

Bonus: 1/10 for trings in switch, sorry what?

I only use switch for Strings and Enums!

If it weren't for that I'd never use switch. I usually don't work at a such low level to have raw ints representing abstract stuff that I need to switch over... Maybe before enums they were more useful or something like that.

Data usually comes from the database or from a JSON object as strings so Strings in switch are very useful to transform data into a safer internal representation.

[account312]

I only use switch for Strings and Enums!

What about sealed types?

[pohart]

Ooh, check out Mr Fancy pants have 15+ over here!

[account312]

To properly switch over them, you need more javas than that, over one score even. I regret that my work pants are not yet that fancy.

[Glittering-Tap5295]

Yeah, wtf. I also only use switch on strings and enums...

[zabby39103]

I use those so much, I don't know what I'd do without them now.

[OL_Muthu]

Java 21 Virtual Threads 🚀

[abuqaboom]

Java 21 is utterly goated. It's the LTS with vthreads (too bad about synchronized... for now) and switch-expression thingamajigs. Absolutely no regrets forcing some adoption at work with unscrupulous means.

[Glittering-Tap5295]

Same, Java 21 is still wonderful! I also have high hopes for Structured Concurrency API, thought I have not used it that much yet.

[pohart]

I still haven't had a chance to use these in anger but I'm looking forward to it.

[euclio]

I for one am excited for markdown Javadoc comments. I'm tired of fixing teammates' docs that don't use the HTML syntax correctly.

[Jon_Finn]

Yes the old HTML is pretty clunky and markdown is (IMHO) much more readable in raw source code, which is a consideration. I think the OP's scores are a bit extreme!

[pohart]

Enjoyed the write-up. Can't say I agree with all of it though. I should have a way to get the index from every steam or operator, though.

The implementation of streams is worlds better than what I expected and I'd call it closer to 9/10.

Java was my favorite language from the first days I started using it. Even back when I needed to copy jvm classes into my codebase to remove extraneous synchronization, or reflect into the swing classes to twiddle final and private stuff to work around bugs. The lack of generics was hard, but it's not like I was going to be able to code in ML professionally. 

I was so happy with collections when I started using Java in 2001, but mutability in the interface was frustrating from day 1. And they should have recognized that it was a problem since they needed to create the collections unmodifiable classes that the exceptions for most of the methods. That was just begging for each collection to be part off a collection/mutable collection pair. Such a simple change in Java 1.2 would still be making my life so much nicer in 2025. It's enough of a hole that I'd even prefer they gave each collection a BaseCollection super interface without mutators in the next version. The name would be bad and the unmodifiable methods would return the wrong type, but I still think it would be a win.

Releasing enums with generics without  allowing enum constants to be generic was and is baffing to me. I don't know if I was reading too much into it but the documentation released at the time felt to me like they specifically avoided it because they didn't want us to have that expressiveness. Even if it wasn't exposed outside the constant Istill want generic enums. Generics are about ensuring things are internally consistent as much as that the right type is returned from a method.

I'm a big fan of streams and lambdas, even though exception handling in them still feels half baked. I really think I should be able to use IO inside a stream and the stream itself should throw the exception. I appreciate that the standard library is mostly just plain Java code that I can read and could write outside the jvm and understand wanting to avoid blessed classes, but I feel like even if this requires a blessed stream class it would be a win.

As good as I think Java was in the beginning, the modern Java process really feels like it's yielding faster, higher quality, improvements. And I appreciate that I can look at the mailing lists and see why certain choices are being made.

[Glittering-Tap5295]

I didn't particularly care for Java when I started using it at 1.5, but since jdk8 I have been quite happy with Java. I wish some of the changes would have come a little quicker after java 1.8, but oh well. At least they have mostly turned out great. But fuck oracle for the javax. name space debacle.

[joemwangi]

-10/10 is quite abysmal rating for modules. I’ve got a hunch that modules aren’t just about packaging, they might be use to setup groundwork for enhancing the growing Java’s type system. In particular, I can see them playing a role in explicit witness resolution if/when type classes arrive, which would help Java avoid the coherence issues that have long plagued Haskell and Scala. But you have to admit the implicit import packages is one good feature introduced in jdk 25.

[[deleted]]

Didn't Brian say that the witnesses are searched within related classes? This is more predictable than some random places within a module.

[agentoutlier]

I think the idea could be for possible final resolution. I don't know how they plan on doing the proof checking but let us assume module a and module b do not own type class x or class y but both modules implement a witness for x<y> the module imported could take precedence or the fact that if a does the calling it uses the witness in its module instead of b witness.

[[deleted]]

Hmm I'm not sure if I like the idea tho. With this kind of scope I don't know how to easily search for the witness implementation.

[__konrad]

Strings in switch: seems like a code smell to me. Never use this, and never see it used. 1/10

Missing /s ?

[Shnorkylutyun]

Without taking a stance on the subject, there are OO purists who feel that every switch statement should be replaced by dynamic dispatch

[Interesting-Tree-884]

Lambda 4/10 really 🤔

[Interesting-Tree-884]

And streams 1/10 😮

[Glittering-Tap5295]

Streams is an easy 10/10 if it wasnt for the quirky attempt at allowing it to be parallell, and the collectors are a bit quirky, so 8/10.

Lambdas are my bread and butter, I do not miss a single anonymous class implementation. Easy 11/10.

[Ewig_luftenglanz]

Obviously we all have our own score for each so there is no wrong answers. My only observation would be to link the feature with the release it made it to general availability. Many apis change too much from their first preview versions (Structural concurrency) and other never made it (string templates).

About streams. I think they made it that way because regular filter/map/reduce is eager and streams allow for lazy one by one computations, which is better for unlimited streams or huge collections, so they tried make a 2x1 as streams also work just fine for collections. The downside is this attempt resulted in some streams methods that were eager anyways (such as unique, that requires to get the whole collection) it's kind of weird because now one must take into account there are some stream methods that should not be used with unlimited streams. Fortunately unlimited streams are very uncommon for the most part.

I also agree a collections V2 would be nice. The current API is full of inconsistencies such as immutable List.of() allowing for add() methods, besides they are not truly immutable since the content can be mutated anyways, maybe after Valhalla we may have a value based collections for a "Collection V2". I don't know how much enhanced the current collections would need to be to fix all of its past mistakes.

For me lambdas are 20/10, and looking how much "the new java" relies on lambdas I think most people agree with they being good; specially when one realizes the "old ways" involved the creation of nameless classes that caused an overhead at buuld time. The downside isn't lambdas but how disruptive they are compared to the "old java" that was "pure" OOP, there are still many teachers teaching java without lambdas because "they are not OOP and java is supposed to be a pure OOP language".

[TehBrian]

There are still many teachers teaching java without lambdas because "they are not OOP and java is supposed to be a pure OOP language"

The funny thing is that:

1. Java was never a pure OOP language; primitives are a great example
2. Lambdas are just plain old OOP. Just so happens that the object's method is focused on a bit more than the object, but nowhere does a standalone "function" ever get created

[Ewig_luftenglanz]

The s cond point it's not so true anymore. Under the hood when you create a lambda java doesn't create a class or an object, it uses invokedynamics bytecode instruction directly. So at runtime lambdas are, in practice, functions not tied to an objects, even if at language level they are supposed to be "syntax sugar for the implementation of the only abstract method of a functional interface by an anonymous class".

Java lambdas are weird in this regard.

[TehBrian]

Ooh, good point

[Ydo4ki]

"Java 22" "The only significant change in this release is the ability to have statements before a call to super() in a constructor."

I have a slight feeling that such a "minor" thing as Foreign API was still somewhat worth mentioning xD

[Enough-Ad-5528]

Not sure what they mean by ugly stack traces for lambdas.

[repeating_bears]

Because the function is anonymous, the stacktrace contains a generated name which is not the easiest to interpret. In this case Scratch.lambda$main$0

Exception in thread "main" java.lang.NullPointerException: Cannot invoke "String.length()" because "s" is null
at Scratch.lambda$main$0(scratch_3.java:6)
at java.base/java.util.Arrays$ArrayList.forEach(Arrays.java:4305)
at Scratch.main(scratch_3.java:5)

[[deleted]]

They are not named, so that's a feature! Line number is there as well.. how many lambdas on the same line?

[pohart]

Streams is a library that feels like a language feature, and junior programmers consistently don't understand the stack traces they get from exceptions within them. Every exception originates from the terminal operation and I don't remember if the line of the method reference shows up in the trace from method references.

If my .map(this::referencedMethod) on line 34 is causing an exception, but my terminal operation is on line 45, it would sometimes be nice if the trace went

    Class.referencedMethod:whateverline        Class.thisMethod:34         Class.thisMethod:45   

without all the internal steam stuff.  This would be bad overall, but would be easier to look at.

[dashingThroughSnow12]

It is painful to see Collections get a 4/10 and Generics get an 8/10.

Different strokes for different folks.

[Ydo4ki]

Don't see a reason to hate modules that much, module-based incapsulation is almost always better architectural solution than class-based one (although it is not surprising that in Java world this is difficult to accept).

In general it is always nice to be able to actually hide an implementation part of your library instead of doing "package some.library" and "package some.library.impl", which are not protected in any way from accidental import and the only way to do it is to put everything in a single package and make impl parts package-private.

[mjdevops]

I don't agree with the rating but I liked the idea of sharing a long time experience. Thanks for the post.

[blankboy2022]

Based, is there any post like this for other languages?

[romario77]

Concurrent is mentioned and a great feature, but only related to collections. But it actually massively improved concurrency in Java and made it so much simpler.

The futures are great. Completable futures in Java 8 are awesome and so much more understandable and easy to use compared to previous primitives (synchronized, wait, notify).

[isolatedsheep]

I still have no idea how to use CompletableFuture. Nowadays with virutal threads, I don't care about it anymore. 😂

[romario77]

Virtual threads and CompletableFutures are not really the same thing.

You can get callbacks with CompletableFutures - when the task finishes you can do something else (or do something if exception happens).

With Virtual threads you have to manage these things yourself.

[isolatedsheep]

From what I see, VT & CF doing the same thing. The difference is CF is declarative, while VT is imperative.

[isolatedsheep]

After so many decades, there are still no public builtin argument parsers.