I think this is a good point. From memory, the Java EE pruning policy states that a pruned spec can be supported by vendors but must still pass that spec’s TCK. Vendors can optionally decide to support it with the understanding that there is reduced application portability. This assumes there are no plans too evolve the SOAP-related specs. The specs can continue to exist but do not have to be included in the Jakarta platform.
It's not an easy call but I think the
right call is to remove JAX-WS. It's hard to claim "cloud native
Java" while carrying around SOAP as baggage. As you note, vendors
can still continue to support SOAP users for the indefinite
future.
Reza Rahman
Principal Program Manager
Java on Azure
Please note that views here are my own as an individual community
member and do not represent the views of my employer.
On 10/3/2019 1:28 PM, Guillermo
González de Agüero wrote:
I agree SOAP is still widely used and can't be removed so
soon, but that shouldn't be a big problem as long as it easy
to enable again (e.g. adding Apache CXF as a dependnecy).
Older projects won't actually migrate to Jakarta EE 9, and
most existing certified runtimes will keep it to support their
existing customers.
Pruning it from the requirements, on the other hand, opens
the door to new vendors which aim for more modern and lighter
runtimes. I would make it optional to support.
Alasdair
Nottingham
Kevin Sutter wrote on
10/1/19 1:15 PM:
Excellent
strawman, Bill. Thanks!
What
about Entity Beans? You mention "client
view", but did you also mean to include Entity
BMP and CMP Beans? I'd vote +1 for that
pruning as well.
I agree, that should probably be on the list.
I
noticed that you didn't include Jakarta
Management in the Pruning list. The other
Stable APIs were included to be pruned
(Registries, RPC, and Deployment). Did you
just just forget Management, or is there a
reason why you wouldn't include that in your
list to be pruned?
At the moment it isn't marked "proposed
optional". We had hoped to update it rather than
prune it, but if there's no longer any interest in
it we could consider pruning it as well. We need
to decide what the pruning process is for Jakarta
EE.
+1
I think a new spec for the use case given it was
going REST over JMX makes sense. I don’t know of
much usage from the customer apps I have seen.
Any
justification on which Java SE 8 APIs should
be moved to Jakarta EE 9 and which ones
shouldn't? Or, was it just gut reaction to
usage scenarios?
Mostly the latter. CORBA and SOAP usage is
dropping significantly, but XML is still widely
used. Mail needs Activation, which is why it's
still there.
I still see a lot of SOAP out there. Even
JAX-RPC is used by a significant existing
application estate. I think we need to show a
future for these SOAP apps in Jakarta EE and
pulling in the JAX-WS APIs is the right approach.
+1
- Dmitry
_______________________________________________
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
_______________________________________________
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
--
Reza Rahman
Principal Program Manager
Java on Azure
Please note that views here are my own as an individual community member and do not represent the views of my employer.
_______________________________________________ jakartaee-platform-dev mailing list jakartaee-platform-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
|
