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.
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?
- TCK
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.
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.
