Okay, good morning, can I have a good morning?
Can everyone in the back hear me?
Okay, I did theater in high school and college.
Maybe it's good for something.
We'll find out.
So, let's talk a little bit as I do every year,
except for the years that I miss this event, which is rare.
About the state of the Open JDK community,
the JDK and Java.
This year is coming up, as you might know,
a pretty momentous year for Java.
Sometime in May, I believe the 23rd of the 25th,
Java will be 30 years old.
And some other people here have been working on it
for most of those years, which I don't know
that's a sign of sickness or whatever.
But anyway, so 30 years and Java is still
one of the most popular programming platforms in the world.
You don't believe me, you can ask Redmunk.
There are many surveys of programming languages and platforms.
A very degrees of believability.
I think Redmunk is probably the most believable.
This is their survey from June of 2024.
The X-axis is a popularity rank derived from GitHub.
The Y-axis is a popularity rank derived from
number of tags on Stack Overflow.
And there are lots of interesting languages here.
Way up in the corner.
You'll see Java.
Next to something called JavaScript.
I'm not sure what that's all about.
Python, whatever.
Anyway, it's way up there.
And I think it's going to stay way up there.
So why has Java been so extraordinarily successful
over the past 30 years?
One part of the answer is our relentless focus on two big goals.
One is developer productivity.
It's all about helping developers build and maintain large
and reliable programs.
Okay, yes, so we started with Applets, which we're small and flaky
programs and browsers, but Java grew up.
The other thing we focus on is program performance.
Whether that's measured at a startup time, warm up time,
latency, or throughput, or whether it's measured in space.
Whether that be at the static space or dynamic space.
And we focus on these goals in the face of constantly evolving program
and error times.
For example, mixed functional and object oriented programming.
In the face of evolving application areas, big data and machine learning.
Evolving deployment styles from on premise to the cloud.
And of course, evolving hardware.
Nowadays, it is not uncommon to have terabyte size.
These deeper memory hierarchies trying to combine vector and
SIMD instruction sets with regular CPU computation.
And of course, deeper and more numerous process or pipelines.
As important as the goals we choose are the means by which we work to achieve
them.
Another key to Java's success has been the fact that we take the time to
think about the big picture and the long-term.
Not just about, oh, we know what PR is interesting this week to add some
future to the platform that, oh, my gosh, we're going to have to support that for
30 years.
You're kidding me.
We don't act only as developers.
That is people who create things.
We also try to act as stewards.
That is, we try to be responsible for overseeing and protecting something
that is considered worth caring for and preserving.
We try to preserve the past while evolving for the future.
Our work is thus guided by two core values.
Readability and compatibility.
Readability is essential to maintainability.
If you can't read the code that you wrote a month ago or that a colleague
of yours wrote 10 years ago or 30 years ago, then what are you going to do when you
need to fix a bug?
Compatibility has many dimensions.
There's technical compatibility.
Those of you feel familiar with the JLS and the JVMS understand that there's
source compatibility.
There's binary compatibility.
There's behavioral compatibility.
All are important.
There's somewhat odd kind of compatibility, which we've come to call migration compatibility.
That's the question of, well, you have existing code.
New features come along.
How hard is it to take that existing code and adapt it to use the new features?
The first big example of that in the Java platform was generics when we added generics
in Java 5.
We took great pains to make it possible for code that had adopted generics types and
code that hadn't to interoperate together so that you could gradually migrate a code
base to use generics rather than having to do all of it all at once.
One of the big trade-offs there was we didn't get reification.
But you know what?
It actually worked out pretty well.
Another type of compatibility is what I'll call intellectual compatibility.
We don't want a new feature to require developers to throw away everything they
knew and have to start all over again.
New features built on existing knowledge.
They don't destroy it.
Preserving these values while moving the platform forward is much harder than it looks.
But that is what we've been doing for 30 years and we will keep doing it.
Now we used to do this at a relatively slow pace, a fairly sedate pace, a fairly
sedately pace with a new release every few years.
But eight years ago we changed.
We switched to a rapid cadence, shipping a new release every six months, light clock
work and strictly limiting the number of back ports along term support releases.
Some have come to call this the tip and tail model.
And I suspect you'll be hearing more about that as time goes on.
This was a radical change but it worked out better than any of us at home.
It resulted in less process reduced overhead, greater stability and best of all more features faster.
I have colleagues I work with closely and it's entertaining sometimes to realize
they don't actually know when the next release is going to ship.
And that's okay because they're busy working on a feature that will ship in the one after that.
So we've shipped all these releases in the last eight years.
We will ship JDK 24 next month.
JDK 24 will hopefully have its first release candidate next week.
And the next long term support release, JDK 25 in September.
Now this truly is a community effort.
It's a valuable, creates this table every six months, like clockwork.
And it's got lots of interesting data in it.
This is a graph, oops, we're cutting off on the right-hand side.
Sorry about that.
The area of each box represents the number of issues resolved in the JDK mainline,
not the update releases in the JDK mainline from release 11 through 24.
Now this big red box is, you might guess, is Oracle.
But we've got lots of contributions from others.
We have red hat.
Sorry, red hat, you're not red because whatever.
Lots of contributions from SAP.
A significant contributions from people unafiliated with any large organization.
I think that's pretty cool.
And then you have random, you know, lesser contributions.
But still important ones from Amazon, Google, Tencent,
and you can go down here and you find, like, Ozil, and Huawei, whatever.
Anyway, a broad, broad base of contributions.
So in terms of the releases, we have shipped in the past year.
Let's see, this is 2025.
Going back to 2024.
A year ago at Fauston, we were about to ship JDK 22,
Java 22.
There were 12 gems in that release for those of you who don't know,
since our JDK enhancement proposals.
They're the process by which we document and explain big new features in the JDK.
Or sometimes small features that are worth significant notice.
So there were 12 gems here.
I went through them all.
The orange ones are those coming from outside of Oracle.
In Java 23, JDK 23 lasts September.
We also had 12 gems in a variety of areas.
We'll notice some of these are marks various ranks of preview,
or incubator, third preview.
8th incubator for the vector API, that one's taking quite a while.
Around the time we switch to the 6 month K, cadence,
we also introduce the concept.
Two important concepts.
One is that of incubator modules, which is a place where APIs can live.
They'll be distributed with the JDK.
They'll be available for end users to use.
But they are not a committed part of the platform.
They are experimental.
Please try them out.
Tell us what you think.
They're also preview features, which are not shipped in separate modules.
These are historically mostly been used for language features,
which you can't really ship in a separate module.
So many language features have come in.
They come in as a preview feature, which means you need to enable it in order to use it.
But you can use it.
It's fully specified.
It's fully supported.
It's there.
We reserve the right to change it.
Hopefully not significantly as time goes on.
And eventually, preview features are either finalized or removed.
And we actually have removed one that we decided was not ready.
All right.
So that was Java 23 and JDK 23.
We were coming up, as I said, on Java 24.
JDK 24.
There are 24 jups in JDK 24.
This was carefully planned.
No, wait, no.
It's a sheer coincidence, actually.
But sort of an amazing number.
Lots of good stuff in here.
Again, I won't go through it.
So I know there are probably a lot of folks in this room who don't work on the JDK itself,
because you're here to find out about this out the status of Java and what's new.
If you are, I'm glad you're here.
And I encourage you to test out the early access releases available on JDK.java.net.
Release candidate for 24 is coming out next week.
And 25 is actually already available.
Java 25 JDK 25.
There are zero jups.
So far, this release will ship in September.
I could make random guesses as to what's going to be in it.
But we won't know until we're done.
That's another one of the great things about this process.
It drives management mad, because you can't tell them what's going to be in the release.
But too bad.
Again, early access releases for 25 are already available.
And there you will find lots of really bug fixes, small enhancements that didn't make 24,
et cetera.
And I expect the first step for stable values will probably come in pretty soon.
All right.
So let's try to look ahead a little bit at the big picture.
So as I said, we're all about developer productivity and program performance.
And we generally focus our work by asking, what are the pain points that people are experiencing,
developers are experiencing, customers are experiencing that we can address in the platform.
And we try to address them in the platform in a logical and consistent way.
So I'd like to just walk through some of the things we're currently working on.
And these are organized around pain points and competition and one project.
So one pain point that we've been hearing about actually for 30 years is Java is too hard to teach.
Public static void main open-prem string what to a freshman in computer science.
You've got to be kidding me.
Okay.
So we're working to make that story better.
The main competition here is Python.
Python has been making in rows in education.
You know, I think in significant part for this reason.
So in project amber we're doing something we've come to call paving the on ramp.
I think on ramp going on to a highway.
We want that to be a much smoother experience.
We want beginning programmers to be able to write, you know, hello world or a simple, you know,
tell me what your name is and hello here's name and move on to bigger examples without having to type.
Public static void main.
Another thing we hear is Java is to do verbose.
Yes, we've been hearing this for 30 years also.
And see Sharpen, Kotlin and Skala have all gained some popularity in part because they are less verbose than Java.
This is another pain point that amber is addressing by reducing language ceremony.
By bringing concepts that have been proven in other languages such as Haskell.
Java now has algebraic data types.
They don't look like the algebraic data types in Haskell, but you've got records.
You've got sealed classes.
You've got pattern matching.
Yeah, it's a little more verbose than Haskell, but all the express of power is there.
And it's amazingly useful.
Java starts up too slowly.
Yes.
Go JavaScript and Python.
I'll have Java beat in this regard.
In Project Lydon, we are working to do what we call selectively constrained dynamism.
Java is an extremely dynamic language.
It's also partly a static language, but it's much more dynamic than many people give it credit for.
That dynamism is a source of power, but it's also a source of long startup time.
And so we're working to improve that.
Initially in Lydon, we had a concept of condensers, this condenser model,
that we thought was going to be useful.
It turns out that we've been able to do a lot of work on startup and warm up directly in the hotspot
Java virtual machine.
By taking existing components that we have, rearranging them, changing how they're used,
we actually have some compelling prototype work that gets significant reductions in startup time
without you having to change your program at all.
And I think that's pretty cool.
The first jet coming out of Lydon is actually in JDK 24.
That's called the Head of Time class loading and linking.
If you're familiar with how Java loads and links classes in the JVMS,
it's the fairly detailed, detailed and specific process,
and it all has to be done at runtime.
Well, now we can do that ahead of runtime in a training run,
so that you don't have to do it at runtime,
and that results in significant improvements.
Forads are too expensive.
Yes, well, when Java first came out, it was on so-called green threads,
and it's entertaining to see other programming platforms that are newer than Java.
They have come out, and they have called their threading systems green threads,
not for any other reason, other than the Java did in the early days.
Green threads was basically a manual multiplexing of multiple threads
onto one operating system thread.
We fairly quickly, in the early days of Java moved on to the more logical thing,
of one Java thread per operating system thread,
you know, by then operating system systems,
at least the unixes were getting pretty good at multi-threading.
But over time, we found that well,
one Java thread operating system thread is too constraining,
because operating system threads are really expensive.
You have to allocate, you know, a megabyte for the stack,
you know, other overhead.
So with loom, we have virtual threads,
and we can now compete very effectively with platforms like go.
The cost of a virtual thread in Java is, you know,
the actual overhead, if I remember right, is three or four hundred bytes,
plus whatever stack space it requires.
There's no fixed allocation.
You can have millions of virtual threads,
and it works perfectly fine.
Another cool thing in loom,
is not quite finished yet, is the combination of structure
concurrency and scoped values, scoped values,
which are from Mr. Hayley here,
are the right way to do what we used to call
a thread local storage.
And structure concurrency is a way of managing, you know,
medium, large, enormous flocks of threads.
This is something that goes, it is actually,
actually cannot do.
So Java is ahead of go in that regard.
Another pain point, cash misses are too expensive.
If you have a simple abstraction for points,
it contains two doubles.
Now suppose you have a really larger array of points.
Is that a ray of points going to look anything like
an array of points and see looks in memory?
No, it's going to be an array,
and each element is going to contain a pointer
to a point object somewhere else in memory.
Chasing all those pointers gets to be very expensive.
We're trying to do any kind of serious science
that the machine learning computation.
So we're trying to address that in Valhalla
with two features.
One is value types, the ability to declare a class
that does not have identity,
and thus can be, for example,
stack allocated to register allocated by the virtual machine
and also laid out much more efficiently in memory.
And no restriction.
So we're going to have what some call emotional types in Java.
You can write string question mark,
you can write string, string exclamation point,
and they will mean essentially what they mean
in other languages such as Kotlin.
That's kind of an interesting story.
Valhalla is working on Valhalla for like 10 years now.
It is Java's epic refactor.
It is deep cuts in both the language and the virtual machine.
And we never expected that null restriction
was going to be in a central part of the story.
But as we got to the peak of complexity and began
to simplify things we realized,
if we could only ensure that certain things were never null,
then it would make the whole,
all the work for the VM to lay things out in memory flat
much easier.
It would also make things easier to reason about by developers.
So we're getting null restriction,
even though that really wasn't the plan.
Another thing that Valhalla is addressing
is the fact that generics and primitives don't mix.
Next, right now you cannot write newer
ray list of int, right?
That just does not work.
So once we have generic specialization,
you will be able to write not quite that,
but something equivalent to it.
And the array backing it really will be an array of ints.
It won't be an array of pointers to capitalize integer objects.
numeric loops are too slow.
The hotspot JVM does have,
it does do a certain amount of auto vectorization,
but it's limited in what it can do,
and it's fairly brittle.
Meaning you could have some code that auto vectorizes
great today.
You could make a small tweak in it next week,
and then it would not auto vectorize.
And your performance would fall off a cliff.
That's not good.
So our answer to that is in project Panama.
We're working on the vector API,
which allows you to write explicit
Cindy instructions, but in a portable way.
So it's a portable API with different backends
to the different Cindy architectures that we find
on different processors.
Using native libraries is too hard.
Job the Java native interface.
Actually, the Java native interface is a lot better
than what came before.
Those of us worked on the JDK in the very early days,
the native interface was ten times harder than JNI.
So JNI was a big improvement, but it's still kind of sucks.
So we have replaced JNI with the foreign function
and memory API from, which is also from project Panama.
The FFM API went final in,
I think it was JDK 23, so it's there.
It's no longer in incubator preview, and you can use it.
Moving right along.
Using JPUs for AI is too hard.
AI computation, graphics computations, machine learning computations.
People want to be on GPUs, whether they're GPUs
from Nvidia or AMD or Intel or whatever.
That's too hard.
So what we're trying to do in project Babylon
is provide a way to take Java code,
converted basically to high level intermediate representation,
which a framework could then transform
into CUDA code or spear recode or PTX code
for GPU type hardware.
So you will be able to write GPU computations
in sort of a sub dialect of Java,
have it automatically transformed
into code for the GPU that you're using.
People sometimes ask, well, what is Java doing about AI?
When is Java going to have built in automatic differentiation?
We need that for machine learning.
And the answer is, we're not going to have that
in the Java platform, but we focus on in the platform
is things that only we can do in the platform.
In fact, the bottom five features here
will all help AI applications.
They will make it possible to interact
with native code, AI libraries, native code,
linear algebra libraries, such as lists.
They will enable you to interact with GPUs
and we've already got some compelling prototypes
of, for example, code that can manipulate
Linux machine learning models and both train them
and execute them in Java.
So again, if you're here because you're interested in Java,
that's great.
If you're interested in Java, you're not working on Java.
Please go to JDK.gov.net.
We have really access fields of 23 or 24 and 25
along with other interesting stuff.
And that's all I have.
We have four minutes, should we take questions
or just move on, your choice.
Anybody want to ask something in your choice?
It must be interesting.
It kind of tends.
And if you look, you'll have, like,
you'll have a child.
And I personally, in a comfortable place.
Yeah, I mean, these are my people.
We're all here.
All right.
Thank you.