Still crying for the Elvis operator. For business and database logic, this is the most missing Java feature. We don't want to wrap everything in Optional and lambdas.
They are instead going for nullness markers, so String! will be a String that cannot have null assigned to it. This is a better solution IMO. With the Elvis operator, you have to constantly remember to use it.
@@vinterskugge907 Well, this are two different things. We need both. The Elvis operator is for writing shorter code, especially when navigating through nested data structures.
@@peacemakerle Different but related: With nullness markers, the Elvis operator will be less useful, as many elements in those data structures will be marked non-null. So much less useful that it would not make sense to prioritize it. And I don't think they will (or should).
It took me an embarrassingly long amount of time to userstand that this was not about new features applied to the spring framework..... I really like the new data oriented philosophy. The way to represent future's state with sealed class makes me think of rust's enums ! I wonder if the rest of the APIs will shift this way. I'm thinking about optionnals, and maybe even an error type ?? (Since we still can't handle exceptions in a functionnal way without creating some custom "Try" type. It really is a pain point I experienced
I think the design of AsyncReturn is a great alternative for some situations, but not a great showcase of the problem this solves. after all, this solution conflates happy and error paths in a way that is very much problematic for pure java code... however, when you call a rest api from your code, this could be really powerful, cause you may want to for example examine returns to see what exactly went wrong, and if it's worth retrying
@@shadeblackwolf1508I don't get why mixing the happy path and the error path would be a problem. Error as value is coming back strong in modern languages
I can compile java 17 project with java 8 dependencies but I cannot compile scala 3 project with scala 2 dependencies 😢 (maybe because I'm butterfingered idk)
Using records widely here in business logic. But I really dislike that the canonical constructor of public records can not be private. Now, people are exposing constructors which should be private because there are static create-functions or builders which should be used instead.
The "with" thing seems like a great addition to records. I live in Java 11 World right now, but will be moving up to JDK-21, hopefully, soon. I simply do not understand the massive amount of fan-fare about records, although the most interesting concept about that is that all records are "Read-Only" which seems like a reasonable addition. I know that while something (anything, really) is under development it will seem a lot more important to the programmers until they are finally finished with it.
@@peacemakerleit's because the sealed interface can model heterogeneous values and avoid unrepresentable states, while the enum is forced to include constants that do that. Otherwise it's overkill: just use enum
There's no single, correct way to defensively copy objects. Object.clone(), when it works, only makes a shallow copy. If you need e.g. a List as a field, you can do this to force it to be immutable: record R (List x) { R { // shorthand skips the arguments x = List.copyOf(x); } }
37:50. I fundamentally disagree. You could have made the exceptions on the original signature checked and get the same benefits of the compiler telling you if you miss any case plus: - Avoids the additional boxing due to the `AsyncResult` type, plus better performance in the happy path - You get stack traces in the cases of failure (`Failure`, `Timeout` and `Interrupted`) - You can quickly propagate to the caller unlike `AsyncResult` (no `?` operator or similar) - Compositions comes for free. If a function `f` throws `X` and function `g` throws `Y`, then a function that calls both functions can throw `X & Y` due to the fact that `throws` supports a union of exceptions. With a sealed interface you don't get that, meaning that the dev now needs to create a wrapper for the result types (see `anyhow` in Rust for example) I don't think we're gaining anything valuable with this. I would much rather have proper support for Nullable types or a better `catch` clause for multiple exceptions types (syntax sugar on top of multiple `catch` clauses)
2:04 "we've been delivering quite a lot". No, that's not a lot. Scala delivered all of those features in one shot. 4:08 Productivity-oriented language features: Scala can pattern-match on lists. I think that's very productive. Java doesn't need to copy Scala if it has better features. 22:11 looking at the 2 aligned arrows on the `case` lines, I wonder if there's any tool that can align those arrows for me (something like scalafmt). 44:21 suppose that record A contains record B which contains record C ... which contains record Z. Now I want to create a new instance of A from another instance of A where a field in the record Z changes its value, how do I write that? Does "record with" create more garbage for the GC to collect that a mutable class?
Thank you, I'm glad someone else agrees with me on this. A lot of this has been done, and done better, already. Java the language is not innovating, it's copying, and not doing a good job at it. They invented a new escape character for template strings which they yanked out in JDK 23 - all this for a feature that has been in other languages for decades. Heck, records were done already with Lombok, and they worked with all the existing libraries using reflection like Jackson because they used standard bean methods for properties. These new record types don't. All the innovation is being poured into the JVM. The rest of us are moving on to Kotlin, Scala, or really anything else.
@@knm080xg12r6j991jhgt Java is, generally, avoiding the pitfalls most languages have fallen into while integrating solutions into the language. Loom is objectively better than Async-Await. Java string templates are an objectively more powerful (and safer) construct than naive string interpolation. You've clearly read none of the documentation and the back and forth in the development mailing lists.
Record still pisses me of. Start with a record. Then you need mutable state, so you have to change it to a class, and then you have to add in all the junk code that records got for free.
Yes, I thought the same. The generation of default equals/hashCode/toString should be a feature which isn't bound to a specific supertype or immutable state. Better would be, for example, to control it by annotations. It also sucks that arrays aren't compared by value (but that is only in rare special cases a problem, usually we are using collections).
Java is ancient in terms of features. All of this presentation is just copying the low hanging fruit of Scala which is a JVM language - 10 years later! Talk about "last mover advantage"
![Interview with Product Manager in 2024 [Corporate]](/img/1.gif)
Still crying for the Elvis operator. For business and database logic, this is the most missing Java feature. We don't want to wrap everything in Optional and lambdas.
Without null safety the elvis operator is just Syntax sugar wihthout much use.
They are instead going for nullness markers, so String! will be a String that cannot have null assigned to it.
This is a better solution IMO. With the Elvis operator, you have to constantly remember to use it.
@@vinterskugge907 Well, this are two different things. We need both. The Elvis operator is for writing shorter code, especially when navigating through nested data structures.
@@peacemakerle Different but related: With nullness markers, the Elvis operator will be less useful, as many elements in those data structures will be marked non-null.
So much less useful that it would not make sense to prioritize it. And I don't think they will (or should).
@@vinterskugge907 In real-life applications you will still have many situations where some element in the data structure can be null.
The pattern showed for AsyncResult looks exactly like a Rust enum, a shortcut to get that kind of thing would be great.
Let me be clear, I am REALLY HAPPY that my loved Java could copycat the good things of other languages.
I am pretty sure I saw that pattern in Scala codebase I was working on few years ago.
It took me an embarrassingly long amount of time to userstand that this was not about new features applied to the spring framework.....
I really like the new data oriented philosophy. The way to represent future's state with sealed class makes me think of rust's enums !
I wonder if the rest of the APIs will shift this way. I'm thinking about optionnals, and maybe even an error type ?? (Since we still can't handle exceptions in a functionnal way without creating some custom "Try" type. It really is a pain point I experienced
AsyncReturn looks great! good to know about that
I think the design of AsyncReturn is a great alternative for some situations, but not a great showcase of the problem this solves. after all, this solution conflates happy and error paths in a way that is very much problematic for pure java code... however, when you call a rest api from your code, this could be really powerful, cause you may want to for example examine returns to see what exactly went wrong, and if it's worth retrying
@@shadeblackwolf1508I don't get why mixing the happy path and the error path would be a problem. Error as value is coming back strong in modern languages
No. Stack traces are gone. Have a luck to debug in production
@@alexgorodecky1661why would stack traces be gone? The exceptions should be stored in the records for you to do whatever you want with them
I am still not sure why do we need JEP445 when Jshell is there...
Why Java is becoming more and more like Scala Language ?
it does not. Java slowly introduces new useful features that increase productivity without making code unreadable and keeping backward compatibility.
I can compile java 17 project with java 8 dependencies but I cannot compile scala 3 project with scala 2 dependencies 😢 (maybe because I'm butterfingered idk)
The unstoppable train marches on. 🍾👍
Using records widely here in business logic. But I really dislike that the canonical constructor of public records can not be private. Now, people are exposing constructors which should be private because there are static create-functions or builders which should be used instead.
The "Better Return Type" looks like Result Pattern with steroids!, i like it
The "with" thing seems like a great addition to records. I live in Java 11 World right now, but will be moving up to JDK-21, hopefully, soon. I simply do not understand the massive amount of fan-fare about records, although the most interesting concept about that is that all records are "Read-Only" which seems like a reasonable addition. I know that while something (anything, really) is under development it will seem a lot more important to the programmers until they are finally finished with it.
Record pattern matching looks very verbose, why can’t we just shape instanceof Circle c and just use it?
Whats the benefit of records and sealed interface vs an enum?
This question makes no sense. Those things have completely different purposes.
@@peacemakerleit's because the sealed interface can model heterogeneous values and avoid unrepresentable states, while the enum is forced to include constants that do that. Otherwise it's overkill: just use enum
“Only use immutable data”, my database would like a word.
@lepingouindefeu I write Java enterprise applications that are all about modifying and managing mutable data.
Why records not return implicity in the accesors a defensive copy of a mutable fields?
There's no single, correct way to defensively copy objects. Object.clone(), when it works, only makes a shallow copy.
If you need e.g. a List as a field, you can do this to force it to be immutable:
record R (List x) {
R { // shorthand skips the arguments
x = List.copyOf(x);
} }
😊
37:50. I fundamentally disagree. You could have made the exceptions on the original signature checked and get the same benefits of the compiler telling you if you miss any case plus:
- Avoids the additional boxing due to the `AsyncResult` type, plus better performance in the happy path
- You get stack traces in the cases of failure (`Failure`, `Timeout` and `Interrupted`)
- You can quickly propagate to the caller unlike `AsyncResult` (no `?` operator or similar)
- Compositions comes for free. If a function `f` throws `X` and function `g` throws `Y`, then a function that calls both functions can throw `X & Y` due to the fact that `throws` supports a union of exceptions. With a sealed interface you don't get that, meaning that the dev now needs to create a wrapper for the result types (see `anyhow` in Rust for example)
I don't think we're gaining anything valuable with this. I would much rather have proper support for Nullable types or a better `catch` clause for multiple exceptions types (syntax sugar on top of multiple `catch` clauses)
सब।? 😊
you are looking for JEP draft 8323658
I thought string templating just got dropped? (which is actually a success story in a way)
Not dropped, just saying that this version of it is not what they want, and they'll take their time to find a better solution
@@alessioantinoro5713 That's still dropped. They're starting over completely.
@@bentels5340 Starting over is a big word, they do have experience over what they did already, so it dont think it would take too long
❤ am the first to comment
AsyncResult is useless ... Try .. catch will be more clean .
I will forced to implementar all egde cases ? ( Timeout and interrupted )
2:04 "we've been delivering quite a lot". No, that's not a lot. Scala delivered all of those features in one shot.
4:08 Productivity-oriented language features: Scala can pattern-match on lists. I think that's very productive. Java doesn't need to copy Scala if it has better features.
22:11 looking at the 2 aligned arrows on the `case` lines, I wonder if there's any tool that can align those arrows for me (something like scalafmt).
44:21 suppose that record A contains record B which contains record C ... which contains record Z. Now I want to create a new instance of A from another instance of A where a field in the record Z changes its value, how do I write that?
Does "record with" create more garbage for the GC to collect that a mutable class?
Thank you, I'm glad someone else agrees with me on this. A lot of this has been done, and done better, already. Java the language is not innovating, it's copying, and not doing a good job at it. They invented a new escape character for template strings which they yanked out in JDK 23 - all this for a feature that has been in other languages for decades.
Heck, records were done already with Lombok, and they worked with all the existing libraries using reflection like Jackson because they used standard bean methods for properties. These new record types don't.
All the innovation is being poured into the JVM. The rest of us are moving on to Kotlin, Scala, or really anything else.
@@knm080xg12r6j991jhgt valhalla... one day...
@lepingouindefeu project Valhalla sounds like a magic then 😊
@@knm080xg12r6j991jhgt Java is, generally, avoiding the pitfalls most languages have fallen into while integrating solutions into the language. Loom is objectively better than Async-Await. Java string templates are an objectively more powerful (and safer) construct than naive string interpolation. You've clearly read none of the documentation and the back and forth in the development mailing lists.
Record still pisses me of. Start with a record. Then you need mutable state, so you have to change it to a class, and then you have to add in all the junk code that records got for free.
why do you need mutable state?
With expressions should help with that
Yes, I thought the same. The generation of default equals/hashCode/toString should be a feature which isn't bound to a specific supertype or immutable state. Better would be, for example, to control it by annotations. It also sucks that arrays aren't compared by value (but that is only in rare special cases a problem, usually we are using collections).
For me, component accessor for immutable state is pure dumb. It is not FP, it's crazy Frankenstein of OOP and FP
@@alexgorodecky1661 then you clearly have no understanding of the theoretical underpinnings of FP. Ever heard category theory?
Java is ancient in terms of features. All of this presentation is just copying the low hanging fruit of Scala which is a JVM language - 10 years later!
Talk about "last mover advantage"
33:12 lol, guy has never heard of multicatch from Java 7