 Well, hello and welcome to another Dev Nation Live. I'm super excited to have you all here today. We have a large crowd to talk about the future of Java E. I know many of us here are kind of new to Java in some cases based on the chat that I've seen happening in the leading up to this presentation. We have people here who do some C-sharp work, moving to C-sharp on .NET Core microservices, and I have to admit, I do like .NET Core, and I've also seen a lot of Python happening in the big data space. There's a lot going on in JavaScript space, but today we're here to talk about Java. We do have some previously recorded sessions though. One that deep-dived into JavaScript, not too long ago, Enterprise JavaScript. Go check it out at our website. But now we're going to introduce you to Mark Little. We're going to get started with Mark Little. He's going to deep dive into what's happening in the Eclipse Foundation, and Jakarta EE, and Java EE. So, Mark, please get started. Thanks. Thanks, Bert. So I'm going to go straight to the slide and get going. Oh, there they are. Okay, so thanks for the introduction. As Bert says, I'm going to go a quick whirlwind tour of the future of Enterprise Java, sometimes called Java EE, and where it's going in the Eclipse Foundation. So if you've been around in the Java industry, even if you haven't used Java EE, you might kind of understand this little comic that I found online. Java and Java EE or J2E before it have been called dead probably more times than anything else over the last 20 years. But, you know, the reality is actually far from it. You know, as this slide shows, Java EE has been around for almost two decades, and it's dominated the Enterprise Middleware scene for many, many years. And, you know, like it or load it, Java EE deployments do form the backbone of many systems that we take for granted today in healthcare and in financial services, for instance. Even many of the more popular frameworks, such as Spring, use components that were developed originally in Java EE or required to be deployed into a Java EE application server. But, you know, because Java EE has been around for so long, it's inevitable that new technologies and new languages and frameworks will come along and gather more momentum. And Java EE has, for a number of years, had quite an image problem that various implementations have been bloated that perhaps it's monolithic, not suitable for, you know, agile development, not suitable for the next generation of cloud-native applications, for instance. I mean, I'm not gonna spend too much time on that, except to say I kind of disagree, but maybe that's me not being, you could say maybe I'm not being objective. But there are also some good points made for Java EE, at least in terms of how quickly, you know, it's taken hold in the industry. And there are some relevant points about problems with it, such as the speed at which it moves. Again, you know, you look at this slide here and there have been eight releases in 20 years. Many people complain that it isn't able to adapt quickly enough to the changes that are going on in the industry, such as Internet of Things or, like I said earlier, Cloud. And in many ways, that's precisely why, at DevNation in 2016, Red Hat, IBM, Tommy Tribe, Payara, and a number of the large Java user groups, such as Sue Java, which is the largest Java user group in the world, we got together and we announced something called Micro-Profile. And the idea about Micro-Profile was to try and leverage the good bits of Java EE and use them in a way that would help next-generation microservices developers to, like I said, leverage the enterprise, the industry standards that are out there, such as enterprise messaging and transactions, but without having to have a full-blown app server. And also to bring in other things from other areas of the open-source environment that are perhaps pushing microservices and cloud-native development a little bit faster than Java EE was, including things like Netflix, OSS, and perhaps even Spring Boot. Now, since 2016, we've seen a huge amount of community interest and adoption. There are over seven different independent implementations of Micro-Profile to this date. And the aim as this slide states, and I'm not gonna go through it all word for word, you can have these slides afterwards, was not to throw away Java EE, but to build on the experiences of it. Somebody's playing around with the slides. Please stop. And drive more innovation upstream through open-source collaboration. Another aim was that if we eventually got to a point where we wanted to standardize specific APIs, we'd return to the Java community process, which is the process that has been driving J2E and Java EE before it. Now, again, I don't wanna spend too much time on Micro-Profile because I wanna get to Jakarta EE, but last year, because of the sheer amount of adoption that we were seeing an interest around Micro-Profile, we decided to move that to the Eclipse Foundation. So everything that we're doing, it's always been upstream anyway, but now it's under the banner of the Eclipse Foundation. And in the last 18 months, we've announced Micro-Profile at Dev Nation and we've had this move to the Eclipse Foundation. And yet we've also been able to do three major releases of Eclipse Micro-Profile. We're actually working on the fourth one as I speak. As you can see from this slide, some of the things that we worked on, they don't exist in Java EE today. Things like the fault tolerance spec, the metric spec, health check. And again, the idea is to push these back into a standard's effort if and when that becomes necessary. But clearly there was one company missing from the Micro-Profile effort and that was Oracle. And what's been going on with Java EE in the meantime? Well, Java EE itself has evolved, like I said earlier, it's evolved slowly. And again, if you've been around long enough, you'll have heard some of the reports of its death over the last 18 months or maybe even two years, maybe even experienced a few of them firsthand. It seemed that Oracle was pulling back from Java EE, possibly even from Java. There were rumors that a lot of people being laid off that the relatively slow movement of JSRs, which is how Java EE evolves with its specifications, was getting even slower because Oracle was pulling people off them to work on other things. So there clearly were rumors of this being the end of Java EE. But as I said here, Java EE8 was finalized in September 2017 in time for Java 1. But if we compare what's here in Java EE8 to what we've been doing in Micro-Profile, you can see that it's relatively incremental. There's none of the big things that we were working on, collaboratively upstream with the likes of IBM and Tommy Tribe and other big companies and small companies and also individuals. But also at Java on 2017, there was another announcement and I actually think in some ways it's bigger than the EE8 announcement. And that was that working behind the scenes, Oracle had reached out to IBM, Red Hat, Tommy Tribe and others to see if there was interest and collaborative efforts. Again, somebody's playing around with slides to move Java EE to an open source foundation. At the time, we didn't know what that open source foundation was, but eventually without giving it away, which I'll talk to in a few slides, we eventually decided to move it to the Eclipse Foundation. And I think it was a pretty big thing for everybody to do. I mean, if we just stop here for a second and let it sink in, you know, this is something that Sun Microsystems that was driving Java EE before the Oracle acquisition didn't do. They open-source Java with the OpenJDK project, which was a great thing. But there was always this perception that, you know, if Sun didn't do it, then Oracle would never do it because, you know, they clearly were doing the acquisition of Sun to drive revenue, and why would they give away what many people perceived as being the crown jewels? And yet they did decide that it was the right thing to do at the right time. All of the investments that have been made over those 20 years, if you remember the slide I had earlier, from Oracle, from Sun before it, from Red Hat, from IBM, from companies big and small, including Google foundations like Apache, all of that effort that has gone into making Java EE, you know, this dominant enterprise Java stack was basically going to be moved to an open-source foundation and no single company would control it. That is huge. That's really, you know, at the time I said that probably the only other thing that has happened in the whole Java ecosystem that comes close to it is when Sun created OpenJDK. Like I said, though, at the time when we made the announcement, we didn't know where we were going to go with it. Well, hot on the heels of moving Eclipse micro-profile to the Eclipse Foundation, we decided that we would move it to the Eclipse Foundation and the top-level project is called E4J. So that's Eclipse Enterprise for Java, notes, and I'll mention this again in a few slides. That's not the brand. That's actually a very specific Eclipse thing. That's where all of the projects, all of the source code, things like Glassfish, et cetera, reference implementations, they would reside or they will reside under that top-level project, but it is not the brand. So E4J's mission is pretty clear. We are actively working with colleagues in Oracle and Red Hat, sorry, in IBM and others upstream to move all of the current EAPIs, reference implementations and TCKs across to the Eclipse Foundation into this top-level project, looking for wide community participation, transferring ownership or leadership, if you like, of some of these projects from Oracle or IBM or others to members of the community and updating the specs as we go to the latest version of Java. Critically, we also want to update the process by which these things evolve. Now, I mentioned it earlier, but the Java community process is the process that's been in place for 18 years and overseeing the evolution of Java EE from J2E through to Java EE8. But, as I said again earlier, the perception is that this thing moves too slowly, perhaps it's not as inclusive as it should be, and it's not necessarily as seamless in its interactions with open-source communities. So, moving just the code and just the RIs and the TCKs to the Eclipse Foundation, but leaving everything under the control of the JCP wouldn't necessarily achieve the kind of things that we want to achieve. So, we are working again upstream, completely open and know-behind closed-doors efforts to define a new process that allows everybody to have a say in how these specs evolve, how these implementations evolve as well. And one of the biggest things that we're doing is kind of lifting and shifting all of the code that exists, hopefully some of these names like Grizzly and Jersey will not necessarily be new to people on this call, but these are big code bases that, like I said, power a lot of industries today, and we're moving them all and re-licensing them to the Eclipse Foundation. So, here's a, for those interested, quite a nice website that the Eclipse Foundation created. I forgot to put the URL on the web on the actual slide, so I'll mention it here. It's eclipse.org, forward slash E for J, forward slash status dot PHP, and it tracks in real time how the specs, how the reference implementations, how the TCKs are moving through that process from being in the control of Oracle, if you like, across to the Eclipse Foundation. And things move very, very quickly such that I pulled that slide together about a week ago, and if you go there now, I know it looks very, very different to what I've shown. Now, as I said, E for J is the name of the top-level project. It's not the brand name. We ran an open process for people to submit names for the brand, as well as an open process for the logo that would go with it. And there was a vote on both. Jakarta EE is the name that won the brand name, so that essentially becomes the new name of Java EE. And the logo is the one you see here, the clipper, and I'm actually quite pleased to say that that logo was presented, was designed and then presented to the Eclipse Foundation by one of Red Hat's own graphic artists. Okay, so quickly, what's the relationship between Jakarta EE and Eclipse Micro-Profile? Well, it's clear that they both are on kind of an overlapping trajectory at this point. And we do feel that, again, under the control of both communities, at some point, they will come together. These two efforts should merge and Jakarta EE should start to evolve in a very similar direction to where Micro-Profile was heading and Micro-Profile falls underneath Jakarta EE. But, you know, is it still just Java EE? Because if it is, then, you know, is it still gonna have the perception issues that we saw and I described earlier? Because despite the name change, at least initially the technology and the specs are just the same as they were last year. So we've got to address that perception issue and the best way of addressing it is by, you know, driving the specs and the reference implementations in the right direction. I mentioned what we've done with Micro-Profile. I do believe, given the adoption we're seeing with that, that there's a lot of lessons to be learned for Jakarta EE and hopefully we are starting to have that cross-pollination. And it's also interesting to note that there are a number of companies that have publicly joined Jakarta EE that never joined Java EE or at least didn't join in a very active way. So one is Pivotal, for instance. Another is LightBend, who aren't even typically in the Java market. They're much more in the Scala arena. So it's great to see that wider community adoption. But really what I want to let you guys know and hopefully instill in you is that this is not Java EE of old. We're rapidly evolving things. We are really starting to look to address feature gaps that we've had called out over the years, things like asynchronous APIs, making it cloud native, removing legacy things like Cobra and IOP, which we'd started to do under Java EE. There are going to be no field of use restrictions, which some people may know about. I don't really have time to go into that too much. But how we evolve it is going to be driven by the community. It's not going to be driven by one vendor or a few vendors who happen to get together and make some votes on a particular direction. The community is going to get together and has a great opportunity to define where we go in the future. And clearly some areas that are influencing things are microservices. They influence directly where we went with micro profile. We've been seeing Java EE app servers used in microservices for a number of years anyway, but there's a lot more that we can do and we should do. And I think this is already, if you look at the Jakarta EE community mailing list, you'll see a lot of discussions on this, as well as the discussions that are happening on micro profile. The next few slides are really just to give you an idea of some of the conversations that we're already having, which we wouldn't have had in the JCP and the Java EE world. And again, to try and get everybody here, hopefully so interested that you want to either get involved in some of these things directly or come in and propose some new areas based on your own experiences. But where do transactions go in microservices? This is something I like myself because my background is around transactions, but traditional asset transactions, they probably or definitely don't have a role in microservices to the degree they had in Java EE. We've got to evolve that. There's work going on with the Lightben folks and others over the last few years as well around saga-based transactions. It's an active area, and if you have an interest in that, please get involved. Again, just talking about the Lightben people, but how do we do asynchronous reactive in Enterprise Java? This is not something that your traditional Java EE specifications, let alone implementations, are geared to do. So the conversations are already on about how we would do that by modifying the specs and then by getting involved and defining new APIs, defining new reference implementations. It was originally kicked off by James Roper and his colleagues from Lightben. There's a lot of activity now with some of the Eclipse vertex team, if anybody has heard of that. Again, it just goes to the point of how this is a collaborative thing. It's not being driven by one vendor or a smaller number of vendors. There's a lot of interest from the wider community as well. Redpipers is another effort that's feeding into jacquardery and micro profile, at least in terms of conversations and experience. What we want to do with jacquardery is exactly what we've been doing with Eclipse Micro Profile and having conversations based around experiences. This is why we didn't go originally in micro profile to start talking about standardizing first. The worst standards are the ones that aren't based on experience. So everything that we're doing in micro profile and hence everything I think we really need to do in jacquardery needs to be driven through experiences. The more community members we have involved, the better. You don't have to bring code. You don't have to bring your time to actually start to hack on a spec or a reference implementation. You can come and have just as much of an impact if not more by bringing your point of view on a particular topic and even kicking off a particular topic and just leading that and then getting other people from other companies and other organizations and other Java user groups, for instance, to help drive that in a particular direction. Clearly over the last few years, we've seen a lot of interest in Linux containers such as Docker and then Kubernetes as the de facto standard for orchestration of those containers. Last year, we saw a new kid on the block if you like a sidecar approach, which had been around for about six months or so in other guises, but then Istio came on the scene and really took the limelight and drove a lot of the interest in that. Not only does how Linux containers in Kubernetes fit into the jacquardery world, but how does Istio work with jacquardery? Can we offload some capabilities that we would typically have found in your traditional app server into Kubernetes and Istio? And here are some efforts. This is around Wildfly Swarm, which is our own redhead implementation of Eclipse Micro-Profile, but I show this because just to give you an indication, these are again the wider, more cloud-native discussions that we're having as a community upstream and then feeding into jacquardery. So hopefully, I've given you a whirlwind tour of what's brought us to where we are. I really do think that jacquardery offers us a great opportunity to evolve a series of specs and a series of reference implementations and potentially a series of implementations of the whole spec suite in a direction that makes a lot more sense for where we are today as an enterprise Java community, but it fails or succeeds based on getting the community involved. And that, as I said before, that involvement can range from coming in and telling us about use cases to all the way through to giving your time to donate code or donate your time to work on existing code. We need you and hopefully I've given you an idea of some areas where you can come and get involved. It's not an exclusive list. Go to the Eclipse website, join. It's free to join. There's no membership fees. You can get involved five seconds after this talk ends and just read the mail archives. Jump in if you want to ask for help about areas where maybe you can contribute. It's a very welcoming community. It's a very large community now and the more the merrier. So with that said, I hopefully have left a bit of time for some questions. Very good. And actually, Mark, we have a little bit of discussion to have, but I want to make sure we get the link correct for the Eclipse Foundation and Jakarta EE. I have one I found here because that already is the first question. It's like, okay, great. I want to get involved. How do I find out more about the Jakarta EE effort? What is the right mailing list to join and things like that? So let me, can I post something in the chat? Let me see if that works. Yeah. Just add it to the chat tab. Does that work? Let's see here. Yeah. There we go. Okay. I'll post something. On the EE for Japh, I think. So that will take you to the EE for Japh FAQ. And like I said, that's kind of an artifact of the Eclipse Foundation. So that's where everything is happening. That links off everything. But if you go from there, there's another one talking about Jakarta EE FAQ directly. Another way to get involved, if you want to reach out to me directly, I'm more than happy to field questions and point you in the right direction. Okay. A couple of questions here that I think are really important that we want to make sure we cover. One is, will there be a large-scale repackaging? There's that Java X aspect of Java EE. Do you think there's any kind of, I assume that's the kind of packaging people are worried about because that does impact their code? So what Oracle have said, and they've been very public about this. So again, you can Google it or find it in the mailing lists. Anything that's currently under the Java X package will stay under the Java X package. But new things. So, for instance, if we take the fault tolerance spec from Micro Profile and push that into Jakarta EE, that would not fall under the Java X package. That would need to be a new package. And we don't know what that package is yet. Again, we're going to, we're working on that in one of the working groups upstream in the Jakarta EE effort. Okay. And there was another question related to certifications for things like DOD. You know, so what I take from that question is, at what point where we see large customers like the big government DOD start requiring, you know, certain seals of approval, if you will, from the Jakarta EE movement. Do you have any idea on that one? That's a good question. I think implicitly probably, I should have said, the first release of Jakarta EE will be Jakarta EE 8. I think I got the numbering right. And that will be essentially the same as Java EE 8. So what we're doing, the lifting shift is to take Java EE 8, moving across to Eclipse becomes Jakarta EE 8. And it will be identical. So any certification that was for Java EE 8 should, in theory, happen naturally with Jakarta EE 8. As we go forward, though, and evolve things, I think it's going to, we'll clearly need a re-certification and that's going to be driven by, you know, a matter of interest. Maybe it'll be something that particular vendors will get involved with, as often seems to be the case with certification. But, you know, that's probably the best answer I have for you at the moment. It's a bit hazy after the initial release. Okay. Good question. I also see here related to Angular, React, and other really awesome client-side libraries we see for building MVC-style applications. What might happen with Java server faces? Do you have any feeling on Java server faces? Yeah, so the honest answer, I won't focus specifically on Java server faces, but I'll say the honest answer for Java server faces, JMS, JPA, the orb, anything. You name a component in Java EE and the answer to its future is, it depends on where the community wants to take it. It's no longer the domain of Oracle to define or Red Hat to define or IBM to define or that collection of companies to define. And then, you know, the community finds out after the decision is being made. It really is down to the community. And if you have a, you can get involved in every single one of these specs now. You just need to become an Eclipse member and sign up and then start making commits. Okay. And there was a great question related to MVC, and I think it falls in the exact same category. You know, I've seen a lot of excitement around the MVC specification myself out in the community. Do you have any personal feeling about MVC, Mark? So MVC is, there were a number of specs that did not fall under Oracle's control. MVC was one of them. And the MVC lead is one of the PMC chairs along with myself on Jakarta EE. And one of the first things that he did was donate MVC to the Eclipse Foundation. So that's now already part of Jakarta EE. And it will be part of the, you know, the evolution. Where it goes after that, again, is going to be down to the community. But you're right, there's been an awful lot of interest from it. And there was a lot of interest at, you know, some of the recent Java conferences like Java land. Okay. And there's, we'll take this one final question because I think it's a very good one. And in the case of traditional Java EE, it had a very definitive packaging structure, you know, your ears, your wars, your jars. What about in this world of microservices? What about the world of containers and even a containerless architecture? What are your thoughts on that? That is a great question. And rather than me answer it, I will tell you, that is actually a topic that is going on now in the Jakarta EE community mailing list. It's a long, long thread. And it's about what happens to ears going forward. So not wanting to, I deliberately don't answer it because I want to encourage at least the person who asked the question to become an Eclipse Jakarta EE member and get involved in that conversation. Okay. Fantastic. So Ryan, we're talking to you there. And also don't forget to check out MicroProfile.io. There is another way of thinking through packaging in terms of Javi libraries in the case of MicroProfile.io. So all that is happening right now in that community. Well, we are out of time. I thank you so much for your questions. We had a huge audience today and a lot of chat, even including conversations around what do I learn as far as being a new programmer. I apologize, we couldn't really drill down on some of those things. Try to stay on topic. Some questions around spring and how spring is integrated with this. But overall, fantastic discussion. Thank you so much. Make sure to check out those links that we provided in the chat and in the Q&A tab and definitely join our community and show up again for another Dev Nation Live. Thank you so much, Mark, for having us today, kind of hanging out with us. And don't forget, we have a first and third Tuesday of this event. Awesome stuff. Thank you so much, Mark.