Ondro,
Good summary of
the various definitions.
One observation...- The use of "deprecated"
was introduced by me in my Draft PR. It was not there previously.
The only other usage of "deprecated" in the Platform spec
is a mention of EJB CMP 1.1 beans being deprecated since Java EE 5. I
would suggest we change that wording to be "optional" to be consistent
with the rest of our usage.
If we did this,
then we could focus on the feature lifecycle as required -> proposed
optional -> optional -> removed. Sound good?
---------------------------------------------------
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
From:
"Ondro
Mihályi" <ondrej.mihalyi@xxxxxxxxx>
To:
jakartaee-platform
developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Date:
05/23/2020
07:05
Subject:
[EXTERNAL]
Re: [jakartaee-platform-dev] Inconsistency on the term "pruned"
Sent
by: jakartaee-platform-dev-bounces@xxxxxxxxxxx
After all the comments, from a user perspective,
I understand various terms as follows:- required - covered by Jakarta TCK. Implementations
must include it and pass the TCK
- deprecated - as required but may become
not required in the future, either optional or removed. I'm not sure this
is now being used on a spec level or only at the feature level
- proposed optional - as required but likely
to become optional in the next release
- optional - covered by Jakarta TCK. Implementations
don't have to include it, it's possible to pass the Jakarta TCK if it's
not included. If implementations include it they must pass the TCK for
the optional spec. There must be at least one Jakarta compatible implementation
that implements all required and optional specs.
- removed - not covered by Jakarta TCK,
not part of the Jakarta platform. No need to have a Jakarta CI that implements
it. If implementations include it, they only have to pass the Jakarta TCK
and the standalone TCK for the removed specification. Implies that a removed
specification must have a standalone TCK before it's removed from Jakarta
Platform.
There are differences
between all of these definitions, although sometimes they are subtle. We
may be able to merge some of them but it's not really needed. However,
we should at least clearly specify all of these terms. And specify possible
transitions between them.
Ondro
so 23. 5. 2020 o 13:15 Lance Andersen
<lance.andersen@xxxxxxxxxx>
napísal(a):
On May 22, 2020, at 7:01 PM, Scott Stark
<starksm64@xxxxxxxxx>
wrote:
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
On Fri, May 22, 2020 at 3:21 PM David
Blevins <dblevins@xxxxxxxxxxxxx>
wrote: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@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java
Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen@xxxxxxxxxx
_______________________________________________
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@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev