I would agree that we should use remove in place of pruned, but this addition:
Agree
Product vendors are _required_ to remove a "pruned" feature from their products for
goes too far. Just as we cannot dictate whether or not a product implementation an optional feature, we cannot dictate if a removed api is made available in an implementation. Once it is removed it is no different from any other proprietary or implementation specific detail.
+1
Three topics:
= "Prune means remove" vs "remove"
I think Edwin hit the nail on the head when said we should not use the word "prune" at all, instead simply say "remove."
= RMI-IIOP
On the PR, I'm digging into the RMI-IIOP language used in the various versions of the specification. The trick with deleting it is this was the section where it was explicitly stated platforms could implement any protocol they wanted. The J2EE 1.4 spec has these key phrases in that section:
- The RMI-IIOP subsystem is composed of APIs that allow for the use of RMI-style
programming that is independent of the underlying protocol, as well as an
implementation of those APIs that supports both the J2SE native RMI protocol
(JRMP) and the CORBA IIOP protocol.
- This allows enterprise beans to be protocol independent.
- The ability to use the IIOP protocol is required to enable interoperability between
J2EE products, however a J2EE product may also use other protocols.
I've gone through this section in J2EE 1.2, 1.3, 1.4 and Java EE 5, 6, 7 and 8. Each leans a different way in how this section focuses. Versions 1.2 and 1.4 lean very "protocol independent" and the rest lean with a heavy bias to CORBA. I think if we were to entirely remove this section it would leave the record unclear.
Given how narrowly this topic is understood, I think the best path forward might be to update this section to state to acknowledge the history here, what is no longer required (explicit IIOP support) and what is allowed (protocol independence). I'll take a swing at that next week.
= Removal and impact on implementations
When we initially discussed removing items from the specification and TCK, there were sentiments expressed that an implementation could continue to support the remove items. For example if we had voted not to rename JAXB, it could still be included under the old javax namespace. The Draft PR has language stating items removed from the specification must be removed from all implementations.
This will be immediately problematic as removal of a CORBA requirement while remote EJBs remains optional would create rules that would impact GlassFish and WAS (likely others) very negatively as the only way they support remote EJBs is through CORBA. As we're relying on GlassFish to satisfy the "at least one implementation must pass all required and optional components" rule, the Jakarta EE 9 plan would be impacted as well.
The evolution of the IIOP requirement and how that would relate to "implementations must remove" would be this:
- Everyone does their own thing, maybe that's not so good
- Everyone can continue doing their own thing, but you must also do the most common thing
- No one can do the most common thing
That last bullet is the problematic one; we need to figure out how to cut technical debt like IIOP from the platform while allowing others who have the debt to continue forward. The most natural thing in this regard would be to simply revert back to the first bullet.
Here's the same evolution scenario with something like NoSQL or MVC:
- Some implementations ship with the standalone MVC specification
- MVC is now a requirement in Foo Profile
- MVC is optional
- MVC is removed, and therefore no one can ship it even as a standalone specification
Unless we fix that last bullet everything will stay in optional status and we'll create a situation that is in practice competitively unfair to GlassFish.
The right final bullet might look like:
- MVC is removed from the platform. If you ship it as a standalone specification, you have them to answer to if you are non-compliant.
--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com
> On May 20, 2020, at 9:56 AM, Kevin Sutter <sutter@xxxxxxxxxx> wrote:
>
> Hi,
> As I started to update the Platform spec due to our Jakarta EE 9 Release Plan content, I noticed that the term "pruned" has different meanings depending on the context...
>
> In our Release Plan, we identified the following technologies as "pruned", which in this context meant "removed from the platform":
> • Jakarta Stable API Project Specifications
> • Jakarta XML Registries
> • Jakarta XML RPC
> • Jakarta Deployment
> • Jakarta Management
> • Support for Distributed Interoperability in the EJB 3.2 Core Specification, Chapter 10
>
> But, if you look at theJakarta EE 8 Platform Spec, the term "pruned" means to only mark the technology as "optional, but it's still part of the platform" (Section 6.1.3 Pruned Java Technologies):
>
> "Technologies that have been pruned as of Jakarta EE 8 are marked Optional in Jakarta EE Technologies."
>
> Big difference...
>
> First off, I'm taking the stand that we really did mean "removal" when we declared those technologies as "pruned" in the Jakarta EE 9 Release Plan. We've been driving that way with all of the Specs, APIs, TCKs, and CIs for Jakarta EE 9. Just clarifying that definition and expectation.
>
> The point of this note is to get agreement on the direction of the Platform spec for these definitions. Here's my proposal. Comments/suggestions welcome.
> • Change Platform spec to use Optional instead of Pruned (in the current spec context).
> • Modify the definition of Pruned to mean Removal.
>
> For the last bullet, we could decide to just drop the term "pruned" and use "removed" instead. But, since we already have used the term "pruned" in the Release Plan, I think it would be more consistent to just alter the definition of "pruned" to mean "removed" in the Platform Spec.
>
> Of course, we would need a "Note" of some type to indicate this change in terminology.
>
> Thoughts? I'd like to get some general feedback before embarking on this type of change since it could have quite the ripple effect. Thanks!
>
> ---------------------------------------------------
> Kevin Sutter
> STSM, MicroProfile and Jakarta EE architect @ IBM
> e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
> phone: tl-553-3620 (office), 507-253-3620 (office)
> LinkedIn: https://www.linkedin.com/in/kevinwsutter
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________ jakartaee-platform-dev mailing list jakartaee-platform-dev@xxxxxxxxxxxTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037Oracle Java Engineering 1 Network Drive Burlington, MA 01803Lance.Andersen@xxxxxxxxxx
|
