Java's Plans for 2024 - Inside Java Newscast #61
Вставка
- Опубліковано 1 чер 2024
- In 2024, Java keeps evolving. Let's see what the OpenJDK projects Amber, Babylon, Leyden, Lilliput, Loom, Panama, and Valhalla plan for this year and how that will push Java forward. Whether pattern matching or other language improvements, interaction with foreign code, memory, or platforms, memory locality or efficiency, or startup time, there are plenty of regions where Java will improve in 2024. Keep in mind, though, that most of the work in any given year will not be released in the same year and so many of these improvements will only be usable in 2025 or later.
~~~ Chapters ~~~
0:00 Intro
1:16 Project Babylon
Project Babylon openjdk.org/projects/babylon/
JVMLS talk: • Code Reflection #JVMLS
IJN episode: • Java On The GPU - Insi...
Pushed prototype: mail.openjdk.org/pipermail/ba...
Prototype details: mail.openjdk.org/pipermail/ba...
2:14 Project Loom
3:05 Project Leyden
Project Leyden: openjdk.org/projects/leyden/
JVMLS talk: • Project Leyden - Captu...
IJN episode: • The Holy Grail of Java...
"Toward Condensers": openjdk.org/projects/leyden/n...
"Condensing Indy Bootstraps": openjdk.org/projects/leyden/n...
4:17 Project Amber
Project Amber: openjdk.org/projects/amber/
JEP 455 - primitive patterns: openjdk.org/jeps/455
"Pattern Matching in the Java Object Model": openjdk.org/projects/amber/de...
"Uniform handling of failure in switch": inside.java/2023/12/15/switch...
7:32 Project Valhalla
Project Valhalla: openjdk.org/projects/valhalla/
JEP 401 - value types: openjdk.org/jeps/401
Nullness markers: bugs.openjdk.org/browse/JDK-8...
Conversation about nullness markers: • How Project Valhalla A...
9:02 Project Panama
Project Panama: openjdk.org/projects/panama/
jextract: github.com/openjdk/jextract
9:51 Project Lilliput
Project Lilliput: openjdk.org/projects/lilliput/
JVMLS talk: • Project Lilliput - Com...
IJN episode: • Save 10-20% Memory Wit...
10:37 Outro
Tags: #Java #OpenJDK - Наука та технологія
Little error, FFM API was finalized in JDK 22, not 21
Oh right. 🤦♂ Good catch, let's get this comment pinned.
the new format is great and the content of this newscast was great. We want more :-) !
I am falling in love more with this channel. You are motivating my Java Journey. Thanks.
It really is the perfect intersection of informative, dry, and humorous.
Thanks guys! 😍
Broadcasting from Odeonsplatz, love it! Munich is just beautiful!
Exciting times ahead! Thanks for the promising outlook 🤓
My pleasure! 😊
Thanks for the update!
Such great content!
Hello, Thanks for the great video and I have subscribed to stay up to date :) Wanted to know any plans of implementing something like Isolates in GraalVM in OpenJDK, now that SecurityManager is deprecated with JEP-411?
I am still willing to bet Valhalla will drop 2026-2028 at the earliest xD
Ignoring my personal griefs.
A lot of this looks really promising :)
Especially with the withs API coming :3
I'm with you, man. Setters are an antipattern.
✊
New format is great!
Munich?
Indeed. 💯
❤
Contrary to the predictions of previous years, this time it was very conservative
Maybe I'm learning? 😅
MUC it is.
The Java language stewards
should get a Turing Award
for computer language stewardship.
6:11 The "with" keyword in project Amber looks beneficial! Even though its quite jarring in java to see a keyword coming after a variable name...
---
*Since the word "when" implies time* I would like to see it be used functionally similiarly e.g. for aligning the order of virtual threads or for predictive branching rather than having it being an alias for "&&" in switch.
"when" in general is a reference to a condition, which could mean time or could mean other things
Any support for ML?
Literally everything listed will benefit ML 🙄
Babylon will be very useful for it
Nice jacket bro? Where did you get it?
Thanks, I love that thing. Bought it at a festival nigh a decade ago and wear it almost exclusively. The brand is called Buddhaful and I just looked it up: they still have the jacket! It's called "Lancelot Jacket" (was much cheaper when I bought it, though).
I'm still looking jaotc to make a comeback everyone loves a comeback story right?
valuetypes should have been done 5 years ago at 17.
Withers look super interesting...
Watch out lombok, in several more years i'm replacing you!
I never use(d) Lombok. For me, it's an anti-pattern lib.
@@andreaschrist4093 despite years of fearmongering, i've never seen it cause an issue and it saves thousands of lines of code.
@@adambickford8720 But saving LOC is never an issue with modern SW development. Who cares? And: if you want to save space AND get rid of Lombok, use Java records.
@@andreaschrist4093 Its far more than a few LoC. You don't have to regenerate boilerplate like hashCode() and equals() which prevents bugs. It promotes good code when things like builders are a simple annotation, no chance to implement wrong.
Records might be good someday, but without things like simple 'withers' they are nowhere near comparable. They aren't even value objects! Every single manual property being copied is a potential bug.
I've still never seen a concrete reason not to use lombok, usually just outdated "what if" dogma that hasn't happened yet.
looks like java has more features than c++ already. am wondering if developers working with java have feature scope e.g. what java features are desirable and which are not.
Java has way fewer language features then c++ or it's more similar brother c#. The jdk group is one of the strictest juries on what feature is worth it that I know. They shatter feature ideas day and night if they don't solve a big problem and are just a small improvement to something.
It's heartbreaking on one side but it keeps the language concise and simple.
Definitively not 🤨, just going to cppreference to see how messy the language is.🫣
we need generic enums
I'm afraid that's not going to happen (or at least not soon): mail.openjdk.org/pipermail/amber-spec-experts/2017-May/000041.html If you don't want to read the whole mail, search for "Unfortunately" and start there.
why did you break clipboard, so that it cannot read (same data flavor) what it just wrote there, the same app. only "ctrl-v" of a clipboard data from another app would work, not from the java app itself. "ctrl-c" to another app through clipboard would work, and as side note drag and drop works into the java app. java-17/21 compatibility of the runtime jre level (both dont work correctly) if you ask but java 8 compatible code. btw is it hard to can projects, if they are doomed but you have already invested lots of something in them? like babylon gpu runtime of java. keep your projections simple, for the users and your own sake. make sure your foundation principles are healthy, otherwise you limit all what you build with them. specifically the template style generic classes limitations without reason. would you mind "Kawa" language that implements all that you have not done correctly as an example. spend time in necessary things, dont create unnecessary work. feature might not be worth it at all.
I stress, the java native GPU opengl/vulkan 3d/compute programming (not native library or gpu executing java directly) is the most critical if you want any platform game/graphics software foothold. extend what you currently have in the 2d opengl graphics acceleration implementation. instead of babylon, I mean implement vectorization of math/graphics for both cpu and gpu first. even if it steps on javafx or other adjacent/community projects heavily. jvm is the java native abstractor, not the community native libraries.
about the clipboard issue, getContents() and isDataFlavorSupported() is not null/false even if it does not give any (image) data out with getTransferData(). the image in the clipboard seems to be 100% transparent when the java app tries to read its own pushed clipboard data contents. are you not really copying the clipboard data so that cant be modified by the caller?
some objects are not truly buffered (independent) when they should be. or even if they would be documented or work like buffered.
openjdk21 on win11 does not seem to be able to show system tray icon and console even if specifically configured in the advanced settings to "show console" and "place Java icon in system tray" and "enable tracing" and "enable logging".
numpad key press events dont support shift (or other modifiers) if using e.isShiftDown(), like numpad0 specifically. not even e.getModifiersEx() supports SHIFT-NUMPAD0.
感觉不如C#
We can wait forever. No way back: point of no return is already passed...😑
with looks very simular to Groovy.
Amber is such a bag of bad ideas.
Clueless
The "with"-expression (at 6:11) looks useful :)
But yeah, "STR" could've been just part of "String", as it is public static and only generates Strings anyways. Its a new flavor/syntax of String.format, which is more easy to read but has no field (length) formatting anymore - even though the same complexity of syntax got newly added back with FMT and zones, which look very similiar to String.format syntax, but now you have String formatting/interpolating scattered across the classes String, MessageFormat, STR, FMT and Stringbuilder... Which could have been a chance to unite them all. Functionality-wise FMT might be a _successor_ to String.format while STR might be _an easier way_ to use String.format - but I don't have enough experience/time spend with STR/FMT yet to tell for sure. Yet I'd prefer to see both functionalities (STR and FMT) accessable using the same prefix ( idealy just String."\{}" ).
The simplified main might be good for marketing Java to noobs and for people without an IDE or for coders who aren't fast typers..
And the ability to write statements before this()/super() can be useful for validating constructor parameters before (unnecessarily) calling a (super) constructor. This might be niche but I can't see a downside in it, as its just more freedom, without any forced cost.
I try to see the big amount of quick changes optimistic. But I have stomachache as well with the newly added keyword "when" (as a non-optional alias for "&&" in switch). And I'm not alone with that.
@@TheBigLou13 The important part of string templates is neither STR nor FMT but that we can all create our own template processors that benefit from the same syntax improvements and can apply domain specific rules to return non-String objects. Check Inside Java Newscast #47 for more details.
Well, all of this is a sign that I should forget about Java and switch to C# or Golang. There's a proverb that says: "The crow wanted to learn how the partridge walks, but it forgot how to walk itself." If Java is constantly trying to be like C# or Golang or etc, then it's better to go directly to these languages because I'm sure Java will forget its own way.And of course, I know great developers who believe that this has happened before.
Complete nonsense. Are you a software dev or do you have only theoretical knowledge?
Those new changes feel like real fresh air. Finally, Java doesn't feel like you need to struggle.
Api is becoming better.
Unless, you get paid for amount of lines of code 😅, but even with that - you can be on Java 7 (before lamdas and java time)
@@markandrievsky6317 I work with Java since 10 years and never ever felt "the need to struggle" with Java. I can see the point of @ahuramazda9202 - even though there are many cool features as well (virtual threads, records, more stream stuff, Pattern Matching - even though the "when" keyword causes me pain, since its just a forced alias for "&&" which makes it so much harder to read now)
@@markandrievsky6317 I agree,
Java is indeed still on their way and bring only the best features that are completely thought through to production. It seems like java has stepped up features released but that's an illusion. They changed their release cycle and are more prominent with videos like this recently. Making it look like more is changing than it actually is.
Personal note
I really prefer having 2 feature releases with previews than to get dumped a world of features every few years.
Whole I fully support the "withers" like:
var carlWithers = someMrWithersName.withFirst("Carl");
they are much needed.
But I absolutely reject Brian Goetzes idea of with blocks, like:
var carWithers = name with { some code }
Not only does it look strange to the Java syntax, I think it is overambitious, and wants too much.
The record.withAttribute(foo) syntax is perfect for the common case. If I want anything more, like some block of code, I can still override the with method, using, you guessed it, the common established Java syntax.
They don't make much sense with common classes either - they certainly don't need them, so transforming a record to a common class just makes things more cumbersome. I don't see any benefit in that.
These "with blocks" are a prime example of feature creep and should be avoided. Sorry, Brian, but I think you're going too far and need to take a step back and think again, if you're creating some kind of "YAGNI" feature.
That is an interesting point I haven't thought of yet. I think of "with" as a "reusable new" keyword, where you can dynamically clone an object and overwrite some values without the need to recreate the whole object from scratch. A natural use case for "someRecord with {}" might be a database pojo, mapped into a record, where you want to update some fields but keep the rest of the record intact.
If we'd follow your suggestion using something.withFirst("Carl") - how does this method (withFirst) come into existence? Should there be an implied with[AttributeName] method for every attribute? Like reflection? Or should the with-method have two parameters like hashmap.put(key, value)? I see a benefit in a with{codeblock} in big classes where you can use the codeblock to parse a stream with loops and maybe gatherers into all the fields of the object you're clone-with-ing.
Without a codeblock you'd have to write something.withFirst("Carl").withSecond("Carl").withThird().withFourth().... which could get very very long and I'd expect that you'd create a clone of a clone of a clone with every new .withAttribute(); But with a codeblock you only create one clone with many overwritten fields at once.
@@TheBigLou13 "f we'd follow your suggestion using something.withFirst("Carl") - how does this method (withFirst) come into existence? Should there be an implied with[AttributeName] method for every attribute?"
Yes. Just like the accessor methods on records. If you have "record Name(String first, String last){}" then the compiler will generate "name.first()" and "name.last()" for you, if you don't define these methods yourself. It's no stretch to also generate
"name.withFirst(String first)" and "name.withLast(String last)", as long as you don't define them yourself. Just as shown in Nikolai's example.
" I see a benefit in a with{codeblock} in big classes where you can use the codeblock to parse a stream"
You're doing too much then.
You can easily create a method that does all this parsing and have it "return new Data(myParsedStuff, otherParsedStuff, oldData.retainedStuff).
You can also put that method on the record itself, if you wish.
If you really need to have a block that you can inject, just have this:
record Foo(int id, String name, float value){
Foo with(Function modifier){
return modifier.eval(this);
}
}
and call
var nuFoo = myFoo.with((original) -> {.......; return new(original.id, someNewName, someNewValue)});
it will do the same, look almost the same, but not introduce a new syntax.
"something.withFirst("Carl").withSecond("Carl").withThird().withFourth()"
Nothing wrong with that, but if you have more things to modify than to retain, the old way is still valid:
"new ("Carl", "Carl", third, fourth, something.original)"
You don't need the with block. The with block is hardly needed for anything else then changing one value, and if you need to change more than just one value, it's not better than a factory method, has no benefit over calling the constructor and if you really really need to pass in a block, it can be achieved (as I demonstrated) by defining a method using a lambda.
Withers should just be the equivalent of accessor methods for immutable records to reduce the most common boiler plate.
With blocks on the other hand introduce new boiler plate.
Just compare:
someFoo with { first="Steve"; }
someFoo.withFirst("Steve");
someFoo with { first="Steve"; last="Jobs" }
someFoo.withFirst("Steve").withLast("Jobs");
you're saving one "with", as the expense of more symbols, like =;{}, plus new syntax to learn.
And given some clever formatting, both are just as readable. I don't see the benefit.
I absolutely disagree. If you allow wither blocks you only need a single additional allocation to change n fields of a record. If you generate a single with method for each field you require n extra allocations for n changed fields. The only other option would be to generate a new method for each possible combination of fields which would be a true disaster.
Edit: another option would be to introduce optional arguments and named parameters to create a with method with every field optional using that but this would require two new language features we don’t have yet.
@@smallfox8623 this is misconception of yours, or let's it's say, it's what it looks like would happen, but doesn't. Have you ever heard of these things called "escape analysis" and "inlining"? In this case, the JIT compiler can prove that none of the allocated intermediate objects and its fields will escape the scope of your method. It will not allocate any memory on the heap, but can resort to allocating the variables on the stack, inlining their initialisation and finally compile it to just setting some registers. This is called "scalar replacement".
This is not new tech. Escape analysis was first introduced in JDK 6 and has been improved since.
What Scala does is perfect, which allows to modify any number of fields, the rest get copied:
al newObject = oldObject.copy(name = "Tim", age = 21);