Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-spec.committee] javax to jakarta poll

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


Back to the top