 Hi everybody! For those who don't know me, my name is Mike Lankiewicz. I'm the executive director of the Eclipse Foundation. And my talk today is called Jakarta EE Free at Last, probably an excessive title, but I got a bunch of people in a room, so it worked. So the talk is really about what we've been doing for the last two and a half years, transitioning the technology formally known as Java EE from the Oracle and JCP over to the Eclipse Foundation and a little bit of what that means. So this is not a technical talk. I'm happy to answer questions to the best of my ability as we go through this, but my ability to write code expired a long time ago. So, all right, so we've talked a little bit about how this thing, the whole thing got started, a little bit about how the Java EE ecosystem worked. For those of people that are in the Java ecosystem, some of this is going to be familiar. What we actually did to pick this technology platform up and move it, and then a little bit on what's going on moving forward in Jakarta EE 9, and then finally sort of close with a little bit of a report card compared to where we ended up relative to the original expectations. So it's hard to believe, but this whole adventure began in 2017. So I can't remember if it was still Java 1 or if it was code 1. Might have been the last Java 1. So this crazy Oracle VP named Mark Kavage stood up on stage with some folks from IBM Red Hat and Tommy Tribe and said that they were going to pick up and move. Originally they were going to move to some foundation and they talked to Apache, they talked to Linux, they talked to us, and eventually there was a decision made to move it to Eclipse. And so what they talked, and so these, the next couple of slides are basically, these are the slides that Oracle themselves prepared to explain what was going on to folks. And so basically they want to move the community and vendors into a vendor-neutral open source foundation to take over the management of this. And there's a lot of good reasons why Be More Agile, flexible, open compatible, while retaining compatibility, all perfectly good motivations. But a big part of the reason why they wanted to move is because economically Oracle was tired of carrying the weight of the whole thing themselves. And the other vendors, particularly IBM and Red Hat said, hey, if you want our participation, we're not going to do that under the status quo. You need to change the game. And this was the game they decided to change to. So when we, talking about what it was that we were originally trying to do was, well, we want to obviously, the Eclipse Foundation is an open source foundation. Open by default is everything that we do. So open process. We have lots of practice at getting large vendors to collaborate together. It's kind of a bit of sort of our secret sauce as an organization. Transition the EE for J in calendar year 2018. Well, we'll do the report card later, but obviously that didn't happen. And move the glassfish code, all the RIs, TCKs, product docs, process for creating new specs and evolving the existing specs, create a compatibility process, yadda, yadda, yadda, yadda. And then of course, the thing from Oracle, we're still your vendor of choice. We still love you. We will still support you. And so some additional details. So release Oracle Java E8 and Glassfish 5 technologies. Move it over to Eclipse, RIs, TCKs and product docs. Build a compatible EE for J implementation that passes the existing Java E, TCKs. Use the existing Java X package names and component specification names for existing JSRs for continuity. Define a process by which we can move stuffs forward, recruit community and developers. So get more people involved in all of this. Evolve the platform and potentially incorporate Eclipse micro profile technologies. So I'm not going to be talking much about micro profile in this, but if you want to ask me questions about it afterwards, I'm happy to. And then get this done as quickly as possible. Alright. So before we kind of go into, you know, what or how we actually executed this whole move and what we came up with in the end, it's important to sort of reflect on how was the Java E ecosystem managed. So basically there's this complex web of intellectual property dials and knobs that companies use to control platforms. These slides were, if you're a FOSDAM fan, these slides are clipped out of a talk that I did in the legal dev room back in 2017 called Corporate Shenanigans. And so if you want to take a look at that, you can. But basically you've got, you know, code, which is what most people in this room care about. But then there's patents that have things to do, there's specifications, trademarks and certifications. And every one of these provides companies with dials and knobs that they can use to control things. So of course source code, as we know, is free and easy to get because Java EE was and is open source. So the source code was maintained under the Glassfish project, which was dual license CDDL and GPL plus class path exception. So GPL plus class path is a Shura license most of you are familiar with. CDDL is what's commonly referred to as a weak copy left license. It's actually very, very similar to the EPL and in particular the EPL 2.0. So one of the things that had to happen was we re-licensed all the stuff that was CDDL plus GPL plus class path to EPL plus GPL plus class path. That was very minimal disruption to the community because the CDDL and the EPL licenses are very, very similar. At least in it, they look, they read very differently, but the legal effect is very similar. And of course Glassfish like OpenJDK if you want to contribute, you have to sign the OCA. The specifications are managed by the JCP. I'm sure many people here are familiar with the JCP. It's not an independent vendor neutral organization. It's run as a division of Oracle. And then each spec or each JSR would probably be more precise, has to provide a spec document, a reference implementation, a TCK and each one of those has their own license. If you want to get the TCK, this is in Java EE. I'm actually not sure how it works in Java SE, 100%. You have to sign a non-disclosure with Oracle just to see a copy of the agreement. And of course the TCK itself is confidential. So that makes it hard to exchange views and results. Patents are pooled during the specification process at the JCP and arguably that's still the major value of the JCP that still exists is that multiple vendors sit around a table and because of their participation at the JCP, then there's multiple, the patent portfolios of multiple companies are helping protect the consumers and adopters of this technology. The license to the TCK is very long and complicated and it's not necessarily written to help you and does usually cost money. And the way that the patents flow is you get a license to the patents once you've fully passed the TCK. The license to the Java EE trademark also is not necessarily written in your favor and can be expensive. All right, so that's kind of sort of a synopsis of the way the Java EE ecosystem worked. So what did we do? So it's important to remember that in October of 2017, the Eclipse Foundation itself was an open source foundation. We did not have a spec process. It just didn't exist. And so one of the common misunderstandings that open source people have is that they think that open source licenses can basically completely replace specs and spec licenses and that's actually not true. The main difference is when you contribute to an open source project, your contributions, if there's any patents that read on your contributions, those patent licenses only flow to people who derive their code from that code. Whereas specifications are documents which where the patent, anybody who does an independent implementation of that spec gets a license to the patents even though they didn't use your particular contributions. The other main difference is that when you contribute to an open source license, any patents that your company may be contributing are scoped just to that contribution or the combination of that contribution with the larger body at the moment that you make the contribution. Whereas in specs, the patent licenses are to every patent that your company owns that might read on the implementation. So the patent differences between what you have in open source versus a well run spec process are completely different. And we hadn't even started really thinking about what it would be to do this and it turned out the lawyers at the time said it's going to take you a year and I'm like, no, it was probably over a year by the time we were done. In there it was like transfer all of glass fish. Of course as part of that all the trademarks were glass fish. We had to do all the code and IP review, the re-licensing. And we had to build a massive build farm for glass fish because they had this sort of workflow where they'd make a change and kick off a build right away and they needed to have a completely functioning binary pop out the other side in a couple of hours. I think the first time we did it, it ran for 48 hours and failed. So you've all done this. It's just work, right? Create a new brand. We came up with this beautiful little sailing ship and that's the Jakarta EE brand. And to replace the JCP, the copy cup that said Java EE underneath it. And originally the intent was that the new spec process was going to allow us to evolve the Java X namespace. And that didn't work out. There's a couple of reasons why that didn't work out. One is Java X, Oracle says that the namespace Java X is a Oracle trademark. Just editorial comment. I've never met a lawyer that doesn't work for Oracle that thinks you can trademark a namespace. But they insist that they can. So we're not going to argue with them. So they have, because in trademarks they have a lot of quality control. So if you wanted to evolve Java X, Oracle would get to do a lot of quality inspection on everything that came out of supposedly vendor-neutral spec process. So it didn't work out. And then create the new branding program. So just in some numbers, we brought on, actually ended up being more than 39, but call it roughly 40 new open source projects at the Eclipse Foundation, onboarded 160 new committers, put up about 100 Git repositories and did a lot of build pipelines. But one of the things that happened really early in 2019, that was actually super important and I think gets under, very much underestimated by a lot of people, is that all of the Java EE TCKs are now completely open source. So the entire Java EE TCK is licensed under the Eclipse public license 2.0 plus GPL with class pass exception, which means that we have complete transparency over the evolution of the TCK. All challenges to the TCKs are just bugs, contributions to the TCKs are welcome. So we've greatly increased the pool of contributors. And one of the things that's super important is that the TCK license, the Eclipse Foundation TCK license that this operates under, it's on our website, you can read it. And one of the things that it says is that you can make explicit claims of compatibility if you pass these tests, even if you don't want to license the mark. So if you have something that passed all the tests, you can say we're compatible. And that's perfectly okay. If you actually want to put the sailing ship on your product, the requirement is that you have to become a member of the Jakarta EE working group, which to put that in a perspective for a small startup with fewer than 10 people will cost you $3,000 a year. And you can actually, even if you're a huge company, you can get the license for 40k a year. I can, I don't know the exact numbers, but I'm willing to bet a lot of money that that's several orders of magnitude cheaper than the previous licensing. I'm not going to go through the whole thing here in terms of the new spec process that we created. Suffice it to say that it has a life cycle. It's in some ways, it's basically the union of the best ideas that we got from the JCP plus the best ideas that we have from the Eclipse development process. Everything is open source by default. And, and then we, so we expect all things to move forward openly and transparently through the entire life cycle. So just to compare, so to how we do sort of the JCP versus the Jakarta spec process, it's in the Java EE world, this is, I don't think this, this is certainly not true anymore in the Java SE world because of Japs and the, and the way that things flow out of open JDK. But I think it's fair to say that in the Java EE world, there's, there was a history where a lot of times, things got done first in specs, historically, particularly historically, and then they try out implementations. That's how you end up with abominations like bean managed persistence. And the way that we have the, the approach that we have in Jakarta EE is very specifically everything is code first and then you spec later. And in particular, it's actually written into the, into the process that we won't accept a new proposal for a spec if there's not some open source implementation out there somewhere. So the two things that we're looking for is a demonstration that something can, that does this can be built. And the second is that there's some indication that the world gives a shit. Because if you build a bunch of software and nobody cares, why do you need a spec? So that's what we mean by code first. In the JCP, there's this strong notion of a spec lead to the degree that in many cases, the spec lead controlled the pen. Everything that we do at Eclipse is collaborative by nature. And I guarantee you, as we start moving forward with some of these specs, we're going to have some enormous bun fights on the mailing list, because instead of having some strong spec lead saying, no, this is the way it's going to be, all the boys and girls involved are actually going to have to negotiate with one another and come up with how the spec is going to evolve. So collaborative is, is important, especially open collaboration. But it does, it can and I predict that it will lead to some more conflict. Documents and TCKs are open source. So everything, all the artifacts, the middle, in particular the work in progress are all completely available under open source licenses. Rather than having this notion of one normative reference implementation, before you can declare a spec final, you have to have at least one compatible implementation. And compatible implementation is defined as it has to pass the TCK, and it has to be available under an open source license where the open source licenses are EPL, Apache or VSD. So as long as you have a fairly liberally licensed open source implementation that passes the TCK, you can declare the spec final. But it's not normative in the sense that if you, it doesn't resolve disputes. And this, the process of doing certification itself is self-certification, and you have to maintain records to demonstrate that you pass all the tests. In the interest of time, I'm probably going to whip through this pretty good. Basically, you end up, imagine a world where you develop specs entirely under open source licenses, and then you're done. Remember I was talking about those funky patent grants that happen in spec processes that are different than open source licenses? So when you're done, we re-license the artifacts under different licenses. So the document itself becomes published under a very liberal copyright license that's based on the W3C spec license. So it's a copyright license that says go ahead and implement this in software. You know, you're free to do that. Then the, there's an API that exists that's under, well it says Eclipse Public License here, but we do have a couple of specs that are under Apache, so it would be under that. The TCK license I talked a little bit about before, it's a binary license. So there's one particular binary that's derived from the open source code that's under this, and you have to pass that version of the TCK to claim compatibility. And then, as I said, then the compatible implementations have to be under an open source license, and there's a choice of three at the moment. And then compatible implementations come from that, and we're really happy that when we shipped our first Jakarta EE8 specification, which is basically a copy and paste of the Java EE8 specification, but under the new licensing regime, we got a bunch of compatible implementations put out into the marketplace really quickly. So we're up to four different vendors, Eclipse Foundation with Glassfish being one of them, Open Liberty, Pyera, and Wildfly from Red Hat, and Oracle has made announcements that WebLogic is going to be coming sometime, I think, in Q1. All right, Big Bang! So because we couldn't agree on being able to modify the Java X namespace, we get to break compatibility. So everything that you used to know is Java X dot servlet dot yadda yadda yadda is now going to be Jakarta dot servlet dot yadda yadda yadda. And there's work that's going in to build open source tools to help with the transition, but we're going to have, there is going to be a one time only complete disruption of the technology formally known as Java EE. And this was, and there was, it was a great community moment to watch the amount of discussion that went into making this decision. So if anybody was following those mailing lists, I mean, it was really good. There was a lot of back and forth, but it ended up in a really good place. We're going to get rid of some cruft. So there's some things that have been sitting around in Java EE for a long time that nobody really cares about anymore. So we're actually going to actually deprecate deprecated specifications. So we're going to have some minor enhancements, some really small number of specs. We're really trying to keep that to a minimum for pure backwards compatibility. And so there's no new specs in EE9, but there will be Java SE 11 support. And so we do expect that most vendors will also support Java SE 8, but SE 11 will be included. So if you go back and look at how we did, actually, I'm sorry, that was really super green at one point. So go back to the original thing, the original goals that I laid out, I think on slide number four. So how do we do? So we re-license everything, check, built a compatible glassfish that passed the Java EE 8 to that check, use the existing Java X namespaces, large fail on that one, define a process to evolve the existing specs we did, although under the Jakarta namespace, recruit vendors and other community members. Actually, that's working out really well. You can actually watch the community engage and become more active. And we're starting to see some interest from new vendors to participate. Evolve the platform and potentially incorporate Eclipse Micro-Profile, that's still a work in progress. I couldn't tell you how that's going to turn out right now. And probably one of the biggest fails is this took way longer than anybody wanted it to. So we wanted to be done by the, you know, originally by the end of 2018, and here we are at the beginning of 2020, and we're still plugging away. The good news is that once we get EE9 out of the door, we do expect that there's, what sorry, what we've explicitly told the projects is while we're while we're doing EE9, if you at the individual spec level want to branch and do something interesting, go ahead and do it. So you might actually see new versions of just JAXRS or Jakarta Batch or Servlet happen in parallel with us actually doing a full platform release. And I think that's it. Thank you. Hope you have time for questions. Any questions? Oh, come on. Yes. Absolutely. Yeah. Oh, sorry. Thank you. Repeat the question. The question was how was it under sun? Was it actually any different than under oracle? And no, all the stuff where I said oracle was just as true under sun. Any other? Yep. Yeah, so ripping, so what we have, so sorry. Thank you. Repeat the question. Within the world of containers, do we expect to see the, so I'll sort of define it as cutting these large platforms up into smaller standalone specifications that can be used independently of one another? Absolutely. Yes. That's also the way micro profile works. And so we expect to go down that I expect to see the perhaps even additional profiles be created, which are targeted specifically to more modern use cases. All of these things are not only possible, they're probable. One last question, Charlie. Anybody? All right. Thank you.