Jakarta EE JakartaOne Livestream- September 2019, 27 Apr 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Jakarta Concurrency: Present and Future | JakartaOne Livestream - September 2019

Description

Speaker: Steve Millidge

Jakarta Concurrency defines a framework for leveraging concurrency in application components without compromising container integrity. In this talk, learn why we need this specification, its components, where it's headed, and how you can get involved.

///GET SOCIAL!
Subscribe: https://www.youtube.com/user/EclipseFdn
Follow us on Twitter: https://twitter.com/JakartaEE
Follow the conference: https://twitter.com/JakartaOneConf
Like us on Facebook: https://www.facebook.com/JakartaEE/
Become a member of our Jakarta Tech Talks Meetup: https://www.meetup.com/jakartatechtal...
Join us on LinkedIn: https://www.linkedin.com/groups/13597...
Tag us: #JakartaEE #JakartaOneLivestream

A

B

So hello welcome Steve millage back after the industry keynote, so my question is: have you managed to pass the audio certification test? Jakarta is specification you know in between, or you still need some time.

C

We still need some time they take quite a while to run okay.

B

Then the conference takes another eight hours or see what happens? You know? Okay, so you are the power guy of I are actually so. We already had a chat, so I guess it was the very first commit from you we're all right. I.

C

Think so I think so so perfect.

B

So now, let's concurrency and Jakarta, okay.

C

It's over to me. Yes,.

B

C

All right, so this presentation is really looking at Jakarta concurrency, present and future. So I'm, Steve millage as Adam says, I'm, the founder of payara and maybe I did the first commit, maybe I didn't and I'm. Also for my sins, the project lead for the concurrency utilities within e4j and Jakarta one sorry not to cause one to Carter EE, which is me why I drew this straw straw to do this presentation. So what I'm gonna do is I'm gonna, basically look. Why do we need concurrent Jakarta concurrency?

C

What are the main components of Jakarta concurrency? It's quite a small specification and then I'll look at some ideas that perhaps we can do in the future. Obviously now Jakarta ee8 is released, then we need to turn our minds to what happens with Jakarta concurrency going forward, and there are a number of ideas floating around. A lot of them had been stopped cold from the github issues and also just ideas that that we've had under discussion.

C

But this is all really early days and then we'll talk a little bit about how you can get involved with the Jakarta Jakarta concurrency and generally in Jakarta EE how we need to move it forward now.

C

Obviously, today is a momentous day and we've got Carter released and I was heavily involved in gay into Cartier concurrency released, which is a lot of busy work around clips, Jenkins jobs and running it through test Suites and those are things and now that busy works over. We need to turn to what we do next. So why do we need to Carter concurrency, and this will also cover a little bit of review of what obviously, what Java EE concurrency utilities covered.

C

So what is to count concurrency so effectively this a project and specification name for what used to be called jsr 236, which was concurrency utilities for Java EE, which is not a very sexy name, but it came in in Java, EE 7. So it's quite late, there's probably many Java EE applications out there that don't use it at all.

C

It was wasn't updated in Java, EE, 8 and in you know, following the rules of what Jakarta he 80s there's no change into Carter EA tie that other than the Maven coordinates. So the purpose of Jakarta ee 8 was to release something that was effectively binary, compatible with Java 8. So no changes were allowed to api's when we went went from Java, EE 8 to Jakarta 88 and that's similar to concurrency.

C

So the only thing that has changed is we've got op Rev. The version number two one point, one point: two and the Maven coordinates have changed to have the Jakarta namespace. So previously it was Javitz Enterprise concurrent now it's Jakarta Enterprise concurrent and the artifact for the API is Jakarta Enterprise, concurrent API.

C

So most people won't use these because you'll use the Bill of Materials and just pull in the Jakarta e8 maven dependencies, similar as he would do with Java EE, but it has moved if you you know, if you need to do anything with it specifically or you need to, or you want to develop on it, okay, so just summarizing where we are now. So what was the goal of the original Java EE eight specification, so this is actually coming straight out of the spec.

C

So one first goal is to utilize existing in applicable of java re' platform services. So that's a big word to say that you know quick spawning threads or we're not allowed to spawn threads in java re' application server. If we, but if we need to, then we need to be integrated with other Java Java EE platform services, so that would be J and D I transactions, security being able to call EJ B's, be able to you, know, use the CDI CDI beans as well and relate it to that.

C

We obviously want trying the the specification is trying to provide a simple, flexible API that you can use normal concurrency design and the API mirrors the equivalent Java SE API. So the second goal was to allow Java SE develop as a simple migration path. So because, because it mirrors the SE API, we've managed executives and schedule schedule executives. You use them in the same way as you would in a CE platform, but you get all the benefits of Java EE or Jakarta EE from the first point.

C

The second one was to provide component providers and that's the people who basically create applications or iya files, while files, so you can easily add concurrency to your existing applications and therefore it supports very simple, common and advanced concurrency patterns. It's because it's effectively built on Java SE, then it's very familiar from a Java SE world.

C

Okay, so what is a use case? So this is a simple one or a complicated one, depending on your point of view, so be friar to Jakarta concurrency, your java re' concurrency, if you wanted to add an asynchronous break in your application.

C

So, for example, you know if you cut a ecommerce system and it needs to you, generate a list of orders or something and that's going to take a period of time and then that needs to be emailed off or something, and you don't want the user to be sat there waiting for the HTTP request. We finish then, prior to Jakarta concurrency, and the only way to do this was for your servlet or jax-rs or whatever you JB was big to push this through in a JMS queue.

C

So many old Java applications do this and the many old Java applications that he's provide consultancy fall back in the day when I was a consultant used to purely use, JMS broker just to provide an asynchronous break.

C

So if it needed to generate a port, the servlet word or the you know of the JSP or whatever your application would would would basically queue a message on to a JMS queue. It's just finding the details of the report you need to generate.

C

You know all the information returned to the user to say you know, please wait or your report will be sent later and then an MDB would pick that up run some long-running action to generate the report and that will be running on a JMS or JC a thread if the JMS provider was a JC, a adapter and then that would potentially either store the results in a database or it would respond again and another JMS queue with the correlation ID and in the future.

C

The servlet would, you know, take that identify a poll poll, the database or poll the queue, and then you know provide the user with the request updated. So you know this is one of the problems with early Java EE, and this was incredibly heavyweight architecture just to push an asynchronous break into your application. You need to run a separate JMS broker or use the one internal to the server.

C

There was transactions. You know two different transactions rolling around you could. Potentially. If the servlet was also accessing the database, you could potentially have an ex a transaction between the database and the JMS queue. The things really got really heavy, but that that was the only thing you could do in the old Java EE before Java 7, so with Jakarta concurrency.

C

What you do now is that you, you can use what's called a managed executive service, so the manage executive service is has the same API as the standard Java SE executive service, so you can submit tasks, could make groups tasks and it uses a thread pool and that thread pool will typically be managed by the application server itself itself and an application server is like to manage threads.

C

It doesn't specify that you, you have to have a thread pool, so it could be that if we in a different application server, it could just be running through a common thread pool or you could have an individual thread, pool /, executive service, but suppose so what you would do is and I in the new model is your request would come in your breasts service or your servlet would basically use the manage executive service package up the report details push it onto a separate thread and then that thread can would just basically run separately to your application, which would return and then would run within a set just on a lightweight thread within the application server.

C

So this model is is much much more lightweight than running a full JMS broker. Obviously, and that provides the you know, capabilities to basically spawn forward to you threads asynchronous in the application server without you having to spawn new threads in your code, which would back in you know, is not not good practice within an application. Server well managed runtime.

C

Typically, the application server wants to control the number of threads it has so that it can manages this workflow I mean the purpose of an application. Server is to manage. You know, workloads that are running within the JVM.

C

So, just to show the code for something as simple as that we have bring it up.

C

So we have a basic restful web service here, and this is very simple: razaw some Pascal concurrency and what we can do is we can inject a managed executive service will see the scheduled one later and.

C

Simply through doing the resource like that, what we will do is we'll pick up the default, so the specification says there must be a default and it's executive service within the application, server and injecting it without a jndi. Lookup means that we could just pull in the default one. We could obviously specify J and J name, lookup name if we wanted to, because we can deploy multiple different executive services for different usages.

C

You may want to do that if you need to tune your application very very specifically so I have worked on java, re' application service applications where you need to you know manage which thread pools or which groups of threads are running different services, and you can do that by deploying different executive is a different change. I lookups often you need to do that, for you know in highly tuned systems, if you're managing race conditions or live locks under heavy load, so that you know two services will be running on different different threads rather than competing.

C

For the same. You know small number of threads and to basically put through that simple use case of an AC. Can a synchronous break? We have a simple job here and all you would need to do it's a similar API to the grac executive service api. So you can see, you've got submit collar balls, runner balls. We got invoke any which will you know which you can submit a whole series of tasks.

C

I mean phone call and basically, that piece of code will run this lambda on a separate thread from the actual serve or the restful web service request. So we have that deployed into payara. I can find it so we have a payara server running some running NetBeans here and it has PI are built into it. We have a PI server running, which is not showing anything but I'm, hoping that if I poke a simple job, you can see job submitted and we got job running in us running on a separate thread.

C

So it's return job submitted and it executed the lambda and and the job running came out. Okay, so that's the sort of very, very simple way of money executing asynchronous code within any each Carter, EE application, server and application. Again. Many people don't use this yet because it's not it's a couple of reasons.

C

What many people don't use it because it only came in in java, re' seven, so in SEO we've used in java re' seven, then you won't be able to do this and secondly, which we'll come to later is jakarta, concurrency, isn't in the web profile, so there's no apparent reason. Well, that should be, but it didn't make it into the web. While so it's only in the full profile application, server.

C

C

So second use case for Jakarta. We concurrency is essentially running multiple tasks in parallel, so obviously we're using manage executor service. It may be no in this use case. For example, if you have, you know, Nordic from a shop an e-commerce shop and you need to maybe check take the credit card payment, also check the stock and perhaps do other things as well. You know set up the delivery update the CRM, whatever else that you may need to do in in the micro services type of architecture or in monolithic architecture.

C

Previously, without using Jakarta concurrency again, people used to send these off and Jamis queues and be picked up and executed on separate MDBs. So what you can do now is you can submit a number of tasks in parallel. So this could like its call, the credit card payment, and this could be updating, CRM system to say you placed an order and then the manage executor service can you can your application can wait until both tasks complete? They were run in parallel in separate threads. They may call out.

C

You know they could use micro profile, risk, client, API and call out separate micro services and wait for their responses and.

C

Again, the manage executor service gives us the capability to do that.

C

So if we look what that looks like in code who to go to- and that means again again- I've coded one up so there's a lot of boilerplate exception handling in here, but effectively. What we can do is we can use the same injected executive service and essentially, we can submit the job in this case lambda, which is going to sleep for two second I retrieve the future and then I'm submitted basically a second job again submit sleep for two seconds, and then we can join the two back together.

C

Again, you know by looking at the futures novice the future could return, have a return value. We could could be run a callable here, provide a return value and then check the return values to provide something to the user. So it's pretty simple to do.

C

One of the key key things to remember is manage executives will also ensure that all the java re' context is set up on these new threads so that that's the key goal really for the executive for managed executives in Jakarta concurrency, so that when you, you know in this rest request when you submit this this job or this task, this piece of code within the lambda will be running within the context of the application that called it. Even though it's on a separate thread.

C

So that means it will inherit the know which application you're running in so it'll Herot the application class loader. It could inherit any security principle that was within the applications. If we put authentication or authorization constraints on the restful web service, then they would be carried through into the thread.

C

You would retain the Jin D context, so you'd be able to look up application, locally scope, resources, for example, data sources, JMS cues, if you were gonna, do that or any other locally scoped resources, and because of that, you can then also obviously call locally JB's like I mentioned before lockups EDI beans, and the only thing you got a watch with CDI is- is the interaction between scopes and on the thread. So this is a little bit unspecified so to be safe, you'd, look at application.

C

Scope to CDI beans would be the safest thing to do so, obviously, because for a request, scope bean, it's possible um likely from the request, could actually close before your job completes, or your task on your separate thread completes if you weren't going to do wait for the futures. So as we say for you, you would mainly use application, scoped, CDI beans and that's an area where we can look at in the future under Carta concurrency.

C

To make sure that know we can maybe specify like correctly and or maybe this becomes a separate request or or whatever, so to see that execute. We can go back here. We have there's your link to get request the parallel job, it'll, wait, 2 seconds and then come back and you can see within the pyro server log. We can see that we had job two running. We had job one running a job, one finished we had job to finished and then we got completed from here and it should take.

C

Maybe one two seconds so they're running in parallel.

C

Okay, so again spawning you know, do asynchronous code spawning threads or using separate threads within your request is simple: you don't need to go into all the complexity of you know, async methods or any of these sort of things. You can actually use familiar executive services from Java util concurrency well, just for the added basically added features of that it supports context propagation from one thread to another in the Java EE context, which is very powerful.

C

Okay, so go back.

C

So that's basically, second, you is obviously running tasks in parallel, the other one is periodic requests so before Java concurrency, the only way you can really do a periodic job, our periodic task would be to use eg, B, timers e to be timers been around a long time and you could use the ggb timer servers to kick off. Take off tasks on this effectively on a separate thread, but you can also do this now with a managed schedule executive service. This this, you know essentially mirrors the Java SE scheduled executive service.

C

So you probably request in you can spawn off a periodic task and then that uses the API can run up, we're not set intervals, and that can run periodically if the Egypt Eimer API in you know, Java 7 and above has you know, is much more powerful in that you can schedule cron times you can use cron syntax to schedule, tasks and Java C job egb timers also can be persistent, whereas in this case this wouldn't be a persistent task and also DB time is a cam I'll.

C

Do how cluster semantics to find in their specification. So it does say that a persistent timer will only run on one node in a cluster. But if you just need you know simple scheduled tasks, then you can just use the manage scheduled executive service in the same way easy with G's Java, SE typical way to use it would be either to if you want it.

C

You know running for the length of your application to schedule it out the application and deploy time so that to do that, you would maybe use a servlet initializer or a CDI listener that listens on the application, loaded events.

C

And then you would, you know, kick off and submit a task to the scheduled executive service or you could do as a need to be singleton on it, and you know- and it starts up at startup annotation but using the code is like, is again very, very simple, so he's a periodic job, I'm gonna submit it through a again for a rest call and it will keep running so we have injected the manage scheduled, executor service.

C

So again, there's a default one of these and the default one has to be there as part of the specification. So then we can inject it directly or you can create separate executive services for different different purposes and put them on a different JDI name and you'll be able to use resource lock up to get a different executive service.

C

But if we look at the code again, it is incredibly simple.

C

So we just basically use the injected scheduled executor here. I just put schedule that fixed rate you've got all the standard sort mirrors the SE API, so we can schedule a callable you can use triggers, which is a which is an extension, so a trigger which I think I've mentioned later provides business logic for deciding when the callable should be. Should we run so from here? You could write, you know very specific business logic. When you create the schedule, you could say only runs 3:00 p.m. on a Friday, the 13th, or something like that.

C

Second, obviously, you've also got scheduled at fixed rate and schedule with fixed delay which depend on you know the different, whether it happens basically so I'll calculate whether there's latency to make sure that things have certain rate, and these will just be a certain delay after the previous task was run. So it's very again very simple code: it's not complicated stuff.

C

We can run this in pi hora and it's gonna go infinite through sec here.

C

So if you look at periodic job, we've got one submit and then, if we go in NetBeans you'll see, this is now going to continually print this out until I shut down the server okay. So these are very simple: API is mirroring the SE API.

C

So there there's simple use cases for using Jakarta concurrency, it's very, very small API. It mainly just mirrors a Soviet JSC API, but there are some other components which are are used. If you can't use I can't create a managed executive service, because perhaps you you know you may have one already or you may have to integrate with an API that doesn't use, manage executive services but uses normal Java, SE ones.

C

So, as I said, the main piece that we've seen is the managed executive and the managed scheduled executor, and these mirror the two Java SE api's. So as I said, there's a default instance of each has a distended jndi name. You can create additional ones for your specific needs. So to do that in PI, our server. You need to use the administration console here, so you would go into the administration console.

C

We have concurrent resources, creator, manager, executive service and then groups, gonna, lock me back in. Do it again.

C

So you just create a new one and you can specify the JDI name, there's a whole bunch of other things. You can specify. None of these are standard, but these are very specific.

C

You can decide, you know say whether it could supports long-running task, so these are long ones that the server won't, therefore won't get upset if it lacks for a long time. You can specify hong, after which basically says that if sequester takes longer than X number of seconds and the server will consider, this is a has a humm request and therefore the server is a little bit in trouble, and then you specify your core number of threads in the thread pool from payara. This will end up corresponding to a specific thread pool.

C

Then you got requests that you can set for the maximum number of threads, the core number of threads etc. So this is how you would configure this in payara, but different application servers will have it in different ways: how to do it, isn't standardized.

C

The other enhancement which I haven't shown over a normal executive service is that within the specification you can have what are called task listeners.

C

So a task listener is present. It's effectively a callback interface which will show and tell you whether your task is when it's been submitted when it's been executed with. If it's been aborted, so you can get feedback, so you could therefore monitor the status of various running jobs. So if you, you know somebody whole bunch jobs, and then you want to create a UI for people to see what to where they are and what the status is. You could do that with the task listener API.

C

Secondly, I briefly mentioned the trigger interface. When you submit a scheduled job, you can provide an instance of a trigger and that trigger instance, can do some business logic to decide. You know when this actual Java is ready, or this task is ready to be scheduled.

C

So there's essentially this very simple interface, which basically says gives you the time and says you know: are you ready to go true or false, and you can obviously then within that call any other Java Java JRE service, to make that determination, look up databases or whatever you want to do so. These are the ones that we've seen managed executive manage scheduled.

C

There is another one called manage thread factory. So this again mirrors the Java EE thread Factory, and you would use this for when you need to provide a thread factory to maybe an API that doesn't you know that is an is the API all that isn't Java EE aware and therefore you can't use the executive service or you know you might want to do something you just want. You know a thread to just fire off and do something quickly, so you don't want to go through a pool or anything like that.

C

You can just submit a thread, so I've got again there's some code on there, but I'll show it in NetBeans. So we have one here as an example, so basically going to use a managed thread I'm on a pond here that there's a there's, an executive service which is a normal SC one. So that's not a GRE one, that's a standard, Java SE executive service, and then we can inject again the thread factory again you can. Those thread.

C

Factory has a default one and therefore you can use that directly or you can create them through the administration console. If you need any different parameters or different, you know, priorities, etc. This is just going to show that we can use a managed thread factory to basically create threads for an executor that we have no control over. It's just standard Java SE.

C

So here we just check whether this executor, so it's been created. If it hasn't, we create it and then we submit again. This is a lambda runnable and it's just gonna print out. What my current thread is and again this pods have managed thread pool does is when it creates a thread for the SE api. It will ensure that thread is set up in a way that it can inherit.

C

The required java re' contexts so again it will inherit the security, the class loading, the jndi namespaces, all those things, but you need the bean managers etc so that you can then run standard Java cards at each code within within the submitted task.

C

So if we run this with in payara, so we have a manage thread that submitted it and you've got periodic job still running, but we can see that miss P code ran in a separate thread, and this is the name of the thread. Concurrent under slash underscore default thread. Factory is the jndi name of a standard thread factory.

B

C

And if you run it again, you can see that it's created thread so he's creating new threads on demand, but and they are separate, obviously the one that's executing the service, but you would be able to call any Java EE code within that. Okay, so that really is used for integration. So you know anything that executives in those se world can take your thread factory as a parameter. So anything that needs an executor when the API that requires you to pass in one, then you could create one standard, one with anomalous, refractory.

C

The next standard class, really in the a in the specification, is the contact service. So the contact service is a little bit more complicated and probably a little bit more.

C

Esoteric in its usage, I suppose so what it is is when you need an object to run in a java, re' context, but you've got an unmanaged thread. So that's one that hasn't come from a managed executive service or manage the thread factory and what it does is effectively when you create it. It captures the context that was that of the java re' application at that point in time, and then, when later, when you use the proxy, it will reestablish the context.

C

It's pretty easy to see in the code, but it allows you to capture context and because the context has to be serializable, it allows you to pass context about so I've seen this sort of thing used in security, whereby people need to capture this, the authenticated user or the principal that's on the java logic artery thread, and they need to pass that around and they need to reestablish it when something is executed on a different thread.

C

So, for example, here we creating a standard Java SE runnable, we're creating a standard, Java SE thread and starting it, and what we're gonna do is to make this capture the context.

C

What you do is use the context service which has been injected here and you create a contextual proxy, and what that is, is it's basically going to create a you know reflecting proxy using you know the normal proxy API and that's the instance that you're going to wrap and that's the interface that the proxy has to inherit?

C

Okay. So when we this thread, basically, who calls run on this runnable, the context service will establish or the proxy will establish the correct context which they've inherited so the security, the genuine namespace, the class, loader, etc and then run this method within that context. So it's used it's much more complex, but it is very powerful. So if we just go back to the runnable proxy see, we started a new thread and this was spit it out that it had run in the context. So again, these are where you just need to submit a object.

C

If you like to a thread that you don't control and- and you need to capture the context and then run it in a new basis, we establish that context before you execute the method.

C

C

That's one of the four main services that are in current in Jakarta concurrency, the driver. You can current currency details, as was so that's how you would use it. I say it's a pretty small API and there's not many classes in there, but it hasn't changed in java, re' seven. So what what we want to do for say: jacquard tree 9gr tree 10, so these are just some ideas, so these are all now open to the community. These ideas have been cold predominately from github issues.

C

So if you've got any ideas or you use concurrency- and you want to want to see how it you know, you want to see how it changes or you want to change it. Then this is so. The the project is where you need to raise those those questions and those issues. So I'm gonna go through a few. We don't have code because obviously this doesn't exist yet so the first one is deployable, managed objects so currently to create a managed object, which is a and I talked about, managed objects.

C

I'm talking about managing executive service I manage thread factory on one in schedule executive service. Currently, the only way to do that in pron and probably in most other application servers in US is to do it through the administration console. So you can see here you can create them through through your admin console. Obviously, as we move to you know more lightweight runtimes, like PI or a micro, where we don't have an administration console or we're running a single application, then that has limitations in that you would need an administrator to set that up.

C

So what we're suggesting is just like you can now do datastore, def, datasource definitions and deploy a data source and connection pool along with your application. There's an application scope resource.

C

Then you know we should be able to do that with these managed objects as well. This would allow you you know. If you create an application, you would be able to just like with davis definitions, specify on on one of your beans that you put this annotation, and this would then create a manager executive definition on deployment time, give it a jndi name, tell it which contact service you could you wanted to use again?

C

You could package that in your application, you could specify the max concurrency and min concurrency, so we would avoid sort of thread pool semantics, because some application servers, don't you know, create separate thread pools for these things. That would also then allow you to control your concurrency pretty closely within the application. You could have different thread, pools for doing different things or different thread groups for doing different things, which, like said, you often need to do in quite high.

C

You know high load or highly tuned systems to prevent deadlocks or live locks or or that sort of thing. So that's one thing that we think would be quite easy to do. Obviously, there's already the capability and all the products to actually create these things through the administration console so causing an annotation to deploy. One should be pretty simple: we should and we be able to add properties and things to do. You know application server specific.

C

This will be very useful in the payara micro situation, so power micro is a web profile plus extras version of payara, which is just in command line. So I've got here. This is quite difficult to see because it's probably underneath your pictures of my face.

C

It says java, Java, Python, micro, so PI or micro just runs as a straight jar file, and then you tell it to deploy a bar, and then that would run exactly the same application that we've got now, which I won't show, but because of its model, where you just give it a while file to run, you would typically run this within a docker container.

C

You don't really have an ability to to create these managed objects on the fly, although PI or micro does provide a way to do that command lines, but it's a bit clunky it'd be much better to do this through.

C

You know deployment within your application. That's the best way to do data sources and PI or micro, for example. You'd put the date sauce definitions on your honor on an object like an e DB or an application scope, CGI beam, and it will deploy the data source for you without having to create pre-boot scripts and post boot scripts. So, for example, that duck deployed and then you've got our different web services there.

C

So the foible managed objects would be powerful and allow you to do quite a lot of concurrency control and thread pool creation within your app code application. The other thing we're thinking about is a schedule annotation, so I say at the moment. All you can do is use a schedule, my own schedule executor API directly or we could or you can create each of you timer annotations, 3gp, eg B's. That will give you would give you a schedule, but why can't we just do that for CDI beings so death had this would look here.

C

We have a application, scope, CDI bean. We had a schedule annotation. Potentially, we could have give it a logical executive name, so you could then also deploy, which you know group of threads, that you want this to run on and then in similar to the eligio, be timers api.

C

We could have a cron like syntax to you, know to actually show and tell it to run every five minutes, for instance, and this could also potentially support persistence, otherwise that other, although that would expand the api to ensure that you had a persistence layer to, but given that application servers or runtimes like pi or micro have to support persistent timers, then this is already there.

C

We could define what the cluster semantics of this are. You could add cluster semantics to it. We could have you know singleton, which says it only runs on one node in the cluster or we could say on you know all cluster nodes or you know whenever we could we decide. We think that about that be quite powerful, with that, it's very similar to I believe that there's something similar in spring there. You can do this on, so that would just bring that into Jakarta again pretty trivial thing to do.

C

It's just going to be submit that object into a schedule executor. Next one is async, annotation or I. Think or asynchronous. We could then the logical place for an asynchronous annotation is within the concurrency specification.

C

We could just put an async again. The annotation can specify which executive to you so you've got a lot of control over which thread, pools, etc or thread groups that you want to run the method on, and then you could support a method, signature that you know. We turn the future, and this would again, you know, provide very simple async functionality into CDI and the foundation of other async box. You know API is within the whole platform. Spec could be based off something like this.

C

C

Then there's another piece of work that needs to be done. We need to catch it with Java util concurrent, so Java util concurrent moved on and, as you know, Jakarta concurrency is effectively an implementation of Jakarta. Sc has built on top of Jakarta SC concurrency, along with the manage threads, then the certain areas that we need to do just to bring the spec up to you know up to scratch with.

C

What's in Java I see, you know nine and an eight, so the first one that's being suggested is obviously we need to support the fork, drawing pool in a standard way and therefore we could create. You know, manage fork/join pools, and this would allow us to create new streams through in a managed way, and so when I say managed, I mean have all the context of Java EE, so the security principle, a class load in the danger, high name space and all those other things that you'd expect in the bean manager.

C

So we could potentially do this now. Then, in that you could you can you can get around this? You could create a fork, drawing pool with a specific executor implementation, which you could pass in a manage an executor cuz. It implements a SC executor interface, so you could do that, but it'd be good to have a way to do that as a standard across other application servers, which doesn't necessarily mean it needs to be programmatic.

C

So we could, you know, deploy these or configure it in a way that that it's fairly transparent, again flow came in and Java 9 to bring a reactive like API into Java 9 beyond. So we need to look at how we would integrate that so that we could use flow in a way that manager objects can be incorporated. So we can create the right threads. We can create the right context and we can, within subscribers and publishers, you'll be able to use Java educator ee objects.

C

Another one obviously is currently the api's future base. So we need to support completable future there's a couple of ways. We could do that we could add the API onto the manage executor, so we could have a run. A sync and supply a sync: Apio managed executor. X' or we could create effectively a corresponding class, which is a managed computable future, so those things only discussing and standardizing, but once we've done that we des love catch up normally with Java, util concurrently and then there's some alignment with micro profile.

C

So microprose profile has created microphone file context propagation, which was basically created into some extent as a response to the fact that Jakarta concurrency wasn't off the ground, so we could align with that.

C

We could either you know we standardized it, but that effectively is bringing in the api's for completable futures and also has a more sort of powerful context capture api and has more well defined semantics of you know, of how CDI beans interoperate with context propagation and Mike profile, so the so that needs looking at and look at how we align that or potentially we implement that into Jakarta yi.

C

Finally, this that or there's some general platform alignment that needs to be done say. The specification is a bit loose on how to guard concurrency would interact with context and dependency injection and Mike profile. Context. Propagation has gone much further on this, so we can look at that I'd like to see this brought into the web profile, because there's no reason that it isn't there's nothing that it depends on that isn't in web profile and for pyro micro, which is ostensibly mainly web profile api's.

C

It was too useful in the API to to lead out so prior micro supports, Jakarta, concurrency and then obviously, then brings you know, thread management into. Like you know, web profile implementations, we could go bit further. We can re, implement Jakarta interface beans asynchronous on the concurrency api.

C

We could either quit create a new async annotation and allow that to be used as an alternate to the the entrez beans one or we could potentially modify the enterprise beans one to allow a named executive service to be specified to be used as the thread pool, so that would go achieve the same effect but I'm you know I'm quite like trying to align these things onto the single API is rather than getting the wrong import for the wrong asynchronous annotation got a bit further and maybe a bit more radical.

C

You can potentially re-implemented rice being timers onto the concurrency. That would require a new schedule annotation and then that annotation could be usable, CG, bees or gently our interest beans and CDI managed beans.

C

Alternatively, again we could potentially put on the timer annotation the current one, which man, whose executive service to be specified, maybe the jndi name or a logical name and then again further one is async servlets and jax-rs. We could again implement them on top of Jakarta concurrency simple way. Simplest way is just to allow them to take a parameter, which is a logical executive name and then ensure that if that name is set, then it uses that executor to implement as the thread source or the the asynchronous source.

C

Finally, there's some cleanup that needs to be done on the actual API as it currently stands, and some evolution or some little enhancements. We could do that, make it more powerful.

C

Obviously this came in Java 7 and there was no changes, Java 8, so there's no date and time support in the API, so the the api's could be modified so trigger in particular, and last execution use dates. They could be moved to or added methods for date and time support. We can provide some concrete trigger classes. So I said a trigger can use your own business logic to define when the message whether when a scheduled task is due to be fired, we could create a cron trigger spring.

C

Has this it's even mirrors the trigger API from Jakarta concurrency, so we could create one that for somebody, then again, some of the deploy bomb range object, punished, objects, the configuration attributes, aren't standardized, they're, just examples within the specification we could standardize some like max concurrency min concurrency priority, some things like that. If everyone agrees what that set is so how to get involved. So, as I said, these are all ideas called from the github issues, so the clips project is they're, the URLs they're. All these live stream.

C

Presentations are all recorded, so you'll be able to see this there's a mailing list way. We can discuss concurrency utils. Anyone can register Jakarta user all open source now, so everybody can get involved, no expert groups and I'm no expert and I'm Project Lead. So if you want to raise features that you want go into, github just raise a normal get her wish. You, like you with anything else and then it'll get discussed.

C

There is a Eclipse project which does I think compatible implementation, which is the version and implementation of concurrency utils. That's bedded in GlassFish and both Paora and perhaps others remember this. We are now in Jakarta world, so this is now code first open source development. We want to create these annotations, then we can start messing around with them straightaway on the projects. So thank you, I think I have five minutes left, so I shall try and see. If I can answer any questions, it's gonna go freaky on me, though. I think.

C

So I might stop sharing my screen. Then there we go. Okay. Is we got two so both from Reza? Where do we need my community contribution folks to take that one first everywhere, I think we've got we have a set of, they say those ideas. We have there's a set of work and we can start that now, but I'm, definitely not the font of all ideas and the rest of the project team.

C

So if anyone has anything burning, then first thing to do I would say is to raise an issue on github issue tracker and we can track those, and you know the new feature requests it just even though it use the word issue, you can have new feature requests and then alignment of micro profile- it's not touched on that I. Think micro profile has done some good work and mainly because of the slowness in the ducati transition.

C

I think we can take a lot of that work and look to implement that potentially within Jakarta yeah, then the Ducato namespace Oh in another way has also worked on in micro profile, reactive streams, which is a bit more hardcore.

C

If I came over to Carter II, the question is really whether that would go in concurrency or in its own API, or whether it's going to end up in Java SE anyway. So those needs looking up.

C

C

A

So yeah Steve- that was amazing. Thank you, so much I think we're now getting ready for the next session and we will let Steve go and we'll talk to you in a bit on the panel again. So we truly appreciate you being here.

B

A

Will end this session and invite everyone to the next one see you there.

C

A