I hope one day Brian finds the time to write an advanced book about modern Java and all of its quirks and features. He is like a walking talking encyclopedia.
@@encapsulatio there are a few missing bits for sure, but the third edition is still very much relevant, even if the most recent features aren't covered. That's Joshua's Bloch tweet from last year about the fourth edition: "haven't started writing the fourth edition yet. I believe there haven't been enough substantive changes to the language to warrant it. Maybe in a couple of years..." Also data oriented programming is just a new fancy name for a combination of object and functional technics (although Brian Goetz wouldn't agree on that one). You can learn a lot by studying Haskel, Ocaml or maybe even Scala if you already have some OOP background
This guy is the best thing that happened to Java. He's been making spot on design decisions for decades now. My only complaint these days is that each version of Java does not ship with an up to date Language Server Protocol implementation. Yes Intellij is great but its just too big when you want to work on small projects (or a lot of very large projects), I want a decent development experience in a bog standard text editor.
That's exactly what the Java Platform Extension for VS Code is addressing. Not only, it'll support the latest and greatest Java version, it'll also support the next version while it's in Early-Access. See inside.java/2023/10/18/announcing-vscode-extension/ for more info.
@@delabassee sadly that just seems just to be netbeans packaged as a vscode plugin (and btw, it's already possible to attach for example a standalone vim session to something like eclipse that way) - but its not "large IDE + lightweight editor" i want, its "lightweight editor + lightweight LSP", and furthermore, i don't want to use vscode either.
@@johangamb So "Intellij is great but its just too big" but you want a "large IDE + lightweight editor" ? TBH I'm a bit confused 🤔 Also, you're saying that is already possible with vim/Eclipse. But Eclipse in this particular case is problematic as it uses JDT, and JDT is always behind when it comes to supporting new Java lang features, especially in EA phases. And to clarify, it's not "netbeans packaged as a vscode plugin", it is the NB LSP Server and a forked client side UI. 😉
@@delabassee think you missed the "not" in my sentence: "but its not "large IDE + lightweight editor" i want, its "lightweight editor + lightweight LSP""
Nice to hear about the 'with syntax' as the main gripe with records is the requiremenet to specify all values in a sequenced list, meaning it's hard to add attributes with default values.
Goetz is amazing, and Java is getting AWESOME. If Goetz is looking for a job try diplomat. I was expecting a question on pointers, civilized pointers, and Goetz would have said, "it’s a perfectly valid concern ans we have been thinking about it".
So many of Brian's comments (eliminating boilerplate, shorter println, etc) are geared towards making java 'easier to newcomers'. I'd love to see Brian give a talk at a future "Computer Science Teachers Association" conference and see awareness of these improvements trickle into the curriculum and eventually the AP exam.
Records in Java provide a compact syntax for declaring classes which are transparent holders for shallowly immutable data. However, they do not support a private constructor or a builder pattern out of the box. To maintain compatibility and avoid telescopic constructors, it's advisable to use a class with a private constructor and a builder pattern. This approach allows for the addition of new fields without breaking existing code, as the builder can provide default values for any fields that are not explicitly set.
7:12 Lombok is an organ, record is a harpsichord. You play the same chord twice, they will have the same volume/timbre/hashcode. My metaphor is leaking…
Brian's recommendation for what we should do about java beans is that records _might_ have withers someday. Records were released 5 JDKs ago... where are the withers? Records are being sold as this big improvement because it has a lot of useful "semantics", but then the JDK team has barely implemented what we might really want with them. Pattern matching is nice and all but it's not even approaching the core problems of data modeling in java. I think Brian is correct that few of us would desire beans and mutability with the right structures, but that's IF we have the syntax sugar to support common operations. Which to be clear, records are very incomplete, so there is no coherent recommendation for what we should be doing! It's hopeful that java is changing as fast as it is but also pretty depressing that even when they start picking some directions everything still somehow remains 5 years away.
People (myself included) use records a lot and mostly productively and joyfully, so "barely implemented what we might really want with them" is quite an exaggeration. If you can't use records without withers, you can auto-generate them just like you auto-generates getters and setters (which people have been using for decades without language support). But, yeah, a with expression would definitely be a big step forward for Java, it's just that completing the pattern matching story was more important. But I can't wait to get it either and I really hope we'll see something on that front in 2024.
I think one of the weak points of java currently for attracting new people, and this is coming from experience looking at students around me in university, is the build systems. Maven is very confusing, and Gradle is even worse when you just wanna start getting stuff done. Compare that to something like Rust's Cargo system where you can just install dependencies like npm and run your code with a default configuration, and it makes Rust seem like a much more attractive language than java. This is important because the build system is the very first interaction you have with getting your code up and running, which is the first "milestone" someone that might start a projects sets themselves up to do.
Tbf, the literal first thing a student should see is a bog standard, Gradle-less project. But I agree it’d be nice if Gradle were simpler - the issue is, build systems are inherently complex!
Honestly. I wish records would allow for a private consturctor so you could implement deduplication caches.... Also valhalla at this point has to come in a reasonable timeframe besause they started locking features behind it... And these features are a lot more interesting then valhalla... Either release the features or finish valhalla... I think it was loomen. And that is really interesting for game dev too...
He gets to work in a way that most of us don't: he can spend hundreds of hours over several years finding the right design. That's awesome, but to be honest, it's not for me, so I'm glad he gets to do it. I just like to build stuff people find useful.
if you dont care about performance yes purge mutability... but if you do care about performance that's a stupid stupid idea, i have no idea why people keep pushing this. Everything we have designed in the hardware layer is meant to reuse memory, to achieve higher performance, not throw away and create new memory every damn time. If you can reuse your objects like String that's perfect, but creating new object just because you need to mutate one field is stuipd. I have great respect for Brian, but his advise is for new or mid devs doing boring web applications that have no substance to them. Instead master how to do efficient parallelism, how to use mutable state to reuse memory that you may already have in your cpu cache...
Working with Kotlin is more productive. The language is more expressive and concise. Java still lacks named parameters, whereas Kotlin has a null-safe operator. Despite the introduction of pattern matching and records in Java after so many years, it still falls short. String templates are less convenient to use in Java. When I worked at Allegro, one of the largest e-commerce companies in Europe, where we had over 2000 microservices, most of them were written in Kotlin. The speed of delivering new functionalities is crucial. Sorry, but Java still lags behind.
That's gotta be BS. Yeah, Google says so, I know. Probably some AI-sourced BS. However, one of the conferences (uberconf) describes him as "a professional software developer for 20 years". Very much doubt he started at the age of 53.
@@JoeMwangi Working with Kotlin is more productive. The language is more expressive and concise. Java still lacks named parameters, whereas Kotlin has a null-safe operator. Despite the introduction of pattern matching and records in Java after so many years, it still falls short. String templates are less convenient to use in Java. When I worked at Allegro, one of the largest e-commerce companies in Europe, where we had over 2000 microservices, most of them were written in Kotlin. The speed of delivering new functionalities is crucial. Sorry, but Java still lags behind.
@@cya3mdirl158 strange, you jumped straight to Kotlin benefits, yet I just pointed out your absurd claim that using list as record properties is a bad idea, yet, that's not the case. I was just pointing out that that's a skill issue. Anyway, rushing String Templates without resolving some issues such as security is something they are tackling, furthermore, they found out a better way of approaching it hence a design overhaul will be done. Kotlin String Templates did have injection vulnerability if I recall in past discussions in Kotlin forums.
@@JoeMwangi I know this but you see I always have to remember to override these methods when using records. Two I also look at from the point of convenience of using the language. I know the pains of string templates but we don't use them like in these examples from JEP. Because I think only a lousy programmer does that. Java architects have forgotten that Java is less pleasant to use and don't want to change anything here for the better
@@cya3mdirl158 looool. No programming language has a magical solution for the list field problem you're pointing out, even Scala. To be honest, java is more simpler and explicit for mutable list in records problem, either through the constructor or method overrides. As I said, it's a skill issue rather than convenience as you're trying to push. Also, didn't I say they are redesigning the string templates based user feedback (specifically from large projects library users), and discovering better approaches. Java Architects seem to be open to opinions and understanding the problems to allow better features. But here you are with absurd complaints.
It would have been better if they had asked him more pointed questions. 1) How do you plan to outcompete Kotlin on the server-side part? Java has already lost Android development. 2) When will you finally add null safety like in Kotlin? 3) How do they feel about Java losing ground and more new projects starting with Kotlin? Java is no longer needed by anyone in 2023; while they were picking their noses, the work was already done for them. And now they are trying to do everything possible not to fall behind other languages. It's very funny to watch how they release various improvements that were needed 10 years ago. I still don't understand why Java is needed when there is Kotlin new and modern Java.
1. Java didn't lose Android development because of Kotlin, but because of Oracle vs. Google thing; the server-side is still all on Java and I believe if it's losing, it's not because of Kotlin, but for other kinds of programming languages and paradigms; 2. wait for Valhalla to complete; 3. this is a provocative and personal question where you already imagined his possible reaction, don't you? ;) Java is needed because it runs most of your web services around the globe, reimplantation is not an option here, so it is obviously reasonable to keep it improved 😊 If you don't want to use it for your next pet project, don't use it :)
Given that this were audience questions that I solicited on UA-cam, Reddit, and Twitter, I think what you're trying to say is "It would have been better if I were subscribed to Java socials, so I could ask more pointed questions". 😉 But I can take a shot at your questions. 1 & 3) My understanding from talking to OpenJDK members is that they're less concerned with growing Java's piece of the JVM pie (which is what most other languages focus on by pitting themselves as "the better Java") but by growing the JVM pie itself - a rising tide lifts all boats. Also, people asked the same questions about Groovy and Scala a decade ago and Java is still here. 2) Probably never because there's no good migration path from where Java (and the billions of lines written in it) are now to that place. And trust me, I'd love to get there, too.
I would love to see the record-like definition for enums, and I think it actually makes sense. public enum MyEnum(String val) { ONE("Hello"), TWO("World"); }
Removing System,out.println from the JDK is out of the question - that would break too much code. But once the simpler alternative arrives, you can remove it from your code. And getters/setters don't exist in the language. That's a construct we developers created and constantly abuse. You can greatly reduce its presence in your code base today by redesigning it, so non-record classes that expose all their fields become rare.
@@nipafxyeah removing it would cause chaos but doing something like kotlin/groovy where println is a top level function would be great. Regarding getters and setters having a property based approach keeps the syntax nice and terse.
@@31redorange08 That's true for professional Java development but don't underestimate the importance of having a good learning or hobby-level experience.
Hi Nicolai (@nipafx), I've got a really good idea. I think you should change your name to Nicolai LTS then you don't have wink at us whenever LTS comes in discussion 😉
I hope one day Brian finds the time to write an advanced book about modern Java and all of its quirks and features. He is like a walking talking encyclopedia.
Honestly he does not even have to do it himself but supervise experts on different aspects of Java and make out of it a book.
yes!
Just read Effective Java 🙂
@@matdryz It's super outdated. Java 21 has too many new productivity features and data oriented features that do not exist in that book.
@@encapsulatio there are a few missing bits for sure, but the third edition is still very much relevant, even if the most recent features aren't covered.
That's Joshua's Bloch tweet from last year about the fourth edition:
"haven't started writing the fourth edition yet. I believe there haven't been enough substantive changes to the language to warrant it. Maybe in a couple of years..."
Also data oriented programming is just a new fancy name for a combination of object and functional technics (although Brian Goetz wouldn't agree on that one). You can learn a lot by studying Haskel, Ocaml or maybe even Scala if you already have some OOP background
This guy is the best thing that happened to Java. He's been making spot on design decisions for decades now. My only complaint these days is that each version of Java does not ship with an up to date Language Server Protocol implementation. Yes Intellij is great but its just too big when you want to work on small projects (or a lot of very large projects), I want a decent development experience in a bog standard text editor.
That's exactly what the Java Platform Extension for VS Code is addressing. Not only, it'll support the latest and greatest Java version, it'll also support the next version while it's in Early-Access. See inside.java/2023/10/18/announcing-vscode-extension/ for more info.
@@delabassee sadly that just seems just to be netbeans packaged as a vscode plugin (and btw, it's already possible to attach for example a standalone vim session to something like eclipse that way) - but its not "large IDE + lightweight editor" i want, its "lightweight editor + lightweight LSP", and furthermore, i don't want to use vscode either.
@@johangamb So "Intellij is great but its just too big" but you want a "large IDE + lightweight editor" ? TBH I'm a bit confused 🤔
Also, you're saying that is already possible with vim/Eclipse. But Eclipse in this particular case is problematic as it uses JDT, and JDT is always behind when it comes to supporting new Java lang features, especially in EA phases.
And to clarify, it's not "netbeans packaged as a vscode plugin", it is the NB LSP Server and a forked client side UI. 😉
@@delabassee think you missed the "not" in my sentence:
"but its not "large IDE + lightweight editor" i want, its "lightweight editor + lightweight LSP""
totally agree. and a great communicator as well
Glad to see Java still keeps its own charm while it is still improving.
Nice to hear about the 'with syntax' as the main gripe with records is the requiremenet to specify all values in a sequenced list, meaning it's hard to add attributes with default values.
I'd like more "with" to be some kind of an operator, bu hey, it's Java. :)
Helpful statement about preview features being fully usable.
Awesome video! Please make this an annual event (if possible).
Thanks! :) We did it last year, too, but back then we researched the answers ourselves: ua-cam.com/video/ZaGnGs9TeNc/v-deo.html
Nice! Looking forward to part 2!
Goetz is amazing, and Java is getting AWESOME.
If Goetz is looking for a job try diplomat.
I was expecting a question on pointers, civilized pointers, and Goetz would have said, "it’s a perfectly valid concern ans we have been thinking about it".
So many of Brian's comments (eliminating boilerplate, shorter println, etc) are geared towards making java 'easier to newcomers'. I'd love to see Brian give a talk at a future "Computer Science Teachers Association" conference and see awareness of these improvements trickle into the curriculum and eventually the AP exam.
story of emperor death as reason to change a spec is epic :) !
I would watch an hour of java interviews
Can someone explain the issue at 13:30? Is the problem with making a constructor break despite not changing its signature?
24:40 I'll use the Valhalla Preview in production. Brian Goetz said it's ok.
Brian is literally the reason I know so much about the JVM itself. I'm not a systems architect but I did stay at a holiday inn last night. 😂
Very interesting, please more of that! But on the other hand not too much, cause we don't want to keep Brian away from his awesome work 🙂
Great video, more of this please
Records in Java provide a compact syntax for declaring classes which are transparent holders for shallowly immutable data. However, they do not support a private constructor or a builder pattern out of the box. To maintain compatibility and avoid telescopic constructors, it's advisable to use a class with a private constructor and a builder pattern. This approach allows for the addition of new fields without breaking existing code, as the builder can provide default values for any fields that are not explicitly set.
7:12 Lombok is an organ, record is a harpsichord. You play the same chord twice, they will have the same volume/timbre/hashcode. My metaphor is leaking…
Brian's recommendation for what we should do about java beans is that records _might_ have withers someday. Records were released 5 JDKs ago... where are the withers? Records are being sold as this big improvement because it has a lot of useful "semantics", but then the JDK team has barely implemented what we might really want with them. Pattern matching is nice and all but it's not even approaching the core problems of data modeling in java. I think Brian is correct that few of us would desire beans and mutability with the right structures, but that's IF we have the syntax sugar to support common operations. Which to be clear, records are very incomplete, so there is no coherent recommendation for what we should be doing! It's hopeful that java is changing as fast as it is but also pretty depressing that even when they start picking some directions everything still somehow remains 5 years away.
People (myself included) use records a lot and mostly productively and joyfully, so "barely implemented what we might really want with them" is quite an exaggeration. If you can't use records without withers, you can auto-generate them just like you auto-generates getters and setters (which people have been using for decades without language support).
But, yeah, a with expression would definitely be a big step forward for Java, it's just that completing the pattern matching story was more important. But I can't wait to get it either and I really hope we'll see something on that front in 2024.
great video and an awesome talk, thank you infinitely ☺️
So we need a dead Japanese emperor to drastically change Java specifications, right?
with data classes, before records I didn't even bother with getters or setters, just made everything public final.
yes, at last someone said that 😆
I think one of the weak points of java currently for attracting new people, and this is coming from experience looking at students around me in university, is the build systems. Maven is very confusing, and Gradle is even worse when you just wanna start getting stuff done. Compare that to something like Rust's Cargo system where you can just install dependencies like npm and run your code with a default configuration, and it makes Rust seem like a much more attractive language than java. This is important because the build system is the very first interaction you have with getting your code up and running, which is the first "milestone" someone that might start a projects sets themselves up to do.
Tbf, the literal first thing a student should see is a bog standard, Gradle-less project. But I agree it’d be nice if Gradle were simpler - the issue is, build systems are inherently complex!
where is this
This was recorded at Devoxx Belgium in Kinepolis/Antwerp.
Honestly. I wish records would allow for a private consturctor so you could implement deduplication caches....
Also valhalla at this point has to come in a reasonable timeframe besause they started locking features behind it... And these features are a lot more interesting then valhalla...
Either release the features or finish valhalla...
I think it was loomen. And that is really interesting for game dev too...
Listening to Brian makes me feel quite dumb😂
That makes two of us. :D
Me too, but also comfortable that Java is in good hands.
He gets to work in a way that most of us don't: he can spend hundreds of hours over several years finding the right design. That's awesome, but to be honest, it's not for me, so I'm glad he gets to do it.
I just like to build stuff people find useful.
On the other hand listening to @nipafx makes you feel …..? 😏
Same
Java for games - yes!, mutable fields for records - never. Very practical.
if you dont care about performance yes purge mutability... but if you do care about performance that's a stupid stupid idea, i have no idea why people keep pushing this. Everything we have designed in the hardware layer is meant to reuse memory, to achieve higher performance, not throw away and create new memory every damn time. If you can reuse your objects like String that's perfect, but creating new object just because you need to mutate one field is stuipd.
I have great respect for Brian, but his advise is for new or mid devs doing boring web applications that have no substance to them. Instead master how to do efficient parallelism, how to use mutable state to reuse memory that you may already have in your cpu cache...
Wow baiting us with Valhalla news 😢
Working with Kotlin is more productive. The language is more expressive and concise. Java still lacks named parameters, whereas Kotlin has a null-safe operator. Despite the introduction of pattern matching and records in Java after so many years, it still falls short. String templates are less convenient to use in Java.
When I worked at Allegro, one of the largest e-commerce companies in Europe, where we had over 2000 microservices, most of them were written in Kotlin. The speed of delivering new functionalities is crucial. Sorry, but Java still lags behind.
Woah just learned Brian is 73 years old. No way...
Wow, I wouldn't give him more than 50-55 years old
I agree, no way. I asked and it's off by ~15 years. (This info is coming from Google's About sidebar, right? )
That's gotta be BS. Yeah, Google says so, I know. Probably some AI-sourced BS. However, one of the conferences (uberconf) describes him as "a professional software developer for 20 years". Very much doubt he started at the age of 53.
Hello
basically everyone is asking why java is not kotlin :D
just use kotlin, stop asking for them to play catch
Why are these silly creatures always trying to fix someone else's work. Why can't they create their own work? 😇
Records are not immutable. Try to use list as of property…
Sting template looks terrible.
Fortunately we have a Kotlin.
Haha. That's a dumb comment. You can override a java record method to make it return a copy of the list. Now the original list won't change.
@@JoeMwangi Working with Kotlin is more productive. The language is more expressive and concise. Java still lacks named parameters, whereas Kotlin has a null-safe operator. Despite the introduction of pattern matching and records in Java after so many years, it still falls short. String templates are less convenient to use in Java.
When I worked at Allegro, one of the largest e-commerce companies in Europe, where we had over 2000 microservices, most of them were written in Kotlin. The speed of delivering new functionalities is crucial. Sorry, but Java still lags behind.
@@cya3mdirl158 strange, you jumped straight to Kotlin benefits, yet I just pointed out your absurd claim that using list as record properties is a bad idea, yet, that's not the case. I was just pointing out that that's a skill issue. Anyway, rushing String Templates without resolving some issues such as security is something they are tackling, furthermore, they found out a better way of approaching it hence a design overhaul will be done. Kotlin String Templates did have injection vulnerability if I recall in past discussions in Kotlin forums.
@@JoeMwangi I know this but you see I always have to remember to override these methods when using records. Two I also look at from the point of convenience of using the language. I know the pains of string templates but we don't use them like in these examples from JEP. Because I think only a lousy programmer does that.
Java architects have forgotten that Java is less pleasant to use and don't want to change anything here for the better
@@cya3mdirl158 looool. No programming language has a magical solution for the list field problem you're pointing out, even Scala. To be honest, java is more simpler and explicit for mutable list in records problem, either through the constructor or method overrides. As I said, it's a skill issue rather than convenience as you're trying to push. Also, didn't I say they are redesigning the string templates based user feedback (specifically from large projects library users), and discovering better approaches. Java Architects seem to be open to opinions and understanding the problems to allow better features. But here you are with absurd complaints.
The biggest problem for Java is unfortunately Eclipse.
How so?
Just wait until this guy hears about IntelliJ
It would have been better if they had asked him more pointed questions.
1) How do you plan to outcompete Kotlin on the server-side part? Java has already lost Android development.
2) When will you finally add null safety like in Kotlin?
3) How do they feel about Java losing ground and more new projects starting with Kotlin?
Java is no longer needed by anyone in 2023; while they were picking their noses, the work was already done for them. And now they are trying to do everything possible not to fall behind other languages. It's very funny to watch how they release various improvements that were needed 10 years ago.
I still don't understand why Java is needed when there is Kotlin new and modern Java.
1. Java didn't lose Android development because of Kotlin, but because of Oracle vs. Google thing; the server-side is still all on Java and I believe if it's losing, it's not because of Kotlin, but for other kinds of programming languages and paradigms;
2. wait for Valhalla to complete;
3. this is a provocative and personal question where you already imagined his possible reaction, don't you? ;)
Java is needed because it runs most of your web services around the globe, reimplantation is not an option here, so it is obviously reasonable to keep it improved 😊
If you don't want to use it for your next pet project, don't use it :)
Given that this were audience questions that I solicited on UA-cam, Reddit, and Twitter, I think what you're trying to say is "It would have been better if I were subscribed to Java socials, so I could ask more pointed questions". 😉 But I can take a shot at your questions.
1 & 3) My understanding from talking to OpenJDK members is that they're less concerned with growing Java's piece of the JVM pie (which is what most other languages focus on by pitting themselves as "the better Java") but by growing the JVM pie itself - a rising tide lifts all boats. Also, people asked the same questions about Groovy and Scala a decade ago and Java is still here.
2) Probably never because there's no good migration path from where Java (and the billions of lines written in it) are now to that place. And trust me, I'd love to get there, too.
I would love to see the record-like definition for enums, and I think it actually makes sense.
public enum MyEnum(String val) {
ONE("Hello"),
TWO("World");
}
Oh god no...
That sounds like a terrible idea.
What about derived types or cached values inside a enum.
These would no longer be possible.
Please get rid or replace system.out.println and getter/setters as they pollute the code so much.
Removing System,out.println from the JDK is out of the question - that would break too much code. But once the simpler alternative arrives, you can remove it from your code. And getters/setters don't exist in the language. That's a construct we developers created and constantly abuse. You can greatly reduce its presence in your code base today by redesigning it, so non-record classes that expose all their fields become rare.
@@nipafxyeah removing it would cause chaos but doing something like kotlin/groovy where println is a top level function would be great. Regarding getters and setters having a property based approach keeps the syntax nice and terse.
Writing to System.out is rarely needed anyway.
@@31redorange08 That's true for professional Java development but don't underestimate the importance of having a good learning or hobby-level experience.
@@nipafx Yeah, that's why all the major IDEs have templates for this specific call.
16:30 Two guys talking about something with passion and not even noticing two girls that went behind them. This is what separate the men from the boys
Hi Nicolai (@nipafx), I've got a really good idea. I think you should change your name to Nicolai LTS then you don't have wink at us whenever LTS comes in discussion 😉