Jakarta EE Community, 15 Jan 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Jakarta EE 9 Update | 2020-01-15

Description

No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).

A

Everyone happy new year. It seems a long time ago now. I can try and share the screen.

A

Okay, everyone got out. Ok, so I'll give you a quick update on atacar tree 9. Again, I did the same on the last call. It's been Christmas in between, but I'll give you an update of where we are so such Carter e 9 we're calling it a tooling release.

A

The reason for that is, you know we think it's a good good opportunity to update all the specifications for the namespace change without you know, bringing any new specifications at this point and without bringing any other breaking changes to specifications other than the names face change, and this is really to give opportunities for, for you know, tools like IDs to build some tools around moving from dev X to Jakarta also gives people like PI, R and others to explore how we can provide compatibility for old applications that are still running in the name space on our runtimes and the advantage of Jakarta a java re' is it's um managed runtime and them it may give us opportunities to to mitigate some of their namespace change issues and because it will be a stable platform with no other breaking changes.

A

Then your developers out there can also use this as a target for their application migration, so cautery 9 will then give you know, give you that interim release where you can look at how you would change your application up for to Carter e 9. Without you know, any other breaking changes where we are at the moment is just before Christmas. It was a big mad panic to get the release plan out.

A

The release plan now is in voting and I think the boat ends either today or tomorrow, as on sometime this week, and it's looking like most people have voted for and I wanted office. He built it again, so this is likely to go ahead in its current form. So the content in more detail of what we've got is. We are pruning a number of legacy api's from Shekhar tree nine, mainly around XML registries, and things like that.

A

There's more detail in the actual release plan: I've got time to go into each API here, there's also a lot of debate around bringing in api's from SCA which are no longer than SE 11, so xml binding activation web services and through a lot of feedback from the community, we've decided both to bring those into Jakari 9 and move them into the Jakarta namespace, but also then, as a consequence of that, to require Java SE 11 support for platform compatibility.

A

So essentially it was more. It makes more sense to target Java SE 11 if we are bringing in XML binding and activation and web services. Otherwise we would get in a mixed mixed mode with SE 8 and as the base platform individual API is, as I've said on on the slide. They will be released in a format suitable, third use of with JDK 8.

A

So what that essentially means it'll be compiled, JDK 8, source compatible, I mean classifier compatible, so you'll be able to use them in JDK 8, but the actual runtimes that one certification will need certify on Java C 11 we're also following them: the the BIGBANG rename. So everything that is included into cautery 9 will be moved to Jakarta namespace, including, as I said, XML binding and activation.

A

So we're intending to release in a number of phases again, there's a lot of detail in the release plan that we think that goes into waves and which API will be first, but in general, we're looking to get release candidate, API jars with it in the Jakarta namespace onto mavens as soon as possible. So as soon as an api, JA has been moved.

A

The namespace they're able to push out release candidate API jars without going through, like formal review and those sort of things really so that we can get it into the hands of people that want to want to play with these see if they work also to get it into the later API is that come along we'll need obviously something in the Jakarta namespace for all our dependencies so that they can, you know, move their API jars into each card namespace.

A

So we show you could see API jars appearing in maven central pretty soon and each individual spec. Can you know when it's ready? It can release its final at any time. You don't need to wait for the full flap full platform, subject to the normal Eclipse Foundation specification process.

A

Again, Eclipse GlassFish will start soon. As these API release candidates start appearing in maven central also, we do have a staging as well, then you know the Eclipse classics. Project will start picking these up and incorporate them into GlassFish itself, and then, when we've got all of them sort of done, we intend to create a full platform release candidate and that full platform release candidate. Will you know if she called both web profile and full profile include the API jars, a compatible implementation and the tcks?

A

And at that point we will sort of pause and give ourselves a couple of months with a release candidate for people to to bash on it and if there's any problems that would give us a breathing space to fix anything before a final release in 2020 so two months later from from the RC, so that targeting on the moment, q2 2020, that's our target date. We don't know what we don't know so again.

A

Take that date, as as it is, which is where we're aiming for who knows, we will hit early, we may hate late, but the final release loves me include all the spec documents, all the final jars, a compatible implementation, which is a requirement which then passes the TCK, and they prefer hoping to do that in QT 2020.

A

So the project's kicked off. They said the release, planners and vote. People are starting to do work and we're tracking it on a project board and github. This is the URL of the board and there's a number of pull requests already made for quite a lot of the what we call the first wave API jars, which the essentially the API jars were the least dependencies, and this board I think only got set up about a day ago. So it was pretty hot off the press, but progress will be able to followed on that.

A

We do have a stage and repo as well set up called Jakarta OSS got some type to organic and API jaws will appear in there first and then they'll move in to release candidates in to make them central. For you can pick up publicly and so because Dakar tree 9 is now clips were in. You know it's fully open source. You can be part of it. I put some URLs just for reference. So a lot of the conversation around the e9 release in totality you'll happen on the platform list, which is on there.

A

We do have a community list which is just for general. You know, chat around Jakarta and then each individual spec has its own mailing list associated with its project and with its repos on github. We are, you know, looking for people to contribute, you can contribute to code, you can contribute TCK. You can characterize the spec documents which which that someone be going into you on this call. Similarly, you know when the are sees come out. You can start playing with them.

A

Mess with them raise issues on them, I mean fundamentally in the Dakar three years open source. Now, just one final common is that while we do in Jakarta e9, we can also start looking at jakar, 310 and gathering ideas and new features that we want to release as e 10 and they'll. Be you know, the intention for us is to release. You know e turn quite quickly after nine. If we can so the e10 work doesn't have to stop. While we do unite and that's all I've got so back to Tanya.