As we discussed f2f the other day, I'm less concerned about the package name than I am about the inference that backward compatibility isn't an area of importance for MicroProfile or that somehow it is the aim (domain) of Jakarta EE. Stability of interfaces is a key area of concern for developers and hence for MP; yet that doesn't have to mean no changes for a decade and no backwards compatibility methodology. Likewise for Jakarta EE I'm sure the will be discussions around strong backwards compatibility in the style of Java EE but we have to find a way to innovate quickly too if that is to survive and be meaningful in today's fast moving environment. Therefore, I'd caution against anything that suggests an implicit notion of stability of interface in the name.
Sent from my iPhone Hi All.
I have some thoughts on the new package name (Jakarta).
Just an idea. Let me know what you think.
Phillip
The broader Java EE community I suspect will be more than happy to volunteer for such an initiative.
Reza Rahman Principal Program Manager Java on Azure
Please note views expressed here are my own as an individual community member and do not represent the views of my employer.
Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message -------- Date: 6/10/19 8:19 AM (GMT-05:00) Subject: Re: [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta namespace
That's what I'd been assuming - a namespace change and a coordinated effort by the vendors to uplift their tooling.
Example, it was a slow start to start with converting popular libs to jigsaw/module system but once we got all of the key folks involved it's moved very quickly.
Is there a shared list anywhere of the major tools that need updating (compile and runtime)? Unless we go back to one of the very first Big Bang proposals and only change the namespace and nothing else. That’d be the quickest solution (for Big Bang).
Mark.
For big bang approach, I think there is still one open question.
As per Bill's notes, " Big Bang proposal says "some or all" will be
moved to jakarta.*; it allows us to leave behind specs that we plan
to abandon.",
this suggests further talk needs to happen for deciding the spec shortlist. I think the list needs to be refined first before the decision is made. I fear if big bang approach is chosen, we need more discussion to finalise the list. Further delay is unavoidable. One of the possible outcome is after a lengthy discussion, only 10-20 specs are to be maintained. This sounds incremental to me. I don't think a decision should be reached with open questions. Unless, Big Bang means migrating all specs.
With incremental approach, I think the roadmap is much clearer. Any specs can start evolving straight away.
Thanks Emily
Whatever we do we should close on a decision soon. Or we could be here still discussing it next year. I said at the start we need to consider as much data as possible to try to make an informed decision and I'm not seeing any new data coming in at this stage.
Right, Option 1. you go incremental and if you realise you're screwed, you stop in this mid step can can't do anything. If you realise it works then you have to go through the pain by a thousand cuts.
Option 2. you go big bad and if you realise you're screwed, you stop or get this "fresh platform" with less conversion rate. If you realise it works, you've saved 999 cuts to your users I also believe that Option 2 has a better chance of moving the ecosystem than Option 1, therefore a better chance of success. Big Bang FTW. On 5 Jun 2019, at 21:57, Bill Shannon wrote:
I continue to believe that the success of either approach will
depend on whether or not we have an effective binary compatibility
solution. So for me the fine print on my opinion is "assuming we
have a good enough binary compatibility solution".
If we start out with the incremental approach and find out that it
hurts too much, then what do we do? We can't go back. We have to
keep moving forward no matter what. Even if it means inflicting
pain at each release. So why not get it all over with at once.
Either way, I suspect many developers will skip these early releases
of Jakarta EE until these issues settle out.
Kevin Sutter wrote on 6/5/19 11:47 AM:
+1, John. We
can start incrementally and move to big bang later. We can't do
the
reverse.
---------------------------------------------------
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:
John
Clingan <jclingan@xxxxxxxxxx>
To:
jakartaee-platform
developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Date:
06/05/2019
12:55 PM
Subject:
[EXTERNAL]
Re: [jakartaee-platform-dev] Transitioning Jakarta EE to the
jakarta namespace
Sent
by: jakartaee-platform-dev-bounces@xxxxxxxxxxx
I’ve been pretty quiet up to this
point,
following the discussion. Early on was I was for “big bang” for
various
reasons already outlined in other comments. What I find
increasingly concerning,
the more I think about it, we are guessing/making assumptions as
to the
impact of a decision.
“We don’t know what we don’t
know”, IMHO. Making a big-bang change is a big step that could
have unforeseen
consequences to the ecosystem and the user base. We are a small
group discussing
the namespace issue that is trying to represent a developer base
of probably
1M managing potentially millions deployed apps based on these
specs. A
more conservative approach would be to do an incremental update,
measure
the impact and learn some things along the way, and then decide
if further
incremental steps are required or if we can simply move the
remainder.
On Jun 5, 2019, at 9:20 AM, Bill
Shannon
<bill.shannon@xxxxxxxxxx>
wrote:
Oracle agrees
that
Big Bang is best.
Steve Millidge
(Payara) wrote on 6/5/19 9:12 AM:
Just to add
Payara
favours a big bang approach as described in https://github.com/eclipse-ee4j/jakartaee-platform/blob/master/namespace/proposal-01-bigbang.adocwe believe a
majority of APIs need to evolve and therefore a majority of
apis will eventually move to the Jakarta namespace so may as
well do it
now.
From: jakartaee-platform-dev-bounces@xxxxxxxxxxx<jakartaee-platform-dev-bounces@xxxxxxxxxxx>On Behalf Of Scott
Stark
Sent: 05 June 2019 16:59
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] Transitioning
Jakarta EE to the
jakarta namespace There
has been no decision and there continues to be uncertainty as
to the best
approach. Vendors seem to favor an incremental approach as
there is a belief
that it eases backward compatibility stories. Developers seem
to favor
getting the move over with. I think the current plan is to
talk about a
plan toward a decision on the upcoming June 12 community call.
Has
a definitive decision on this been reached already? If not,
when will it
be reached? If a decision has been reached, can the community
have visibility
into how each of the stakeholders voted on this issue and why? I
looked at the recent meeting minutes and it is very unclear to
me if a
vote was held and what the rationale from each decision maker
was. In particular
I would personally like to understand how community input was
weighted. I
am still hoping we can all celebrate together soon with the
right forward
looking and community focused decision being made by
stakeholders. Reza
Rahman Principal
Program Manager Java
on Azure Please
note that views here are my own as an individual community
member and do
not represent the views of my employer.
Sent
via the Samsung Galaxy S7, an AT&T 4G LTE smartphone --------
Original message -------- Date:
5/6/19 7:23 PM (GMT-05:00) Subject:
[jakartaee-platform-dev] Transitioning Jakarta EE to the
jakarta namespace
[Contents of this
email
represent discussions of the Jakarta EE Specification Committee
over the
last several meetings. The statements here have been reviewed
by
and represent the voice of the Jakarta EE Specification
Committee]
As announced in
the
Update on Jakarta EE Rights to Java Trademarks[1] post on
Friday, future
modification of the javaxnamespace will not be allowed.
While this is not what was envisioned
when Jakarta EE started, in many ways this in our best interest
as the
modification of javaxwould always have involved
long-term legal and trademark restrictions.
To evolve Jakarta
EE,
we must transition to a new namespace. The primary decisions we
need to
make as a community and industry are how and when. Given all
delays and
desires on everyone’s part to move forward as fast as possible,
we would
like to have this discussion openly as a community and conclude
in one
month. It is the hope that in one month a clear consensus
emerges and can
be presented to the Specification Committee for final approval.
In an effort to
bootstrap
the conversation, the Specification Committee has prepared two
proposals
for how we might move into the new namespace. These should be
considered
a starting point, more proposals are welcome. No final decisions
have been
made at this stage.
The guiding
principle
for Jakarta EE.next will be to maximize compatibility with
Jakarta EE 8
for future versions without stifling innovation.
Other proposals
should
incorporate the following considerations and goals:
- The new
namespace will
be jakarta.*
- APIs moved
to the jakarta
namespace maintain class names and method signatures
compatible with equivalent
class names and method signatures in the javax.* namespace.
- Even a small
maintenance
change to an API would require a javaxto jakartachange of that
entire specification. Examples include:
- Adding a
value to an
enum
- Overriding/adding
a
method signature
- Adding
default methods
in interfaces
- Compensating
for Java
language changes
- Binary
compatibility
for existing applications in the javaxnamespace is an
agreed goal by the majority of existing vendors in the
Jakarta EE Working Group and would be a priority in their
products. However,
there is a strong desire not to deter new implementers of
the jakartanamespace from
entering the ecosystem by requiring they also implement
an equivalent javaxlegacy API.
- There is no
intention
to change Jakarta EE 8 goals or timeline.
- Community
discussion
on how to transition to the jakartanamespace will
conclude Sunday, June 9th, 2019.
It is envisioned
binary
compatibility can be achieved and offered by implementations via
tooling
that performs bytecode modification at either build-time,
deploy-time or
runtime. While there are open questions and considerations in
this area,
the primary goal of the discussion that must conclude is how do
we move
forward with future modifications to the APIs themselves.
Proposal 1:
Big-bang
Jakarta EE 9, Jakarta EE 10 New Features
The heart of this
proposal
is to do a one-time move of API source from the javaxnamespace to the jakartanamespace
with the primary goal of not prolonging industry cost and pain
associated
with the transition.
Were we to take
this
path, a compelling approach would be to do the namespace rename
and immediately
release this as Jakarta EE 9. Additional modifications would be
put into
a Jakarta EE 10 which can be developed in parallel, without
further delays.
- Some or all
Jakarta
EE APIs under javaxwould move
immediately into jakartaas-is.
- Any packages
not moved
from javaxto jakartacould be included
in Jakarta EE, but would be foreverfrozen and
never move to the jakartanamespace.
- Jakarta EE 9
would
be refocused as quick, stepping-stone release, identical to
Jakarta EE
8 with the exception of the javaxto jakartanamespace change
and immediately released.
- Jakarta EE
10 would
become the new release name for what we imagined as Jakarta
EE.next with
only minor impact on timeline.
- Work on
Jakarta EE
10 could start immediately after rename is completed in the
GitHub source
and need not wait for the Jakarta EE 9 release to actually
ship.
Pros:
- One-time
coordination
and cost to the industry, including; conversion tools,
users, enterprises,
cloud vendors, IDE creators, platform vendors, trainers and
book authors.
- Easily
understood rule:
everything Jakarta EE 8 and before is javax,
Jakarta EE 9 and after is jakarta
- Consistent
with the
javaxto jakartaMaven groupId
change.
- Highest
degree of flexibility
and freedom of action, post-change.
- Industry
would have
the opportunity to begin digesting the namespace change far
in advance
of any major new APIs or feature changes.
Cons:
- Largest
upfront cost
for everyone.
- Specifications
that
may never be updated would still likely be moved.
- Decision to
not move
a specification is permanent and therefore requires high
confidence.
Decisions:
- Which
specifications,
if any, would we opt not to move?
- Would we
take the opportunity
to prune specifications from Jakarta EE 9?
- Do we change
the language
level in Jakarta EE 9 to Java SE 11 or delay that to Jakarta
EE 10?
Proposal 2:
Incremental
Change in Jakarta EE 9 and beyond
Evolve API source
from
javaxto the jakartanamespace over time on
an as-needed basis. The most active specifications
would immediately move in Jakarta EE 9. Every Jakarta EE
release,
starting with version 10 and beyond may involve some javaxto jakartanamespace transition.
- The most
active APIs
would immediately move from javaxto jakarta
- APIs not
changed or
determined by the community to be unlikely to change would
stay in javax
- Jakarta EE 9
would
be a mix of javaxand jakartapackaged APIs
- If a change
was needed
to a javaxAPI post Jakarta
EE 9 for any reason, that API would transition fromjavaxto jakarta.
- Jakarta EE
10 would
be a mix of javaxand jakartapackaged APIs, but
a different mix than Jakarta EE 9.
- At some
point down
the road, Jakarta EE xx, it may be decided that the
migration from javaxto jakartais “done” and the
final APIs are moved.
Pros:
- Cheaper up
front cost
and reduced immediate noise.
- No need to
move specifications
unless there is an immediately visible benefit.
- Potential
for less
impact from API change overall.
Cons:
- Prolonged
coordination,
cost and complexity to industry affecting conversion tools,
users, enterprises,
cloud vendors, IDE creators, platform vendors, trainers and
book authors.
- Use of
restricted javaxnamespace
prolonged.
- Frustration
of “always
changing” packages may deter application developers and
become a permanent
perception of the brand.
- Difficulty
in remembering/knowing
which Jakarta EE release an API was moved. “Is Connector javaxorjakartain Jakarta EE 11?”
- Difficulty
in keeping
the industry in sync.
- New
implementations
may find themselves having to deal with the javaxto jakartatransition, unable
to avoid legacy costs and therefore decide not to enter
the space.
- Transitive
dependencies
to other specifications may make incremental change
difficult or impossible.
- Restrictions
on what
Java SE implementation can be used for certification
Decisions:
- Do we start
small or
start large?
- Which APIs
would immediately
need to be changed?
Out
of Scope
The following are
very
important community discussions, but do not require a decision
in the time-frame
allotted:
- Roadmap or
release
date for any Jakarta EE.next that would contain new features
- List of
specifications
that may be deprecated, pruned or removed from Jakarta
EE.next, if any
- Specification
text
around backwards compatibility requirements, if any
- What
profiles should
be defined
However, depending
on the path chosen, some of these topics may require immediate
resolution
before the chosen path can be executed.
[1]
https://eclipse-foundation.blog/2019/05/03/jakarta-ee-java-trademarks/
--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com
310-633-3852
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
--
_______________________________________________ jakartaee-platform-dev mailing list jakartaee-platform-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
|
