Re: [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta nam

[David Blevins <dblevins@xxxxxxxxxxxxx>]

Hi Scott!


> On May 6, 2019, at 6:44 PM, Scott Marlow <smarlow@xxxxxxxxxx> wrote:
> 
> Thanks for getting this discussion started, much appreciated! :)

Thanks to everyone in the Specification Committee.  Very much a group effort.  I say that explicitly to remove any perception of me as a deciding authority.  "tweets are my own" and all that :)

I want to have fun throwing out crazy ideas like everyone else :)

> 
>> Other proposals should incorporate the following considerations and goals:
> 
> Are these considerations/goals a "should" or "must"?  Are we looking for feedback on these "should" goals and are these goals separate from the (due to Oracle trademarks...) restrictions mentioned in [1]?

They should all be considered a must, but I'll give the reasons so we're all on the same page.  Some are written in stone, some on wood.

>>  *
>>    Even a small maintenance change to an API would require a javaxto
>>    jakartachange of that entire specification. Examples include:

One part legal.  Any modification to behavior or method signature would have to be done in another page.

The "entire specification" is a self-imposed restriction.  The specification committee disagrees (or not yet agrees) on many things, but this wasn't one of them.  Is there a use case you see that would involve a specification only partially moving?

>>  *
>>    The new namespace will be jakarta.*

Two motivators:

 - this was decided/communicated a year or so ago when we did the jakarta GroupId change.  We always knew we'd need another namespace for new specs.

 - branding and cost. We've cleared this one and clearing another would take time and money.

>>  *
>>    APIs moved to the jakarta namespace maintain class names and method
>>    signatures compatible with equivalent class names and method
>>    signatures in the javax.* namespace.

Motivator here is so that tools can be written that do a "namespace upgrade" and things are otherwise the same or better.  Both an attempt to keep the cost of those tools down and to keep things very understandable/stable as possible for people.

Now that doesn't mean that we can't discuss doing the complete opposite of some of these things, just that unless we come up with some way to satisfy the motivators, we're unlikely to see them go anywhere so it's a bit of "proceed at your own caution."

We need all the good ideas.  Keeping them motivation use case focused is best.

One I had not even considered before your post, but attempting to read between the lines of your questions.  Perhaps you might be indirectly poking at some kind of possibility like this:

 - we have both jakarta and jakartax packages
 - jakarta package is for shinny new legacy-free apis
 - jakartax is for heavy legacy stuff we don't want doing a "land grab" on jakarta

Putting words in your mouth, but perhaps sorta near a line of thought that you might have been imagining.


-David