My view is that Sebastian's proposal is
a great start and what is actually needed is more community
awareness and informed input. My hope is that the vendors listen
carefully to that input and decide what they really want to do
(and I don't think the current vendor thinking that I can see is
the correct one for the broader ecosystem).
Republishing and amplifying Sebastian's
post is an essential step to further engaging and informing the
community. What is needed though is that vendors decide where and
how they want this community input and at what time they are
really ready to receive and act on it (I believe the sooner the
better. There is no quelling this discussion. The more we punt on
this the more we have unproductive side discussions in various
vacuums without participation from stakeholders responsible for
actual changes).
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.
On 7/25/2019 6:20 AM, Sebastian
Daschner wrote:
You've
proposed several specs from MP move over to Jakarta. Doing
that means no work can happen in MP for those specs anymore
otherwise it results in diverging specifications. When a
Jakarta release is available for those specifications MP would
need to discard it's own version and use the Jakarta one,
which would result in a Jakarta EE 9 style package rename
headache for MP users every single time there was a new MP
release that contained a switch from an MP to Jakarta spec of
the same thing.
I'm not proposing to "move" the specifications to Jakarta,
rather than updating it with the efforts that happened in MP, be
it by creating a (new) Jakarta incubator or updating an existing
EE specification. This is more similar to the efforts behind the
Config JSR, which has been submitted as a JSR, and will be
restarted under Jakarta. However, MicroProfile Config still
exists, which totally makes sense and it is required as of
today.
For
another group of MP specifications you've proposed making them
"Jakarta EE Incubators". This appears even worse than Jakarta
just taking the specification from MP, as not only do we get
diverging specifications, but an indeterminate amount of time
whereby Jakarta EE and MP are developing and releasing the
same thing until such time as it no longer incubates in
Jakarta and MP needs to replace to use that version, and we're
back to a Jakarta EE 9 style package rename for users.
I fully see your point, and you're right. However, we already
have the situation with CDI and JAX-RS, which are used in
MicroProfile yet can't evolve on their own, that's why we have
mp-rest-client, and likely other such cases in the future.
For this to advance, Jakarta ultimately needs to update it's
current specifications, but also Jakarta will need to include
solutions and approaches done by MicroProfile, however, in a way
where all Jakarta specifications benefit from it. For example,
users might want to use configuration from the whole Jakarta
umbrella in a unified way.
I certainly don't want to be religious about that proposal
and I'm interested in technical solutions rather than
politics, so I'm very open to different proposals on how to
resolve the situations and constraints that I tried to
describe in my blog. Feel free to propose something else.
Again, I don't think this proposal affects MicroProfile much
more than what we already have in the mentioned areas.
Your proposal also
completely ignores the differences in the specification
model. Sure the Jakarta EE processes are going to be lighter
than the JCP, but my understanding is they will still be a
lot heavier than MP today.
A Jakarta incubator process doesn't have to be
heavyweight at all.
What does that leave MP
to do? It essentially means it can only develop new specs,
as everything else is in Jakarta EE. That's not exactly
leaving MP "as it is today", unless the statement is meant
as "MP stays as is with the spec versions it has today and
no longer improves or innovates, and doesn't produce new
releases".
That proposal doesn't hinder MicroProfile from producing new
projects, new releases, or totally ignoring Jakarta specs, at
all. I mentioned it might make sense for MicroProfile to
include updates in Jakarta, but that of course has to be seen.
Realistically, until
Jakarta EE can show regular releases, and specify a cadence
(which I don't think has been defined), any talk of moving
anything from MicroProfile to Jakarta EE is premature in my
view. Today MP is putting out three releases a year with
anywhere from 2-5 updated/new specifications in each of
those, and we've seen the usage and success grow
dramatically over the last couple of years. Why would the MP
community put all that at risk for such an unproven release
schedule?
Again, I don't want to "move". I'm talking about the Jakarta
view, which new things might be adopted and how Jakarta might
advance further. I do believe now is the best time to have
this conversation to be able to start quickly once all
previous organizational issues have been sorted, and already
have an idea where the community has agreed upon. This of
course includes the assumption and hope that Jakarta will be
able to release something, which is something I believe we all
believe in.
I firmly believe that
Jakarta needs to show some successful releases and plans
around dealing with more traditional specifications before
there should be any thought of how MicroProfile might fit
into that picture.
I believe that if we only start thinking about the whole
ecosystem once things can move we loose even more valuable
time.
Sebastian
I have stated this before, but perhaps it
bears repeating just one more time. For many users of Java
EE, the key concern is whether the same set of
stakeholders can successfully invest in two separate
efforts that look a lot alike. If they cannot and need to
pick winners and losers, the situation looks ugly fast to
most potential adopters. That is why it is best to make
these decisions sooner rather than later, really listen to
what the broader community wants and make changes even if
they are painful to some right now.
It is not too far fetched to observe that
the key problem with Java EE and the JCP was not process -
it was levels of investment, commitment and motivation.
After all, Java SE does not seem to be having much issues
with either cadence or utilizing an effective incubation
process under the JCP these days.
Peace.
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: 7/24/19 11:07 AM (GMT-05:00)
Subject: Re: [jakarta.ee-wg] Proposal on Jakarta EE’s
innovation & relationship w/ MP
How would
MicroProfile stay “as it is today”, when you’re
proposing moving basically every spec currently in
MicroProfile to JakartaEE?
I meant this as opposed to the idea of
transforming MP to an / the incubator for Jakarta,
which is an idea that quite a few in the community
share / shared (including myself: [1]). I claim
there is a need for a "rebase" process, i.e. to
integrate updates to the specifications such as
CDI or Concurrency back to Jakarta EE. For now,
these updates and innovation happen in MP.
Integrating / merging / porting these ideas to
Jakarta leaves MP intact w/r/t branding, or
production-readiness, which is where a few in the
community have expressed their concerns with, and
where I do think this is valid. This is why this
proposal emerged at JCrete, and what I wanted to
say with MP stays "as it is today". Most of us are
active in both MP & JKEE, and from a technical
perspective I don't see much collision nor
competition, however, I claim this proposal puts
the least "risk" to the MP community and brand.
I still don't see how your proposal leaves MP "as
it is today" for several reasons.
You've proposed several specs from MP move over to
Jakarta. Doing that means no work can happen in MP for
those specs anymore otherwise it results in diverging
specifications. When a Jakarta release is available
for those specifications MP would need to discard it's
own version and use the Jakarta one, which would
result in a Jakarta EE 9 style package rename headache
for MP users every single time there was a new MP
release that contained a switch from an MP to Jakarta
spec of the same thing.
For another group of MP specifications you've
proposed making them "Jakarta EE Incubators". This
appears even worse than Jakarta just taking the
specification from MP, as not only do we get diverging
specifications, but an indeterminate amount of time
whereby Jakarta EE and MP are developing and releasing
the same thing until such time as it no longer
incubates in Jakarta and MP needs to replace to use
that version, and we're back to a Jakarta EE 9 style
package rename for users.
What does that leave MP to do? It essentially means
it can only develop new specs, as everything else is
in Jakarta EE. That's not exactly leaving MP "as it is
today", unless the statement is meant as "MP stays as
is with the spec versions it has today and no longer
improves or innovates, and doesn't produce new
releases".
Your proposal also completely ignores the
differences in the specification model. Sure the
Jakarta EE processes are going to be lighter than the
JCP, but my understanding is they will still be a lot
heavier than MP today.
Realistically, until Jakarta EE can show regular
releases, and specify a cadence (which I don't think
has been defined), any talk of moving anything from
MicroProfile to Jakarta EE is premature in my view.
Today MP is putting out three releases a year with
anywhere from 2-5 updated/new specifications in each
of those, and we've seen the usage and success grow
dramatically over the last couple of years. Why would
the MP community put all that at risk for such an
unproven release schedule?
I firmly believe that Jakarta needs to show some
successful releases and plans around dealing with more
traditional specifications before there should be any
thought of how MicroProfile might fit into that
picture.
In this case,
single-threaded is best because the focus needs to
be on the successful release of Jakarta EE 8. What
would be the point of having this discussion now
if Jakarta EE 8 release is postponed or doesn’t
happen? We need to discuss this topic when the
time is right.
Could you please elaborate that? I don't see
how such a conversation is putting the release of
Jakarta at risk, or how it changes things whether
Jakarta EE 8 happens tomorrow or next month?
Actually I see quite the opposite: If we would
come up to an agreement on the mechanics of such
as process, regardless of the current legal /
political situation, this would potentially even
enable to get some initial work done, e.g. define
what first incubation projects could include. The
industry would then see more progress and that
things are advancing which IMO adds more to the
success of Jakarta rather than waiting for much
longer (which I claim come with the danger of even
more companies migrating away). I'd like to
understand where these two things are technically
constrained to not move on in a multi-threaded
way.
Thanks for all your responses, highly
appreciated.
Sebastian
Sebastian, the topic of your
proposal has been discussed at length before
by members of both Jakarta EE and
MicroProfile. It’s a topic that’s in the
parking lot that needs to be picked up by both
communities once Jakarta EE 8 is successfully
out. In this case, single-threaded is best
because the focus needs to be on the
successful release of Jakarta EE 8. What would
be the point of having this discussion now if
Jakarta EE 8 release is postponed or doesn’t
happen? We need to discuss this topic when the
time is right.
Reza, could you please refrain
from amplifying Sebastian’s post via the Java
Guardians until both communities can allocate
time to discuss this topic in the future?
My fear is that your present
efforts on this topic, although well intended,
may negatively affect the success of both
projects. And my feeling is that now is not the
right time to take on this topic.
Thank you,
Cesar
How would MicroProfile stay
“as it is today”, when you’re proposing
moving basically every spec currently in
MicroProfile to JakartaEE?
While
the current heads down focus is
Jakarta EE 8, I fully agree with
you there is no real way of
deferring this discussion in the
broader community.
Thanks, this was exactly my
motivation why I wanted to start
this conversation now. I
understand that there is a lot
of urgent work in the pipeline,
however, in a single-threaded
model, things will take quite a
bit of time :)
Regarding the MicroProfile
community: This was actually the
idea why the proposal suggests
that MP stays as it is today, in
order to keep the branding,
community, etc. intact.
Sebastian
I have to say
this is just awesome. Thanks
for doing this. Do you mind
if I propose that the Java
EE Guardians republish this
content and amplify it?
While the
current heads down focus is
Jakarta EE 8, I fully agree
with you there is no real
way of deferring this
discussion in the broader
community. Everybody wants
to know what happens the day
after Jakarta EE 8. Might as
well start somewhere and
this looks like a pretty
good starting point to me in
terms of getting people
thinking.
Cheers,
Reza Rahman
Principal
Program Manager
Java on Azure
Please note
views expressed here are my
own as an individual
community member and do not
reflect the views of my
employer.
Sent via the
Samsung Galaxy S7, an
AT&T 4G LTE smartphone
-------- Original
message --------
Date: 7/23/19 3:12 AM
(GMT-05:00)
Subject:
[jakarta.ee-wg] Proposal
on Jakarta EE’s innovation
& relationship w/ MP
Hi there,
At the JCrete
unconference, a few of us
were brainstorming about
the vision of Jakarta EE
and especially the
relationship with
MicroProfile. I wanted to
start that discussion in
order to get everybody on
the same page especially
how the relationship
between Jakarta EE and
MicroProfile, and
Jakarta’s innovation
should look like. I
believe that a lot of us
agree on things already,
however, I believe it
would accelerates the
process if we start that
discussion.
I've created a blog
post [1] on this topic
which I wanted to
cross-post here on this
list. Feel free to forward
or redirect me to a
different mailing list
that potentially fits
better.
The following is a
proposal on the bigger
picture of the Jakarta
standardization process,
the relationship with
MicroProfile, and the fact
that there is a need for
an incubation process.
Please note that
everything is up for
discussion. My original
view was to use
MicroProfile as an
incubator for Jakarta [2],
however, some folks within
the community have
expressed their concerns
with that idea since the
MicroProfile brand gets
more and more established
and is seen as more than
just an incubator
technology.
Motivations &
reasoning
- There is a huge need to
advance and innovate on
Enterprise Java. Also, we
need the possibility to
innovate and discard some
of the innovation without
being carved in stone in
standards, already.
- We need a process to
rebase the incubators on
the baseline, in
order to use updated APIs
from other specifications.
- We need an umbrella that
ensures that multiple
technologies work well
together. The incubator
projects need to work well
with the baseline
specifications as well.
- We need to make it as
easy as possible for end
users to use Jakarta EE
and its incubators and to
update to newer versions
once things get
incorporated into the
baseline.
- We need to agree on the
details of incubators and
standards, regarding
format and contents of
technical documentation,
examples, and Java
packages.
- MicroProfile is
establishing its brand and
ecosystem which is seen as
production-ready
technology (more than just
an incubator) and which is
something we might want to
keep.
- We might want to start
these considerations now,
in order to align
stakeholders and to decide
what the picture looks
like, even things only get
realized weeks and months
from now.
Proposed process
- The Jakarta umbrella
contains specifications
that are part of the
baseline (which
corresponds to the Java EE
umbrella).
- Jakarta incubators are
the typical way to
innovate and advance
Jakarta in newer
technologies. Published
versions of incubators can
be used in combination
with the Jakarta baseline,
and offer a quicker way to
implement and discard
things.
- Jakarta incubators are
based on a specific
version in the baseline
branch and can and should
re-use the technology
contained in the baseline.
Incubators use the same
design principles and the
jakarta
Java package in order to
make it easy for early
adopters to switch from
incubator dependencies to
specifications.
- Longer-running Jakarta
incubators can and should
be rebased to a recent
Jakarta version in order
to use the latest
technology and to
facilitate usage for
implementers and users.
- Jakarta incubators that
have proven themselves can
get included into the
baseline branch as proper
Jakarta standards. In
order to make that
transition easier,
incubators use the jakarta Java
package and follow a
certain (simplified)
process on documentation,
specification, and code
examples. However,
everything inside an
incubator may change
before transformed into a
Jakarta specification.
- All Jakarta incubators
and specifications need to
provide a specification,
targeted to implementers
and users, as well as
documentation and
getting-started code
examples on commonly-used
patterns, targeted to
users. The documentation
must include a short
motivation why and in
which cases the technology
is required, and enable
users without prior
knowledge to get started
quickly.
- The MicroProfile brand
and ecosystem stays as is
and can continue to evolve
as is with all its current
projects. Jakarta
incorporates the efforts
and innovation that
already happened within
MicroProfile, with
adaptions where required.
Once Jakarta includes new
specifications, for
example Config, it might
make sense to rebase
MicroProfile to then
include these new
standards instead of its
current projects.
Diagram
I propose to advance
the future of Jakarta EE
with the following
technology:
New standards in
Jakarta EE
- Configuration
(Jakarta-Config) will be
a new specification
project in the Jakarta
baseline. It originates
from the efforts behind
the withdrawn Config
JSR, and MicroProfile
Config.
- Model View Controller
(from JSR 371)
- JCache (from JSR 107)
- Deployment
specifications:
standardizing the way
how to deploy and modern
apps, how to provide
libraries, what the
runtime directory layout
looks like, thin deploy
artifacts, etc.
Updates on EE
standards
- Concurrency:
incorporating approaches
from
mp-context-propagation
and bulkheads from
mp-fault-tolerance
- Security:
incorporating approaches
from mp-jwt-auth
- JAX-RS: incorporating
approaches from
mp-rest-client where
reasonable
New incubators in
Jakarta EE
- Fault-tolerance:
circuit breakers,
timeouts, retries,
fallbacks, features
taken from
mp-fault-tolerance
- Observability:
features from
mp-metrics,
mp-open-tracing,
mp-health
- Testing: incorporating
ideas and approaches
from Arquillian, Spring
Test, Testcontainers,
and maybe more
- Reactive-streams /
messaging: features
taken from
mp-reactive-streams and
mp-reactive-messaging
- LRA (or different
name): approaches taken
from mp-lra
- Open API: features
from mp-open-api
As always, anything
is up for discussion.
WDYT?
Sebastian
[2] https://blog.sebastian-daschner.com/entries/microprofiles-role-jakarta-ee
_______________________________________________
jakarta.ee-wg mailing list
jakarta.ee-wg@xxxxxxxxxxx
To change your delivery options,
retrieve your password, or
unsubscribe from this list,
visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-wg
_______________________________________________
jakarta.ee-wg mailing list
jakarta.ee-wg@xxxxxxxxxxx
To change your delivery options, retrieve
your password, or unsubscribe from this
list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-wg
--
Cesar Saavedra
Senior Principal Technical
Product Marketing Manager
(407) 492-9801
_______________________________________________
jakarta.ee-wg mailing list
jakarta.ee-wg@xxxxxxxxxxx
To change your delivery options, retrieve your
password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-wg
_______________________________________________
jakarta.ee-wg mailing list
jakarta.ee-wg@xxxxxxxxxxx
To change your delivery options, retrieve your
password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-wg
_______________________________________________
jakarta.ee-wg mailing list
jakarta.ee-wg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-wg
_______________________________________________
jakarta.ee-wg mailing list
jakarta.ee-wg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-wg
--
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.
|