From: Werner Keil <werner.keil_at_gmail.com>
Date: Tue, 29 Jan 2013 12:54:40 +0100

Bill,

On Tue, Jan 29, 2013 at 6:23 AM, Bill Shannon <bill.shannon_at_oracle.com>wrote:

> 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.
>
>
If you think there's something to improve in that wording, I guess it'll be
best to speak to PMO and the 358 WG/EG about it. There are many areas, so
rephrasing something like that may not have the highest priority for them,
but ultimately both JSPA and the Process Document shall be improved.

The whole ME space will have Profiles and it looks like even SE is heading
there with some of the new JEPS. So Profiles might be the new "Umbrella
JSRs" at least that is the common understanding of those actively involved
in the current 358 work-stream.


> 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.
>
>
That was not really questioned, the minimum version was.
If products by IBM or even Oracle in either SE or EE space benefit from
this, I guess it's legitimate to try being backward-compatible, despite a
general trend to get the latest SE version out on as many machines, e.g.
for security reasons[?]

Unless the method signature changed, it may be seen as future compatible
with a simple extension of AutoCloseable, e.g. in version 2 of the JSR,
when SE 6 may no longer be relevant for active project development.


>
> 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>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.
>>
>>
>
>
>
Werner