| Re: [jakartaee-platform-dev] [EXTERNAL] Re: [DISCUSS] Include Jakarta Data in EE 11 |
|
Microsoft intends to vote +1 for inclusion of Jakarta Data in EE 11. Microsoft recognizes that some vendors have existing and committed investments in technologies that overlap or even compete with Jakarta, for example Spring Data and Red Hat Panache. Microsoft continues to support these vendors with their existing and significant investments in several well known Azure offers. Microsoft believes Azure customers best interests are served by standardized solutions. In the case of the repository pattern, we have numerous customers that use the repository pattern with JPA. Having this in the standard will help meet their needs. Some comments culled from the discussion. Steve Millidge wrote: SM> We have a “chicken and egg” problem here. We can’t see how SM> something bakes/matures in the market without shipping it in SM> products. So I think there is a middle ground option here before SM> making it mandatory for all in a platform profile. [...] SM> Same comment for all 3 under discussion. People said the same thing about Facelets. I advocated for its inclusion in Java EE and the record has proven its adoption successful. Scott Stark wrote: SS> But specs can be included in products without being in the SS> platform. This is not Java EE any longer. Technically, that's true. But the inclusion of a spec in the platform, and the subsequent forcing of compliant implementations to implement the spec, has historically been one way that the cross-vendor portability value proposition of Java EE has been achieved. I'll cite CDI and JPA as two other examples. I know a thing or two about the impact on adoption of a spec being included in a platform. Again, from JSF, people opposed to JSF being included in J2EE 1.4, but we put it in, and it helped adoption of JSF. Finally, coming back to adoption, this is our first chance to add any new features to Jakarta EE 11 since the heroic efforts to create a truly open standard not beholden to any one dominant vendor. This was not 100% true with Java EE, though the stewards of the spec were way more open than most give them credit for. Another reason to include the spec is to answer those who say, "Why would I choose Jakarta EE? It doesn't include anything really new over Java EE!" |
edburns@xxxxxxxxxxxxx | office: +1 954 727 1095 | Calendar Booking:
https://aka.ms/meetedburns | | Please don't feel obliged to read or reply to this e-mail outside | of your normal working hours. | | Reply anonymously to this email:
https://purl.oclc.org/NET/edburns/contact |