Jakarta EE JakartaOne Livestream 2020, 9 Dec 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Jakarta EE 10 Round Table | JakartaOne Livestream 2020

Description

Moderator Otavio Santana is joined by Steve Millidge, Kevin Sutter, Dmitry Kornilov, David Blevins and Scott Stark to discuss the roadmap for Jakarta EE 10

Jakarta EE 8 has been delivered and Jakarta EE 9 is well on the way. This is a perfect time to begin exploring the horizons of Jakarta EE 10. This panel discussion brings together the likes of Payara, Oracle, IBM, Tomitribe, and community leadership at large to begin gazing into the crystal ball together! Come along and bring your thinking cap with you - there will be plenty of opportunities for you to interact first hand with the panel!

Get Social!

Website: jakarta.ee
Subscribe: https://www.youtube.com/user/EclipseFdn
Follow us on Twitter: https://twitter.com/JakartaEE
Like us on Facebook: https://www.facebook.com/JakartaEE/
Join us on LinkedIn: https://www.linkedin.com/groups/13597
Tag us: #JakartaEE

A

Yes, we are live here to talk, talk more about the future of jakarta ie right, so I'm here with amazing guests to talk about why going on next right, uh my name is otami santana and to celebrate the jakarta e9. I do what I love to do. I play a little bit of piano. I drank my favorite drink, coconut water and yes, I danced some brazilian music.

A

How about you david? How are you please introduce yourself? Please tell us: what do you do to celebrate today.

B

um Yeah well so I'm david levins and uh you know what I'm doing to celebrate today is work on tommy. You know, I think I think I think we all work on the release quite a bit, uh steve included. You know everybody works on the release and then, when these releases are done, we all go work on our implementations because we got a lot of work to do there. So that's uh that's the celebration, so we've earned our way to that uh that honor.

A

Okay: okay: okay, kevin! How are you so.

C

Pleased good thanks, so I I don't really have anything really planned for today to celebrate either we did have uh an earlier. We had an all hands meeting at ibm, and so this came up during that and um I talked about how the you know: ducati 9 release happened in november and we're celebrating today and we've got several sessions all day today. So that's about it.

A

Okay, hello, scott: how are you.

C

Good. Thank you.

A

So please introduce yourself and then tell us to the whole audience. What did you do to celebrate? The new version of jakarta e.

D

um I'm scott stark um senior director of the software development at red hat, primarily the jboss division. um Today, I'm planning on going bowling in merida mexico for a celebration.

A

That sounds exciting. So, okay, let's go.

B

To the next one, in a way you got to take one pin away: isn't there 10 there by by by default, see yeah you gotta remove one pin, so it's all nine. It's fine with me.

A

Okay, let's go to the next one, see if okay, that's easy steve, I can see a little a bottle behind you, probably wine and it's empty. Therefore,.

E

A

E

It is so I'm steve millage, I'm the founder of piara. So after this I think I'll be going out for a puncher. I think in I'm in portugal. So I also go up some puncher. I've done three sessions, so I'm ready for some drink.

A

Yes, finally, hello dmitry, hey.

F

Today, yeah I'm doing well it's evening already. So if you ask me about the celebration in jakarta e9 right, so it has to be some nine things to do, but I'm not going to open nine bottles of wine it's too much, but a little bit. I will open something I will drink a little bit. I remember this year. It was a nice year uh related to jakarta, e9, uh possibly only magic after night, but anyway that's another story uh so yeah I will celebrate somehow.

A

Okay, how about playing nine different music with the guitar behind you.

B

That's something you need to do a jakarta band because I mean you got the piano covered. I could go guitar creature bass. Is there drummer here.

F

uh You know I I actually can't hear a lot of echo. uh Is it only me or everybody hear it.

A

Okay, guys there is a account round roundtable that four, you can put your question here to this amazing guest answer to you so right now we have one hour of the more expensive console time right. We have red hat, ibm oracle, everybody just one place to answer your question. Please go ahead.

A

Yeah, probably they do more code better. They do better code than play some music, and but anyway we got some questions from twitter. Let's go the the first one. How is the jakarta e future is going? How about jakarta e 9 uh 9.1.

C

Okay, I'll I'll respond to that one. um So we we've started that discussion. I put together uh google doc to try to get input on 9.1 and I think, based on the replies, I've gotten so far in the comments, I think we're all pretty much in agreement that we want a limited 9.1. We want the java se11 support, that's the goal for 9.1 and um and also to clean up the corba and rmi iiop um situation.

C

I mean we tried to do a good portion of that cleanup in jakarta e9, but there's still a little bit more work. That needs to be done, so um I I think we're pretty much on the same page. Now we just have to get that kind of finalized into a real release plan and then get that out to you know the community for further review and comments, but um at least it wasn't way off the board. When I opened up that google doc, I think uh the comments were pretty much in line, so that was.

B

Good yeah- and I think I would just add that, like in terms of just straight up new features, um we might not see too many in uh 9.1 or any, uh but we are definitely open to doing. um You know a number of point releases if pop you know if the community comes up with new features and a specification and release them that will have the bigger impact on on what is the next release of maybe a 9.2 with some new features, uh it may be a 10 with new features, but either way.

B

Now is the time for us to develop new features.

B

So uh you know if you want to get involved in the specification projects we've been saying in the past, you know hold on wait, hold on wait, we're almost there now we're there, uh and so you know definitely do get involved in the projects uh and they will dictate the real timeline and the real.

B

You know when these things show up so.

A

Oh by the way, everybody you have the option to put priority in your question. So if you have any questions you enjoy, you can vote. Therefore there will be a we can do the question. First then another questions right. So please vote if you enjoy any kind of question in the session. Okay. So let's go to this next one. So this question comes from edufa.

A

uh He currently sees a lot of frameworks such as jakarta, microprofile, spring and quakers, and the question was about: is there any kind of synergy between jakarta and kwaku's? Is there any plan to put quakers together with jakarta e.

D

Well, I'll take that um so a general issue that we have to deal with in jakarta, ee and microprofile.

D

Is this discussion around what the ee10 roadmap is going to look like and how those two projects are going to interoperate or you know, collaborate and you know, help have a more unified cloud native environment, and so I think one of the things that we've started to talk about in the steering committee is the notion of a cloud for a cloud for native java alliance. That's going to you know potentially take any working group, that's interested in cloud native java and define how those specifications under that pseudo umbrella.

D

It's not going to be a formal legal structure, but some kind of agreement. You know how do we align technically? How do we align and marketing wise, etc? And so one of those things that we'll have to deal with is you know how does micro profile in jakarta coexist and interoperate and relate, etc?

D

And obviously that's where corkus will fit in? Is you know, in terms of ideally we'd like to see a new, smaller profile in jakarta? That's specifically targeting the dependencies of microprofile and then corcus would be one of the implementations that builds on them. For example,.

B

I would definitely love to see a headless version of youtube with no ui technologies at all and.

D

B

You know just attacking.

D

Yeah and well the other twist there with quarkus and things like micronaut um and grail are, you know, actually have an aot oriented versions of those platforms as well, which is another new component. We really haven't addressed in jakarta yet, but that is you know a main feature. That's showing up in cloud cloud.

D

A

Okay: okay: let's go to the next question uh from thiago and hiki hopner, I guess he's a brazilian. How is the progress of using java se11 across all the implementations.

B

Well, we support se11. Already we put a lot of work into that in 2019 and and so that support has been there for a while. We have people deployed on uh sc 11 that we commercially support.

B

um So you know we're there that the tck itself has work to do to run on se11 uh and so there's there's work. We have to do in 9.1 for that, as kevin alluded to, and I guess other people can comment on their their status on 11.

E

Yeah I can cover so payara supports se11, uh both in server and micro. It has for a while uh for the glass fish side that will be aligned with uh jakarta e 9.1. So I think fujitsu have done a lot of that work already. It just needs to be brought up to speed with the latest classfish six.

C

Oh open liberty is in the same boat with supporting java 11 and that's been been in place for a couple years anyway and, like david said, we can't say that we're compliant yet because the tck still needs a little bit of work but um running wise. We we run with javasc 11, just fine.

F

Yeah, I can say the same for oracle products. You can run biblogic on java c11 and we also have hilidon, which is java, c11 uses as a minimum version of java, so it's 11 plus. Basically, so it looks like all of the products I can't say most. I think all of them are actually java c11 compatible across all winners.

D

Yeah data wildfire runs that way, so so our focus certainly is going to be on getting the tck running and also trying to uh kickstart. Some of the efforts we've been talking about that other speakers have alluded to is trying to uh partition the tck and get that in a little better shape for future releases. So I I don't know how much we can get done for 9.1, though.

A

Okay, we have a good one from anu sampath. How jakarta is going to embrace reactive.

A

C

What what kind of programming was that reactive or reactive, okay,.

F

No, that's it's! It's actually good question so jakarta itself, the api style, the development experience of jakarta is not really reactive right, so the reactive programmer style is not supported by jakarta and to be fair, uh I didn't see any attempts to bring uh a reactive parrot, diego itself, into jakarta e right. So uh if there are some ideas about that, if someone wants to bring it, so you can try it. You can kind of. You know talk with us and you can um contribute it. Let's put it this way.

F

On the other hand, where I plenty of frameworks out of jakarta but supporting microprofile, let's put it this way with support reactive programming right. uh You can, for instance, take a look at helidom which supports micro profile and, at the other hand, as a another. Flavor supports reactive programming and I'm sure quarkus does the same thing.

D

Yeah we we'd rather see the reactive apis first show up in micro profile, and then you know once they have a proven thing. You know like, for example, one thing might be cloud events or something like that that makes sense to pull into the enterprise, but really we really need to see it manifest, and certainly we need uh the demand from our customers which, to this point you know, if they're going to do that, they're going off to uh the platform like micro profile.

D

I don't know that we would advocate pushing that into jakarta at this.

A

Point: okay: let's go to the next question: how do you think microprofile can be aligned with jakarta e.

B

Well I'll comment on this one just because I think people misunderstand the the goals right. So when we launched off micro profile, we were not ever we were not.

B

We were imagining this as complementary from the get-go and that the jcp would still be holding java ee uh and our our our kind of perspective on it on that time, and still is that we always needed a place where we can collaborate uh and try to evolve in a in a way that is kind of rapid and experimental and sacrificing backwards.

B

Compatibility to make that happen if necessary, right and so basically micro profile is a project no different than say spring uh or or any other type of open source project that delivers libraries for people to use in. In that regard, we try to keep things stable. We may change things once in a while in a way, that's backwards and compatible uh and therefore having jaccard ee be dependent on micro profile. Apis is as difficult as having jaccard ee be dependent on spring apis right. There's there just because we happen to be the same.

B

People doesn't make it technically any easier to take something that doesn't have a 20-year backups compatibility guarantee and put it into something that does have a 20-year back or compatibility guaranteed, not quite 20 years. We haven't discussed it, but that's what it's worked out to be so far, um and so there's technical challenges there and when I say technical challenges I mean we would have to decide not to keep doing.

B

This will work fast and rapid, and if we need to break things, it's okay we'd have to uh completely abandon that tenant tenant in micro profile to take the apis as is and just move them and make them used in jakarta. So there's a challenge there and you know solutions to it could be uh make a jakarta version of the api um we sort of went that way. When we initiated a config jsr, there was going to be a config jsr under the jobx namespace that was based upon microprofile config.

B

That is absolutely one of the ways we can handle this. It's a community discussion, but just so we're clear, as is micro profile and card ee, have different backwards compatibility goals.

B

For the sake of innovation, so you know, let's make sure to understand that they're technically not aligned in that regard. You know that doesn't mean that ideas can't flow from micro profile into cardi. In some way, we just need to figure that out.

C

The other thing that I'd like to expand on there a little bit is, you know: microprofile. We recently became a working group, which then also um implies or required that we follow a derivative of the eclipse foundation specification process so now that we microprofile now that we will be generating specifications that are compliant with the efsp and jakarta ee does the same thing now. There is some more synergy that could happen between those two projects and before microprofile became a member or created this working group. That was not possible so that that is one item.

C

You know what one of the work items that happened in 2020 that will allow us to work together in the future.

D

Yeah I mean what we'd like to see happen. I mean I mentioned we'd like to see a new micro profile or a lighter profile. Let's call the light profile that you know centers on the dependencies that micro profile currently has and then pulls in things like config, that a little more mature. But then there is the big question of exactly how those specs evolve and develop and are are put out, but you know in conjunction with that. I'd also like to see the that profile actually release independently of any other profiles.

D

The web profile, the full profile we even like to see something: we've we've coined an enterprise profile that is targeted toward backward compatibility and transformation of ee8 and earlier applications as a notion that we help standardize. So there's a consistent, you know notion of how do I take a legacy. Application actually run it on a newer, a newer runtime, for example,.

F

A little bit to add to that conversation uh about jakarta and micro profile relationship. uh Currently uh how I see it uh currently micro profile supports only jakarta ee-8, which is still java, x, name namespace. So I think that the first step uh to uh kind of uh copyright uh you know these two projects would be uh to add uh support of the latest jakarta version, which is in jakarta namespace to microprofile.

F

I guess that it's in the plans, uh uh but it may happen only the next year uh at the jakarta e-10 time frame, possibly and when mac micro profile supports uh decartified apis uh it will. It would be easier to kind of do more integrations and investors.

E

So yeah, I'm just gonna, add that uh so to cut my profile actually sits on top of jakarta he's not a platform in its own right. It's got cartoony as the as the baseline, so as dimitri says, first thing is actually aligning keeping that aligned with carter as dakar tree moves forward. I think some bits of microprofile may move into different specifications.

E

So there's been talk about bits of fault, tolerance like async, asynchronous and bulkhead could probably more likely live in uh to cut a concurrency uh things like that may happen, and as things stabilize you know, maybe we move them into jakarta e. Maybe we keep them where they are, but it ultimately is aligned uh as it's as it's based on top of jakarta. At the end of the day,.

B

Yeah- and a key thing to mention is that uh pretty much all of us have a platform that has micro profile and jakarta in the same box: shipping together right, so they're they're, not in any way prevent you're, not in any way prevented from using both of them in the same box.

B

So in a lot of regards, when will they get aligned is sort of they're already shipped de facto by everybody together and when we're doing our bytecode transformations to produce jakarta ee9, you know tommy9, it contains micro profile and all the apis have been micro transformed to be jakarta apis, so we're even transforming our micro profile implementations to upgrade them to jakarta. Namespace.

B

um It's really just a matter of could a spec from jakarta ee depend on a spec from micro profile and a critical question to people really who ask that question? When are they going to be aligned? um Would you be okay with eliminating the backwards compatibility guarantee in jakarta ee, because that may happen? As you know, it may be that people decide all right. We want some uh of what that fun micro profile thing is going on there and that results in backwards and compatibility in in jakarta. Is that what you do you want that?

B

Because you know, if we push this conversation uh um in a certain direction, that may be one of the outcomes right, so you know. Definitely let us know if that is important to you right. Do you need the kind of factors compatibility guarantee we've been offering over the last 20 years.

A

Yeah, that's a nice opportunity to remember, follow jakarta ee and twitter facebook. I guess no instagram right. Nobody use instagram right now, I'm not sure uh I'm not young anymore, so I'm but anyway follow us on twitter, facebook, email list- and here comes the next question. So what tools are available for developers looking for help with the immigration between javax to jakarta.

E

C

E

I was going to say that, to be honest, takata is a runtime. It's probably a runtime problem uh to migrate a lot of these applications or support backwards. Compatibility to these applications so from a lot of the presentations I've seen implemented, implementations like payara will support both javax and jakarta and then allow them to run on on newer uh runtimes.

E

I think then, other tooling vendors will need to step up and and work out how they move their tooling.

B

Yeah we're doing the same thing as steve mentioned is we're attempting to support both of those uh from the same code base, um and you know just because it's way I wouldn't say it's easier for us to uh do the bytecode transformations on our server versus you doing it on your applications, because it's not easy to do the bytecode transformation on our server.

B

We have to put a lot of work into it, but we can catch all the edge cases in our stuff a lot easier than it is for every individual user to have to catch all the edge cases. So we think by code, transforming transforming to create effectively two servers. A java x server and a jakarta server is probably the easiest way for everyone to move forward, uh at least for the set for several years, uh and the eclipse transformer is the the key to that.

B

So that's the tool uh I did mention briefly in the industry keynote. We have a tommy patch plugin that actually will allow you to go and replace an individual java file, uh and- and so you can actually add, if else blocks and other things where simple bytecode transformation isn't possible. So that's been critical for us as well, so we can patch individual files and and change the logic just slightly to handle.

B

You know, string, name, spaces and things like that, but uh I hope.

E

That gets near the.

B

C

Well, the other thing that you know, I think we've all talked about how the transformer has been used in our application servers runtimes, but the transformer can also be used for applications that are just looking to experiment with the new namespace and we even we use a transformer on the early versions of the pck. So we took the whole jacardi eight tck and ran that through the transformer, and we had an early version before we had ducati e9 tck. So it is.

C

It is something that you could do for test cases or applications uh if you're looking to get started with it with the new name, space.

D

Right and you can even integrate it into uh you- know your build chain. So, for example, we have uh an alpha version of quarkx where we're actually building native binaries that are utilizing the transformer to transform both the quarkus components, as well as your application uh in in the quarkus build chain to produce a native image that supports that.

B

Yeah, I guess I'll add to that- that we do use the transformer uh on our examples in in the tommy repo we have about like 180 different examples all in java x and each one of them has the eclipse transformer plug-in, maven plug-in hooked up into it, and we do produce a jakarta version of that same example that those do run. So uh you know you can easily get 95 of what you're aiming at accomplished with the eclipse transformer yep.

A

Okay, that's time to talk about future trends. We got a question for sagi. Is there any proper way to deploy jakarta applications, and is there any trends or recommendations to deploy this application, such as containers, for example,.

B

Can you say that again, I didn't quite understand.

A

Is there any proper way to deploy jakarta e application, and is there any trends or recommendations to deploy this kind of application? For example, using containers.

D

Well, certainly, the cloud native deployments are becoming more important and I think everyone has spoken to that at various points today. So certainly that's one piece that we're focusing on with the quarkus toolchain. You still have the legacy applications that are run as monoliths in you know, personal club or private clouds as well. As you know, traditional hosted servers. I mean that's going to continue to be a mainstay for jakarta for a while, but you know I do think that's part of that cloud native initiative or cloud cloud data for job initiative and alliance.

D

I think we need to focus on, and now we come up with standards and uh patterns for supporting that a little better.

E

I think one of the beauties about carter e is that there isn't one standard way of deploying a jakarta application. So jakarta gives you a package packaging which is a wall file or an air file, and you can deploy that into a power micro running on a docker container or you could deploy it into a traditional.

E

You know six node server cluster in a data center or even you know some of the implementation support mainframes. So I think that's one of the the beauties of jakarta is that there isn't an answer to that question.

B

Yeah it's one of those. It's always kind of laugh a little bit when I hear the question not that it's a bad question, but basically from the beginning of java ee, it's been uh designed to be agnostic of the runtime, so you write an app that is no way bound to the runtime, and so therefore the runtime can exist in any form factor. That's imaginable. It could be a cloud, it could be a raspberry pi. It could be whatever you want.

B

Your application is not in any way impacted you can deploy on all of those and then later on in you know like the late 2010s, you know the 2010 range, the cloud computing started to become popular and then people immediately turned around said hey.

B

When are you going to do that thing that you've been doing the last 10 years and uh and it's sort of like we already had that covered right and we didn't have to change anything to enable cloud uh for ee, and you know, there's gelastic and azu and azure and uh beanstalk, and all these things that support ee implementations in the cloud and so they've been around for a very long time, and the right answer is whatever you want to do right, you could bundle it all up in the server you could ship them as one unit.

B

You could do your app separately. You could put them in a docker container kubernetes. All these things are possible. You're, not limited in any way.

A

Oh hello, arjun: how are you so? Let's go to the next question uh from arjun qing. One of the major proposed themes in jakarta is the cdi alignment make many other apis. For example, java server face to use cdi.

A

However, the largest question to ancient cdi to go to start starting point, for example cdi light. What do you think about this? You go to cdi lights. Should you should we go to cdi alignment.

D

Well, that that's a conversation that we're just starting to have so the fundamental issue or the the point of change for cdi light. Is it's focused on ahead of time compilation, so it's focused on producing native images and removing some of the implicit and explicit requirements or expectations for runtime analysis of a deployment.

D

So that's a big discussion that we have to have, and we have to get straight, is I mean? Is there going to be? Basically, a new spec that that cdi is focused on aot is, is the relation it's kind of the same thing microprofile and java? We have a new paradigm with this aot compilation.

D

How are we going to integrate it into both jaccard and microprofile? Cdi has started that conversation and that's what that's the conversation that we're having right now on the cdi dev list. Is you know what does cdi like mean?

D

What's the relationship to the legacy apis, I think it's kind of orthogonal that other specs make more use of cdi in the client facing applications because realize the build time uh apis that we're talking about are traditionally what people use for integration of the implementations. It's not really what the the api or the components in an application make use of.

B

Yeah I'll add on that. I think that there's some opportunity to have a discussion on whether some things could be moved out of cdi into their respective specs, like the basically ejb requirements in cdi, probably could be moved into the computer.

D

Well, I'm advocating that's a necessity, a necessity, because right now that was a huge problem with uh you know putting a release hours. You basically have circularity with respect to the tcks and so part of the tck work. That's something I think absolutely needs to be.

F

Done let me have my two cents here. All right, so uh uh what's cart was saying, is absolutely right. So a cdi light profile. As I see it is uh basically needed to produce native images cdis itself using a lot of runtime operations, and especially cdi extensions, are not really compatible by building native images and ahead of time compilation by design right. So it's not possible to do it.

F

So the idea is to introduce the lowest level lowest level cdi profile, which supports ahead of time, compilation which supports a special kind of extensions which are not the same as portable extensions now, but possibly uh portable. uh This. This new extension may behave as portable exter instantious as it is now, so there is a discussion going on at the moment right and uh uh at least uh the understanding. The idea is.

F

What I have in my mind is that cdi light profile is for lightweight frameworks like carcasses like helidones and so on and full cdi profile, which is enterprise profile which exists. Now there are two profiles right cdi, sc cdi enterprise edition um this ee profile of cgi will still exist and uh its main uh consumer. Let's put it this way: is uh jakarta e right, jakarta specifications and uh about cdi alignment right? Well, uh it's definitely needed because uh it's better to have one injection mechanism uh used by all specifications.

F

It becomes easier to use, uh for instance, currently in jax arrest, where different injection mechanism.

F

Designed by jacksonville itself right- and it supports cdi too, so it becomes a little bit of a mess right- that using two injection mechanisms and one specs and one's back so uh cdi alignment will eliminate that and it will make one universal injection mechanism across all the specs. So it's definitely good stuff to do. But a discussion is ongoing right.

F

So if you folks want to participate in the discussion join uh cdi made in list- and there are going to be some even meetings uh to you know if you have some opinion, if you have something to share, uh join the discussion and write in everyone.

D

Yeah, I actually posted the the mailing list, uh what I call it, what were you joined where you gonna join, and there is actually going to be a meeting next tuesday, where uh some of the implementers who are been starting. This discussion will will talk about it. Some more.

B

And uh thank you, ariane for the question. By the way everyone mispronounces his name, they always say arjon, it's aryan. As I understand it, so uh you know you're gonna you, everybody sees his name. A ton and you've always probably wondered how to pronounce it there. It is he's an awesome guy.

A

um Thank you david. You correct me.

D

F

A

I I have the feeling, because, usually nobody speak, my name correctly. You.

B

Get called tavios on such a regular basis as people added to your name, yeah, exactly.

E

B

A

But anyway, there's a good question from kiko. Is there any feature to jsf in the next jakarti versions?.

B

Well, probably, ariane would be the guy to answer that question. Yeah.

C

Or- or I see that that is out there too, so he might have a view on that as well.

D

It's definitely it's definitely. A community ariane does in fact already have a message saying it's still evolving. So there you go.

E

Yeah the point for that is that there's actually the specification projects that drive that forward, not not us as vendors, so are in leading that specification. Therefore, you know he can drive forward jsf, it's not it's not like. We repre predetermine this. It's the community that will drive forward to specifications.

B

Yeah yeah, I mean that's like the stock answer is when people say you know, will this be in there? It's like you tell me. Are you going to work on that? You know because if so then, yes, right, that's as simple as that.

A

Okay, just for my minutes left, I got one question here: jakarta is implementation first, but what does that mean.

B

It means that we can't release the specification unless there is an implementation at minimum right. It can mean a lot more other things, but that's like the bare bones can't get past that requirement.

B

um You know, so we have to have an implementation there. Before we can ship a specification, we can't ship a specification that uh doesn't yet have an implementation. Maybe hopefully someday will that's just not what we do so so that's the bear. That's the minimum definition.

A

Okay, nice, unfortunately, just three minutes left that was amazing conversation round table and to last question for sure need to talk about the future, a question to everybody: what respect to the future.

B

In three minutes.

C

B

A lot of a lot more fun features and uh a hundred new community committers to all the specification projects.

C

So one thing I'd like to point out and david- and I were just having a conversation about this yesterday- is having all of this in the open is such a big big plus I mean having the tcks available, we're able to look at them, discuss how everybody is passing or not passing certain tests and we're doing this in the open. It's just it's fantastic.

F

Talking about features, I would like to mention that, for instance, in jason b uh we have a list of features. We are planning to add to the new version of the spec, it's public. It's me now issues tracker there. There are quite nice features.

F

uh We are playing into f, so just take a look, uh jason, p, jason proceeding also has, and these two features it's much smaller, but uh there is something interesting, definitely to take a look again uh and uh talking about jax rs uh that these folks already had a list of features a year ago, which we want to add right and then somewhere in public published too.

F

uh So again, uh you folks, who want to contribute, who think that some piece, some other pictures are needed, feel free to check the teachers feel free to contribute your own ideas to the specs and uh contribute.

B

F

And without you, without you, without your ideas, um nothing will happen. So I'm inviting everyone to participate.

B

Yeah, exactly what kevin and denuclear said you know, I'll be blunt. We already had access to all the specifications as vendors over the last 20 years, so we're not gaining anything new by this openness we're so excited because it allows all of you to participate on equal footing to us in a way that has never been possible. Please do that right. We're excited about this openness because it brings you to the table.

B

Please take advantage, we're begging! You come make. This be the community that we want right.

A

Steve scott final.

E

Word, I would just reinforce that. Really it's it's getting involved, it's the openness and what I'm hoping for is a whole flood of brilliant ideas to appear on github issues on various specifications and I'd be happy to go away and implement them. I definitely don't want to dream them all up.

D

Well, I I think what I would add is our focus is really going to be on defining the platform and pro new platforms and profiles to understand how uh you know these new things like iot and micro profile fitted together. um uh We really have to have some management actually put the profile specs out. You know to have a consistent platform, so um that will be our focus.

A

Thank you. Everybody see you in the next session bye bye that.

E

A