Foojay Podcast #3: Journey to Jakarta EE

Transcript

Automatically generated from the audio, so it can contain errors in names and technical terms. Suggest a correction.

[0:00] Hello and welcome to the Foojay podcast today we’re going to be talking about Java ee Jakarta EE and their role in cloud-first environment specifically we’re going to talk about what’s the role of a 10 year old server-based specification for app servers when many things in the cloud are serverless or server service based and with the development of things like micro profile containers and thin Wars there’s actually a lot more than you’d expect for the current Jakarta EE and it’s nothing like its early 2000s heavyweight cousin and with the migration from java ee to Jakarta ee that’s now hosted at the eclipse foundation with tons of Industry contributors there’s a lot of great things for everyone welcome to the Foojay podcast all your news about OpenJDK now I’m going to go through and we’re going to introduce the guests on today’s podcast hi there my name is Eva grimstead I’m the Jakarta ee developer Advocate at Eclipse Foundation and I’m happy to be here at the Foojay podcast and so thank you for inviting me yeah hello I’m Richard bisser I’m working as product manager for payata at the moment so my goal is to have a nice

[1:18] Implementation of the entire Jakarta ee spec within our products and of course very very nice to be invited for this talk my name is Josh Juno I’m a Java ee to Carter e developer and DBA by day I’m an author and open source contributor by night and I really appreciate the invite this is going to be fun and I’m Eric costlow I handle developer relations for contrast security we help embed security tools inside of applications and very much in the Java and Jakarta ee specification to pick out ways that those applications are vulnerable and demonstrated to people so that they can actually fix security risk in custom and third-party code and what we want to do to start the podcast is to go through and summarize a couple of the recent articles that have gone on Foojay that relate to Jakarta ee ecosystem so the first one that we want to talk about it was called is the job at Jakarta ee deployment model out of date so Rudy since you deal a lot with pyara and the presence of different Java EE and Jakarta ee specifications do you mind summarizing this one and just giving us a little bit of background

[2:31] Yeah sure well for those that soon that know Jakarta you have a deployment model where you build your application Within A Word file or an ear file and then you run it on the runtime that’s also called the application server sometimes there is a lot of change here during the last 10 years or so there are movements of going to a fat Str application for instance where you combine the runtime and your application into one artifact and run it as such but we still think that the deployment model of Jakarta ee is a very good one because the developer needs to concentrate on creating the application it should not be working around how should I deploy this in the environment is it how is the environment a cloud environment is the environment maybe even a Raspberry Pi so he needs to concentrate on delivering the functionalities the second step is then how do you get your application up and running and that’s something different with that deployments model of Jakarta you can perfectly balance those two you have the developer who creates the application and then later on the operations can deploy it and configure

[3:56] It to wherever they like so they don’t need to care that the developers don’t need to care about the infrastructure which is always nice they should concentrate on what they should do providing functionality for the end user so besides that Hollow at the thin Word file which we have with DJ Carter the fat jar has it has some advantages because it is just simple one single artifact that you need to install but currently we mentioned in the cloud era a lot of a lot of those systems are using containers with different layers if you package your application together with your runtime then every single line that you change within your code results in an entire New Image container image that not only contains that one single change and also includes the unchanged runtime so that’s an overhead which slows down your deployment and Etc so we tax deployments model although it is 10 20 years old well that fits perfectly for your Cloud environment because if your application change your Wi-Fi changes and only that change is pushed to your infrastructure so for me there are two main reasons why

[5:18] Jakarta deployment model is still a very good one a very good fit for today’s applications even in a cloud environment got it and what’s what exactly is the difference between a thin war and a fat War but yeah so with that Teen Wolf file you only have your application code there so your business logic that you have written for your application maybe some third-party dependencies that you are required for that specific application only that is included within the word file but not your runtime so for instance payal server or via micro is not included in that inward file in that artifact that means it is much smaller it is sometimes much smaller than one megabyte and that means that it is easier to transport it is faster Etc and as I said you don’t need to push every time that big layer to your infrastructure because you have changed one little line of code because in that Fab jar there is not only your application but the entire runtime I would just like to add that I really do think that there is still a place in the world for monolithic applications and deploying to an application server

[6:35] Container you know not every application is well suited for the microservices or cloud-based deployment there are lots of Enterprises that really rely upon application server containers and there are also ways to make applications modular and still run them in the same container you know you can have different portions of an application running in an application server container and you know swap them out as needed or modify as needed and it’s still a very efficient way to run Java e and jakarti application so I do think that the deployment model is still valid in this era and I think it will be valid for a long time to come so this actually sounds really helpful because it used to be the days of you had a server that was there and the server would already be installed with like a pyara or a web server or weblogic but Rudy it sounds like what you’re saying is now you can package the application server or like the pi r micro profile runtime as part of the application so that if you need to deploy somewhere it’s not like you’re deploying to this pre-existing server

[7:45] That’s been set up it seems like you’re deploying the whole application all in one which probably makes it easy to go especially to like a horizontally scalable environment it is this possible but it’s not a requirement because as I mentioned you can easily do the same thing even the horizontal scaling without having a fat share file so the show the fact that you choose to include a runtime yes or no that’s that has nothing to do how you are going to run it so you can indeed includes within your application the pr Michael runtime but you can also keep it outside of it so you can start by a micro like a Java minus jar option so you start the runtime as a simple Java application and then you point to default file and it then it loads that word file at the same time that this it is running your prior micro application so it is a possibility we have included it for those who want it but it’s not a requirement so that deployment small model of a separate what file you can still use it to them even with that more modern approach of that payer micro which is not really an installable artifact but you just run it

[9:03] And it installs it during the put of the runtime itself Okay cool so it sounds like the Jakarta ee deployment model is still modern and definitely not out of date because you can change it to whatever you want it to be given the way that your application works yes correct nice all right and with that with the Java deployment model being present in date we have right now we’re in kind of a cloud-first world where everybody wants to deploy things up into the cloud you’ve got AWS you’ve got Azure and you’ve got gcp you have all these different areas with servers and services so one of the other articles that we had on Foojay is also called is Java and Jakarta ee Cloud native so when we talk about the deployment model what can we say about the cloud Readiness of java and Jakarta ee yeah so this article is actually a kind of a pointer to a webinar series that Steve millage from priora did and I would really encourage everybody who has the time over to go and look at that webinar it’s is it five or six episodes and they’re all very relevant and absolutely something you should less

[10:23] Meant though and it actually this article ties very well into the things that Rudy was talking about and is Java or Jakarta ee Cloud native and how do you run the application securely in the cloud and to be able to talk about this you kind of have to Define what is cloud native and to Really Define Cloud native I’ll actually read some of these stuff from the cloud native Foundation that where they Define Cloud native and that is cloud native Technologies and power organizations to build and run scalable applications in modern dynamic environments such as public private and hybrid clouds so that is one part of it so we’re actually running if you’re running in able to run your application in a cloud environment you’re actually Cloud edit sort of the other thing is that the cloud native Computing Foundation seeks to drive adoption of this Paradigm by fostering and sustaining an ecosystem of Open Source vendor neutral projects and when you talk about open source and vendor neutral that’s where Eclipse Foundation fits in and that’s where Dakota Eve fits in so all these

[11:43] Technologies within Jakarta ee are vendor neutral they’re open standards so you can build your applications and deploy to any Cloud that offers them and one interesting thing if we tie back to the article that really was talking about is the old style of developing Java e and jakarti application servers applications where that you had your server running somewhere down in the basement or somewhere often under the desk of the developer but we don’t talk about that so you would deploy your application to the application server and you wouldn’t only deploy one application you would deploy two or three and all your applications into the same application server so that they were all running on this poor little machine under the desktop and this way of deployment that’s that’s not actually how you do things today when you develop a modern Jakarta application the way you do it today is that you have one application server and one application so you deploy one application into your application server and then you wrap that in a container or somewhere and run it wherever you want

[12:59] And if you think about this model the previous model where you had all the applications and put them in stuff them into your application server well that’s actually what we’re doing today when we’re taking all our applications and smash them into a kubernetes cluster unless that stuff manage everything so it’s kind of the same thing we just added the deployment thingy to it so all developers are now in addition to writing the actual code that earns you money the functionality code that really was talking about what you should focus up we’re also writing a lot of yaml to kind of orchestrate all these containers and if you think about how Jakarta e and the model that we used to have the ability to deploy all applications into a server that somebody else was taking care of if you have a system like like for example priority cloud or other providers out there where they manage these application servers in a way that they scale horizontally as much as you want and you as a developer you focus on building your application in the thin war and throw it down the cloud and let them handle it

[14:19] That’s kind of the Dream World for an foreign developer and when you add these Open Standards and open source apis that you’re using if I want to move to another vendor well I’ll take my thin war or my jakarti application and deploy it on another Cloud as long as I follow the standards there’s no vendor tie-in and I can deploy it anywhere I want in any cloud and let the people that actually know how to configure these things configure them for me so I can focus on making money after all we are Java developers are not configuration script developers yeah one of the ways that I deploy some of the code that I work on in my spare time you know Java developer By Night Josh to play off your term I I’ve really taken a liking to the quercus framework and so I just write a bunch of web actions that I test locally on my own system through just straight up HTTP then I native compile it and it Autumn I can automatically push it up into AWS Lambda or Azure functions and the whole thing just works there immediately and it takes care of the API Gateway it takes care of the execution and it’s just it’s the code

[15:36] That I’m I’ve written tested locally running native serverless on the cloud yeah and when you actually think about that you’re using the same apis the same Technologies as you would use if you’re writing a monolithic application for a bank in a server vault or if you’re creating microservices or if you’re creating serverless functions it’s all Jakarta e apis it’s all the same technology so it’s very flexible and can address any needs you would have asset developer yeah it’s actually what I’ve been doing I think it’s amazing because locally it’s a monolith when I deploy it to the AWS Lambda it’s no longer monolithic or maybe it is I don’t really know the details but the whole thing just runs and I was talking with Adam being a while ago and he tells me that it’s actually just using micro profile under the hood oh yeah so the Quarkus supports some of the micro profile apis and also they incorporate a lot of Jakarta Technologies as well as spring technology so that they have the possibility to package a lot of stuff in that runtime all right Josh what are you deploying up

[16:53] Into Cloud native applications through just the standard Jakarta ee specification like how often are you seeing people use that and how often do you use it yourself actually I’m a bad person to ask on that one because I don’t really deploy to the cloud that’s right so you just have a really cool environment maybe under your desk the area that we’re not supposed to have my server is under the desk no we do have kind of a local server environment that I deploy to and so it’s not really cloud-based yet it works very well for our needs and it does seem though that most of the applications that I am working with are either still in the monolithic format or we are broken out into Individual Services that are running in separate War files and those are then deployed to you know the scalable piara server or another local application server container that is just on a server a virtual server sitting in the environment okay so this is probably one of the reasons why it’s beneficial that Jakarta ee is both Cloud native and can also run locally because

[18:13] I used to do a lot of cost analysis of companies that would do migrations to the cloud and some of them would consume like three times their budget in about a fourth of their annual cost so imagine something costing three times the amount of your yearly spend in about a fourth of that time like it’s insanely expensive so what would happen is even though I know as like developers and people in technology we’re supposed to talk about everything moving to the cloud a lot of these organizations would start to move there and then they’d say whoa whoa we gotta scale this stuff back and then they would put it into a data center or something that ran in the on-premises environment just purely on a cost and effort basis so I know it’s real common for a lot of organizations to mix and match both of these yeah and I do believe that there are some security considerations for those who you know some organizations that do not want to be in the cloud for that reason or you know it’s just not an acceptable approach in some circumstances so having the ability to you know choose the dynamic and deploy to the cloud or deploy to a local

[19:24] Server environment you know it really is beneficial maybe I can comment on this that our that we see when our customers are using it that you have the entire range you have people who just run it on a physical Hardware so a physical server that is indeed stored somewhere under the desktop or in a separate room if you see them environments with virtual machines locally or within a data center we see them running on Azure and AWS so we see the entire range of options and possibilities used within our customer base so that’s I think one of the benefits you can choose what suits you most and indeed migration to the cloud can be sometimes costly because maybe they want to do more than they need to do as ever mentions what is cloud native basically it is running within a cloud environment making use of those Cloud resources like maybe monitoring and routing Etc a bit of automation but nothing prevents you from using whatever technology you like for that cloud native solution so Jakarta ee perfectly matches within that image all right yeah I think the only thing that I kind of I like

[20:52] What I’m seeing in the Jakarta ee space and in all these Foojay articles I think probably the only thing I don’t like is something called Veterans law of headlines which is more a journalist activity that anytime a question or anytime a headline is a question that can be answered yes or no the answer is usually no but in this case the answer is yes so it’s a bit of a headline state that we could probably change that because it seems like this is a really beneficial thing that makes it easy to deploy an application whether that runs locally as a monolith in the environment we’re not supposed to talk about or up in the cloud and I agree that’s just again to repeat it that’s one of the major benefits of running with Jakarta is you’ve got that flexibility to run it where you’d like and however it best suits your organization yeah and to come back to the story where we say that a developers needs to focus on functionality and also about their environment or even writing yaml because a lot of people don’t like writing yaml and all those kind of things that’s that is actually the goal of

[22:07] Of our product which we have now in the pipeline which is called piara Cloud that you only need to worry about that one file and you uploaded one file into the environment and the environment takes care of deploying it for you so you have the ability to specify some parameters configuration parameters like where is my database located or which are the values of my configuration parameters but after that it takes care of creating the container image for you it takes care of deploying that within the for the moment the azure environment and they’re running it on EQ but in the native system so you don’t need to write or yaml yourself it’s done for you it takes care of providing the routing it takes care of the SSL configuration so that you have is your application with secure endpoints Etc so again that’s the same deployment model as Jakarta to just deploy your what file that’s ever said to throw it on the cloud and the cloud knows what to do it that’s that’s the main idea of what we are doing now with biara Cloud for the moment we don’t have the opportunity to do have a free trial

[23:31] But it is just the deploying of your what file in an environment so it is exactly the same as what you do when you would run by our server locally so I mean in that sense it works as expected with if you know payer cool so if I want to try that I can just go ahead and use piara server or deploy any more that I want to my local system and it’s basically the same thing just I have less scalability because I don’t need that when I test yes correct so we are working on some scalability features and functionality but for in the first version it is just running your application as as it is later on We Will adding the options to have your scalability defined based on the numbers of requests or the load of your environment for instance one of the other good articles that came into the Foojay environment was just another question of why Java developers continue to rely on Jakarta EE and we’ve been talking about a lot of this over time of how it simplifies deployment in terms of writing a single application and just being able to help someone else manage the infrastructure but Josh do

[24:45] You want to talk a little bit about why developers are still relying on Jakarta EE and Java EE sure that’s that one is easy I think it’s standardization I yeah for years now you know Jakarta ee platform may be named different but it still uses the same apis as Java e has been using for years I think if you go back to Java E5 the platform started to change into a more modern platform so at that point we started to see easier deployment for ejbs and apis that made things much easier to use and then from there you know you move on to EE six and seven and things got much much more streamlined and much more easy to develop and much much more sophisticated without all of the XML configuration and whatnot that was required in the early days of java EE and so now today you know if you go to Jakarta ee it’s very much the same as we had in Java E8 but now there’s a new name space so instead of using Java X you’ll use Jakarta and that is basically the only difference at this point however it is more geared towards the cloud because at this point there are more apis that are going to be added

[26:15] It’s more extensible and it works very well with Solutions such as microprofile very pluggable and so you have flexibility in your architecture and you can use things that you would like to use or not use other portions of the platform so that’s another benefit is that there are multiple profiles for Jakarta ee you can if you think you are going to be building an application or a service that wants to make use of everything that’s part of Jakarta you can do that otherwise if you only want to use certain pieces of the platform you know there’s a web profile and I know in the future there are discussions about making even more profiles to make things more streamlined another nice thing is as mentioned by Evar earlier the backboard compatibility and standardization like I had mentioned really if you’re building a jakarti application you can still utilize all that functionality that was built possibly years ago on an earlier version of java ee you may have a little bit of imports changes to make with your namespace conversion but it’s still basically the same underlying apis

[27:29] Which gives you nice stability and it’s also very easy to configure as I had mentioned there are very little to no lines of XML that need to be written nowadays to deploy you can if you would like to configure and fine-tune things utilize XML but most of this now is this configuration is happening in annotations so there is much less configuration that is needed and much more programming or excuse me I shouldn’t say much more but it’s much more on the you know developer side where we can use nice features such as annotations and to do our configuration rather than going into XML and also there are lots of different containers that are compatible with your cardi if you go and look at the Jakarta ee site right now you can see the compatible implementations and so you’ve got lots of flexibility on where you’d like to deploy you know you may build an application using glassfish and then deploy through something like pyara or you can go to wildfly or some other container of your choosing so you’ve got lots of flexibility for the different you know deployment containers that you

[28:48] Choose so in terms of an application migration I know we have a lot of years of java EE and I do agree everything that I use is annotations based and I typically have an environment or properties file that specifies like where the database or where the message queue is so it’s really easy this notion that it’s heavy weight and stuff at least I haven’t found that for over you know 15 years or so Ivar as the eclipse Foundation kind of became the new steward of the Jakarta EE and you have the namespace change what are some of the things that people do to manage those import statements and just make a simple migration to take advantage of the new ecosystem oh so you have several opportunities there and but before I go there I just also want to add something to what Josh said here and also you have the from before you were thinking of a Jakarta or Java e application server as something big and heavy but the implementations nowadays that the modern implementations of compatible implementations of Jakarta e are much more streamlined and smaller than ever and they are so modular that

[30:06] You only kind of get what you need so you can configure them to just pick the choosers the pieces that you actually need in your application and have a minimal run time out of it so it’s not like you need the entire web square or weblogic or you name it you kind of get the pieces that you need so the namespace migration and this is actually something that is relevant not only for Jakarta e developers because if you think about it if you’re using spring framework you’re probably running it on a tomcat embedded in Spring boot or Jetty or something and all of these are on the Jakarta namespace so it will affect other developers than those who are pure chicory developers and there are tools to help you with it it’s not that hard to do manually but if you want to do it by just having your bytecode transformed you can use a tool called the eclipse Transformer that will take your byte code and change it from the Java x namespace to the Jakarta namespace now if you don’t want to use the eclipse tool you can go to Apache and find the Apache Tomcat migration tool

[31:26] Which will do the same thing so you can pick and choose what tool you want and if you don’t want to do this and stick to the Java X namespace well most of these implementations of Jakari actually embed a the Transformer or similar Tooling in the runtime so you can deploy your Java X based application and it will be at runtime transformed to Jakarta and run as if it were on the new namespace what I would recommend a developer to do if you have can do it is to actually do the change yourself and transform it and not do the bytecode manipulation and for that good luck there’s tooling there as well the latest version of IntelliJ has built-in migration supports you can just open up your application on the javax namespace click and you’re done so there are lots of options out there to do this stuff for you so there are no way to no no reason to wait it’s just go in there and click migrate and you’re done wow that’s cool I didn’t know that the IDE would literally just go ahead and do it for you for your custom code yeah it will I I’m not sure if it’s actually out there or if it’s still a

[32:44] Beta but the next version of IntelliJ will definitely support this yeah that sounds like something that they would be doing but that’s just I mean that’s cool because now you can take credit for it and then like you know maybe spend some time go do something else for a while and say oh I spent two hours changing something and you know kick back and relax I guess exactly Rudy question does pyra the current versions of Pi R server don’t they use the eclipse Transformer if you would like to utilize the Jakarta namespace yes correct our current version of Prior five uses the Transformer so that you can use the newer version so the Jakarta based namespace applications on your existing pair of five so you don’t need to change the reason behind that is that maybe you have a larger organization and you don’t want to switch in at a certain moment so that you can do a gradual switch from the from one namespace to the other and as ever mentioned I think all vendors have that also in their newer product based on DJ carton namespace because Java EE and also Jakarta ee is known for

[34:01] Its backwards compatibility I also mentioned it just so this namespace change although it was required for legal reasons is of course a big event in the community because it is for the first time in let’s say 20 years that such thing happened that there is a major breaking change that’s something potentially did not work from before so that’s the reason why all those fund vendors put it in there product so that the ease of migration is easier and can be managed more gradually yeah even though that name says migration looks like a big event on paper I haven’t really seen too many problems or difficulties with it like almost everything that I see works just fine I’m sure I’ve probably seen something not work but like I’m trying to think of it now and I can’t come up with an example I’m just kind of keeping a door open to pretend that something isn’t yeah and what we also see is that most products open source projects or on and others out there are adopting the namespace so you can already run hibernate with the Jakarta namespace and as I mentioned Jetty and Tomcat the next major versions of spring

[35:21] Framework and the spring boot will also adopt the Jakarta namespace because if you think about it if you’re using spring framework you’re using a lot of Jakarta ee code underneath and also some of them are actually exposed to like Bean validation is used directly in Spring as well as the as I mentioned the hibernate for persistence so when these kind of products are moving to the Jakarta namespace spring framework will follow and then you will see all the major group of developers moving over to the Garden namespace as well yeah there’s so much cool stuff here I know I talk to people all the time who say haha I don’t use ee I use spring and you know you just kind of sit there and you go oh but did you know it actually uses ee under the hood so congratulations you are actually using it yeah that’s right or I know I like I said I’m a big fan of Quarkus because it just it has made a lot of good decisions and kind of gives me an easy to develop with framework and you know when I was having that conversation with Adam I was surprised how much of it is actually

[36:34] Just picking up parts of Jakarta EE and like showing them to me yeah and one thing we’re actually working on you mentioned it briefly previously for jakarti time we are introducing a new profile which we’re calling the core profile and one of the goals of this profile is to make runtimes like quarkus able to be certified on Jakarta SL so we’re we’re creating a subset of Technologies and also streamlining some some of them that it makes it easier to do the native compilation that quircus does so you would be able to have smaller runtimes that are certified jakarohi core profile and be compiling to Native so that’s a step in the even further a step in the direction of the cloud cool yeah I remember the last thing that I natively compiled it went from about a 70 megabyte Deployable to about a 20 megabyte Deployable and is I think about five times faster yeah so when you’re doing that you can kind of stop talking about Jakari even big and slow yeah my stuff starts up in like 100 milliseconds so like slow is not the word I would use and what we’re also working on

[38:05] Now is as I said we’re working on jakarti 10 and actually last week we announced the release plan for jakarti itam and we are going to start releasing the individual specifications as soon as in October and continue to have to release process because there are some dependencies between them so just do it slowly and carefully and make sure everything is right and then be able to release a version of platform and the web profile in q1 next year and the core profile will follow shortly after that so we will have we’re doing something new here by releasing the profiles independently and we’re doing it approximately a year after the last release so it’s a pretty fast pace of development going on there in Jakarta right now all right so if we want to get started and use Jakarta ee to 9 today which is the current version what level of support is there for building the applications whether it’s a Greenfield app or whether we’re doing the migrations like what tools are people using well I know that Apache netbeans 12.4 has Chip cardi E9 support in it you can

[39:26] Also use 12.5 which is currently in beta and this will allow you to use glassfish six so there is support out there and actually for the namespace migration is very easy to do as well you know you can just go ahead and start to create applications in netbeans and use Jakarta E9 as your specification and then just start to use the new namespace and there everything seems to work seamlessly and I know that also as Evar had mentioned earlier IntelliJ has support for tricarti 9 as well I’m not sure does anyone know about the eclipse they do have some support for some of the apis there is a project that is pretty interesting going on in Eclipse Foundation it’s mainly driven by some students that are being Guided by Engineers from IBM which is a language server for Jakarta ee so they’re developing a language server for some of the apis and these are running very smoothly and nicely in the Eclipse IDE as well and this is a open standard language server protocol so basically every IDE could use it if they wanted to cool so that’ll help people simplify the migration of ensuring their application

[40:49] Is up to date as they bring their start times down to like the 100 millisecond that modern Jakarta ee gets another thing that should be mentioned is that there is a you know a landing page now for on the web such as with other Frameworks you can go ahead and just create a standard out of the box Jakarta application just with a click of a button now integrating in whatever Technologies you’d like to use and then to deploy and then we’ll just go ahead and run Okay cool so kind of like the spring initializer or the code.quarcus where you just say like I want this and it gives you a skeleton project where you have like only the parts of the spec that you need and nothing else yeah that’s correct you can choose what you’d like to use and also the other solution is if you’re using microprofile which is also what your cardi compliant that also has a similar interface on the web so easy to create a application that is just a very small skeleton application and build up from there if you’re if you want to create from scratch yes indeed there is there are exciting times it’s not that because

[42:04] Jakarta or at the ancestor Java e is 20 years old that you cannot use with modern Technologies you can just deploy it where you la where you like what do you for example a periodic cloud is that a nice one for so yeah we are very Keen to see the next steps with Jakarta ee10 the new functionality in features and beyond that because it seems to have a regained again a lot of growth and we are happy then of course because we are a big fan of Jakarta EE yeah it’s pretty amazing that the technology can live on for so many years and still be vibrant we have a large community of contributors there are companies and there are individuals and we always looking for more so if you are interested in participating within Jakarta go to jakarta.e connect with us and start joining developing this excellent technology yeah there’s definitely a lot of cool and really great stuff going on and it’s really easy to use it’s really easy to use locally and it’s really easy to use up in the cloud so I think a lot of great things have been getting done in that ecosystem all right thank you both there thank you

[43:19] All very much for attending today’s podcast and I want to thank everyone else for listening give me the friends of OpenJDK