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.
I'd like the advice of this group on an issue with the Batch API.
The Batch API specifies how applications can define job steps.
Job steps are combined into a batch job using an XML file that
is effectively a batch "job control language" script. The application
starts a batch job by supplying this batch JCL script to the Batch API.
There are at least two models for how an application might deal with
these batch scripts:
1. The batch scripts are an integral part of the application. They're
supplied with the application and controlled by the application.
2. The application supplies only the batch job steps, expecting that
an external agent (usually an administrator) constructs a batch
script using these jobs. The application controls the execution
of the script, but not the content of the script.
In the first case it seems obvious that the batch script XML files
should be packaged with the application and the application should
refer to them by using a resource name in the application (possibly
a name valid for Class.getResource(), possibly a name of a file in
a fixed location in the application) when using the Batch API.
In the second case, the application needs to refer to these scripts,
but the scripts aren't packaged with the application, so it's not
clear how the application should refer to them. The Batch API
specifies this case very loosely. The Batch implementation is
free to interpret the names given to it in any way it desires,
locating these batch scripts wherever and however it wants. The
names used with case #1 above are portable, assuming they
haven't been overridden in some Batch implementation-specific way.
Normally, when a Java EE application uses a resource that's external
to the application and can be configured by an administrator, we
expect the application to declare this external dependency using
(e.g.) a @Resource annotation. This creates information known to
the deployment process that alerts the deployer that an external
resource is being referenced and must be supplied.
The Batch API provides no way to expose to the deployment process
an application's dependency on an externally supplied batch script.
An application might fail at runtime because the administrator didn't
supply the expected script with the expected name.
I've proposed that the Batch API make use of @Resource to handle
this case, similarly to how we've handled other cases, but they've
rejected that proposal. They believe the loosely defined approach
that leaves all the details up to the implementation is sufficient.
Which approach do you prefer?
1. The current Batch API approach of leaving all the details
up to the implementation.
2. Find a way (e.g., @Resource) to expose these application dependencies
on an external batch script to the deployment process.
Let me know what you think.
[javaee-spec users] [jsr342-experts] Re: Batch API issue