Date: Tue, 29 Jan 2013 00:55:07 +0100
Bill,
Thanks for the reply.
At least the JavaDoc of SE 7 contains @Resource as part of the standard
annotations coming with SE, too. If this has been around in 6 already, that
might make it easier to use in a non EE environment, although it probably
would need some other form of container or runtime then. CDI or even JSR
330 AFAIK isn't shipped with any SE level Java distribution so far.
Exactly that was my question you answered before. And while as a new JSR it
may not have to deal with prior versions, it still has to clarify, if it
intends to be part of EE only or standalone. RI and TCK also depend on
that, thus there may have to be one as part of the EE Umbrella, and a
standalone version,
So 2.1.4 may not directly apply, since they plan to make it available both
with EE 7 and standalone, but 2.1.3 states, "the most recent" version of
each Umbrella JSR. Which by definition are SE 7 or EE 7. If there's room
for freedom and interpretation by the EG and Spec Leads of an individual
JSR, so be it, but it isn't compatible with the most recent version of SE
for some functionality.
The arguments are still discussed, at least the one that says the two
interfaces are not to be used by applications and hence not part of the
public API (words of the Spec Lead I recall) so they may not be in the
right place, rather than not extending a part of SE.
Werner
On Mon, Jan 28, 2013 at 11:44 PM, Bill Shannon <bill.shannon_at_oracle.com>wrote:
> Werner Keil wrote on 01/25/13 17:17:
>
> Bill,
>
> Thanks a lot for pointing that out.
>
> I would prefer 2.
> Is @Resource the only or best option you see, or would other alternatives
> like @Inject if technically feasable also work?
>
> Only @Resource (and related annotations like @EJB) expose the required
> information to the deployment process. @Inject is processed during CDI
> initialization, which happens after deployment.
>
>
>
> Sorry to add this here again, but in the JSR 358 (JCP.next) EG we just
> came across some interesting and valid points about Umbrella JSRs like EE
> and those JSRs meant for inclusion. Markus I believe must have quoted
> section 2.1.3 of the JCP procedures already, and Batch has upgraded to JCP
> 2.9 where this is quoted from:
>
> 2.1.2 PROTECT THE INSTALLED BASE AND GUARD AGAINST FRAGMENTATION
>
> Changes to the Java programming language, the Java virtual machine
> (JVM,) the Java Native Interface (JNI,) packages in the "java.*" space, or
> other packages delivered only as part of Java SE, have the potential to
> seriously disrupt the installed base if carried out inconsistently across
> the Platform Editions. In order to protect the installed base, any such
> changes can only be accepted and carried out within a UJSR for Java SE.
>
> *In order to guard against fragmentation, new Platform Edition
> Specifications must not substantially duplicate existing Platform Editions
> or Profiles.*
>
> 2.1.3 PROFILES AND API SPECIFICATIONS TARGET CURRENT PLATFORM EDITIONS
>
> All new or revised Specifications must be compatible with the most
> recent versions of the targeted Platform Edition Specifications. In order
> to achieve this, all UJSRs to define new Profile Specifications or revise
> existing Profile Specifications must reference either the most recent
> Release version of the Platform Edition Specification they are based upon
> or a newer version of that Specification that is under development via an
> active UJSR.
>
> 2.1.4 PLATFORM INCLUSION
>
> The JSR submission form requires the submitter to state whether the
> JSR's RI and TCK should be delivered as part of a Profile or Platform
> Edition, in standalone manner, or both. The final decision as to whether a
> specific JSR is included in a Profile or a Platform Edition is made by the
> Spec Lead and Expert Group of the Platform Edition or Profile JSR, and is
> confirmed by the EC ballots on the relevant JSR. If the Spec Lead for the
> Platform Edition or Profile JSR turns down a request for inclusion then the
> JSR must deliver a standalone RI and TCK.
>
> *Technologies may be incorporated into a Profile or Platform Edition
> after having been initially delivered standalone. A JSR for a new version
> of an API that proposes to become part of a Profile or Platform Edition and
> is considering discontinuing standalone availability must state the
> rationale for this change and must inform the public of the intention to
> discontinue the availability of the standalone RI, and TCK one JSR
> submission in advance.*
>
> The signature of the 2 interfaces that duplicate AutoCloseable from SE 7
> may not be that "significant", but the interesting and vital question
> remains, if and under what terms, JSR 352 shall be made available
> "standalone" if the minimum SE version was 6, or would this qualify as
> "backport" into EE 6 Umbrella instead?[?]
>
> They're clearly not proposing to change anything about EE 6.
>
> None of the sections quoted above apply to the issue you've raised with
> the Batch spec.
>
>
(image/gif attachment: 35F.gif)