Thank you very much.
And now let's get going with the next one.
Decade of JDK updates in OpenJDK.
Technically it's more than a decade now because we started doing JDK updates in OpenJDK a long, long time ago.
But we'll just stick with the title.
Don't take anything I say here as, I don't know, serious investment device or anything like that.
Just saying I'm talking about code.
So we have 10 years in less than 30 minutes.
Let's go with the prehistory.
We started doing updates in OpenJDK with the OpenJDK 6 project back in 2007.
So, Sun, microsystems, some of you may know it.
OpenSourced Java under OpenJDK back in 2006 for the first parts.
That was the compiler and hotspot.
And then delivered the rest in 2007 in May.
But the rest at the time, well, let me show you.
It was announced to OpenSource in November of 2006.
But then we released Java 6 in December of 2006.
And so, like I said, Sun opened Source the compiler and hotspot.
But there is a lot more to the JDK than the compiler and hotspot.
There's like all the libraries and stuff like that.
And so that wasn't open source until May.
And so Java 6 was released.
But it wasn't open source yet.
Instead, what Sun had released at the time was the in-development version of Java 7.
And of course, it had changes that were different from Java 6
because it's going on for a while developing.
And so, we looked at that.
And in particular, Joe Darcy from Oracle looked at that and said,
this is a problem, let's fix it.
So, he took the code from OpenJDK 7, the development version,
and cut it down again, pare down to the Java 6 specification,
and created the OpenJDK 6 project in 2007 that was based off OpenJDK 7,
which leads us to this wonderful little crazy diagram of how OpenJDK 7 was born.
You know, Java 6, there is builds and stuff,
and then Java 7 development starts, and then 10 builds in,
OpenJDK 7 happens, and then again, like, builds happen and happen and happen,
like 20 of them and all of a sudden.
Oh, yeah, OpenJDK 6, let's do that.
That's a good idea.
And so, we did that, and we did that quite successfully.
For many, many years, Joe Darcy was the project lead for OpenJDK 6.
He then got adopted by distributions, went into Debian, Gen2, Fedora, Red Hat,
Oracle, you know, I guess, whatever else is there.
And so, that was the first time we actually started doing updates for OpenJDK,
for release in the community led by Joe Darcy,
who's been from Oracle, for several years until 2011.
At that time, we then started to, we then shipped JDK 11,
and so Joe then moved on to do other things.
Kelly O'Hare from Oracle took over for a few more years,
and then in 2013, I think, that was the time when Java 6 reached the end of public updates.
And so, at that time, it was also the end of the road for the Oracle maintainers
of OpenJDK 6 in the OpenJDK community,
because once we were done publishing public updates of the Oracle J-Ri,
we were also done, of course, contributing to the open source version of the Java 6 documentation.
And so, what happens next?
Well, people who were using OpenJDK 6 were wondering what's going to happen.
Will you be, I don't know, making us all pay tons of money to get Open Source fixes?
Well, what we did was actually to create a process to have transitions between
maintainers in the open source projects in OpenJDK.
So, just as we transitioned from Joe to Kelly in 2011,
once Kelly stepped down, once we were done contributing to OpenJDK 6,
we then asked in the community, hey, so we're good, we've achieved what we set out to do.
Is there somebody else in the community who has an interest and capability,
very important bit, to maintain OpenJDK 6 project further?
And as often, somebody appeared over there, that's Andrew, and said, yes, let me do it.
And so, we worked with Andrew a bit, and it took over for a couple of years,
and did this job until 2016, and then Andrew was also done maintaining OpenJDK 6
as the lead maintainer as Project Lead, and said, all right, transition time.
Is there anybody else who's willing to take over OpenJDK 6 updates and maintain them going forward?
And then again, somebody else popped up, it was Andrew Brign.
I don't think he's here from Azul, and he kept OpenJDK 6 alive for, I think, three or even,
about three more years.
And so, that means beyond the lifespan of OpenJDK 6, and it was initially sort of planned,
it got extended by the community for a couple more years, actually,
going through different maintainer changes along the way.
And this is something that I think is quite unique to how OpenJDK does things.
In most open source communities, changing maintainers is something that only happens when you get hit by a bus,
or burn out, or whatever you do.
We try to plan for these things, because sharing this possibility makes people grow.
And so, putting people in these leadership roles, actually, it gives them opportunity to just grow personally,
but also to actually do things differently, and maybe even better along the way.
And so, to show you a bit of that, when Java 7 came out,
we decided to actually make OpenJDK the reference limitation for Java.
The platform. So, the specification has a reference limitation,
and before Java 6, there was the Oracle Java 6 limitation.
For Java 7, that's when we started doing the representation as the OpenJDK reference binary.
So, that was good, because it meant that the reference limitation and the ship is OpenJDK 7 was the same thing.
It also meant that, as with 6, with its complicated history of pushing things back and forward while they're different,
and with all these costs that come with that, we could actually start from scratch with 7,
and just do the updates of Oracle Java 7 and OpenJDK simultaneously from the same code base.
So, we could actually not just move to OpenJDK as the official one-time reference limitation for Java 7.
We could actually have a JDK 7 updates project where we developed the JDK 7 updates in the Open,
in the OpenJDK community, and then use those as the basis to deliver the Oracle JDK updates in our case,
or I don't know, Fedora updates or whatever else people did with that.
So, that was a project I started in 2011.
So, basically, I took over from Joe, and we did a few things differently.
So, one of the things we did was we created a new project, which was different from the JDK release project itself,
to be able to develop updates along with their own processes, because update releases are quite different from a JDK release.
Back in the days, as I said before, two to four years for JDK release, big, large projects that have actually culminated in one deliverable.
JDK updates more of a meat grinder.
So, we have a three-monthly release cycle, basically.
We have four CPU updates, critical patch updates per year.
So, that's quite different from releasing like once every few years.
This requires a very different process to accomplish.
And so, that's what we then did, which we changed things quite a bit to make them work both for OpenJDK releases in the community,
but also on the Oracle side of things, so that the Oracle JDK deliver,
deliver could actually benefit from this process, from this code, from contributions, and actually keep contributing back to this model.
And so, we did this, again, for a couple of years.
So, I was the project lead for OpenJDK 7 updates for four years,
and we introduced the concept of a maintainer team, so it wasn't just me doing stuff.
It was a team of four or five people, including Sean Coffey, who is somewhere around here, and Rob McKenna from Oracle.
And we did this for four years, and then again, JDK 7 from Oracle came to its end of public updates, as expected.
And we said, guys, we're done here.
It's just somebody else who would be willing to pick up the work on the updates we've done with the processes we've defined,
and to take this further, if they wish so.
And then somebody was capable of doing that, who has the community scale license and so on and so on,
experience delivering JDK updates.
And again, Andrew Haley appeared.
So, he wasn't completely, I guess, wasted from maintaining OpenJDK 6,
but he embraced the challenge to maintain OpenJDK 7 for a few more years.
So, he did that.
Whereas, in 2020, Andrew was then done and also passed on the torch.
The same thing, as on the main list.
And Andrew Brigham stepped up again and did OpenJDK 7 updates for a bit longer.
And I put the final act to both OpenJDK 6 and OpenJDK 7 updates by doing the votes to actually archive the projects last year.
So, there won't be any more updates to those, because they were basically at that point completely done.
But it shows that we have a model that actually works in distributing responsibility for updates development,
and that actually works in delivering something that's very rare across most open source communities.
Long term maintained versions.
So, and what we do at Oracle, when we were done with 7, we focused on 8, of course, on 8 updates.
So, whenever a new project is created, there is basically a new update train just coming along.
And as I mentioned, Sean was one of the maintainers for OpenJDK 7 updates.
For OpenJDK 8 updates, Sean become the project lead.
So, again, new possibilities, new set of eyes, look at the processes, new set of improvements to make to the process.
And he did.
And so, 8 was, as many of you probably know, a pretty big and significant release.
Not just because of LAMDUS, but also because a lot of people used 8, and probably still use 8.
And we kept adding features in the update project to 8.
So, in 8 Update 20, we added a bunch of features in the VM, and the new port, 8 Update 40,
we added a whole slew of VM features and a bunch of other stuff, Java FX stuff, whatever.
Web views in 8 Update 60.
Every six months, we used to pull in a lot of stuff in the JIDK8 updates project.
And this is the thing that I mentioned before.
That's a lot of work, and maybe it's too much work, because it leads to something that looks a bit like this.
Like a beached whale a bit of a release.
So, you start with the GA, and then you have this huge hump of features.
You just, just one more feature to add.
Just one little more feature to add.
This is one more thing.
And then eventually, after a few years, you know, the whale gets thinner, and at the end, just before you leave,
there's just all these other leftover fixes you want to throw in as the big tail rips down.
And, you know, that can work, but it's very, very stressful over time.
And so, as you see here, every six months, in features, that's probably a good idea.
We should do it for real releases, right?
So, that's what we did for GA's.
And for 8, we all did the same thing.
We transitioned.
Sean was a project lead for a couple of years.
And then, 2019, Oracle's Java 8 went through the end of the public office process.
And again, Sean asked on the list, again, is it Andrew Haley?
Yes, it is.
Andrew Haley stepped up again and became the open dedicated update project lead.
So, that's how it carried on continued, right, for a while.
And now we get to the modern times, which is a wonderful movie with Charlie Chaplin, I think.
But also, what we do in the J.D.C. Update Project.
So, with the modern times, as I said, we have now released every six months,
so we can't really afford to maintain each one of those as the Oracle updates team forever.
Because there is no such thing as the end of the public updates anymore, anyway.
So, what we do, and Rob McKenna is now the project lead for the Update Project,
we have a single project that just does all the updates for J.D.C. Versions after 9.
And in this project, there are repositories for each different update train,
like J.D.C. 11U or J.D.C. 21U or J.D.C. 17U.
And these repositories have repository leads.
And so, at Oracle, we lead the development of the updates for the first six months,
and then we predictably step down, and as somebody else to carry the maintenance burden forward,
if they so wish to do, and are capable of doing so.
And so, the funny thing is, of course, that's not always the case, right?
So, for 9, of course, Rob was a project lead for six months,
and then nobody stepped up, obviously.
Same for 10, and then for 11, hey, Andrew Haley stepped up,
and became the 11 Updates repository lead, and has been so ever since, I think.
Then the same for 12, nobody stepped up.
For 13, then, not an LTS release, but an Azure MTS release,
and the Uranus Terenco stepped up, and was the repository lead for a while,
and then, as we'll stop doing that, and that was the end of J.D.C. 13 Updates,
that's also archived.
The same for 15, but you also stepped up, and then for 17,
the LTS release Andrew stepped up, and still is active, I think.
It's not correct when you said it in I believe.
Oh, yeah, sorry.
I'll fix it, we'll fix it in the post.
Yeah, this lasts from like two years ago, sorry.
I think it's more real, so we'll do 25 for those.
And then for 21, 17 over there is the repository lead.
So we have this model that's, I think, quite unique in the open source world,
but I think works really, really well, because it's on one hand predictable,
you know, when the subcontainer steps down.
On the other hand, it allows others to actually step in,
and continue to maintain a release for as long as they actually feel it's necessary for them.
And that's not easy to pull off.
And as part of that, we also have people who have been working to improve the documentation
on continuity of the updates.
So for example, in our wiki, we have some nice explanations of what it takes to actually
get you fixed into an updates release train.
And one of the funny things, and why I like to talk about process so much,
is that if you set up the playing field right, good things just follow.
And setting the playing field right here has been to actually process-wise get the fixes,
not to happen in the updates project first, but to get them to happen on the feature release first
in the JDK tree itself, where the action is.
And only when they come in there, ready for that, to backport them to the corresponding update release
that they're relevant for.
And this avoids a whole lot of complications around, for example, only having fixes coming in to say 11,
but then as we'll discover, you need them on 17 later.
It just means you take what goes into 22 these days,
and then pull it back to 21, 17, 11, or 8 as applicable.
And that looks a bit complex in ASCII.
That's because it is.
And like I said, because we have a release every three months,
the JDK update project is not the project you usually start out with,
if you try to come up with the open JDK.
It's a meat grinder.
This is basically where the sausage gets made.
And sausage making is never pleasant to watch.
But if you do it right, the results can be very tasty.
Even vegetarian sausages, so no worries.
So, and just as an example how we do it,
we go to GitHub, you can see the pull requests for the updates projects,
and then they'll have corresponding tags on them that explain where they go.
For example, this one has in its title the bug ID.
If you go to the bug ID, you'll find in JIRA and open JDK,
it has a bunch of labels to it.
And the labels actually say for which releases this particular project,
this particular fix is destined.
So for example, this one was supposed to go into 17, into 8, and into 11.
It was requested, and then the maintainer said, yes.
He also said no when the field changes viscose.
So with that, I'll say thank you for helping us make JDK better and working updates.
I would encourage you to come and join us with the open JDK and do stuff with us.
For that, I'll leave you to the other talks.
Thank you.