Java Withers - Inside Java Newscast #67
Вставка
- Опубліковано 17 чер 2024
- JEP 468 proposes a solution to the verbosity that can come from modeling mutable state with immutable records: derived record creation aka with expressions aka withers . That'll make it easy and succinct to create a copy of a record instance while changing just a few components.
Links
JEP 468: openjdk.org/jeps/468
It's not names parameters: mail.openjdk.org/pipermail/am...
Chapters
0:00 Intro
1:23 When Immutability Births Verbosity
3:22 Derived Record Creation
5:12 Nitty Gritty
6:39 Named Parameters - Not!
8:34 Brian Goetz on Named Parameters
Tags #Java #JDK #OpenJDK - Наука та технологія
Nice enhancement. Re Brian Goetz's point about considering backwards compatibility of future enhancements and not just implementing a new cool feature: This is one of many reasons I was very comfortable coding in Java.
Yes, exactly
This new 'with' feature would have been nice to use when I was mis-using the Object#clone() method early in my career. Also, I saw the video title from my mobile. When I searched for it on the PC to actually watch, I almost got lost in a sea of Java 'Minecraft' Wither videos (not complaining).
I fully understand the implications of implementing named parameters with default values, but please, continue exploring potential solutions. There must be a way to satisfy everyone's needs, even if it requires some compromise. This feature is undeniably valuable
Loved the track on the background! Vvvzuuum!
great
Any thoughts about named parameters?
Creating records with a lot of parameters is somewhat messy
The actual problem for me is the public constructors in all records, some constrains cannot be maintain for several reasons and when that happens flexible contracts are a safe place: Builder pattern, defaults... I disagree with some lombok decisions and I usually omit it from my projects, but builder (with tobuilder) annotation saves plenty of work. Please, consider private constructors in records and some kind of builder pattern with defaults. That solution is portable to classes (it was there before) and already tested in other languajes. No need for `with` when you have an actual object and there is less chances to abuse that.
Are there any plans to add the equivalent of @lombok.Builder so that we can finally can get rid of Lombok?
Don't withers (or record deconstruction patterns for that matter) cause the exact problem regarding refactorability Brian brings up?
Once you have clients using withers on records, refactoring a record type into a class would break that client code, or am I missing something?
As it stands yes but I believe the plan is to bring withers to standard classes via the introduction of a “destructor” that would allow a class to be decomposed into its components
In my mind, the more elegant solution would be to have built-in builders for records (like you would get from lomboks @Builder annotation) and give those builders an of() method. That way you could create a modified instance like so:
var newPoint = Point.builder().of(oldPoint).x(42).build()
At 5:27, the name of the record class is "Point5D", but the name "Point" is used to create its instance. Is that a mistake or I am getting something wrong?
So, min 9:30, is 'with' also allowed for classes? otherwise, how does this do not break refactoring from records to classes?
actually the problem of refactoring, especially for third-party libraries, can be attributed to a lot of things...
That was exactly my thought when I listened To Biran Goetz part. If there is no wither for classes, then the path to refactoring from records to classes will be lost.
One could presume they considered adding withers was more worthy than adding named parameters 😁
@@ESGreenie To me, this just mean that we are going to soon get with for classes, where classes can implement some annotation to tell what is the 'canonical' constructor and what the argument names are. I do not see another way out of this funky situation. Or... drum roll..... deprecate the 'class' keyword!
This seems great to me. Why not?
so in records we can set the parameters value using its name? like ```end``` in python ``` print("hi", end=" ") ``` ?
Javaland was great!
Maybe we will get default value for method arguments one day. It pains me that I have to overload method when I want to have default values for methods
Java WithUs :)
And now the JEP has the Release field set to 23 already...
lol Mike "String Template" Tyson
'Whithers'?
Ooops 🤦Fixed, thanks!
I wish we had method parameter deconstruction. For example:
boolean lineStartsAtXAxis(Line(Point(_, double y), _)) {
if (y==0) return true;
else return false;
}
Not with a method. but that should be possible with a switch or if instanceof with a deconstruction pattern , right?
the wither method is look like the double braces instantiation if you look more into it
public class Program {
public static class Vector {
{
a = 10;
b = 10;
}
public int a;
public int b;
}
public static void main(String[] args) {
var vector = new Vector() {
{
a = 0;
b = 0;
}
};
}
}
Subclassing to initialize is not great
That looks daft!! convoluted and difficult. If only you had known Scala, you would have implemented a copy() method on the Record class. Just as Scala has been able to do with case class's (immutable values / types) for years! I once had a very brief email exchange with Brian Goetz, about having a copy method Record types. Immutability is great, but sometimes, it can be necessary to adjust an immutable value. Brian responded with "he saw no possible use case for such behaviour". 😀
This is the same way how C# does, Java is more like copying from C#.
The java from microsoft?
Every language is copying from everyone else. As Brian Goetz have said many times, Java goes slowly forward in order to see which feature actually works well in other languages before including them. This way you won't end up in the mess which is C#, C++ and partly Kotlin.
@@pompiuses Resume: java is a well structured language for business. Java still one of the more used languages on every site that you search, most people that don't like java is because they don't use java.
@@pompiuses Calling C# or kotlin a 'mess' compared to java is... cute.
Builders + withers , and we can convince teams to stop using Lombok.
I certainly do not like the "record" construction.
Go all-in for a regular Builder-pattern, not obfuscating it with most weird naming, have a closer look at Lombok and "@lombok.Builder(toBuilder=true)" because this is really, REALLY good!
No new, half-backed semantics not looking like any living animal, duck or elephant, pleeease!
Annotations are a bandaid not a cure.
Annotations are not a good solution because they feel ad hoc.
In the other hand Lombok it something Java developers had been force to live with to avoid half of the boilerplate code needed to manually implement builder pattern and getters and setters, but has been said several times that code generators are not advisable because they are actual code generated that programmers has not control of.
Records pisses me off. Not because of records themselves, but because they make classes seem second-class (hah) citizens.
Immutability has very little value for me in my day-job. Getting rid of boilerplate does.
Immutable objects and values are very useful, especially if you want to access it from many threads at once (You can do that without creating race conditions - because it's immutable!).
I'm using a mix of traditional OOP and Data Oriented Programming (not to be confused for Data Oriented Design)
Golang fans tell that go's garbage collector is world class. No other language has such world's best and most performant gc.
I don't like it. The simple Withers are good enough for 99% of all cases and for the rest you'd just create your own with-method that takes more than one parameter.
And that works without any new syntax that people have to learn and that doesn't blend in well with the Java language and that works exclusively for records ("we want there to be a path to refactor records to classes") and without awkward limitations that are hard to understand for lots of people and catch you by surprise.
I don't like the idea because it wants too much and is a typical case of over engineered YAGNI.
Oh, and please, whoever reads this, before starting the argument about unnecessary object creation, read about escape analysis.
One step closer to a `@lombok.Builder(toBuilder=true)` 😎
The more steps from Lombok, the better.
@@askarkalykov I guess you meant " one more step away", right? 😗
@@delabassee I guess @mfe_ forgot to add word `functionality` at the end of their comment.
@@askarkalykov i hear this all the time about lombok but when pressed 'why' it always boils down to some kind of irrational bias and 'what ifs' the NEVER happen IRL
do you like Vada Pav?