Jakarta EE: Free at Last
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Alternative Title |
| |
| Title of Series | ||
| Number of Parts | 490 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/46966 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
FreewareCausalityBitFreewareJava appletCodeProcess (computing)OracleComputer animation
00:57
Java appletComputing platformTraffic reportingPlastikkarteBitProcess (computing)QuicksortAdventure gameJava appletClosed setExpected valueComputer animation
01:32
Level (video gaming)Java appletCodeAdventure gameOracleMultiplication signComputer animation
01:57
Enterprise architectureJava appletOpen setOracleOracleGame theoryDecision theorySlide ruleOpen sourceMereologyWeightOpen setData managementGoodness of fitComputer animation
03:02
Enterprise architectureJava appletOpen setProcess (computing)CollaborationismTime evolutionDisintegrationOracleProduct (business)Continuous functionComputing platformBuildingImplementationEuclidean vectorSoftware developerOpen sourceProcess (computing)ExistenceProfil (magazine)CASE <Informatik>Axiom of choiceConnectivity (graph theory)Latent heatAnalytic continuationOpen setSoftware developerOracleComputing platformBitQuicksortSelf-organizationTraffic reportingDefault (computer science)PlastikkarteGlassFishCodeProduct (business)ImplementationGroup actionJava appletComputer animation
04:43
Java appletImplementationCodeSource codeSoftware developerOracleProcess (computing)Division (mathematics)Term (mathematics)QuicksortData managementComplex (psychology)Java appletWeb 2.0Slide ruleProcess (computing)Category of beingDialectComputing platformSocial classSource codeException handlingVulnerability (computing)Sound effectLatent heatPublic key certificateIndependence (probability theory)Self-organizationResultantMultiplicationDataflowOpen sourceDuality (mathematics)Division (mathematics)Sign (mathematics)View (database)Projective planeOpen setPoint (geometry)OracleBus (computing)CodeECosPhysical systemTable (information)GlassFishComputer animation
08:20
CodeProcess (computing)Heat transferChannel capacitySpacetimeQuicksortJava appletOpen sourceProcess (computing)Computer programNumberGraph coloring40 (number)Projective planeCausalityNamespaceHeat transferCodeGame controllerRepository (publishing)BuildingMereologyDataflowComplete metric spaceMultiplication signBit rateGlassFishImplementationDifferent (Kate Ryan album)Pattern languageSource codeLatent heatCombinational logicMoment (mathematics)OracleExistenceComputer animation
11:57
BuildingJava appletRepository (publishing)Open setContinuous functionSoftware testingLocal GroupDuality (mathematics)Projective planeRepository (publishing)Open sourceBuildingExecution unitOrder of magnitudeEvoluteSoftware testing40 (number)Flow separationProduct (business)Group actionProcess (computing)Exception handlingWebsitePerspective (visual)Entire functionSocial classJava appletInheritance (object-oriented programming)Computer animationProgram flowchart
13:53
Process (computing)Process (computing)Default (computer science)Video gameCycle (graph theory)Open sourceEntire functionTerm (mathematics)Software developerQuicksortComputer animation
14:20
ImplementationJava appletSource codeCodeOracleProcess (computing)CodeMultiplication signImplementation2 (number)Price indexSoftwareNatural numberEmailElectronic mailing listOpen sourceProcess (computing)Java appletRow (database)Software testingArithmetic progressionNormal (geometry)Resolvent formalismPublic key certificateCASE <Informatik>CollaborationismOpen setPersonal area networkDataflowRevision controlObservational studySource codeComputer animation
17:10
Open sourceCodeOpen sourceSoftwareBitKeyboard shortcutRevision controlImplementationAxiom of choiceMoment (mathematics)Process (computing)Different (Kate Ryan album)Multiplication signGoodness of fitWorld Wide Web ConsortiumComputer animation
18:20
Open sourceImplementationComputing platformServer (computing)Open setOracleImplementationWeb 2.0Latent heatLogicMultiplication signProcess (computing)Control flowNamespaceOpen setOracleDifferent (Kate Ryan album)BlogJava appletComputer animation
19:04
Java appletSpacetimeMoment (mathematics)Open sourceDecision theoryMultiplication signJava appletBuildingGroup actionMaxima and minimaProcess (computing)Latent heatNumberComputer animation
20:39
PlastikkarteExplosionContinuous functionOracleJava appletProduct (business)BuildingImplementationEuclidean vectorProcess (computing)Computing platformSoftware developerQuicksortProjective planeLevel (video gaming)PlastikkarteBranch (computer science)Revision controlPoint (geometry)GlassFishParallel portNamespaceSlide rulePlotterNumberMultiplication signMilitary baseProcess (computing)Profil (magazine)Computing platformArithmetic progressionJava appletStapeldateiComputer animation
22:23
OracleLatent heatProfil (magazine)CASE <Informatik>Coma BerenicesQuicksortComputing platformAbsolute valueRight angleComputer animation
24:00
Point cloudOpen source
Transcript: English(auto-generated)
00:06
Hi everybody. For those who don't know me, my name is Mike Malinkovich. 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
00:25
two and a half years, transitioning the technology formerly 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
00:43
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 talked a little bit about how
01:01
this 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
01:21
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. Sorry, I can't
01:40
remember if it was still Java 1 or if it was Code 1. You remember, George? This might have been the last Java 1. And so this crazy Oracle VP named Mark Cabbage 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
02:00
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 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
02:24
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, or while retaining compatibility. All perfectly good motivations, but a big part of the reason why they wanted to
02:43
move is because, you know, 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
03:06
that we were originally trying to do is, 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 our,
03:20
sort of our secret sauce as an organization. Transition to EE4J 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
03:44
specs, create a compatibility process, yada, yada, yada, yada, yada. 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 then so some additional details. So release Oracle Java EE8 and
04:01
Glassfish 5 technologies, move it over to Eclipse, RIs, TCKs, and product docs. Build a compatible EE4J implementation that passes the existing Java EE 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 stuff forward. Recruit community and
04:25
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. All right, so before we kind of go into
04:48
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 EE ecosystem
05:01
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 FOSDEM fan, these slides are clipped out of a talk that I did in the legal dev room
05:20
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
05:43
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
06:03
exception. So GPL plus class path is a sure a license most of you are familiar with. CDDL is what's commonly referred to as a weak copyleft 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
06:21
we re-licensed all the stuff that was CDL plus GPL plus class path to EPL plus GPL plus class path. That was very minimal disruption to the community because the CDDL and EPL licenses are very, very similar. At least in it, 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
06:46
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,
07:06
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.
07:24
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
07:44
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
08:01
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 fully pass the TCK. The license to the Java EE trademark also is not necessarily written in your favor and can be expensive.
08:21
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.
08:43
Like 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
09:04
when you contribute to an open source project, your contributions, if there's any patents that on your contributions, those patent licenses only flow to people who derive their code from that code. Whereas specifications are documents where the patents, anybody who does an independent
09:23
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
09:40
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
10:01
in open source versus a well-run spec process are completely different. And we didn't even like, 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
10:20
all of Glassfish. Of course, as part of that, all the trademarks for Glassfish, we had to do all the code and IP review, do the re-licensing. And we had to build a massive build farm for Glassfish 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
10:40
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 sort of the Jakarta EE brand. And to replace the JCP, the coffee cup that said Java EE
11:07
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.
11:28
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 it. So they have, because in trademarks, they have a lot of quality control. So if we wanted to
11:43
evolve Java X, Oracle would get to do a lot of quality inspection on everything that came out of a supposedly vendor neutral spec process. So it didn't work out and create the new branding program. So just in some numbers, we brought on, actually ended up being more than 39,
12:02
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,
12:23
and I think gets 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 class exception, which means that we have complete transparency
12:43
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
13:02
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,
13:22
we're compatible. And that's perfectly OK. 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 into 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
13:45
license for 40K a year. 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, but in terms of the new spec process that we created,
14:01
suffice it to say that it has a lifecycle. 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 then we expect all things to move forward openly and transparently through the entire lifecycle. So just to compare
14:25
how we do the JCP versus the Jakarta spec process, in the Java EE world, I don't think this is certainly not true anymore in the Java SE world because of JEPs and the way that things flow out of OpenJDK. But I think it's fair to say that in the Java EE world,
14:41
there was a history where a lot of times things got done first in specs, particularly historically, and then they try out implementations. That's how you end up with abominations like being managed persistence. And the way that we have the approach that we have in Jakarta EE is very specifically everything is code first and then you spec later. And in
15:05
particular, it's actually written 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 that does this
15:20
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
15:43
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 lists 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
16:02
how the spec is going to evolve. So collaborative is important, especially open collaboration, but it can and I predict that it will lead to some more conflict. Documents and TCKs are open source. So everything, all the artifacts,
16:20
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
16:43
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 it doesn't resolve disputes. And the process of doing certification itself is self-certification
17:06
and you have to maintain records to demonstrate that you pass all the tests. In the interest of time, I'll probably whip through this pretty good. Basically you end up, imagine a world where you develop specs entirely under open source licenses and then
17:22
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
17:45
go ahead and implement this in software. You're free to do that. Then 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
18:00
about before, it's a binary license. So there's one particular binary that's derived from the that version of the TCK to claim compatibility. And then as I said, compatible implementations have to be under an open source license and there's a choice of three at the moment.
18:22
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
18:42
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
19:08
on being able to modify the Java X namespace, we get to break compatibility. So everything that you used to know is, you know, javax.servlet.yada yada yada is now going to be jakarta.servlet.yada
19:22
yada yada. 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 formerly known as Java EE. And this was, and there was, it was a great
19:46
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
20:03
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 to 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
20:23
specs in EE9, but there will be Java SE11 support. And so we do expect that most vendors will also support Java SE8, but SE11 will be included. So if you go back and look at how we
20:42
did, actually, I'm sorry, that was really super green at one point. So go back to the original goals that I laid out, I think on slide number four. So how did we do? So we re-license everything, check. Built a compatible Glassfish that passed the Java EE8 to that check. Use the existing
21:04
Java X namespaces, large fail on that one. Define a process to evolve 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, some interest from new vendors
21:25
to participate. Evolve the platform and potentially incorporate Eclipse Microprofile. 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.
21:41
So we want it 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 what we're, while we're doing EE9, if you at the individual spec level
22:04
want to branch and do something interesting, go ahead and do it. So you might actually see new versions of just JAX-RS or Jakarta batch or servlet happen in parallel with us actually doing a full platform release.
22:23
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.
22:50
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.
23:12
Yeah. So ripping, so what we have right, so sorry. Thank you. Repeat the question. Within the world of containers, do we expect to see the, I'll sort of define it as cutting
23:23
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,
23:45
they're probable. One last question. Charlie, do you, Oh, anybody? All right. Thank you.