As Java SE 7 will be the default download on java.com for months when JAX-RS
2.0 got finally released, and as JAX-RS 2.0 (in contrast to JAX-RS 1.x) is
intended to be an integral part of Java EE 7 (for which Java SE 7 APIs are
the mandatory minimum base platform), I support your proposal. I do not see
any need to support JAX-RS 2.0 on Java SE 6. Possibly a move to the Java 7
API will bring more benefits, e. g. using Fork/Join internally to improve
internal parallel processing in Jersey (using CPU cores for
"intra-request-parallelism" instead of "inter-request-parallelism") etc. I
think this could not only reduce the code footprint of Jersey, but also
further improve up its processing speed.
From: Marek Potociar [mailto:marek.potociar_at_oracle.com]
Sent: Mittwoch, 4. Juli 2012 22:08
To: jsr339-experts_at_jax-rs-spec.java.net
Subject: [jsr339-experts] Java SE 7 features in JAX-RS 2.0?
Hello experts,
Just to start a discussion:
The comments around issue
http://java.net/jira/browse/JAX_RS_SPEC-165
brought up an interesting topic of whether or not should we consider
adopting Java SE 7 APIs in the JAX-RS 2.0.
As indicated in the issue, we could base our Locale - String conversion
support on a standard JDK API methods. Also there are other places where the
Java SE 7 features and API could be used to the benefit of our users - e.g.
we could change some of our classes and interfaces to implement
AutoCloseable so that the components can be used in a "try with resources"
code blocks. There may be also other places where Java SE 7 constructs could
be adopted.
For those of you who are more conservative, before you completely dismiss
the idea, let me remind you that by the time we release JAX-RS 2.0, the Java
SE 8 will be most likely out and as such Java SE 6 will become EOLed (which
means no further public SE 6 update releases anymore).
In any case, just a thought... please share yours.
Marek