|
I agree the pace seems very slow and no
one seems to know what the exact timelines are. Maybe this is a
concern that should be escalated to Jakarta EE stakeholders?
Keeping pushing MicroProfile only goes so far while competitors
just keep rolling forward. Java EE was already behind, how much
catch up will Jakarta EE need to do?
On 8/3/2018 1:23 PM, arjan tijms wrote:
Hi,
Seeing how things are currently progressing I think
targeting spec releases or even API releases of JAX-RS (those
are technically not quite the same anymore) for 2018 is quite
challenging.
We'd still need the TCK transferred, clarity about the spec
documents and the agreement over the javax.* packages. Even
the Jakarta EE spec process itself is still being worked on.
At the rate things are currently going I'd be surprised really
if fall 2019 for the first new spec/api release (JAX-RS 2.2)
is possible.
I'd like to propose setting JAX-RS 2.2 tentatively for end
of 2019. We can always move it back if the transfer process
unexpectedly speeds up, but at the moment I think that's a
more realistic roadmap. I.e. better underpromise and
overdeliver than the other way around.
Thoughts?
Kind regards,
Arjan
I
think Java 8 is very important still for JAX-RS 2.x,
but not important at all for 3.x anymore.
-Markus
Regarding
Java 11 I actually meant "Compiles using Java
11", i. e. people cannot load that JARs anymore
on a Java 8 VM. So it might be a big deal if
people must stay compatible with Java 8 VMs.
I think Java 8 compatibility is
the crux of this discussion. Is that still important?
I think JAX-RS 3.0 would be the right time to drop
Java 8 compatibility in preparation for future work.
In
fact I constructed the roadmap around what the
committers are able to deliver, not just what
users would be interested in. In the end,
someone has to do it, and we're no only talking
about API, we talk about pushing out releases
for all existing products, as the EF does not
allow us to do an API without at least one fully
compliant product per release.
JPMS
support and Java 11 support are somewhat
separate issues. Generally I don't think there
are any API changes to consume for JAX-RS from
Java 10 or Java 11. It is really just a matter
of compatibility testing, which is not that
big a deal.
Personally
I think JPMS support for JAX-RS alone is a
relatively minor feature. I imagine most
implementations won't have much trouble doing
this and perhaps JAX-RS alone supporting JPMS
is not that interesting to users either.
Sent
via the Samsung Galaxy S7, an AT&T 4G
LTE smartphone
-------- Original message
--------
Date: 7/28/18 5:59 AM
(GMT-05:00)
Subject: Re: [jaxrs-dev]
[Discuss] Initial Roadmap / Preliminary
Release Schedule
thanks
for sharing your ideas!
I
have tried to add most of it into an updated
preliminary schedule:
Please
be so kind and check this new plan. It now
contains more releases in the same time frame
so I could add more of your requested
features. Now before we can vote on it, we
need another round of feedback. In particular,
the following questions arise:
-
From a purely formal standpoint, can we do
JPMS and Java 9 in a minor version increase or
does that enforce a major version increase?
-
Do we really only want Java 9 in 2019, or
shall we directly jump on Java 11 in half a
year from now?
Thanks
for your feedback!
From: Markus KARG [mailto:markus@xxxxxxxxxxxxxxx]
Sent: Samstag,
21. Juli 2018 14:35
To: 'jaxrs
developer discussions'
Subject: RE:
[jaxrs-dev] [Discuss] Initial Roadmap /
Preliminary Release Schedule
yes,
if we remove something in 3.0 then we MUST
deprecate it in 2.2 or 2.1.1. But this has to
be voted.
IIRC
we have not yet voted about any particular
content of neither 3.0 nor 2.2 nor 2.1.1, so I
just picked what I understood to be common
sense of the various discussions so far.
Feel
free to open an issue wrt deprecating @Context
and set the linked milestone to 3, which
effectively opens the possibility for
reviewing and voting.
Thanks for getting it
written.
Does 3.0 imply *removing*
@Context and other related stuff. If so, those
features should be deprecated in a previous
version to give users a chance to migrate.
_______________________________________________
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To change your delivery options, retrieve your
password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jaxrs-dev
_______________________________________________
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jaxrs-dev
_______________________________________________
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jaxrs-dev
|
