Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] Jakarta EE 9 proposed plan

Coping my email from other thread.


I agreed with proposal, but  I think Jakarta EE 9 should release some new feature, because the Jakarta EE 8 does not have any new features and whether Jakarta EE 9 come without new features we'll have two versions without release new features. I think it can be a bad (or not so good) message to developers.

I like the idea of new profiles and I think it should be started to be discussed.

About SOAP, I think it should be discussed because we have many enterprise applications that consume third part services using SOAP.

Rhuan Rocha

Em qui, 10 de out de 2019 às 16:59, Bill Shannon <bill.shannon@xxxxxxxxxx> escreveu:
Scott Stark wrote on 10/10/19 5:34 AM:
Copying over the post I made last night on the Red Hat position on the suggested approach for EE 9.

- Pruning
Red Hat mostly agree with the API pruning, but there are some questions around SOAP that need to be discussed further.
What exactly are the questions?

Clearly there are some people who think SOAP is still important enough that it should be kept in the platform, and others who are willing to let SOAP support be a product decision and not a platform requirement.

- Package Naming / Backwards Compatibility
Red Hat mostly agree with renaming all packages to the jakarta.* namespace. The wildcard here is that even though we agree that backward compatibility should not be a spec mandate, we do support the common open source backward compatibility project idea and can envision that a feedback loop could develop that changes the opinion on how to best achieve this.

- API Compatibility
Red Hat believe that there should be no incompatible changes beyond the package naming change.
The package renaming introduces a huge incompatibility that may or may not be handled by a backwards compatibility solution in some products.  Would you then allow additional incompatible changes in Jakarta EE 10 that would definitely not be handled by the backward compatibility solution?  Or would you never allow any other incompatible changes?

Like the big band vs. incremental question, is it better to bundle all the incompatible changes into one release, or to spread them out over several releases?  While I don't think we should be "going crazy" with incompatible changes in any event, I think we get one release in which people will be willing to suffer with incompatible changes.

- Enhancements
Red Hat believe there should be no enhancements as there is plenty to do with just the package renaming and any other changes will certainly push out an EE 9 release date.
If there was a fixed set of people that could be assigned to any of the work required for this release, I would agree with you.  But that's not the case.  There are people who could provide API enhancements on the proposed schedule but who would not be doing any of the other work for the release.  I think it's better to evaluate on a case by case basis whether an enhancement adds risk to the release or not.

- Profiles
Red Hat believe that additional profiles are needed to allow for adapting certifiable containers to much smaller subsets than are supported in EE 8. Red Hat also believe that relying on JPMS is not the way to do this.
Do you have a specific proposal for a profile, and would you be doing the work to define that profile, provide an implementation of that profile, and update the TCK for that profile?

- Java SE Support and Modules
Red Hat believe that Java SE 11 should be the baseline for EE 9 and also agree that JPMS requirements are not something EE 9 should be attempting to address.

- Microservices vs Containers
Red Hat believe that Java SE support should be expanded to as many APIs as make sense to support the lighter weight microservice oriented run-times we envision as being important in the future.
Does this conflict with your "no enhancements" statement above?

Getting TCK runs completed was a significant challenge due to the current configuration of permissions in the Eclipse CI environment during the EE 8 release. While it does make sense to split the TCKs up into project aligned with the specification project, doing so for EE 9 would be a major task that would push the EE 9 release date significantly. There should be some investigation into providing read and run access to the jakartaee-tck project CI jobs to facilitate testing of API release candidates without needing to significantly refactor the platform TCK projects.

On Wed, Oct 9, 2019 at 5:00 PM Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:
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

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.

jakartaee-platform-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

jakartaee-platform-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

jakartaee-platform-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top