Re: Java EE Security.Next

Werner Keil

Now that several existing JSRs like 374 started with proposals to EE4J, I wonder what keeps this JSR from doing the same?
Obvious bugs or smaller improvements without introducing whole new API elements are usually natural for MRs, and based on what we heard, Oracle and other vendors should upgrade their Java EE products to use Java EE 8, so they will use 375 and Soteria in all relevant  profiles (Full and Web according to so if say SAP Cloud ( seems using mostly TomEE 7) wants to certify against Java EE 8 then we should see either TomEE or even SAP utilize JSR 375 via its Identity Management for the Cloud to do so ;-)
Same for other Java EE 7 compatible vendors who wish to upgrade. It is possible one or the other might skip it and aim directly at EE4J but there is no definitive answer as to whether it'll offer a similar compatibility assurance or certification. 

So for important fixes or problems there should be at least one or the other MR of JSR 375, but similar to what other JSRs did, it should be very easy to fork/contribute a project to EE4J, too.
Ed who's been in charge of many things here already is one of the project leads for JSON Processing:
So he is at Eclipse/EE4J, Ivar another EG member who also spread the word about JSR 375 is currently the PMC Chair, David also another EG member represents Tomitribe in the PMC. So does Arjan's company Payara. It should be easy to find additional contributors and project leads, if the model of sharing it among 2-3 contributing members is also found appropriate for this project. Given Arjan's contribution to 375 so far, he seems like a good candidate to do this for Payara. Almost every current EG member(company) is involved in either EE4J, MicroProfile or other Eclipse projects and committer already. Others at least signed the ECA which is what current contributors would need to contribute in this new environment. 


Join to automatically receive all group messages.