[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakartaee-platform-dev] Jakarta EE 9 proposed plan
|
Like this even more than the Bill Shannon rendition. Well done Steve as
usual.
Reza Rahman
Principal Program Manager
Java on Azure
Please note views expressed here are my own as an individual community
member and do not reflect the views of my employer.
On 10/10/2019 5:22 AM, Steve Millidge (Payara) wrote:
Thanks for moving this forward Bill as a strawman. I'm inputting the Payara team feedback which I've been gathering for a few days here. It is in broad alignment with the conclusions you have below.
Just to emphasise what we are saying here is NOT product direction for the Payara Platform. Apis we choose to support in our platform over and above what is officially in Jakarta EE 9 Full Profile will be a larger superset and currently also includes Microprofile APIs.
Payara's view of how to drive forward Jakarta EE is guided by a few principles.
First to encourage a vibrant ecosystems of creators of Jakarta Specifications and Products, both open source and commercial, Jakarta EE should lower the barrier for entry to new products by rapidly pruning or making optional, specifications that are old with low current usage and would therefore be a significant burden to support for new entrants into the ecosystem.
Second to drive innovation while maintaining standards Jakarta EE must incorporate new apis after they have proven themselves in the market and these apis should undergo the JESP, incorporate new best practice from a broad participation base and evolve while moving to the Jakarta name space.
Third specifically for Jakarta EE 9 we should rapidly move forward to the new namespace and create a new platform for innovation as fast as possible.
Following the structure of Oracle's proposal;
Pruning
----------
We agree that;
Jakarta Registries
Jakarta XML RPC
Jakarta Deployment
Jakarta Enterprise Bean interoperability
Jakarta Enterprise Bean 2.x and 1.x client view
Jakarta Enterprise Web Services
should be pruned.
In addition we think that the following specifications could be made optional and subject to pruning at a future date;
Jakarta Management
Relating to our first principle we don't think that SOAP should be mandatory in Jakarta EE 9 full profile. In particular we believe that adding SOAP as a mandatory portion of the full profile could discourage future implementors of Jakarta EE and could delay Jakarta EE 9. However SOAP can carry on as a standalone specification under the Jakarta EE working group if the contributors are there. CORBA and RMI/IIOP should not be added.
We also agree that Jakarta XML Binding and Jakarta Activation should be added to Jakarta EE 9.
Package Naming and API Compatibility
----------------------------------------------------
Payara strongly supports the "big bang" approach switching all the non-pruned specification package names to the Jakarta namespace and releasing as new major versions. During this process we also support some minor rationalizing of the package hierarchy to remove unnecessary package depth where present while acknowledging this could make tooling and developer understanding more complex than a straight top level package rename.
We don't support removing of deprecated apis at this stage as we believe this could make the migration for developers to the new namespace more complex.
Backwards Compatibility
---------------------------------
We strongly believe that backwards compatibility, in respect of supporting the javax namespace, should not be a requirement of Jakarta EE 9 as we feel this is against our first principle and would prevent any new entrants in the market now and likely into the future. Backwards compatibility should be left to the market and we agree that it is very likely that current Jakarta EE 8 products will offer some backwards compatibility this requirement shouldn't be imposed on the future through incorporation into the specification.
Enhancements
-------------------
Payara does not think new api enhancements should be made during the switch to the new namespace in Jakarta EE 9. This is aligned with our third principle. We believe Jakarta EE 9 should move to the new namespace as rapidly as possible and Jakarta EE 10 then follow with enhancements and improvements. We feel allowing enhancements could lead to descending into a rabbit hole of incompatibility even when not intended. This however does not stop future innovation targeting a Jakarta EE 10 release from starting at the project level now and that message should be strongly relayed.
Profiles and Optional APIs
-----------------------------------
As profiles are tied to the Jakarta EE Compatible branding, Payara would support a further profile, with less specifications than the current Web Profile in the Jakarta EE 9 or future timeframe. In particular, if the desire is there, we would support a profile that is pruned sufficiently to enable other runtimes e.g. Servlet runtimes like Tomcat/Jetty to achieve the Jakarta Compatibility branding and therefore promote and strengthen the brand.
Java SE Support and Modules
---------------------------------------
Payara believes Jakarta EE 9 should require Java SE 11 as a baseline. We also support the addition of the correct metadata for support of modules and address naming standards. However we also do not believe that Jakarta EE 9 should be based on modules.
MicroProfile
----------------
Following our second principle. We believe Jakarta EE beyond Jakarta EE 9 should incorporate some MicroProfile APIs and be open to incorporating other external sources of APIs. However we believe these apis should be brought into Jakarta EE following the JESP and these apis should not be copied verbatim as they may in themselves contain technical debt and inconsistencies. Copying verbatim would also prevent a wider contributor base having a say during standardisation. While incorporating new APIs they should be moved to the Jakarta namespace and work should be done during the JESP to ensure they interoperate and blend with the rest of Jakarta EE to ensure a consistent platform experience for Jakarta EE developers.
TCKs
------
We believe each specification should maintain its own TCK and an overall platform TCK is also needed to test where specifications interact. We do not think this work is required in the Jakarta EE 9 timeframe.
Steve
-----Original Message-----
From: jakartaee-platform-dev-bounces@xxxxxxxxxxx <jakartaee-platform-dev-bounces@xxxxxxxxxxx> On Behalf Of Bill Shannon
Sent: 10 October 2019 00:54
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: [jakartaee-platform-dev] Jakarta EE 9 proposed plan
Thanks for all the input on, and support of, Oracle's proposed plan for Jakarta EE 9. Given the widespread overall support, I've recast this as the proposed plan from the Jakarta EE platform project. After further review and feedback, I'll ask the platform committers to vote on this plan.
I made the following significant changes to the plan:
- pruned Jakarta Management
- backwards compatibility NOT included
- no new profiles
- Microprofile APIs NOT included
- release in 12 months or less
Some of the changes above were motivated by the desire to release sooner rather than later, which seemed to be the consensus.
The most feedback was probably around the removal of SOAP support.
I think we've adequately explained that products can continue to provide SOAP support based on the Jakarta versions of the corresponding specifications, which will have no changes to their APIs and will continue to use the javax namespace. If platform project committers believe SOAP support MUST be included, now is the time to speak up.
Note that this would have a significant impact on the amount of work to be done for Jakarta EE 9.
Every detail in the plan will have someone who objects. What I'm trying to achieve is consensus on a plan that most people can support, even if no one thinks it's perfect. As usual, I'm looking forward to your continued feedback, especially if you think I'm moving in the wrong direction.
Thanks.
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
