So, with that, we hand it over to our illustrious first speaker, Dalibor Topic.
Yeah, hello, I'm Balkir for myself as well.
Let's see, the microphone that works, works, yeah.
So, my name is Dalibor Topic, I work at Oracle.
And I don't need a mic.
I'm Static-y. Oh, yeah, I'm like metal.
Metal, I'm metal. Okay, better?
No, that's just my voice.
Right, so I work at Oracle as a product manager on OpenJDK.
I also tend to wear many other hats in the OpenJDK community,
like that of a JDK Updates maintainer.
So, are they giving the presentation following right after this one
on how the JDK Updates have evolved across the past decade?
But for this one, let's get started in the interest of time.
Four years ago, our story took a little turn.
Mark Reinhold gave this talk, or version of that from four years ago,
on the state of the OpenJDK in the free Java DevourMid foster.
While Mark couldn't join us this week, he graciously offered me
to actually present the talk as I would give it
after four years later.
So, my version has now to cover not just one year as the tradition demands,
but four years of development of OpenJDK.
For better or worse, I think for better, I don't get four times as much time.
So, I just have 20 minutes, so it would be very compressed.
And I leave the fun parts out for other people to cover in this room.
But almost 34 years ago, the World Health Organization declared
the novel coronavirus outbreak a public health emergency of international concern.
Their highest level of alarm.
And while this development, at least for me at the time,
and probably to most of you might not have seen very concerning while we were here at Brussels,
well, it turned out that in the following weeks and months and even years,
we had a public and our response to it disrupted both the regular life
and the supply chains.
And for us, for the OpenJDK thing in particular,
it came at an in-between moment because we're in the middle of making JDK 14.
Back in September 2019, we had planned to release JDK 14 on March 17th of 2020.
And so, boom, all of a sudden everything changes.
Because we actually planned to have release cannabis in February and then release in March.
And as you may well remember, March 2020 was quite something.
Man, that was something. It was quite disruptive for many people in many ways.
But what wasn't surprising was that we actually delivered JDK 14 as predicted in September right on time.
Just as we planned on March 17th, just like every JDK release since,
we had switched over to this new release cadence of having a release that's predictable and time-driven every six months.
That switch was performed two years prior to that, back in 2018, with JDK 10.
And then it led to much better results than the way the JDK development used to be
prior to that with longer development cycles that are less predictable
and tended to deliver less, let's say, reliable results in terms of actual release dates.
And of course you can now say, well, sure, of course you did release on time
because what was left to do was just to polish your release candidates to perfection, as you always do.
How hard could it possibly be? Well, it's not so easy.
So we actually, in our nine-month development cycle of the JDK releases,
we leave three months to the polishing part to ramp down and actually fix the release down,
whereas the first six months we devoted to developing features and all the new bug fixes that come in.
And so we leave ourselves enough time to actually get to a really high degree of quality.
So while there's probably a kernel of truth to saying there wasn't that much left to do,
there is a lot more to it because as we look at how we delivered the rest of the remaining four years releases,
they also all came in on time during the ups and downs of the pandemic and supply chains and what else was going on in the world.
So there's actually quite more to it than just the fortunes favor of the bold or the brilliant or high-end putters.
So as my colleague Brian Getz said in his keynote from last year,
the bad old days, as we now call them, but they were the good old days back when we were in the middle of them,
they had a very core-strained feature box release model.
So it took us two years, two-four years between releases.
And just this little fact tells you how flexible that was because that's the double the time sometimes, depending how bad things go.
We had frequent delays. There used to be like a running joke sometimes in papers about trade releases.
And we had no predictability. The release management process had to be very heavyweight to accumulate for that.
And we had a lot of temptation because of that, the release is shipping every few years to push in changes that just had to be there.
And so that lead to tweaking of the arms to get things in sometimes.
And also because users wanted these features, not just in latest release, but on the releases they were using,
to tweak the arms of the backport steams release managers to get them backported.
So we had these huge releases that came out and kept getting major feature updates every six months,
not just backfixes, but really big huge features like new garbage collectors and stuff.
So that's a lot of work, but it wasn't really working too well for anybody.
It wasn't working well for us because it had these massive overheads.
It wasn't working too well for the developers and the community out there either because Java developers were getting frustrated
by the pace of Java's development and by the time it took to go from one release to the next to get the major features,
while all around them the world was exploding with excitement around groovy scala.
All right, yeah. Pearl five, come on.
Things happened back about ten years ago, so it was an exciting time for Java.
And so the excessive backports also ended up being a problem for the backporting project because we ended up having to do a lot of work
to get new features and to shuffle things around.
Whereas with the new model we changed things a bit and decided to just focus on backporting what really matters,
which is security fixes, grid fixes, and the rest will leave up to people who really want to do the work.
So to do that we first inquired to see what actually we wanted, what we need for developers.
They tend to want the latest and greatest features.
They tend to want the language changes, the VM changes, the performance fixes, all the good stuff.
Whereas our many Java users tend to be conservative business users.
So they tend to favor and appreciate stability and security.
And they tend to want to have their investment they've been to the platform two, three, five years ago pay off and keep paying off for a few more years as they had planned.
And so it's hard to make these very different goals, hard to fulfill at the same time.
So the old model basically didn't make either developers too happy or the enterprises too happy.
The new model we adopted with these kids is a tip and tail model as George and Brian and others on our team like to call it.
Where all the features that we develop are integrated on the tip of the development.
So they're done where development happens, right, where the action is.
And they're integrated only when they're ready and only when they're ready.
So we resisted the temptation to pull something in just because it's got to get out there, man.
We pull it only in when it's actually fully baked and we believe it's actually done and good enough.
And to actually get to a point where it's good enough sooner, we introduced the concept of feature previews for example.
Where a feature can then get gradually improved and refined to its actually fully part of the platform.
And so that takes a lot of the pressure out from getting code and features into JDK.
Because if you miss one train, there is another one coming six months afterwards.
And if your feature isn't completely perfect, you want to have, use a feedback, you may get a preview, you get to use a preview, a preview.
And you do this a couple of times if you have to.
And this takes what used to be a singular point where you had to make decisions.
Like this is where the release gets done.
Break this away into actually a matrix across time.
So you have plenty of time and space.
You remove the overhead of managing the open source release part and can focus on development.
And that's very important because that's where really the fun is.
On the other hand, the tail part is that of course users really like and enjoy having stable Java releases to work with.
Because one of the defining features of the platform is its stability, reliability and predictability.
So we at Oracle offer commercial support for long term support releases.
And we're not the only ones.
So the many others in the community.
And so this model basically allows both development to happen very quickly, but also allows commercial users, for example, to actually invest into the platform.
And then get security updates and critical fixes and sometimes even more.
But typically that's the focus of the platform.
And when we did this six years ago, there was a lot of skepticism.
Both internally, so at Oracle, also internally in the wider OpenJT community, because it sounded like a lot more work actually to release every six months.
I mean, we knew how releases were.
They were long and painful and never shipped on time.
Right.
So that was weird.
For example, we feared at Oracle, we would end up having releases with nothing to do with the ship.
Will we actually have marquee features every six months?
Is that going to matter?
Well, change changes hard.
We fear change.
But also in the broader ecosystem, people were skeptical.
So you're doing a release every six months.
I mean, are they going to be any good?
Isn't Java 8 what everything everybody ever will need?
Why do more Java releases at all?
I mean, so isn't like, are we going to take over the world?
Yeah, so that didn't quite happen.
But nevertheless, so change is hard.
And so people were really wondering about being overwhelmed and worried.
And the one way how you actually fix this too, well, do the cultural change and show that it works.
And so we had to change our mentality.
We developed the JDK to switch our mindsets, to basically go away from the way things were done before,
to learning to embrace this change and not to panic about missing a train.
It's okay.
There is an excellent.
It's almost like the trains in Belgium, which seem to run fine,
contrast to where I come from.
There's always an excellent.
We don't try to overdo the tail.
We don't try to backport everything to the JDK updates project.
We just backport what we believe needs to be backported.
So just the specific fixes required for security and stability,
maybe platform support, maybe every now and then there is something weird like new character sets
or some data time updates that have to be done.
But that's roughly it.
We don't try to make Java 8 in open JDK be the same as Java 21 because it's not.
It's not going to be.
People who use Java 8 don't care about it being Java 21.
And so this lets us, to philosophy, of breaking down this big, big feature,
the small, tiny elements that can be delivered in six months increments
and removes a lot of the release management process to a point where it's basically invisible.
And things just flow along as they should be.
And so this has worked out better than we hoped.
The time for releases was slashed.
The effort it took as well.
The amount of work that had to be done on backports went significantly down as well.
In particular, one thing that we embraced was the change of leadership in backports.
Because back in the day, when it started doing JDK updates in 2011,
we used to do those for many, many years with the Oracle Open JDK maintainer team.
We delivered Java 6 updates for, I think, six years, Java 7 for five years.
I think eight, also for four or five years, I'm not sure.
And so once we move to this faster release cadence, we're clear to us,
we can't just keep doing like five years of updates on every six months.
That's just impossible. It makes no sense.
Nobody's going to embrace every one of those all the time.
So what we did instead was to move to a model of actually transitioning responsibility in the community for the updates.
Where the Oracle maintainer team now takes care of the updates for the first six months.
But then we passed on the responsibility of those in our community who are capable
and willing of maintaining release further.
Like Andrew over there did for eight and eleven.
It still does.
So if you want to hear painful stories asking later,
and others like Severing will do for 21.
And this is also a painful thing to do in the community because giving our responsibility requires, you know, courage.
But we're fortunate enough to have been working as a community together for a long time now
that we've built up the trust actually in processes to make this work well.
And I think they do.
It also lets us deliver on the Java itself in JDK itself more features faster, which is great.
It makes developers happy.
And this of course, it makes all our customers happy.
JDK developers are happier because they have to spend so much time in their management.
And so everybody benefits.
And so we keep delivering features.
In 21, as my colleague Aurelio Garcia de Ribeiro from Port of Management Team,
says we have four buckets that the features happen into like language and libraries,
performance and housekeeping and stuff.
There is something for everyone, right?
In the prior JDK release, there is even a bit more stuff that came in through this model.
And if you compare with 11, there's actually a ton of stuff that happened in the past,
in the past two LTS releases that is coming to the platform through this very, very quick development model.
And all together, like, you know, the time between 11 and 21 isn't that much longer than like an old release would have been overall.
So this model not just works well in delivering stuff, it delivers a mass of things.
And it delivers so predictably and regularly.
And that's what makes it great.
Then another thing that's important, four years ago, when we were here,
we had the open JDK Commitus Workshop in Brussels where we talked about our tooling.
We had just been going through the progress to update our tooling for JDK development
to move the social management from the material systems that we used and hosted over to GitHub.
That's now Microsoft hosts and pretty much everybody uses.
And that, of course, was also a change that required a bit of courage and also provided opportunity to define tooling that makes our jobs easier
and that helps us manage the JDK coding changes coming in and keeps helping us.
And we keep updating this tooling to help us with backpours and so on.
And so this is a powerful thing.
It's not just about the mindset, it's about embracing the tooling to actually change the things you do under the hood
and to use the power of computers to make working on the computers easier.
And so these days, Open JDK on GitHub is a pretty massive project.
It has around, I think, 120 repositories, around 500 people participating.
And most importantly, the past four years have been the four years with the most changes going into Open JDK ever in four-year terms,
which is like one US presidency, just saying.
So 2020, Trump was president, right?
So it's also the change that led to pretty much most Open JDK contributors coming into the community
because, of course, joining us through GitHub has been much easier than learning an unfamiliar code system
and trying to work around the industries of a very different contribution path for most of the other open source projects.
So that has helped us move Open JDK forward as fast as it was.
So what's the actual change that happened in the past four years then overall?
Well, we've got faster and better at delivering the JDK.
Java has been back in 2020 before the pandemic, one of the top choices for developers for programming up there in the upper top right corner.
And in the last survey from Red Monk for programming languages rankings,
it has remained in the top right hand corner as one of the most popular choices for developers on GitHub and on Stack Overflow.
I'm not so much so sure about Stack Overflow anymore because I think that's mostly a training site for generative AI these days.
But, you know, the GitHub numbers I think are still fairly valid and the GitHub service also very out of cover.
Java is very popular and frankly rightly so because we keep as a community making it better and moving forward.
And just to, as a point of that, in our JDK release blocks that Sherat, one of my colleagues writes,
we have this wonderful slides of the contributions into Open JDK tip from since JDK 11 to 21.
So it's like 10 JDK releases, like five years development.
And of course you can see there is a big red block of Oracle as Java stewards.
We do a lot, we have to do a lot, right?
But it's not just Oracle. There's a lot of other parties participating and moving Java forward together.
And one aspect I really want to emphasize here is that this little blue block over there, that's the independent developers.
That are not affiliated with Oracle, or Red Hat, or SAP.
So those are people who don't work for any of these big companies.
And they have, thanks to the move to GitHub, among other things, and now move so far forward in the contribution queue
to actually make up, I think, the fourth largest block of contributors.
And that's great. I mean, that tells you that we're doing something right in this community.
So thank you to all of you who have actually contributed in the past.
And hopefully we'll see a few of you join us and do interesting things in the next year.
And speaking of interesting things, we have a bunch of projects going on in the community that are active, like Loom,
with Ellen, talking about later, like ZGC, a garbage collector, Panama, Amber, for language changes,
LIDEN, where we work on basically time shifting and time machines and other wonderful things for Java technology.
The Valhalla to make the JVM much faster and simpler, and Babylon to make the Java more suitable for other weird deployment targets
like GPUs. So we do a lot of weird things, fascinating things.
And in particular, these are things where your feedback is very welcome, where your testing effort is very welcome,
where your ideas are welcome. We can actually make a difference.
It's much easier to make a difference than, say, if you were trying to contribute to a JDK Update project,
which is a bit of a meat grinder. I'll tell you that in a few minutes and why it is.
But nevertheless, this is where you can really do stuff and have fun doing some.
And to talk about these projects, in this very dev room, we'll have today myself and Jonathan.
Jonathan Dowland. Yeah.
Over there, talking about JDK Updates at 11.05 and at 16.40.
We'll have Roman Kenke over here talking about Lily Puth at 11.55.
We'll have Maurizio Cimadabare talking about Project Panama.
We'll have Alan Bateman talking about Project Loom.
We'll have Phil, we just saw on the stage over there, talking about Project Wayfield along with Alexei and Niels.
And we'll have Johannes over there talking about some of the work that's going on in the House spot on Save Points.
So you have a chance to meet many of the people who work on the JDK here.
If you haven't met him before, look around and ask around.
You may be holding up your Chippewa review, as was in my case.
Otherwise, enjoy the day, I would say.
And thank you for coming and thank you for being a part of this community.
So this gives us five minutes to shuffle rooms if you want to, and then we move on with the next one.