Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] Inconsistency on the term "pruned"

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."


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

> 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:
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit

Back to the top