so what about that Thread.sleep(16) being 32ms sleep, ie double time of the stated, running in a dedicated separate timer Thread class run() function.

The coding language is just laggy shit

Where can i buy this mug with Java logo?

That may have been the original intent, but after taking notes (probably from Scala & others) Java 9 realised it should ALSO be thought of as a container with max size 1. (It makes its methods like stream and filter make more sense when looked at this way.) It is a shame OptionalInt etc were not consistently rationalized in the same way.

29:50 I suffered this for more than a year

I watched his talk, it thoroughly explained the “year three” stage of complexity I am seeing at the office 😂 I now understand why I am nervous about the peak complexity we aim to ship in Q1 🫣At least I now know we need a complexity collapse 😅!

Thank you for share!

The great José Paumard！！！

I'm not familiar with the pattern keyword.

You mean to say that developing these features is like a computer science PhD (except more people and more time)

My team shipped the peak of complexity 8 years ago, and progress to develop has been slow ever since. We're making the investment now to cut the worst of it. We've taken the most overcomplex part of de domain, wrote our wish interface for it, wrote an adapter from the old peak of complexity interface to the wish interface, and are now migrating a lot of code to use the wish interface at the cost of performance. Once that's done, we can lose the complexity by reimplementing the wish interface cleanly. Yes, we had to fold more complexity in to get here, but when release + 2 ships, the customers will notice dev time decreases and performance gains. How do we know it's the right path? All code migrated to the wish interface, (which has fewer bells and whistles than legacy) has become simpler as a result, and we know the same holds for the new implementation, and the underlying data. So, at the cost of work, we had to invest complexity, but have a clear path to shed complexity in the data (without losing information), the peak of complexity solution, and every part of the system interacting with it. Sometimes you must navigate up to go down, cause you settled in a local minimum, like a little crater at the peak of a vulcano.

Great conference Mr. Paumard.

You allowed million libraries to crop up over 25 years to finally reach here. REST in peace, JACKSON, GSON, JAXB

Can I use the builder pattern with records ?

We reimplemented Java Serialization to address its shortcomings, we didn't implement support for circular object graphs, which allowed us to use constructors and provide tools to assist developers using it to validate invariants, such as class types contained in collections. We also flatten collections into array types that are read only, developers are expected to defensively copy and validate collections anyway, so this made a lot of sense to us. In essence we found that circular object graphs are not needed and usually indicate the presence of poor design.

And ending up like JDK 8? Naaah, nah thanks

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.

What a great presentation. Thank you!

am wrong today if im still using java 😢

Goetz is the GOAT.

procedure that return void ??

👍

Hard to follow

There could be places where we want data from a parent thread to trickle down to child threads. InheritableThreadLocals gives you that power. How is this handled in ScopedValues? My 2nd question is more about design. Let's think from first principles. A software program is data + functions. Here you have segregated them (data/functions :: scopedValue/scopedTask). I understand single responsibility here (if the intention is to keep them separate and allow developers to get creative). However, it would be great, if we could have something like a ScopedVirtualContainer.(which accepts scoped values and tasks in pairs and executes and produces results in some order if specified) . Like we have CompletableFuture.allOf(Cfs...) From my experience, Completable futures are hard to understand for devs not having prior experience of Functional Style of programming. Also, a lot of people do not know how to close a ExecutorService (though there is a clear class level javadoc example on how to close ExecutorService. who reads all that? right? ) Biggest problem is ThreadLocals and InheritableThreadLocals and making junior devs understand their scope. With the old java version, we had to hand code utilities so that not everybody has to reinvent the sensitive parts. Now with VirtualThreads coming in, it helps us remove a lot of our utility code since those features have become native. Thank you for this talk! I watch all your videos on Jep cafe. Big fan! Please continue sharing your knowledge with us. Thanks,

What's the difference between ByteBuffer.allocate() and ByteBuffer.allocateDirect()?

The new memory api is incredibly versatile. It's just not something you are likely to use directly but indirectly through some library using it for performance and low level operations

So, how will I know dependency is a release with tail paradigm.

nice explanation

200 sips of coffee 😂😂😂

Thanks so much for the great videos and sharing your knowledge. If I could offer one piece of advice, try speak a bit slower, you talk a bit too fast and as such your points blur into one another making it hard to pinpoint critical statements. Thanks again!

I wonder if at some point an implementation could output protobuf wire format by reading a .proto file? That would be so good.

Eyyy!! Its Viktor Klang. Met him in 2016 as a cs student volunteering at scala days. Sat down with me after his talk to explain a concurrency concept further. Motovated and inspired me to keep at it with Scala. Great guy!!

The title of the video should have been "Java Language Features" not "Java Language Futures"

These shorts are great and you release rate perfect! Thank you so much!!!

How is it that your examples don't do any of the things that seemed to be needed before, like "SymbolLookup.libraryLookup(<library name>" then the ".find(<method name>).get" then the "Linker.nativeLinker().downcallHandle(" etc. It used to be loads of boilerplate and now it looks much cleaner. Where can I find a "cookbook" for the library I want to use?

Java isn't able to correcly create a TrayIcon in Linux because it uses a 20+ years old API. Notifications in Windows are broken because they use a 20+ years old API. Is there any interest in making Java a language usable for projects that has a UI?

I’d want more on data oriented programming

We are going to have another JavaZone's Game of Codes trailer Nicolai? 😂😂😂😂

2nd..

First commit on new project 😂

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?

Please correct me if I misunderstand the subject at 44:16. But isn't the only reason that we see "MyApp.java:78" in the stacktrace that this example doesn't use "someService::readImages" as a method reference, unlike the example with the platform threads executor?

Is a method call that returns void also an expression?

kotlin lazy provides ability to control how many times lambda can be invoked. Also delegate feature makes it easy to use. StableValue came after kotlin lazy but looks uglier.

Show

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.

It’s nice to see Java evolve. I genuinely appreciate all the effort Oracle and the OpenJDK folks have been stemming. But it’s an elephant - slow, huge, and clumsy. Lots of changes have been long overdue, it’s great they’re being introduced. But it’s all about retrofitting with backward compatibility in mind. You’re now bridging the legacy cruft along with the great core of Java now with the “modern” features. I understand that having a clear cut like in Python or in Scala would fracture the ecosystem. But there’s really so many bad design choices in Java to this day that working in Java is just not making a team agile at all. There’s so many unfortunate inconsistencies and untold caveats, Java has become hard. To every new feature, there’s always attached a list of caveats and gotchas being uncovered within a year or two. That’s the cost of retrofitting. Improvements are great but they aren’t “free” for the language users. Feels a bit like the retrofitting evolution of C++. Just for example, slide 51 at 25:30 showcases an algebraic data type implementation for a type enumeration, as used in Scala or Rust. Avoiding coloring functions with async that example colors the result types. It’s great if most logic can reside in the type system, but Java’s is far from adequate for functional modeling. Now you impose existential types for the sake of inheritance. Not the best choice for type inference. What Java needs are properly typed enums like in Scala. It feels like a lot of words and hype is being stirred up around something so natural and so well known - for decades - too much for something so obvious. You’ve had all that and so much more in Scala, I just wonder why it’s being presented in the narrower Java community as anything novel or important. And it’s still mostly experimental or in preview. The Java developer experience has struggled.

Scala had all of these features 15 years ago 😮

Please do something in UI side..fucckd with Javascript

Good content. Just a note about English: Native speakers would say "How does the reduce() function work?" That's an artifact of Celtic language influence. "How is <x> working?" is also a valid question, but it asks about immediate state. For example, "how does this car work" asks how to turn it on, where the controls are, etc. "How is the car working" asks whether it is currently running, out of gas, etc.