2.1.3 was originally intended to only apply to Profiles. It looks like it's
been rewritten to be less precise. In any event, a Batch spec that works with
both SE 6 and SE 7 is certainly compatible with the most recent platform spec.
The Batch JSR says:
>
> 2.2 What is the target Java platform? (i.e., desktop, server,
> personal, embedded, card, etc.)
>
> Java EE,SE
>
>
> 2.16 Please describe how the RI and TCK will de delivered, i.e. as
> part of a profile or platform edition, or stand-alone, or both.
> Include version information for the profile or platform in your answer.
>
> The batch components described herein shall run on SE and on EE without
> change. The EE EG shall determine where to include the RI and TCK and how best
> to integrate.
>
I don't think there's any question that they intended to work on both SE and EE.
Werner Keil wrote on 01/28/2013 03:55 PM:
> 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
> <mailto: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.
>
>
>