 OK, everybody, it's time to talk about CDI 2, the next version of CDI, which should be released in the coming month. Yeah, we don't have a final date yet, but it's at the beginning of next year. Before talking about CDI, just to mention the Micro-Profile Initiative launched by Red Hat and other partners. And you can register to the Micro-Profile booth or the lunch tomorrow to have more information about this initiative of having a new way to create micro-service application using Java stuff. So I won't present myself. So I'm a CDI spec lead working at Treadat, also tweeting a lot about CDI, of course. And you can follow me on Twitter. So we'll talk about the history of CDI. So all the stuff that were done in CDI since the first version in 2009. And we'll deal with a new feature coming in CDI 2 that you can already test. So most of them are the major one, the Java IC support, the new event stuff. And I'm not sure we want to able to deal with over our point because I don't have a lot of time to speak with you. But if you have questions after the presentation, of course, I'll be happy to help you. So let's go for a flashback on CDI. So it's a rather young specification. It was launched in 2009. And we had two major versions since then. So there was a new release of CDI with Java E7. Today, if you use a CDI on your application server, you are using probably CDI 1.2 version. And we start the work on CDI 2 nearly two years ago. And we should release at the end of the year, our beginning of next year. So for people that didn't have the luck to play with CDI, what is it? CDI is a framework for Java E, which define a lifecycle for a stateful object and give context for those objects. You can add a new context. You can add a new lifecycle. And you also have in CDI, which is the ID injection, you have a type safe dependency injection mechanism. And it's done with very little need of configuration. You can either select the injection at development or at runtime. You also have all the aspect oriented components that you can apply on your CDI bin, which are the decorators or the interceptors. So you can add things like security, like transaction, et cetera. And another point that is very popular on CDI is the event bus. So we have an event notification model in CDI that will evolve in CDI 2. We showed that. Another point that is important for CDI and make the success of the spec is probably the SPI. So we have a lot of tools to extend CDI through the portable extension. So the release of CDI 1.1 and 1.2 add a few features to CDI, nice feature. So in CDI 1.1, in Java E7, CDI was automatically enabled in the application server. We had all brand new tools to do introspection regarding the event, the bin, the decorator, et cetera. So you can have more information on the metadata of the bin you are in right now. And we also give easier way to access the CDI component and the CDI bin graph from code outside CDI. There's also a new way to enable a lot of things in CDI 1.1. You can use the priority annotation to activate alternatives, decorator, interceptor, et cetera. And also to help people using CDI in non-CDI code, we also had a non-managed allowing you to inject CDI bin instance in non-CDI code. So the CDI 2 status. So we started the CDI specification two years ago. We have a weekly meeting on IRC. We have a regular release of the reference implementation. So lately, we release the wild alpha 17, which is the reference implementation for our early draft 2. So we had a lot of nice stuff with it. So you can play with this new wild alpha, wild free alpha. To test the new stuff, I will show you. So you can grab it on Maven Central or download it. And we released an early draft during the summer so you can use it. So if you want more information about the CDI, the spec, how we work, et cetera, and have more information on all the framework or other specification using CDI, you can go on the cdispec.org website. Whoops. So before launching the spec, we had a survey to gather information regarding the feature that people wanted to see in CDI 2. This survey, before the survey, in fact, we launched a more informal survey to have this feature, the needed feature. And we proposed a list of features and asked people to vote. So there are a lot of people participating, about 260 people. And we asked for a new feature. We asked them to write 20 new features from one to five. So it was mainly developer that answered. That was a good thing. And they were using mostly CDI one. And some of them were using CDI one, one, and one, two at the time. It was a good thing. And they were using it mainly in Javai. So result of the CDI of this survey. So all the features regarding asynchronous operation were the first one. So we had requests regarding asynchronous method invocation and asynchronous event support. So we will add the asynchronous event support in CDI 2. It's already done. So you can already use it in the Welfare Alpha. And another very popular request was about bootstrapping CDI container from outside Javai. So on Javai C, it's already done in Javai in CDI 2. So you can use Welfare Alpha at 17 to bootstrap. I will show you the API to do this bootstrapping. We are still working on a solution to bring interceptor and decorator and producer and custom bin. But it probably will be done. Mutable container at runtime, probably we won't do that. It's too complicated and it will break the specification. But we added the ordering of Observer. So you can give a priority on your Observer right now to make sure that one Observer is called before and over one, OK? And in those parts, we still are discussing about those points. But you should know that we probably will launch a CDI 2.1 after the CDI 2 and answer new needs from our users. OK, let's go to the feature. Excuse me, I'm checking something because I'm not sure to have the, sorry. OK, so one of the first interesting stuff is the Javai C support. So in CDI 2, you will be able to bootstrap the CDI container in Javai C. That will be, why did we choose to go that way? Because if you know a little bit CDI, you know that all the implementation today support Javai C bootstrapping. So in a well, in open web bins, and you even have a solution with the Delta spike framework to bootstrap CDI. So the idea was to align with overall Javai spec that most of them already bootstrap in Javai C. And they were complaining that if they make, if you use of CDI, they would have a problem in Javai C because we didn't support Javai C. So it's a way to have a better adoption for overall Javai spec. And the idea also was to allow people to create new components stack outside Javai with CDI like it's done with over a framework like juice or spring or whatever. So it seems very obvious to say, OK, we are going to Javai C. But the problem is if you read the spec, have you read the spec? You read the spec? I've got one people, you know, every time I do a confer or talk on CDI, I ask people who read the spec. I have 100 people in the room, only one guy, Res, and so. Congratulations. So if you read the spec, you saw that there is a lot of integration of overall Javai specification in CDI spec, especially the EGB specification. So we had to split the specification before going to Javai C. So we did that. So if you read the new specification for CDI 2, the first work was to split the CDI core feature, all the features that will be common to Javai C and Javai and another part regarding the Javai stuff for CDI. So all the servlet, EGB, et cetera, feature. And we added this part for Javai C. So today, the spec is divided in three parts, core, SE, EE. It was a bit hard to do, but it's done right now. So that's the API we designed to bootstrap CDI from Javai C. So we are using a kind of builder pattern, builder and approach. So we ask a container initializer. We can add a few features. We can treat the discovery of bins. We can add extra annotated type. We can add extra parameters to the container. In one time, we choose to initialize the container. And we get an AC container instance. And this AC container instance implements the instance in CDI. So you can use the select method to retrieve a bin instance, to ask a bin instance from bin class, from qualifiers, et cetera. So you have something very easy to use. And the things that you already know if you are a CDI user, you will be familiar with this way of doing this. And it gets very powerful. So another stuff we did regarding CDI was Yansing event. So there was two features that were requested. The first one was event ordering. So the ability to put a priority on each observer. And the other stuff is the addition of asynchronous event in CDI, which is a very requested feature. And everyone starting in CDI and playing with events say, OK, now how do I have asynchronous event? It will be available in CDI too, sorry. So regarding events ordering, so we'll ask the commands annotation spec to do a maintenance release to allow the add priority annotation to be applied on parameter. So you can add the add priority on an observer. Of course, the lowest value is first. So priority one is the first observer that will be called. And if you don't have a priority on an observer, it will be called at mid-range. So it allows you to explicitly say, OK, these observers are first. Those one I don't care if they will be called sometime in the middle. And those I want them to be called last. So you can have an announcement very precise of your observer. Right now, we don't have a prioritization on asynchronous event. It's only on synchronous event. So it looks like something like that. So you are using the add priority with the add observes, and you give the order like this. So the nice thing is that you can also use them in extension. As you know, portable extension in CDI make heavy use of observers. Sorry. So you can, for instance, have two extension working on, I don't know, annotated type. And be sure that one will be called first and the other one called second. But you can decide that, or you can decide you keep it the previous way. So regarding events. So today, we have this pattern. When you want to fire an event, you use the event interface, you inject it, and you call the fire method on the object. Observing is like that, I guess you already know. And today, in fact, if you read the spec very carefully, you will see that there is no, in the current spec, there is no specification about whether the event should be synchronous or asynchronous. That's mostly the reason why people ask us. But all the implementers decided to make them synchronous. So we keep that the way, and we add the new stuff. So we have the possibility to mute the payload with the synchronous event. That's a feature that people want to keep on to use. So we have to keep that in a synchronous event. And we won't be able to provide this feature in the same way in the asynchronous event. So that's the reason why if we go blindly to support a synchronous event, we will have a lot of backward compatibility issues. And we have to be extra careful by doing that. OK, so right now, to some app, right now, all the observer are calling the fire and thread. It's not calling a particular order. And you can mute the payload. We also have to keep in mind that we have context tied to the event. So the main contexts are the transactional context and the security context. So in CDI, you have transactional events. So you have to keep those contexts and spread them around the thread. So all this to say that if we are in a sync world, everything is perfect. But in a sync world, it will be a bit harder if you want to keep those features. So if we want to be backward compatible, it can be a bit tricky. So what we decided, all the current sync event must remain sync. So we couldn't change the behavior when the people changed the version of CDI. And if you decide to use a sync event, the decision should be taken from the firing side. But it should be also taken from the observing side. So you have to activate it on both sides. Because you can use the event pattern can be used in third-party libraries, for instance. So you are not owning the firing side. Or the other way, you're not owning the observing side. So there are a lot of use cases where going async without forcing the user to be explicit on both sides will break the code. So we introduced the fire async method in the event interface. So that looks like very similar to the synchronous event today. And regarding the observing side, we introduced the observes async annotation. So this is an asynchronous observer. This is not a synchronous observer. And we have to decide, and that's still in discussion, we have to decide if the firing asynchronous event should trigger a synchronous observer. The decision right now is no. Because we have a lot of different behavior regarding exception. So today, in asynchronous world of events, when you have an exception, all the observer chain is stopped, so the exception stopped the event propagation. But in asynchronous event, we don't do that. We keep all the collection of exception and give it back to the user at the end so he can decide to do something. But all the asynchronous event will be triggered, even if one of them goes in exception. So right now, it's the way asynchronous event and synchronous event works. There are two separated world and there is no solution to make them work together. If you need to have an event triggering asynchronous observer, you have to fire it twice. So we had the possibility to provide an executor in the fire async method. So you can, for instance, use it to send an event to a thread dealing with UI, for instance. So you know you want to notify your swing interface of something. You can use the thread dedicated to that. So it helps you to do smart stuff. Regarding exception, I have to go a bit faster. Regarding exception, asynchronous events are based on the completion stage API coming in GDK8. So you can use this completion stage to retrieve the exception that occurred during the asynchronous event resolution. So you have three solutions to resolve the exception. Sorry. Yeah, that's it. I have a problem with my slide, sorry, because I moved the slide before the talk and it's mixed. So we have three solutions, but it's not due to CDI. It's Java 8 stuff. So you can use the completion stage when complete. So it's a way to deal with the result of the exception. So you can have at the end, OK, if it works, I can work with the result. If it didn't work, I can deal with the exception. With the stage under, you have quite the same, but you can change the exception. You can change the behavior and return something else. Or you can go for a stage exceptionally. That means that you are only waiting for the end of the asynchronous pipeline and do something at the end. So you have all these solutions to work with. I think I'm going to stop here because I have to. What I wanted to show you is the. So we are still an open specification. There are still discussions around CDI. We are eager to have feedback on this new feature. There are new, other new features. If you want to see all the new features, I'll give a talk tomorrow. Don't remember the time, but it's before midday. 11, I guess, something like that. And I will show some code, et cetera. And if you are not happy with something, if you want to suggest something, feel free to send us a message, to tweet something, et cetera. And we'll try to see if we can discuss the point for you to mention. Thank you.