Santiago/all,
I am happy to support this JSR in addition to MVC 1.0. If the "Initial EG
Members" only includes the Spec Lead(s) for now, as already proposed CDI 2
does, I understand you only list supporters, at least for MVC I would also
strongly consider joining the EG.
One thing that goes along the lines of Markus' and Sergey's reply (which I
quote below as the only ones)
> Additionally, Java EE 7 products will be allowed to implement JAX-‐RS
2.1.
That implies, the API (not necessarily the RI) refrains from any direct
link to Java SE 8, such as new types (e.g. java.time, though for a
value-agnostic JSR like JAX-RS or MVC this won't really matter, unlike e.g.
JAX-B or JSON-B, which got one of the highest priorities for EE 8) or
things like the @FunctionalInterface annotation as well as "default" in
interfaces, etc.
MVC 1.0 does not say it wants to support Java EE 7, while CDI 2 at least in
2.3 of the proposal states
The work will track Java(TM) EE 8, to be released as part of the Java(TM)
EE 8 platform. The Java(TM) SE support of the spec will be based on
Java(TM) SE 8.
So "spec" sounds like API, but especially CDI sometimes considered things
to be RI in the past, so if mandatory parts of a CDI API don't rely on Java
SE 8, the RI under an EE 8 umbrella might do so again.
java.time (AkA JSR-310) is probably the worst example of how this went in
Java 8. A once fairly distinct API (javax.time) was entirely engulfed into
Java SE 8, leaving practically no trace of a "Spec or API" behind an RI
full of redundancies. That RI/API conglomerate uses new
@FunctionalInterface or similar SE 8 structures or default implementations
in the few interfaces, so it's bound to SE 8 and seemingly useless to ME 8
due to its size and complexity.
In addition to that java.util.Calendar got a few improvements like
Calendar.Builder, so it's far from "legacy" or being replaced by the
additional API. For EE especially being backward-compatible means, in 99%
of all cases you'll refer to java.util.Date (either directly or via
java.sql.Time) or java.util.Calendar.
JavaFX while not so relevant under EE got its own Duration type not using
JSR-310 either, and it seems fairly incompatible with it even in future
Java versions
And for Concurrency (especially the new Concurrency Utilities for Java EE)
its own Date/Time subsystem with the TimeUnit enum is used. It merely has
similar (plural) named values but is completely incompatitle with JSR-310,
and is least likely to use it, especially if you need Real Time performance
not some bloated API with 155 types that all are dependent on each other.
The JSR formerly known as 310 created a so-called "backport" that is
compatible with at least Java SE 6. Aside from having JodaTime also working
in earlier JDKs, so it's questionable which applications this backport
targets, most likely "green field" solutions that will not use Java SE or
EE 8 in the near future, but not yet rely on JodaTime. Not many would
switch just for the sake of it, before they may upgrade to SE/EE 8 IMHO.
A similar pattern was applied by JSR-354, Money and Currency API by Credit
Suisse. The aim is to offer a "backport" of the entire API (with mandatory
links to Java SE 8, thus it won't work prior to SE or EE 8;-)
As Sergey also hinted, that is a two-headed sword. You might get the
"goodies" of SE 8 like Lambdas, etc. but keep in mind, an API that relies
on SE 8 cannot be implemented by anything under EE 7 with an SE 7 JVM. Nor
will the RI or any implementation of that API work with an older Java
version. I tested that myself and for our Embedded JSR 363 we know plenty
of Embedded and Real Time users that like Sergey said use Java 5 or 6
(Embedded 6 is fully supported by Oracle and vendors using it in embedded
devices like ATMs, Billboards, etc. won't simply update to Java 8 unless
the device breaks down after 5 or even 15 years;-D)
Hence the public API (javax.measure) of 363 is strictly backward-compatible
with Java 5. We refrained from the few temptations like "Diamond" which
Java 7 would have offered for that reason.
And the RI will be binary compatible between Java ME 8 and comparable SE
(Embedded) versions like SE 6 or 7, nothing that SE 8 has and ME 8 doesn't
is used by the RI.
With OpenJDK contributor Otavio from SouJava we created a "forward-port"
rather than a "backport" of the implementation for Java SE 8+ hence also EE
8 when it comes out which uses all the stuff you get there, even
java.time.Instant for timestamps at least as an alternative;-)
A few JSRs under the EE 7 umbrella like Batch also insisted on not using SE
7 for similar reasons. Their API (and mot likely RI, too) still works with
at least Java 6 or even 5, too.
Any new JSR will have to ask itself if it wants to be compatible with at
least a large percentage of Java 6 or 7 users, or immediately throw them
into the Java SE 8 "pond" for the API.
Regards,
Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead |
Eclipse UOMo Lead, Babel Language Champion | Apache Committer
Twitter @wernerkeil | @UnitAPI | @JSR354 | #EclipseUOMo | #Java_Social |
#DevOps
Skype werner.keil | Google+ gplus.to/wernerkeil
-------- Forwarded message ----------
From: "Markus KARG" <markus_at_headcrashing.eu>
To: <jsr339-experts_at_jax-rs-spec.java.net>
Cc:
Date: Tue, 19 Aug 2014 19:03:17 +0200
Subject: [jax-rs-spec users] [jsr339-experts] Re: JAX-RS 2.1 JSR
You can list me as a supporter for JAX-RS 2.1.
May I use the anticipated list of targeted items from your PDF in public
talks on JAX-RS's future?
BTW, as you intend to target Java SE 8, it might me a good idea to add a
mandatory item to that list: Supporting the new language features, in
particular lambda expressions, streams API, and Consumers / Producers. Those
are what people most commonly understand unter "8", so it would be a shame
if we do not overhaul the API using that features.
Regards
Markus
---------- Forwarded message ----------
From: Sergey Beryozkin <sberyozkin_at_talend.com>
To: <jsr339-experts_at_jax-rs-spec.java.net>
Cc:
Date: Tue, 19 Aug 2014 22:02:55 +0100
Subject: [jax-rs-spec users] [jsr339-experts] Re: JAX-RS 2.1 JSR
On 19/08/14 18:03, Markus KARG wrote:
> You can list me as a supporter for JAX-RS 2.1.
>
> May I use the anticipated list of targeted items from your PDF in public
> talks on JAX-RS's future?
>
I'd like to refer to them too.
> BTW, as you intend to target Java SE 8, it might me a good idea to add a
> mandatory item to that list: Supporting the new language features, in
> particular lambda expressions, streams API, and Consumers / Producers.
> Those
> are what people most commonly understand unter "8", so it would be a shame
> if we do not overhaul the API using that features.
>
> Java 8 would be too early, same way as Java 7 was to early was Java 2.0.
We have users still on Java 1.5 due to the internal restrictions. Making
Java 7 a base stack for 2.1 would work IMHO.
On Wed, Aug 20, 2014 at 11:15 AM, <users-request_at_jax-rs-spec.java.net>
wrote:
> Table of contents:
>
> 1. [jax-rs-spec users] [jsr339-experts] JAX-RS 2.1 JSR - Santiago
> Pericas-Geertsen <Santiago.PericasGeertsen_at_oracle.com>
> 2. [jax-rs-spec users] [jsr339-experts] MVC 1.0 JSR - Santiago
> Pericas-Geertsen <Santiago.PericasGeertsen_at_oracle.com>
> 3. [jax-rs-spec users] [jsr339-experts] Re: JAX-RS 2.1 JSR - Sergey
> Beryozkin <sberyozkin_at_talend.com>
> 4. [jax-rs-spec users] Re: [jsr339-experts] MVC 1.0 JSR - Joshua Wilson <
> javajoshw_at_gmail.com>
> 5. [jax-rs-spec users] Re: [jsr339-experts] MVC 1.0 JSR - Santiago
> Pericas-Geertsen <Santiago.PericasGeertsen_at_oracle.com>
> 6. [jax-rs-spec users] Re: [jsr339-experts] MVC 1.0 JSR - arjan tijms <
> arjan.tijms_at_gmail.com>
> 7. [jax-rs-spec users] [jsr339-experts] Re: JAX-RS 2.1 JSR - "Markus KARG"
> <markus_at_headcrashing.eu>
> 8. [jax-rs-spec users] [jsr339-experts] Re: MVC 1.0 JSR - "Markus KARG" <
> markus_at_headcrashing.eu>
> 9. [jax-rs-spec users] [jsr339-experts] Re: JAX-RS 2.1 JSR - Sergey
> Beryozkin <sberyozkin_at_talend.com>
>
>
>
> ---------- Forwarded message ----------
> From: Santiago Pericas-Geertsen <Santiago.PericasGeertsen_at_oracle.com>
> To: jsr339-experts_at_jax-rs-spec.java.net
> Cc:
> Date: Tue, 19 Aug 2014 10:29:30 -0400
> Subject: [jax-rs-spec users] [jsr339-experts] JAX-RS 2.1 JSR
> Hello Experts,
>
> After collecting the feedback on this alias as well as that of the
> community (via the survey), we are ready to move forward with JAX-RS
> version 2.1. We decided to spin off the MVC work into a separate JSR, now
> called MVC 1.0. It is likely that MVC 1.0 will define integration points
> with JAX-RS, but it will be up to the MVC EG group to define those. In
> addition, MVC 1.0 may support other types of controllers.
>
> In preparation for the JSR submission, I'd like to ask if I can list your
> name as a _supporter_ for JAX-RS 2.1 (Note that becoming a supporter is
> different from an EG member). If you want to be listed as a supporter,
> please respond to this message as soon as possible.
>
> Looking forward to working with you again. Thanks!
>
> -- Santiago
>
>
> End of digest for list users_at_jax-rs-spec.java.net - Wed, 20 Aug 2014
>
>