Java Language Update - Early 2024 Edition
Вставка
- Опубліковано 17 лют 2024
- This session discusses recent advancements in the Java programming language, and looks at what’s coming next.
Presented by Viktor Klang (Oracle)
Recorded at Jfokus 2024 ➱ www.jfokus.se
More… ➱ inside.java/tag/amber
Paving the On Ramp ➱ openjdk.org/projects/amber/de...
Tags: #Java #OpenJDK #JDK #ProjectAmber - Наука та технологія
Never heard of Viktor before, but he's my hero because of the Gatherers API.
That being said Concise Method Bodies cannot come soon enough
Thank you for the kind words, Jan! Feedback on Gatherers is most welcome :)
Java is ruling from last 2 decade and it is gonna rule for next decade as well.
Java is pathetic. And True Believers are obnoxious.
Lol keep dreaming
So it will die after 10 years?! Good prediction, perhaps a little optimistic!
Glad, Java language developers woke up! 🔥
Java is a powerful and versatile language that has been evolving rapidly in recent years. I am amazed by the new features and improvements that have been introduced, such as records, pattern matching, sealed classes, and more. However, I also recognize that Java is not the only language that has these capabilities. Many other languages, such as Kotlin, Rust, Go, and JavaScript, have been using similar or even more advanced concepts for a long time. I appreciate and respect the work of the developers and communities behind these languages, and I draw inspiration from them. I believe that being humble and open-minded is a good quality for any programmer, as it allows us to learn from each other and create better software. I would like some kind of mention of those languages, some comparative analysis and trade-offs
on the JVM Scala is defacto the benchmark for FP style programming and type theory . We already
had ADTs and pattern matching 15 years ago 😅 It took everybody else to play catch.
@@TJ-hs1qm The only functional language on JVM is Clojure, Scala sits in between of FP and OOP.
While Scala can be the benchmark for something, it has never gained popularity to become the next big thing. I remember in ~2016-18 everyone was talking about Scala, but it never got beyond just talks about how Scala is great.
At last JDK team has experts in C, Python, groovy, Kotlin and Rust!
the pattern binding use flow-based scoping is interesting
the first time I know it works when I inverted the if statement using Intellij,
guess what? the Intellij once again is so amazing
For the AsyncResult, might we no longer have access to the cause or any suppressed exceptions from the InterruptedException?
Tomorrow sometime you will have Java without mandatory class! Write functionally .Javac 'preprocessor(!)' will add boiler plate class wrapper! Python does it with ubiquitous 'main' module already. Like CPython behind Python, Cjava will be there, for 'fully' functional Java !
Highly informative video on programming language. Great for beginners!🤠
At last JDK team has experts in C, Python and Rust!
35:33 I like it all, except that the first "&&" in a *composite* switch *condition* got renamed to "when".
if, case, when... Will there be a "once" condition in the future?
It's too much.
We're used to see "case" in switch statements out of tradition, but what if we simplify conditions and become more approachable and clear overall:
String text = switch (value) {
if 1 -> "one";
if 2 -> "two";
if 3 -> "three";
if 4 -> "four";
}
See how clean it is? Lets try pattern matching with guards:
switch (value) {
if ValueClass v && v.range > 1 -> doSomething(v);
if NonValueClass v -> {
v.doSomethingElse();
v.doThisAfterwards();
}
}
THIS feels good.
To think even further ahead, if we're already on the topic of redefining switch - Why not leave out the "case" entirely:
String text = switch (value) {
1 -> "one";
2 -> "two";
3 -> "three";
4 -> "four";
}
switch (value) {
ValueClass v && v.range > 1 -> doSomething(v);
NonValueClass v -> {
v.doSomethingElse();
v.doThisAfterwards();
}
}
Or even shorter, if you dare to allow pattern instantiation and access in one:
switch (value) {
ValueClass v.range > 1 -> doSomething(v);
NonValueClass v -> {
v.doSomethingElse();
v.doThisAfterwards();
}
}
Which would allow neat things like this in a way more readable form:
String text = switch (value) {
Integer i "one or less";
2 -> "two";
3 -> "three";
Integer i >= 4 -> "four or more";
}
Compared to how you'd currently have to write it:
String text = switch (value) {
case Integer i when i "one or less";
case 2 -> "two";
case 3 -> "three";
case Integer i when i >= 4 -> "four or more";
}
When does proper null safety come? It’s also clunky to model pure data without “free” functions (outside classes).
In regards to manual garbage collection / free: Yes, that could be a useful functionality to have.
In regards to null safety: You can *always* do Optional.of(nullable).orElse("") or use primitive data types to never face a null value.
Additionally you can make a variable final to enforce that a value gets set.
Good grief, just make a static class of functions.
@@donwinstonYes, that is the alternative. It essentially makes the class act as a package with functions. This would look much better and more intuitive with free functions and records inside a package.
@@TheBigLou13Using Optional in a data structure is bad and should be avoided. Some times null simply can’t be avoided. In these cases compiler support for null safety would be nice.
@@TheBigLou13 Optional is not a fully featured Option monad, and it desperately lacks the benefits of being modeled as an ADT. Moreover, it's not supposed to be used to store data, but as a return value to indicate possible absence - for implementers, the hassle of dealing with null is still pretty much real. A null aware type system is very desperately needed, specially for a language that picked nullability as a default.
Yo first commetn, tired of waiting for valhalla, lilliput.
User
I was not convinced. Not very excited about the future.
The presentation was well-crafted until the pseudo-code slide at 44:36.
how about foundation classes for jvm and not the things the programmers can do with java, let the users do the java libraries, mostly, focus on the language platform. I mean hardware/os interface is the major part of java, not the user libraries. dont fall in the c++ std library rabbit hole. tools not the product, as you dont know what the end product will be. a library in wrong place does not help. its clutter.
one more: every non-array object should be considered as size one array for simple usability and syntax interop. I mean there should not be a single variable entities but only arrays, from zero to one to any size. or even if there is things like "int x=0;" then that x should be considered as "int[] x={0};" in all cases. in computer memory there is no such a thing as single variable, but a range of variable addresses which is always a memory range, array. sometimes more complex looking thing is more simple engineers keeping it simple.
why do you need "new" keyword, you would just do MyClass myclass = MyClass(), or int[] intarray = int[5];
both java and javafx (if using java window refresh system) seem to have jittery frame pacing that the translating camera rendering image flow becomes not very nice to look at.
why does a thread running completely separately from its starter and data induce hickups on a totally separate function in the same application. emphasis on the thread independency in all manners. there is no shared data being used, including window, other than same application main context. say the other thread is calculating some maths without direct contact to the other functionality, and still the thread affects when it should not. all swing related operations including main window dragging around will be lagged by same 0.5sec stutter.
java .jar files need module-path (not only class-path)
So old Java is a poor language. Tomorrow this will be poor! Arrogant Old java bows, without honestly acknowledging, to Python, Groovy and venerable C (function pointer of C is method pointer of Java!!). Learn Python for all , Rust for System Work. Kotlin for android.
keep up the hard work