Java 22 Unpacking - Inside Java Newscast #59

[@nipafx]

I'm not aware of any changes to the feature list. Maybe no last-minute additions/removals this time? 🤞 So what's your favorite feature? Here are my thoughts: Stream gatherers are really, really cool. I use streams a lot and being able to create my own intermediate operations will be very useful (and fun). It's just a preview feature, though, which gives me a chance to pick it as a favorite in a future release. Another great improvement is multi-source-file programs. I often use single-source-file programs (for example for Advent of Code) and being able to seamlessly split into multiple files is very nice. But it's much more important for Java/programming beginners than for me, which catapults this feature from something that's nice to have to the top of my list. Almost. Because in the end, my favorite are unnamed patterns. Without it, avoiding default branches would be very painful, which would kneecap the entire pattern matching story. And that's bigger than even the Java beginner story - at least to me personally.

[@andrewlalis]

I've been doing my Advent of Code solutions in D, but tried a few with Java and was pleasantly surprised at how much shorter a lot of the syntax is getting now. The unnamed variables look promising in that regard.

[@juliandurchholz]

Prologs hands down... Constructor limitations were such a nuisance!

[@jesprotech]

I think all of these features are great! If you ask me to pick the one I like the most, it will be very difficult for me to do that because they serve very different purposes and therefor I can't compare them. Having said that, I am beyond interested in seeing G1 in action and I was wondering if there is any possible way to see that running in the JVM with some tool like JVMVisualizer? I also do a lot of code in Kotlin and your gatheres and collectors segment caught my attention. Collection is something that is mostly implicit in Kotlin code. I can think of that, the advantage in Java, by doing it programmatically, is that we have more broad control over this and potentially we are able to optimize the collection function with our own implementation through the stream that we also customize. Do you think that this is an accurate thought process or are there other secrets in gatherers and collectors in Java?

[@JanMichalSzulew]

You know what I'd love to see? CONCISE METHOD BODIES. Brian Goetz hinted he might be able to prioritize this...

[@VerhoevenSimon]

All of them are very nice, but I'm especially looking forwards to gatherers.

[@lepaludyves5605]

Love the gatherer api. I can’t wait to play with that!

[@JanMichalSzulew]

Multi-source-file programs will be a god send. I frequently write bits of code (most recently it was an utility to diff two file lists and detect potentially moved files) in my IDE (because that's the fastest way obviously) and then when I need to quickly run them on another machine the pain begins. I also love gatherers, I wrote tons of my own already (chunk stream when two consecutive elements satisfy a certain BiPredicate (how many times I had to write it during my career!), sliding window with any step/window size, zip, flatmap with Function bypassing Collection::stream, filter by type and auto-cast and others), hope they won't waste much time being in preview!

[@kosnowman]

Very good stuff especially for new Java developer like myself

[@nipafx]

Welcome to the community and the language! I wish you a joy, fulfillment, and a good income. 😃

[@markandrievsky6317]

Where are Valhalla and Jep for Withers?

[@nipafx]

Not in 22. 😔 I wish I could tell you more, but I have no inside information either. But I'm optimistic we'll see progress on at least one of those in 2024.

[@Speiger]

​@@nipafxI wonder, yes it is extra work afterwards, but at this point, shouldn't they provide a ETA/Release for Valhalla or at least release the Vector API? Because Valhalla would be epic, but the stream API actually has more use-cases then custom primitive types. The main problem I see at the moment, at this rate i expect Valhalla late 2026 maybe 27, not joking, and then we have multiple features that are intentionally held back because "it would be more work to make them work with Valhalla". And while that would be technically API breaking, anyone who already plans to use these features will use them anyways since they are already accessible... Basically Valhalla now turned for me from "Oh that would be awesome" to a "I would rather see it die at this point" feature due to it holding other things back.

[@nipafx]

@@Speiger I really hope it doesn't take quite that long. 😳 But it's not about more or less work with the Vector API, it's that Java doesn't just throw parts of an API away because there's now a better way to do it. Once it's standardized, it's pretty much set in stone. And, yes, people may already be using it, but they do so with the express understanding that there are changes ahead, so they know the deal. Also, if everybody's already using it anyway, there's no need to rush a release, right? 😉

[@Speiger]

​@@nipafx I mean there is no intention in showing a ETA. Which usually means, as someone who has the same policy, obfuscate the length because you know saying: "It will take another 1-3 years" just puts the project in harms way. And i am fully aware of that. But solid API design that can account for Valhalla compat could be provided. I mean the whole collection framework will support valhalla just fine in theory without API changes? I know the data inserted is a bit more specific but i am pretty sure even that could be accounted for on valhallas side. Same could be achieved by simply using deprecation by providing nonValhalla functions and simply mark them deprecated. On the other hand Thread#stop has still a "valid" reason to exists for forwards compat?.... Yeah forget what i just said... In general is, Valhalla atm is a pipedream and now that other features are locked behind it, the team behind valhalla need to provide some accountability. Its the exact same thing as with MappedByteBuffers that are really powerful but SUCK when you need to close the file in any form without closing your program. (had a accidental while true loop because i had to use: while(file.exists()) { System.gc(); File.detele();} because you can turn of GC calls from code)

[@nipafx]

@@Speiger Re Valhalla timeline: The JDK team is generally very careful when it comes to announcing timelines and usually doesn't announce anything before things are about ready to be merged (c.f. virtual threads). I personally don't have any special insights and base my opinions and estimates on publicly available info. Re Vector API: It's not about compatibility with value types, it's that when value types exist, the API would be designed differently (in some places). If you have a specific proposal (i.e. not just a gut feeling) how to account for that, feel free to propose it on the panama-dev mailing list. But as I said, those willing to accept that they have to change their code later, can already use vectors, but Java's general ethos is antithetical to releasing an API in the knowledge that parts of it will become obsolete soon after.

[@cmyanmar13]

I've never seen the value of the streams API. It just do what `for` does, only slower.

[@kavinsp]

That python dig was personal lol😂

[@nipafx]

😁

[@danhoward7697]

Great stuff! Thanks!

[@bentels5340]

Any idea what the holdup is on structured concurrency and scoped values?

[@nipafx]

I think they'd like to get a bit more feedback from real-life users. Keeping it in review now means everybody adopting 21 in early 2024 can experiment with these APIs and report their experience back to Loom.

[@gsestream]

but openjdk jvm implementation still has bugs in linux, like for example the file save/open dialog selection will override the last file even if you type in a new name in the text box.

[@jay_13875]

Multi-Source-File programs are nice. But in my opinion, JBang is still better for most practical purposes. The ability to load Maven dependencies with a simple comment (//DEPS group:artifact:version) is just insanely convenient.

[@nipafx]

Yeah, dependency management is not yet part of the on-ramp story. Hopefully that will change at some point. 🤞

[@jay_13875]

@@nipafx I am curious how that would be implemented considering that the JVM has thus far been completely agnostic regarding build tools and dependency management. Meanwhile, Maven artifacts have become the de facto standard for dependency management on the JVM, but it remains a 3rd party tool that Oracle understandably may not want to take responsibility for. Because of that, I was (positively) surprised that this is even on the roadmap.

[@nipafx]

@@jay_13875 I'm not saying it's on the roadmap, but one can still hope. It would be very cool if beginners could delay using a build tool until they want to build their own JARs, as opposed to when they need their first dependency, which will usually happen much, much sooner. But for the reasons you point out, this is a tall order.

[@jay_13875]

@@nipafx Fortunately, JBang already does all that today. And you can in most cases use it as a drop-in replacement for the java executable, which is why I would recommend it to both beginners and anyone interested in using Java for scripting purposes.

[@Markus_included]

I find the constructor prologue to be a very nice additon, because I once wanted to delegate to a constructor which takes in a JavaFX Button, but if I wanted to set add an image on that Button beforehand, I had to create an IILE or a static method if I wanted to do that. e.g. this( ((Supplier)() -> { Button btn = new Button(); btn.setGraphic(graphic); return btn; } ).get(), func);

[@nipafx]

Uh, that's a nice trick. And by "nice" I mean "creative/horrible/beautiful". :D

[@guai9632]

yep, this artificial limitation is annoying

[@fertiz_]

Are you planning to add automatic serialization/deserialization to records (or maybe optional with annotation)? record Person(String name, int age); byte[] serializedData = Person.serialize(person); Person deserializedPerson = Person.deserialize(serializedData);

[@zoltanboros8963]

@@dispatch-indirect9206 Many improvements are just for writing less boilerplate code. This would be one of it.

[@ndrvsk]

@nipafx Hi, do we expect to make Java api that neat to remove lombok from our projects? e.g. builders Do we expect to have: - Extension methods - Named method argument With named method arguments there would be no need for lombok builder usage, since it's used not as a builder pattern, but as a readable way of construction

[@nipafx]

I asked Brian Goetz (Java Language Architect at Oracle) about named arguments here: kzbin.info/www/bejne/o3aXmoesrbGHeZY I don't have a statement on extension methods on hand but IIRC, the issue with those are that they severely limit local readability of code, i.e. when reading code outside of an IDE, it is unclear where the method comes from.

[@ndrvsk]

​​​​@@nipafxthx for reply. Don't you think that Brian's points aree a bit not convincing? This feature is presented in C# and Kotlin. Why we try to find reasons for not to change it?

[@ndrvsk]

​@@nipafxlombok builder produces x2 heap overhead, but it's widely used just for readability. I guess that would be nice if Java handled it somehow. There is hope for 'Wither' but it looks a bit ugly in current state in Jep, what's more, it requires to add init params, what is not good for a lot of cases. So Withers can not substitute builders As I see it - only named arguments could handle the issue

[@nipafx]

@@ndrvsk I found his points pretty convincing - much more than "it works in other languages". 😉 And your question "Why we try to find reasons for not to change it?" alleges that the reasons came after the decision. Why not assume good will and that the reasons came before and informed the decision? Regarding "withers", I wouldn't see them as a replacement for builders, either. First, because they're not intended to and, second, because they have very different semantics: A wither is limited to changes that begin with a valid instance whereas builders are expressively designed to start with an incomplete state and then verify validity during creation.

[@ВасилЕгов]

@@ndrvsk Yeah, I write in those languages. And I rather not have the Extension methods. They are pure cosmetics. However, as you mentioned C#, the frustration I get when I see a demo of code, for example configuration of an MVC, and it uses, of course, extension methods. But, the method is in a separate nuget, that I have not yet attached. So, I have a method name, and that is all I have to figure out where this metod is declared. That is one of the worst things that I really dont like. And the extension methods get abused, meaning all the libraries get separated into a lot of nugets and each method is in a separate nuget. It is not that great. And for the named parameters, that is one of the other nasty thing that looks nice and shiny but gives you a headache, when you ask yourself -> Which overload of the method do I have? Or you define all the arguments in a method, then you are forced to define default values and so on and so on. Id rather maintain 10 versions of a method that refer to one private method, than having one mega method with named variables and default values. For small projects it may be nice, but when working with people, id rather not have named variables and default values.

[@vukotici32]

can you thin a better name then Gatherer, somehow its sounds wired :/

[@zoltanboros8963]

Pipe?

[@AlexSmile-y2x]

imho, unnamed variables look like crutches in code

[@IfeSunmola]

They're useful though. Most times, we don't need the entire parameters. It's very common with app development on click listeners It'll even be more useful with record deconstruction. If a record has 8 fields, and I only need 3, adding the remaining 5 just adds bloat. It gets even more useful if a Record has another record

[@JoeMwangi]

Writing those variables is annoying and being nagged and reminded by the IDE that you haven't used them, is something quite a crazy experience. Unnamed variable resolves this.

[@JanMichalSzulew]

I'd much rather have "multimap.computeIfAbsent(key, _ -> new ArrayList())" than "multimap.computeIfAbsent(key, ignored -> new ArrayList())"

[@lodgin]

Really hoping that multi-source-file programs can help turn Java into a language that can build itself, like Zig.

[@guai9632]

but why?

[@lodgin]

@@guai9632 Why not?

[@guai9632]

@@lodgin cause it requires spending some resources to make it happen. and I see no profit in it. that's why I'm curious why do you hope this would be done. what profit do you see in it?

[@lodgin]

@@guai9632 You see no value whatsoever in being able to write buildscripts for Java projects in Java? Code-as-configuration is becoming more popular, and rightly so, yet you cannot really do this without using an entirely different language. Why? Why is this a satisfactory state of being in the year of our Lord, 2023? It's silly.

[@guai9632]

@@lodgin I write my build script in kotlin or groovy with gradle. so this problem is kinda solved already

[@ahuramazda9202]

Although I love Java, even the new features of Java create complexity to simplify programming. In fact, you are seeking simplicity in a complex way. It's better to break Java at some point and clean it up again, and this is inevitable.Sooner or later, this will happen.

[@segedilyan1630]

Why do you need java when there is c# which is completely free and has no owners like Oracle who will sue you in the end for using java. C# is already slowly overtaking java in all parameters and features and it is completely open source, which gives you the opportunity to use it without any risks. And it is very easy to switch from java to c# because the syntax is almost the same.