We definitely need to have the conversation about what APIs we want
to remove entirely.
But even after we decide to remove some APIs, we still need to
decide whether the APIs we keep will move in a Big Bang or
Incremental approach.
If, for example, we remove Jakarta XML Registries from the platform,
a product can still include that API, which will remain in
javax.xml.registry. We don't need to keep it around and mark it
Deprecated or Optional, we can just remove it and leave it to a
product decision.
I don't see the advantage of keeping some javax APIs in the platform
and never allowing them to evolve. And I don't want to turn "javax"
into a marker for "dead API".
Kevin Sutter wrote on 7/17/19 6:05 AM:
I think
another piece
of this puzzle is to determine which technologies are actively
moving towards
a release post Jakarta EE 8? We know the JAX-RS is active.
Probably
JSF and maybe JMS. Others? (Sorry, too used to the old
acronyms...)
When we get the technologies lined up for Jakarta EE 9 and then
look
at the dependency graphs that have been generated, we might have
a more
realistic view of whether to do a Big Bang or Incremental move
from javax.*
to jakarta.*.
---------------------------------------------------
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
From:
"Steve
Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>
To:
Jakarta
specification committee
<jakarta.ee-spec.committee@xxxxxxxxxxx>
Date:
07/17/2019
07:57 AM
Subject:
[EXTERNAL]
Re: [jakarta.ee-spec.committee] javax to jakarta poll
Sent
by: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx
How do we specify an incremental
change that doesn't break them at all?
-----Original Message-----
From: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx
<jakarta.ee-spec.committee-bounces@xxxxxxxxxxx>
On Behalf Of Alasdair Nottingham
Sent: 17 July 2019 13:33
To: Jakarta specification committee
<jakarta.ee-spec.committee@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-spec.committee] javax to jakarta poll
I don’t agree with your characterization of Big Bang being
about success
of the platform moving forward and incremental because the
individual APIs
are more important than the platform. I see the debate as
being more around
what causes more hard to the platform moving forward, a change
that breaks
all users in the ecosystem at once, vs one that may not break
them at all.
> On Jul 17, 2019, at 2:16 AM, Bill Shannon
<bill.shannon@xxxxxxxxxx>
wrote:
>
> This still seems like coming at it bottom up instead of
top down.
>
> The reasons to prefer Big Bang have nothing to do with
the pros and
cons of moving any particular API, but rather the harm to the
success of
the platform of moving things piecemeal.
>
> The reason to prefer Incremental is because the success
of the platform
is irrelevant and all that matters is the individual APIs.
>
> I really don't see the point of collecting data about how
many people
want each one of the APIs to be moved. Either we're going to
move
them all, or we're going to move every one that we need to
evolve when
we need to evolve it. We're not going to refuse to move an
API that
needs to evolve just because not enough people want it to
move.
>
> We've already got lots of feedback on Big Bang vs.
Incremental. The
key piece of data that we said we're still waiting for and
that we still
don't have is some evidence about how successful a binary
compatibility
implementation can be.
>
>
> David Blevins wrote on 7/16/19 9:44 PM:
>> I'm going to be very light on javax to jakarta for
tomorrow's
8am pacific community call.
>>
>> I would, however, like 5 minutes of spec committee
time on tomorrow's
9am call to collect some feedback on this poll we put
together.
>>
>> - https://www.tomitribe.com/jakarta/ns/poll
>>
>> This is something we crafted just after I did the
bytecode-level
dependency tree analysis. It started with that in mind -- to
give
people a way to play with incremental thoughts or thoughts of
big-bang
with some deprecation or freezing. Primary a "calculator"
that later turned into a poll.
>>
>> I'm more interested in if we think we can get some
value out of
it in this or a mutated form.
>>
>>
>> --
>> David Blevins
>> http://twitter.com/dblevins
>> http://www.tomitribe.com
>> 310-633-3852
>>
>>
>>
>> _______________________________________________
>> jakarta.ee-spec.committee mailing list
>>
>> jakarta.ee-spec.committee@xxxxxxxxxxx
>>
>> To change your delivery options, retrieve your
password, or
>> unsubscribe from this list, visit
>>
>> https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
>
> _______________________________________________
> jakarta.ee-spec.committee mailing list
> jakarta.ee-spec.committee@xxxxxxxxxxx
> To change your delivery options, retrieve your password,
or
> unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe
from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
|
