0
Our customer uses them, and they like the standardized specifications.
On the other hand, I ‘m not clear how much difficult to communicate between jakarta name space EJB applications
and old javax name space EJB applications. If we cannot achieve them with realistic cost, I may vote +1.
-Kenji Kazumura
From: jakartaee-platform-dev-bounces@xxxxxxxxxxx [mailto:jakartaee-platform-dev-bounces@xxxxxxxxxxx]
On Behalf Of Kevin Sutter
Sent: Thursday, December 5, 2019 8:38 AM
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: [jakartaee-platform-dev] NEW VOTE 5: Prune EJB Interop
Preamble: https://www.eclipse.org/lists/jakartaee-platform-dev/msg01180.html
Please vote +1/0/-1 on the following. Any non +1 vote, please provide reasoning in your reply. Thank you!
Prune (remove) - Vote
Chapter 10, Support for Distributed Interoperability in the EJB 3.2 Core Specification
After a great conversation with David, he convinced me that we should still entertain the pruning of the EJB Interop material. So, here's my fifth vote... :-) We determined
that this section of the EJB 3.2 Core spec outlines the requirements that we would like to remove from Jakarta EE 9. In addition, the following TCK effort could be pruned, which would also be beneficial:
https://github.com/eclipse-ee4j/jakartaee-tck/tree/master/src/com/sun/ts/tests/interop
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter