The past, present, and future of enterprise Java - with Jakarta EE in the middle

In this talk, Ivar Grimstad discusses the evolution of Jakarta EE, formerly known as J2EE, highlighting its past, present, and future. He emphasizes the significant impact of J2EE on the adoption of Java in enterprise applications, which began in 1999. Over the years, improvements have simplified the development process, notably with the introduction of Java EE and later updates, such as Jakarta EE, which moved to the Eclipse Foundation. The speaker explores recent changes in Jakarta EE 9, 10, and 11, including the transition of package names and the introduction of new profiles targeting microservices. Furthermore, he touches on upcoming features in Jakarta EE 12, including enhanced support for NoSQL databases and AI integration.

[music] >> Welcome to this kind of history session on Jakarta EE or an enterprise Java. I've gathered late the the past, present, and future of enterprise Java. And I'm the Jakarta EE developer advocate at the Eclipse Foundation. Uh my name is Ivar Grimstad. I'm a Java Champion, and I'm also let me see if I can get this clicker to work. There we go. So, I'm I'm also

a Oracle Ace Pro and an IBM Champion and involved in a lot of open source communities here and there and also run a Java user group in Sweden. If you want to follow me on social media, you can do so by using any of these coordinates here. All right. So, we're we're talking some history. So, I'm I'm I've divided into three pretty logical parts. It's the past,

present, and the future. And we're going to start with the past. And uh when we when we talk about the the the ancient past of Java, it's it's it dates back to 1995. So, who are you born like like before or or after 1995? Yeah. Okay, couple of you. So, so Java is older than you. Or or you're younger than Java or whatever you want to say.

So, so that's pretty cool of a of a programming language and technology lasting for more than 30 years and it's still going strong. And one of the reasons why Java is still going strong and is in the position it is today is because of a technology called J2EE. Because Java was originally designed to work on the on set-top boxes and devices. But it turned out to be

very good on the server. And we conquered the server side around that time. So, in 1999 Sun created J2EE. And J2EE was a tremendous success. And it's it's because of J2EE that we are attending Java conferences or attending Java tracks or in this room today because if it hadn't been J2EE we would have been at a .NET conference or something else. Because J2EE is what powers the

world. Most of the domain logic in the world is written in Java, is written in Java EE or or J2EE today even. And and and most of the money and transactions goes through this or the world is powered by Java. And but back in those days when they created J2EE they did a little uh let's say over engineering of the things. So so if you wanted to

create a simple class doing like happy birthday like this one and I wanted as an Enterprise Java Bean. So back in that day I would have to take this this little class of mine and I have to to add some stuff around it. And and this is where it gets a little complicated. And this is where some people are a little bit scarred from from this because

you had to take this simple little class and you would would have to extend it some interfaces. It would be a session bean and Enterprise Bean and a serializable. So everybody loves serializable, right? So so so but it didn't stop there. You also had to implement some some other create some other interfaces. The local interface, the remote interface, the the home interface and the local home interface.

So so so all of these you had to create and these again extended the the J2EE versions of these interfaces. So it's kind of a big messy class thingy going on here. And it was even more. The the infrastructure would also create some some some stubs for you. That would that would create implement these local, remote and home And so you'd end up with this just to

say hello world. And and we can we can we can say this was a little bit overhead to to put it slightly. So but but the the thing in blue here that's what we as developers had to kind of create. The other things was generated for us. So so didn't really matter. It just kind of uh complicated the picture. Uh but we also had to take our

uh nice little class diagram and package it in something. And we had to add some XML files and descriptors around it. So we needed a a deployment descriptor for this. And uh that was the standard one. And we also needed to have the some proprietary deployment descriptor depending on which platform we were deploying there. So there were some XML configurations around there. We would have to package

each of these simple beans into an EJB jar or or jar file that is called an EJB jar. And this jar file can only contain one EJB. So if you have multiple EJBs in your system, you'd have to have multiple jar files. And all of these will be packaged into an EAR file or an enterprise archive. So so it starts getting a little bit too much uh

to to uh create just a simple thing. So uh great minds come together and create something better. And Spring Framework came around in 2004. And and Spring uh did address some of the issues with uh with J2EE. So so in in Spring if you had this bean here, uh you would have to add some getters and setters to it. Be- because uh the early days of dependency

injection which Spring brought to us wasn't annotation based. That was the uh the the uh was setter and getters that you would have to expose some internals of your bean to to be able to do the dependency injection that framework created. And uh but you didn't have to implement all these interfaces and generate these stubs and stuff. So it was much simpler. But there were still some

XML uh configuration around. So so you'd have to to to uh to to at least have one XML file to configure your Spring application which bean depended on which And and how how they they uh connected together. And these XML files as the uh as the application growed would would nest each other or reference or point to each other. So, so if you had a large application

back in that day, it wasn't easy to figure out which being came from where. Uh but the packaging was also easier so you could package it in a web archive or a war file or an ear if you wanted or a jar. But but it was usually you would do it as a web archive. So, of course the the the people at Sun saw this happening and

they came up with a Java EE. So, we changed the name from J2EE to Java EE and brought in most of the stuff that Spring had given us. So, we got dependency injection. We got annotation-based dependency injection. So, we got annotations in Java 5. We got JSR 330 that makes it possible to use the @Inject in Java and @Autowired in Spring and use it interchangeably and it

works all fine. And this is because of JSR 330 or Java Specification Request. And so now EJBs looked a lot more simple. actually back in that day, this is how you create a stateless session bean. That's all you need. No XML files. No interfaces. No stubs. No remote. No local. No nothing. One class with @Stateless. No setters and getters. So, this is how an EJB has looked

since 2009. It's 15, 16, 17 years since. And we still call EJBs complicated. And you can package it whatever you wanted in an in a jar or a war or something. You don't need a single XML file. Since we hate XML so much. So, one annotation. Package it whatever you want. That's how EJBs have been since then. So, all of this that is gone history a long

time ago. So, okay, that little history thingy is a little bit setting context that that the platform has its complicated past. It's now in the in the present. It's as easy as it can be. So, let's look at some things that in recent history and how it looks today. So, Spring Boot came in 2014. And Spring Boot changed the game again cuz they they introduced a different

way of thinking. It is much of the same as it's always been, but it's a little bit easier to get started with at least. And also a little bit after that, Java EE changed name again. So, now it's Jakarta EE and it was moved over from the JCP over to Eclipse Foundation. So, so the Jakarta EE working group was created and we've been doing Jakarta EE since

then. And one of the first things we did after getting started, it took a little while. It's a lot of code. It's a lot of documents. It's a lot of things that has to get over, especially the the test suites and everything. So, it took a couple of years before we could release the the first true version of of of Jakarta EE. We released one version that

was just copy of Java EE just to show that the infrastructure works. And then we did the Jakarta EE 9 in 2020 and that is where we changed the names from Java X or packages from Java X to Jakarta. And this rippled through the ecosystem like a hurricane. Everybody here that has touched Java since 2020 has been in some kind of project where you have to change

the package names in your in your code somewhere. So, that shows how everywhere Jakarta EE is. Like, everybody knows about Jakarta EE now and that's mostly because of the name change. It may be not a good memory, but but still it it it makes you aware how much you rely on this technology. Currently we are uh, in uh, 2026, but the latest version we released was uh,

Jakarta EE 11. Let's look at the the latest Jakarta EE releases. As I said, in in 9 we did the name switch change, and we only did a name switch change because we did want this migration to be as easy as possible. If we had done more and changed the APIs in addition to the name space, this migration would be still going on. So, so, so we

did it as easy as we could. It It was hard, but still it could have been much worse. Uh, then uh, in 10 we we released a new version uh, of Jakarta EE, and we introduced a new profile. I'll get back to the the core profile in the next slide. And then we released a Jakarta EE 11 uh, 2 years later uh, where we are now on

Java 21 and and higher and I got a much more CDI centric and also introduced the Jakarta Data Specification. Jakarta EE, just take a little step backwards, it's about specifications. And and when you talk about specification in in Jakarta EE, we talk about the the specification document, which is a human-readable description of the technology. It's a PDF or HTML you can get on the web page. It's

also an API, which is not a normative artifact, but it's still there. That's what we as developers think of as the specification. That's what we get from Maven Central. That's what we use in our development environments. That's what we use when we program this stuff. It's also a technology compatibility kit or a TCK that tests and verify that a specification is actually implemented correctly. And and when

it's implemented correctly, that implementation is a compatible implementation when the TCK passes. And and there can be multiple compatible implementation of a specification, but there has to be at least one open source one so we can ratify and say this specification is actually implementable and it is now a final specification. Let's look at Jakarta EE 10. So so since I since I said we did very few

changes or non-changes in 9 expect the namespace change, we had a lot of changes coming up in 10. So more than half of the specifications were updated between 9 and 10. And and this journey continued to 11. So you can see if you compare the the the blue colors on these, there are almost as many specifications updated between 10 and 11 as it was between 9 and

10. So so we're [clears throat] we're continuing refining the specifications. A lot of these are minor updates. So it's just like lighter refactorings here and there and and add-ons smaller. And some of them are major updates that do more And we also introduce a Jakarta Data as a new specification. So Jakarta EE 11, the the the whole set of specification for Jakarta EE 11 is the Jakarta

EE platform. And the platform is a specification in itself. So it has a a document, it has a TCK, it has an API, has compatible implementations. And compatible implementation of the platform is what we typically call application servers. that is the compatible products of A subset of the platform is the Jakarta EE Web Profile. And this is more targeting the traditional web applications. It doesn't have the

more enterprise-y flavored specifications. But it still is is more or less the the usual set of specification you use for And then in 10 we introduced the Core Profile. And Core Profile is targeting microservices or RESTful endpoints. So so you have the specification for REST and the JSON specifications, some glue in between, and CDI Lite. And CDI Lite is an interesting specification since uh, that one introduced

is a subset of CDI first of all. Uh, and that is kind of the glue that glues everything together in Jakarta EE. And CDI Light did, uh, also introduce the, uh, the possibility of, um, of resolving all the dynamic properties at build time rather than at run time. So, you can use, uh, Jakarta EE applications and and compile them with GraalVM to to create native images if

you want because otherwise CDI resolves a lot of things at run time and that doesn't work well with ahead-of-time compilation. Jakarta EE 11 is based on Java SE 17, which may seem like a long time ago. And, uh, but we when we did this was that we made sure that 21 was just released and we wanted to make sure that those that are still on 17 can

still use, uh, Jakarta EE 11, but those that are on on 21 should also be able to use it. So, we made sure that it works on both. So, we we always test it on 17 and 21, but it also works on 25 and 26. So, so, but we I haven't tested it unless an implementation actually does it, but when we release it, we verify that it

works on 17 and 21. And and th- and with this release we also introduced a release cadence of releasing a Jakarta EE version about a year after an LTS of Java. So, so, that is about a year after 21 we released, And and then we take also the previous LTS and test it on. So, so, when I said we released 11 in in 24, I'm I'm sort

of a little bit I'm I'm I'm right, but also wrong. And, uh, because we released Core Profile in in, uh, 24. And, uh, we we had to wait until, uh, spring of 25 to release the the, uh, Web Profile and and Platform. And the reason for that is that we did a major refactoring of the TCK. You know, the big test suite for test for compatibility because

that was written back in 1999. 30-year-old technology that still worked, but nobody knows how to do it. So so so in order to attract new developers and get people to be able to help us evolve the technology, we had to do some modernization of the TCK and that took a little longer than we anticipated, but we still So so we now lifted it to to use at

least Maven and and JUnit 5 and and Arquillian and and some newer technologies there and not the the old Java test harness test suite. So, let's look at some of the specifications in 11. Not that many but since we only have 30 minutes here, but let's start with concurrency and How many are using 21 or or newer? Yeah, the rest are on 17? 8? Something else than

Java? So so so in virtual threads, the big thing or one of the big things in Java 21, one of the big things were virtual threads. So, we wanted to support virtual threads in Jakarta EE as well. And um as you may know, we have this love-hate relationship with threads in Jakarta EE. yes, we are it's all about threads, it's all about threaded everywhere, but we don't

want you to mess with the threads because we don't trust you. The application server don't trust you and if you create your threads your own, the server may kill it for you. So we So to make sure that your threads are safe, we wanted to use the managed services for it like the managed thread factory for example. And we thought we could do the same thing with

virtual threads because while not that dangerous as as regular threads and expensive, it can still create a mess if it's not used properly. But then you remember we support Java 17. So how were we going to do that when virtual thread came in '21? Well, what we did was we didn't change anything in the APIs because we still compile them with 17. But we added some flags

here and there in the thread factory definitions and the other managed stuff. So so you can set virtual true to indicate that I want to have a virtual thread. So we didn't change the interface we just added a variable and and the default is is false. And and that made us possible to to introduce the Java SE runtime of our support for virtual threads. So so if

you are running on 21 and have the flag set to true, you will get a virtual thread if the platform supports it. But if you're running on 17 or a platform that doesn't support it, you will get a platform thread. So that is depending on the runtime you will get a virtual thread or a platform thread because the APIs are are the same. So let's look at

a demo for that. So I have this very simple application. And and since I'm I'm now simulating an old thing, I'm I'm running on 17. So so I'm compiling it to 17 I'll run it on on something else and I'm using Jakarta 11. Other than that this is just a configuration to to have some different runtimes to test with. The application itself is a Jakarta restful application.

So it implements the the restful application and sets an application path. And I have a simple resource where I can where I can do stuff. So so the first thing I have to do is to define the managed thread factory. So so So so what I do there is I have an annotation here and and you can see I I give it a name I I call

it my thread my managed thread factory I can do give it any name I want. Uh And I want to give uh uh a a flag virtual equals true because I want to have virtual threads. And then in in the where I want to use it, I can I can obtain that resource with the at resource annotation. So so and and this is the name, my managed

thread factory is the same one as I had here. So I just do a a look on that so I have the thread factory. And and that then I can do the start the thread. So I'll just spin off a new thread, say it's running, start it. And then I can and just return the the name of that thread. So so it it doesn't do anything serious,

it just uh it spins off the thread. So Java version. So I'm on 17 here. So so what I'm going to do is Maven clean package. Uh maybe I should spell it correctly. Uh there we go. So so I'll just build it. And and then what I do is to run it in Open Liberty. So Maven Liberty run. So you notice I'm not building it again, I'm

just running it with with the this Maven thing. I could I could run it separately as well, but this is a little bit faster. So so it it it starts up. And when it's up here, I can do um I I call to the threads endpoint. So if I do this, you can see it it says task submitted on thread. Right? So let's stop the server again.

And then switch to use Java 26. So so I'm I'm now on 26 and I'll just run the server again. I'm not recompiling, I'm just running it. And and you can see it starts a little than previous. So so this is a good indication that if if if you want to and this is the the what the demos you see that it's now said virtual thread. Virtual

thread. Same application just running on a different platform that supports virtual threads. So so so that's the runtime support of the virtual thread. But what I'm saying is is if you have any resistance, why should we update Java versions? We'll just say performance. That's one one one thing. Security is another. Efficiency, everything. But but just just by upgrading the Java versions your app runs faster. You don't

even have to touch your code. So, let's look at data. And data was a new specification in And data introduced the the it's a it's a repository pattern for data access. And and if you're a Spring developer, you've probably seen this code before. But surprise for you, this is not Spring data. This is Jakarta data. So so what Spring did here with the Spring data is a

very popular technology and we wanted to to provide the same thing for our developers. So so we we kind of ripped off that that API and and created the same thing for Jakarta. And we also added a query language. So so we have a little bit better query support than Spring has. So so you have the app queries. You can write queries in annotations like this rather

than relying on method names or other more brittle ways of doing things. So, before I go on, I I can do a little demo of data, but uh no, I I think I'll skip the demo data because we don't have time. But I'll I can do it at the end if we have time. Otherwise, you can come to the booth afterwards. I'll be at the Eclipse Foundation

booth and I can run the demo for you there. So we're now this is the present Jakarta EE year So, so let's go to the future. And look at what's coming in Jakarta E12. And with Jakarta E12 we sort of have looked at what's coming and we're thinking let's call it robust and flexible. We usually have some kind of slogan around it. So, robust and flexible and

the reason why that is that it is a robust technology that is evolved over years. We've had it at the Eclipse Foundation since 2017 around there. Uh and it's been alive since 1999 so it's a very mature robust technology. It still is. And it's getting better because we're cleaning the kind of the the the the smaller things away and and making it better. It's also very flexible

because you can run it in every kind of application whether it's a microservice a modular monolith or a monolith or whatever kind of story Java SE even. It just a a you can you can run it as a as a CLI tool if you want. So, so, so it's a very flexible in where you run it. And and the size of the runtimes and In 12 we're

continuing the the the the thinking of that let's take the last LTS, make sure it runs on that one and let's take the current one which is 25. Uh we are on 26 now but 25 was the last LTS. So, so so you can use 25 features if you want. I'm using 24 26 and it works fine there as well but we will verify it on 21

and 25 at least. And Jakarta E12 it continues to evolve. This is a lot of blue specifications here. They're are minor updates in most of them. Some of them are more than others. Um persistence has a lot of changes a lot of cool changes a lot of powerful changes. The others are updates here and there. RESTful web services will have a good update. So, there are some

some good specifications here. We also adding the query specification. And we're also thinking of adding some other specifications. So, MVC is a most likely out, but no sequel is still a candidate to be added. And and we hope to add it and if you want to see no sequel in Jakarta, then this is the time you should voice your opinion on the mail list and tell us

tell those that don't want it that you want it so we can get it in because I think this is a very important technology for us to support. Query is a kind of a maintenance internal thing we're creating about by defining an object oriented query language with Java. We already have it in JPQL and JDQL. that is the Jakarta data persistent language and and a Jakarta persistence

query language. So, so what we're doing is pull the commonalities up there so that data and persistence can use this and they can specialize it where they need it. And if we get no sequel in, they may be using query as it is or add some stuff as well so we avoid the duplication. So, this is kind of an internal architectural thing of how we group the

specifications and avoid Jakarta no sequel is standardizing the integration with no sequel databases in the same way that Jakarta persistence does it with sequel databases today. And a fun fact here is that the implementation at Eclipse of Jakarta no which is called Eclipse JNoSQL that one implements Jakarta data as So, that means that you can use Jakarta data with sequel databases and no sequel databases. Seamlessly switch

data sources. Pretty pretty cool. Of course, you have to be on a very thin use case of these these things because it doesn't support everything, but still it's pretty cool to have that flexibility. MVC is not a candidate anymore, but MVC is still a cool specification. It standardized the action-based model view controller pattern. And it does it by extending Jakarta REST. So so we add the the

app controller annotation on a RESTful web service. So so it changes behavior and becomes a MVC controller. We also have another small annotation like for at view if you want to use that, you can also use a programmatic approach to that different ways of doing this with a fairly fine-grained control over how you want to create your application. It's a pretty cool specification. It's ready there whenever

server-side rendering is getting cool again. Jakarta 12 is scheduled to be in 2026. We're probably going to do the same thing as we did with 11 that core profile will be released later this year in in Q4 and the web profile and platform early next year. So it will be 26 27. We will support Java 25 at a query hopefully no sequel, be more CDI centric in

in Jakarta REST for example, and we will deprecate and clean up here and there. Jakarta 12 all the stuff there can be found on our issue tracker on GitHub. future after 12. should we replace EJBs? We know that this is very difficult for people because that is what the perception is. As I said in the beginning, even though it's been much simplified to to the at stateless

annotation, this is still too hard because the perception of of EJBs being difficult is still there. So we're going to make it a lot simpler. We're going to switch out stateless with And so it's a less characters for your for a AI tooling to generate. You will save some tokens there. And it will do the same thing, but it will be a CDI stereotype. So so rather

than being an enterprise Java bean with all that stuff that happens around there, it will do the same thing, but it will do it the CDI way. So so it will be transactional, secure, and and documented, and monitored, and all that kind of things. This is just a a thought experiment at the moment, but how we we envision that we can do a ad service in in

Jakarta. We're also looking at a Jakarta CRaC And do you know what CRaC is? So that's a coordinated restore at checkpoint. And that is about faster startup of Java applications. So so what we do is what CRaC does is to take a snapshot of your application when it runs good. It's like when you have your laptop up, you close the lid, and when you open it it

it is where you left it. That's how this works as well. So you you you avoid the startup and warm-up time of the JVM and the application itself, and you can just get started directly. It is an OpenJDK product project. it is still it is currently supported by a couple of runtimes, but we want to make it a specification out of it, so it's more standardized how

it works. In in IBM technology, for example, it's called Instant On. It's the same thing. They also implement the the CRaC APIs currently for it to work with Spring. of course we we we cannot have a talk anywhere without talking about AI. And and we're also talking about Jakarta AI. And we actually have a specification going on. It's the Jakarta Agent Artificial Intelligence. And it's under development.

So it's not a candidate for Hopefully for for 13. So so so this is uh this is work being done. So, if you want to look at that and look at what's going on in this specification and maybe contribute to this is a good place to start. Uh to go into the, uh the, uh the specification page page and and look up the the resources for how

to get involved with them there. When we talk about AI in enterprise applications, it's not about creating models. We're we're not going to have a Python version of Jakarta EE. We're not going to force anyone to to to implement anything using Python or anything. You can still be Java, you can still be Jakarta EE, you can have your application and you can integrate with the AI in

some way or the other. And, uh luckily today we can still we can already do that because we have a a some tooling around it. And a very popular API, uh out there is called LangChain for J. And we have a CDI version of it that is called LangChain for J CDI. And and that will integrate very well with Jakarta And I'll show this, uh in a

demo. we have a application here that is called, uh augmented Duke because it's an augmented AI system. So, so what I have here is, uh first of all, I'm on 26, I'm on Jakarta EE 11, and I have a a couple of annotations here. I have LangChain for J CDI portable extensions, so it works with CDI. Uh and I have, uh CDI config, so it works, uh

to be easily configured. Uh I have the LangChain core stuff. Uh and I have, uh the Open AI because I'm I'm integrating with Open AI. If you're integrating with something else, you can use wh- whatever other, uh AI thing, uh you're using. Uh and I also have some some skills, uh better versions here. So, if I look at at this, uh simple thingy here. So, I have

a simple skills service here. And this is how I do it. I annotate it with @RegisterAIService. So, So an interface here with one method that is chat. I can also give it a system message that says you're a helpful agent. So that's all I give it. So and and and what I say here is what you're going to do is call this AI and tell me who

is a famous white peking duck and what does a white peking duck say and where does white peking ducks live? So these things are are stuff I'm going to ask this AI. So so I'm going to start it here um clean. Just want to I think liberty. I started in dev mode so I can do some changes without restarting the server. So it's when it's up and

running here I'll I'll just call uh this endpoint. So I have it you see there. So I'm going to call this skills endpoint. And let's see what that So so what it's doing now is go out to to open AI and and ask this these three questions. And and now is where uh my demo demo is failing or not because now internet is involved, AI is involved.

So if you want to do something risky uh this is what you do. But but I I'll show you when when it's done doing it's it's running here how we can make it a little bit less risky and and control a little bit what we let the AI do. With standard uh Jakarta technology. So So what does it say here? So it says um all right. So

a famous duck is the Aflac duck from Aflac's TV commercials. Okay, that's good to know. It says quack. Uh more specific specifically we can look at what the female duck says and male ducks. Uh and it's a domesticated breed from China. Okay, but this is a this is long. This is not the maybe maybe this wasn't uh the duck guy I I I I want to control

a little what it says about these ducks. So, what I'm I I'm going to use some CDI magic here. And what I'm going to do is I I'm going register AI service. I'm not going to use this one. I'm going to use a more uh lower level way of doing it. So, so what to produce a skilled AI So, so what this is is a CDI producer.

So, so so I I can in in any application I I can create this producer. It produces a CDI bean. So, what it produces here is the skill simple skilled AI service. I'm saying go to open AI, use chat chat GPT, and say you're a helpful assistant. That's the same thing I said to the other one. But I also say follow these skill instructions in this skills.md

Let's see what it says now. So, so it should be updated. So, if I now go and and call this now a little bit more skilled service because I've given it some local skills. So, so so uh So, this is a an augmented AI or or a little bit more agentic way of doing it. So, let's see what what what it does. Uh hopefully it will still

know about this. Okay, it said "Donald Duck is Donald Duck." And what does duck say? "Oh, phooey." Or And what does he say? Can talk Donald Duck here. So, oh brother. And in current tracking and white picking ducks originate from Duckburg. So, so so this is how you can you can give your AI some some skills by by by adding a skills.md md file. And you can

do this I mean you're probably well known to do this with your development tooling, but you can do this in enterprise applications as well. To to give it a little bit narrower thing that this is this is what uh you want to do. So so this is the the duck and where it comes from. It doesn't stop there. There are also other libraries like OmniHi that is

a pretty cool. It's a little bit higher level API and all the different models and it's very easy to use and very little intrusive in your application. It's just one small dependency and you're good to go. how do we see AI moving on on Jakarta EE? So right now we we are on 11. We have the libraries we can use. So so you can say if you

if you remember back in the days from the the TVs you had if you were HD or or HD ready or stuff. So so we're definitely capable of integrating with AI today. There's no reason to wait for anything. We're capable to doing it today. How about 12? In 12 we would at least have Jakarta EE NoSQL which would make it even easier to do to to use

Ragged to augment your AI. So it will be better than it is today. So we can say we're AI ready back in When we move on to 13 which is far in the future, we will most likely introduce the Jakarta EE Genetic AI specification. So in this case we can say we're actually full AI. And what happens later? 14? Well, that's a little bit too far away

to say. So it's hard to know but at that time we'll probably be ultra AI. This is very speculative from my side. we'll see have to see how it goes. So nine was the namespace change. If you're still struggling with the namespace change, we have some tooling around that. We have the Eclipse Transformer and the Apache Tomcat migration tool which are are a binary that takes the

the JAR files and transforms it for you. So, you don't need to touch the code. Uh 10 introduced a lot of new things. Uh among those the core profile and CDI light. 11 introduces data and continues to evolve the specifications. We're now running on on 21 and higher. Uh 12 robust and flexible adding new specifications. Hopefully these two. we're now running on 25. And and 29. AI

works perfectly well with Some history from 1995 to 2025 30 years of Java and and Java EE and enterprise If you look at the the last releases of Jakarta EE you can see the 9 10 11 12 there two-year cadence. That's how we establishing us. And with AI we hope to we hope to move faster than this, but this is this is maybe where we're at. We'll

see how how we can move it. But the important thing is we're fully capable of doing AI today. With that I thank you very much for listening. And I hope you enjoyed the talk. If you want to find out more you can find it here. And if you want to know more you can come to the Eclipse Foundation booth right after this talk and I'll be there

and answer your questions. Thank you >> [music]