I think most people use open source libraries within their project and that means that java as a language is evolving much quicker than the bulk of large projects can keep up with. For me I'm on Java 17 and it's unlikely to advance at anywhere near the required speed to keep up. It's the deprecation of functions in the newer versions which is the main road block for me.
For anybody stuck in Java versions < 21: part of your responsibility as a Softare Engineer is to advice decesion makers to move to newer Java versions; that will require you to know the benefits of newer versions and to learn to balance the functional requirements (new features/ bug fixing/security?) with non-functional requirements (performance, security?, memory consumption
@@diego.alcantara.rosario It's not that simple when your project depends on multiple 3rd party which in turn depend on different 3rd party libraries. Unless they all agree to migrate support for a newer version of java simultaneously then it's very difficult to. You don't have any leverage to make them all update. Also many libraries try to keep their code backwards compatible with java 8,11 and 17 being very common requirements these days. The only alternative would be to dump all 3rd party libraries and write everything yourself which is a dubious decision IMO.
I don't feel like deprecation is happening at difficult to manage pace, but I'm still on 17. Are there particular deprecations that are a problem for you?
@@patrickhart6371For me (open source developer) who has a project which easily references 80+ 3rd party libraries (a significant number of which are linked to JasperReports) the question is not so much which depreciation causes me an issue, but more importantly which depreciation causes issues for my dependencies. Realistically I cannot delve into the source for each of these dependencies to check what is or is not going to cause an issue. So if they say Java 17 supported then that’s what I stay with. It’s just a problem associated with large projects which include 3rd party libraries.
@@31redorange08 Correct! Let us know what you think of the draft JEP 468 though. We've been prioritising other things to be honest, but we hope to make a fresh push on this soon.
@@gavin6630Thanks for the update. I’m particularly interested in using this feature as a simpler alternative to the builder pattern - a config record with some default values that can be easily adapted through the `with` keyword in an immutable manner and sent to a method that consumes that config record cuts down on a lot of the verbosity that a separate temporary mutable class and explicit method wiring would normally have, especially when nested builders are involved.
After 8 years of being in Scala projects I started by my own SaaS with Java and actually I am impressed. I can have a similar developer experience now.
This is an amazing talk. Records look very promising. The only thing I am wondering is how well they will integrate the JSON into Java. Would it come close to how Node.js handles JSON?
The popular JSON libraries for Java handle Records fine. You can write Records to represent the structure of a JSON document quickly, and use a library to serialize and deserialize it.
@@edwardharman1153 I'm sorry I did not express myself properly. What I wanted to know is if I can create objects using a fluent API, like the builder pattern does; but using a record type and without libraries.
I just realized that so many JEPs are still in preview, in discussion or not even being worked on, that lots of Java devs will retire before Java becomes a bit more like Scala and Kotlin, or C# today.
Not sure that is true. If you look at the grid, you'll see we have finalized 8 features in 6 years. We are hoping a whole bunch of others will finalise shortly. We all want everything to move faster...
Fair point! In my defence I wrote the title many months before the talk. But, it makes for a better talk to ground the future stuff with some discussion of recent work...
Spoken like somebody who needs to evolve with the language. Streams and lambdas will almost always be far more readable than loops and anonymous or nested inner classes.
0:00 - Intro
3:54 - Records
9:14 - Sealed classes
11:22 - Pattern matching
20:00 - Data Oriented Programming
29:00 - Implicitly declared classes & instance main methods
33:20 - with Expressions
38:20 - Flexible constructor bodies
48:10 - What's next
50:53 - Conclusion
Mr. Bierman should consider doing ASMR recordings. He has very calming voice
Java is evolving and here i am still stuck in java 8
I think most people use open source libraries within their project and that means that java as a language is evolving much quicker than the bulk of large projects can keep up with. For me I'm on Java 17 and it's unlikely to advance at anywhere near the required speed to keep up. It's the deprecation of functions in the newer versions which is the main road block for me.
For anybody stuck in Java versions < 21: part of your responsibility as a Softare Engineer is to advice decesion makers to move to newer Java versions; that will require you to know the benefits of newer versions and to learn to balance the functional requirements (new features/ bug fixing/security?) with non-functional requirements (performance, security?, memory consumption
@@diego.alcantara.rosario It's not that simple when your project depends on multiple 3rd party which in turn depend on different 3rd party libraries. Unless they all agree to migrate support for a newer version of java simultaneously then it's very difficult to. You don't have any leverage to make them all update. Also many libraries try to keep their code backwards compatible with java 8,11 and 17 being very common requirements these days. The only alternative would be to dump all 3rd party libraries and write everything yourself which is a dubious decision IMO.
I don't feel like deprecation is happening at difficult to manage pace, but I'm still on 17. Are there particular deprecations that are a problem for you?
@@patrickhart6371For me (open source developer) who has a project which easily references 80+ 3rd party libraries (a significant number of which are linked to JasperReports) the question is not so much which depreciation causes me an issue, but more importantly which depreciation causes issues for my dependencies. Realistically I cannot delve into the source for each of these dependencies to check what is or is not going to cause an issue. So if they say Java 17 supported then that’s what I stay with. It’s just a problem associated with large projects which include 3rd party libraries.
Much love ❤❤
What’s the status of record with expressions? I’ve seen it mentioned many times before, but there’s still no preview or EA build of the JEP.
Gonna quote an amber dev that Dave some news on a reddit thread: "no chances for OpenJDK24)
The name's "JEP 468: Derived Record Creation" and according to their Jira, nothing has happened since April.
@@31redorange08 Correct! Let us know what you think of the draft JEP 468 though. We've been prioritising other things to be honest, but we hope to make a fresh push on this soon.
You could try the "record-builder" annotation processor to add "with" methods. I know it's not quite the same as language support though.
@@gavin6630Thanks for the update. I’m particularly interested in using this feature as a simpler alternative to the builder pattern - a config record with some default values that can be easily adapted through the `with` keyword in an immutable manner and sent to a method that consumes that config record cuts down on a lot of the verbosity that a separate temporary mutable class and explicit method wiring would normally have, especially when nested builders are involved.
Java is always my favorite language
Amazing language && features
After 8 years of being in Scala projects I started by my own SaaS with Java and actually I am impressed. I can have a similar developer experience now.
in which java version creation record with "with " expression will work ?
I really need with expression！！！
This is an amazing talk. Records look very promising. The only thing I am wondering is how well they will integrate the JSON into Java. Would it come close to how Node.js handles JSON?
The popular JSON libraries for Java handle Records fine. You can write Records to represent the structure of a JSON document quickly, and use a library to serialize and deserialize it.
Can I use the builder pattern with records ?
There's an annotation processor out there called "record-builder". It generates builders for you.
@edwardharman1153 Thanks, but I have Lombok already.
@@josealonso7321 I'm not sure why you asked the question then.
@@edwardharman1153 I'm sorry I did not express myself properly. What I wanted to know is if I can create objects using a fluent API, like the builder pattern does; but using a record type and without libraries.
@@josealonso7321 I see. There isn't any built-in support in the JDK. Just constructors.
The title of the video should have been "Java Language Features" not "Java Language Futures"
Scala had all of these features 15 years ago 😮
I just realized that so many JEPs are still in preview, in discussion or not even being worked on, that lots of Java devs will retire before Java becomes a bit more like Scala and Kotlin, or C# today.
Not sure that is true. If you look at the grid, you'll see we have finalized 8 features in 6 years. We are hoping a whole bunch of others will finalise shortly. We all want everything to move faster...
"Java Language Futures" spends first 20 minutes telling us about the past.
Fair point! In my defence I wrote the title many months before the talk. But, it makes for a better talk to ground the future stuff with some discussion of recent work...
@gavin6630 sorry, please take it for the plainly glib remark that it was, and not anything serious. It was an interesting talk regardless.
When it comes to readability - I steer clear of lambda expressions.
Spoken like somebody who needs to evolve with the language.
Streams and lambdas will almost always be far more readable than loops and anonymous or nested inner classes.
@ it’s not a matter of learning how or adopting new techniques for me. It’s more akin to preferring “how are you” to “wassup” - a personal preference.
Sometimes lambda expressions make code more readable, sometimes less. A blanket statement "don't use this" isn't very helpful.
Switched to Kotlin
Not me thinking this was about `java.util.concurrent.Future` and we're getting async/await.
🙂Sorry to disappoint...