It's funny that with all the catching up to Kotlin they've done and plan to do (e.g. "paving the On Ramp"), Brian never mentions it aloud 😅 Good to see that going back to Java after writing mostly Kotlin since 2018 wouldn't be that much of a pain. What I'd miss most right now are nullable types and the more compact and powerful stdlib, especially for collections. But also the copy for data classes, which has no alternative with Java records yet, but gets mentioned by Brian as a WIP. I've seen some negativity about the STR template syntax, but my first impression is that introducing a generic TemplateProcessor interface is actually pretty neat. Finally, it was a joy to listen to Brian again. I think the last time I had the pleasure was at Devoxx 2019...
Fascinating! Some amazing features on the way. Great talk! I really like the "with" pattern for records being able to provide deconstruction and then construction without having to code it. I achieve the same thing (sort) of with builders and a change method ..... change(UnaryOperator func);
About the last question of the backward compatibility of Java and the renaming of the Swing packages: As far as I can remember Swing was an external library first with Java 1.1. It's when it was added to JDK 1.2 that the packages were renamed to javax.swing... So it's not like if it was already in the JDK and then renamed.
The chief complaint against Java is its verbosity (I like Java, mostly). Can be solved by making Lombok-like functionality (Records are great but not as widely usable as Lombok's code generation) a part of the compiler & allowing default values for method parameters. What are the arguments against these two?
Wow, that templating feature is ugly, non-orthogonal, and non-extensible. Could nobody come up with a better solution? For example, how about introducing something like Scala's apply methods: an object reference can be invoked in function syntax eg "formatter(args...)" which invokes formatter.apply(args). That seems a much more generally useful feature which can then be used to provide STR("""....""") for string templates.
It's so good to have Brian Goetz as one of the Leaders of java
It's funny that with all the catching up to Kotlin they've done and plan to do (e.g. "paving the On Ramp"), Brian never mentions it aloud 😅 Good to see that going back to Java after writing mostly Kotlin since 2018 wouldn't be that much of a pain. What I'd miss most right now are nullable types and the more compact and powerful stdlib, especially for collections. But also the copy for data classes, which has no alternative with Java records yet, but gets mentioned by Brian as a WIP.
I've seen some negativity about the STR template syntax, but my first impression is that introducing a generic TemplateProcessor interface is actually pretty neat.
Finally, it was a joy to listen to Brian again. I think the last time I had the pleasure was at Devoxx 2019...
Fascinating! Some amazing features on the way. Great talk! I really like the "with" pattern for records being able to provide deconstruction and then construction without having to code it. I achieve the same thing (sort) of with builders and a change method ..... change(UnaryOperator func);
Java is closer to Scala :D. ... Good Job.
Please continue removing the overbossity
About the last question of the backward compatibility of Java and the renaming of the Swing packages: As far as I can remember Swing was an external library first with Java 1.1. It's when it was added to JDK 1.2 that the packages were renamed to javax.swing... So it's not like if it was already in the JDK and then renamed.
First complete Valhalla
Are records the equivalent to case classes in Scala (aka type constructors)?
Nobody care about Valhalla?
Bring back JAOTC!
yippie!
Java is becoming more like Haskell. I like it!😎
My thoughts exactly!
No one touches scala with a 10 foot pole and you’re dreaming of Haskell?😅
The chief complaint against Java is its verbosity (I like Java, mostly). Can be solved by making Lombok-like functionality (Records are great but not as widely usable as Lombok's code generation) a part of the compiler & allowing default values for method parameters. What are the arguments against these two?
Wow, that templating feature is ugly, non-orthogonal, and non-extensible. Could nobody come up with a better solution?
For example, how about introducing something like Scala's apply methods: an object reference can be invoked in function syntax eg "formatter(args...)" which invokes formatter.apply(args). That seems a much more generally useful feature which can then be used to provide STR("""....""") for string templates.
I don't like where is going.
I don't understand Record.
We have POJO.