
[[procedure-for-jakarta-platform-enterprise-edition-certification]]
= Procedure for Jakarta Platform, Enterprise Edition {tck_version}.0 Certification

This chapter describes the compatibility testing procedure and
compatibility requirements for Jakarta Platform, Enterprise Edition Version
{tck_version}.

This chapter contains the following sections:

* <<certification-overview>>
* <<compatibility-requirements>>
* <<appeals-process-ee>>
* <<specifications-for-jakarta-platform-enterprise-edition-version>>
* <<libraries-for-jakarta-platform-enterprise-edition-version>>

[[certification-overview]]
== Certification Overview

The certification process for Jakarta EE {tck_version}.0 consists of the
following activities:

* Install the appropriate version of the Technology Compatibility Kit
(TCK) and execute it in accordance with the instructions in this User's
Guide.
* Ensure that you meet the requirements outlined in
<<compatibility-requirements>> below.

* Certify to the Eclipse Foundation that you have finished
testing and that you meet all the compatibility requirements,
as required by the Eclipse Foundation TCK License.

[[compatibility-requirements]]
== Compatibility Requirements

The compatibility requirements for Jakarta EE {tck_version}.0 consist of meeting the
requirements set forth by the rules and associated definitions contained
in this section.

[[definitions]]
=== Definitions

These definitions are for use only with these compatibility requirements
and are not intended for any other purpose.

[[definitions-table]]
==== Table 2-1 Definitions

[width="100%",cols="25%,75%",options="header",]
|=======================================================================
|Term |Definition
|API Definition Product |A Product for which the only Java class files
contained in the product are those corresponding to the application
programming interfaces defined by the Specifications, and which is
intended only as a means for formally specifying the application
programming interfaces defined by the Specifications.

|Application |A collection of components contained in a single
application package (such as an EAR file or WAR file) and deployed at the same time.

|Computational Resource a|
A piece of hardware or software that may vary in quantity, existence, or
version, which may be required to exist in a minimum quantity and/or at
a specific or minimum revision level so as to satisfy the requirements
of the Test Suite.

Examples of computational resources that may vary in quantity are RAM
and file descriptors.

Examples of computational resources that may vary in existence (that is,
may or may not exist) are graphics cards and device drivers.

Examples of computational resources that may vary in version are
operating systems and device drivers.

|Configuration Descriptor |Any file whose format is well defined by a
specification and which contains configuration information for a set of
Java classes, archive, or other feature defined in the specification.

|Conformance Tests |All tests in the Test Suite for an indicated Technology Under Test, as released and distributed by the Eclipse Foundation, excluding
those tests in the Excluded Test set for the Technology Under Test.

|Container |An implementation of the associated Libraries, as specified
in the Specifications, and a version of a Java Platform, Standard
Edition Runtime Product, as specified in the Specifications, or a later
version of a Java Platform, Standard Edition Runtime Product that also
meets these compatibility requirements.

|Deployment Tool |A tool used to deploy applications or components in a
Product, as described in the Specifications.

|Development Kit |A software product that implements or incorporates a Compiler, a Schema Compiler, a Schema Generator.

|Documented |Made technically accessible and made known to users,
typically by means such as marketing materials, product documentation,
usage messages, or developer support programs.

|Edition |A Version of the Java Platform. Editions include Java Platform
Standard Edition and Jakarta Platform Enterprise Edition.

|Endorsed Standard |A Java API defined through a standards process other
than the Jakarta Enterprise Specification Process. The Endorsed Standard packages are
listed later in this chapter.

|Excluded Tests |Each release of a TCK may include tests that are annotated as excluded. These tests are not required to be run by the TCK user.

|Jakarta Server Page |A text-based document that uses Jakarta Pages technology.

|Jakarta Server Page Implementation Class |A program constructed by transforming
the Jakarta Server Page text into a Java language program using the transformation
rules described in the Specifications.

|Libraries a|
The class libraries, as specified through the Jakarta EE Specification Process
(JESP), for the Technology Under Test.

The Libraries for Jakarta Platform, Enterprise Edition Version 11 are listed
at the end of this chapter.

|Location Resource a|
A location of classes or native libraries that are components of the
test tools or tests, such that these classes or libraries may be
required to exist in a certain location in order to satisfy the
requirements of the test suite.

For example, classes may be required to exist in directories named in a
CLASSPATH variable, or native libraries may be required to exist in
directories named in a PATH variable.

|Maintenance Lead |The corresponding Jakarta EE Specification Project is 
responsible for maintaining the Specification and the TCK for the 
Technology. The Specification Project Team will propose revisions and 
updates to the Jakarta EE Specification Committee which will approve and 
release new versions of the specification and TCK. Eclipse Jakarta EE 
Specification Committee is the Maintenance Lead for Jakarta Platform, 
Enterprise Edition Version 11. 

|Operating Mode a|
Any Documented option of a Product that can be changed by a user in
order to modify the behavior of the Product.

For example, an Operating Mode of a Runtime can be binary
(enable/disable optimization), an enumeration (select from a list of
localizations), or a range (set the initial Runtime heap size).

Note that an Operating Mode may be selected by a command line switch, an
environment variable, a GUI user interface element, a configuration or
control file, etc.

|Product |A vendor's product in which the Technology Under Test is
implemented or incorporated, and that is subject to compatibility
testing.

|Product Configuration a|
A specific setting or instantiation of an Operating Mode.

For example, a Product supporting an Operating Mode that permits user
selection of an external encryption package may have a Product
Configuration that links the Product to that encryption package.

|Rebuildable Tests |Tests that must be built using an
implementation-specific mechanism. This mechanism must produce
specification defined artifacts. Rebuilding and running these tests
against a known compatible implementation verifies that the
mechanism generates compatible artifacts.

|Compatible Implementation (CI) |A ratified compatible implementation 
of a Specification.

|Resource |A Computational Resource, a Location Resource, or a Security
Resource.

|Rules |These definitions and rules in this Compatibility Requirements
section of this User's Guide.

|Runtime |The Containers specified in the Specifications.

|Security Resource a|
A security privilege or policy necessary for the proper execution of the
Test Suite.

For example, the user executing the Test Suite will need the privilege
to access the files and network resources necessary for use of the
Product.

|Specifications a|
The documents produced through the Jakarta EE Specification Process (JESP)
that define a particular Version of a Technology.

The Specifications for the Technology Under Test are referenced later in
this chapter.

|Technology |Specifications and one or more compatible implementations produced
through the Jakarta EE Specification Process (JESP).

|Technology Under Test |Specifications and a compatible implementation
for Jakarta Platform, Enterprise Edition Version 11.

|Test Suite |The requirements, tests, and testing tools distributed by
the Maintenance Lead as applicable to a given Version of the Technology.

|Version |A release of the Technology, as produced through the
Jakarta EE Specification Process (JESP).

|=======================================================================

[[rules-for-jakarta-platform-enterprise-edition-version-products]]
== Rules for Jakarta Platform, Enterprise Edition Version 11 Products

The following rules apply for each implementation:

EE1 The Product must be able to satisfy all applicable compatibility
requirements, including passing all required TCK tests.

For example, if a Product provides distinct Operating Modes to optimize
performance, then that Product must satisfy all applicable compatibility
requirements for a Product in each Product Configuration, and
combination of Product Configurations, of those Operating Modes.

EE1.1 Each implementation must have at least one Product Configuration that can be used to pass
all required TCK Tests, although such configuration may need adjustment (e.g. whether statically
or via administrative tooling).

EE1.2 An implementation may have mode(s) that provide compatibility with previous Jakarta EE versions.

EE1.3 An API Definition Product is exempt from all functional testing
requirements defined here, except the signature tests.

EE2 Some Conformance Tests may have properties that may be changed.
Properties that can be changed are identified in the configuration
interview. Properties that can be changed are identified in the JavaTest
Environment (.jte) files in the lib directory of the Test Suite
installation. Apart from changing such properties and other allowed
modifications described in this User's Guide (if any), no source or
binary code for a Conformance Test may be altered in any way without
prior written permission. Any such allowed alterations to the
Conformance Tests will be provided via the Jakarta EE Specification Project
website and apply to all vendor compatible implementations.

EE3 The testing tools supplied as part of the Test Suite or as
updated by the Maintenance Lead must be used to certify compliance.

EE4 The Excluded Tests associated with the Test Suite cannot be modified.

EE5 The Maintenance Lead may define exceptions to these Rules. Such
exceptions would be made available as above, and will apply to all vendor implementations.

EE6 All hardware and software component additions, deletions, and
modifications to a Documented supporting hardware/software platform,
that are not part of the Product but required for the Product to satisfy
the compatibility requirements, must be Documented and available to
users of the Product.

EE7 The Product must contain the full set of public and protected
classes and interfaces for all the Libraries. Those classes and
interfaces must contain exactly the set of public and protected methods,
constructors, and fields defined by the Specifications for those
Libraries. No subsetting, supersetting, or modifications of the public
and protected API of the Libraries are allowed except only as
specifically exempted by these Rules.

EE7.1 If a Product includes Technologies in addition to the
Technology Under Test, then it must contain the full set of combined
public and protected classes and interfaces. The API of the Product must
contain the union of the included Technologies. No further modifications
to the APIs of the included Technologies are allowed.

EE7.2 A Product may provide a newer version of an Endorsed Standard.
Upon request, the Maintenance Lead will make available alternate
Conformance Tests as necessary to conform with such newer version of an
Endorsed Standard. Such alternate tests will be made available to and
apply to all implementers. If a Product provides a newer version of an
Endorsed Standard, the version of the Endorsed Standard supported by the
Product must be Documented.

EE7.3 The Maintenance Lead may authorize the use of newer Versions of
a Technology included in the Technology Under Test. A Product that
provides a newer Version of a Technology must meet the Compatibility
Requirements for that newer Version, and must Document that it supports
the newer Version.

For example, the Jakarta Platform, Enterprise Edition Maintenance Lead
could authorize use of a newer version of a Java technology such as
Jakarta XML Web Services.

EE8 Except for tests specifically required by this TCK to be rebuilt
(if any), the binary Conformance Tests supplied as part of the Test
Suite or as updated by the Maintenance Lead must be used to certify
compliance.

EE9 The functional programmatic behavior of any binary class or
interface must be that defined by the Specifications.

EE9.1 A Product may contain Operating Modes that meet all of these
requirements, except Rule EE9, provided that:

.  The Operating Modes must not violate the Java Platform, Standard
Edition Rules.
.  Some Product Configurations of such Operating Modes may provide only
a subset of the functional programmatic behavior required by the
Specifications. The behavior of applications that use more than the
provided subset, when run in such Product Configurations, is
unspecified.
.  The functional programmatic behavior of any binary class or
interface in the above defined subset must be that defined by the
Specifications.
.  Any Product Configuration that invokes this rule must be clearly
Documented as not fully meeting the requirements of the Specifications.

EE10 Each Container must make technically accessible all Java SE
Runtime interfaces and functionality, as defined by the Specifications,
to programs running in the Container, except only as specifically
exempted by these Rules.

EE10.1 Containers may impose security constraints, as defined by the
Specifications.

EE11 A web Container must report an error, as defined by the
Specifications, when processing a Jakarta Server Page that does not conform to the
Specifications.

EE12 The presence of a Java language comment or Java language
directive in a Jakarta Server Page that specifies ”java” as the scripting language,
when processed by a web Container, must not cause the functional
programmatic behavior of that Jakarta Server Page to vary from the functional
programmatic behavior of that Jakarta Server Page in the absence of that Java
language comment or Java language directive.

EE13 The contents of any fixed template data (defined by the
Specifications) in a Jakarta Server Page, when processed by a web Container, must
not affect the functional programmatic behavior of that Jakarta Server Page, except
as defined by the Specifications.

EE14 The functional programmatic behavior of a Jakarta Server Page that
specifies ”java” as the scripting language must be equivalent to the
functional programmatic behavior of the Jakarta Server Page Implementation Class
constructed from that Jakarta Server Page.

EE15 A Deployment Tool must report an error when processing a
Configuration Descriptor that does not conform to the Specifications.

EE16 The presence of an XML comment in a Configuration Descriptor,
when processed by a Deployment Tool, must not cause the functional
programmatic behavior of the Deployment Tool to vary from the functional
programmatic behavior of the Deployment Tool in the absence of that
comment.

EE17 A Deployment Tool must report an error when processing an Jakarta Enterprise Beans
deployment descriptor that includes an Jakarta Enterprise Beans QL expression that does not
conform to the Specifications.

EE18 The Runtime must report an error when processing a Configuration
Descriptor that does not conform to the Specifications.

EE19 An error must be reported when processing a configuration
descriptor that includes a Java Persistence QL expression that does not
conform to the Specifications.

EE20 The presence of an XML comment in a Configuration Descriptor,
when processed by the Runtime, must not cause the functional
programmatic behavior of the Runtime to vary from the functional
programmatic behavior of the Runtime in the absence of that comment.

EE21 Compliance testing for Jakarta EE {tck_version}.0 consists of running Jakarta EE {tck_version}.0
TCK and the following Technology Compatibility Kits (TCKs). Version details are defined in the Platform EE Specification document (https://jakarta.ee/specifications/platform/11/), see the heading 'Full Jakarta™ EE Product Requirements':

* Jakarta Activation
* Jakarta Authentication
* Jakarta Batch
* Jakarta Bean Validation
* Jakarta Concurrency
* Jakarta Contexts and Dependency Injection
* Jakarta Data
* Jakarta Debugging Support for Other Languages
* Jakarta Dependency Injection
* Jakarta Faces 
* Jakarta JSON Binding
* Jakarta JSON Processing
* Jakarta Mail
* Jakarta RESTful Web Services
* Jakarta Security

In addition to the compatibility rules outlined in this TCK User's
Guide, Jakarta EE {tck_version}.0 implementations must also adhere to all of the
compatibility rules defined in the User's Guides of the aforementioned
TCKs.

EE21.1 If the Jakarta EE {tck_version} implementation uses a runtime which has
already been validated by the Technology Compatibility Kit,
the Jakarta EE {tck_version} implementation may use result of such validation
to claim its compliance with the Technology Compatibility Kit.

[[appeals-process-ee]]
== Jakarta Platform, Enterprise Edition Version 11 Test Appeals Process
See <<tck-test-appeals-steps>> for the Jakarta Platform, Enterprise Edition Version 11 Test Appeals Process.

[[specifications-for-jakarta-platform-enterprise-edition-version]]
== Specifications for Jakarta Platform, Enterprise Edition Version 11.0

The Specifications for Jakarta Platform, Enterprise Edition 11.0 are found on
the Eclipse Foundation, Jakarta EE Specifications web site at `https://jakarta.ee/specifications/platform/11/`. You may also find information available from the EE4J Jakarta EE Platform project page, at `https://projects.eclipse.org/projects/ee4j.jakartaee-platform`.

[[libraries-for-jakarta-platform-enterprise-edition-version]]
== Libraries for Jakarta Platform, Enterprise Edition Version {tck_version}.0

The following list constitutes the complete list of packages that are
required for Jakarta EE {tck_version}.0:

* jakarta.annotation
* jakarta.annotation.security
* jakarta.annotation.sql
* jakarta.batch.api
* jakarta.batch.api.chunk
* jakarta.batch.api.chunk.listener
* jakarta.batch.api.listener
* jakarta.batch.api.partition
* jakarta.batch.operations
* jakarta.batch.runtime
* jakarta.batch.runtime.context
* jakarta.decorator
* jakarta.data
* jakarta.data.exceptions
* jakarta.data.metamodel
* jakarta.data.page
* jakarta.data.repository
* jakarta.data.spi
* jakarta.ejb
* jakarta.ejb.embeddable (removed from Jakarta EE {tck_version} Platform but still part of Jakarta Enterprise Beans 4.0)
* jakarta.ejb.spi
* jakarta.el
* jakarta.enterprise.concurrent
* jakarta.enterprise.context
* jakarta.enterprise.context.control
* jakarta.enterprise.context.spi
* jakarta.enterprise.event
* jakarta.enterprise.inject
* jakarta.enterprise.inject.literal
* jakarta.enterprise.inject.se
* jakarta.enterprise.inject.spi
* jakarta.enterprise.inject.spi.configurator
* jakarta.enterprise.util
* jakarta.faces
* jakarta.faces.annotation
* jakarta.faces.application
* jakarta.faces.bean
* jakarta.faces.component
* jakarta.faces.component.behavior
* jakarta.faces.component.html
* jakarta.faces.component.search
* jakarta.faces.component.visit
* jakarta.faces.context
* jakarta.faces.convert
* jakarta.faces.el
* jakarta.faces.event
* jakarta.faces.flow
* jakarta.faces.flow.builder
* jakarta.faces.lifecycle
* jakarta.faces.model
* jakarta.faces.push
* jakarta.faces.render
* jakarta.faces.validator
* jakarta.faces.view
* jakarta.faces.view.facelets
* jakarta.faces.webapp
* jakarta.inject
* jakarta.interceptor
* jakarta.jms
* jakarta.json
* jakarta.json.bind
* jakarta.json.bind.adapter
* jakarta.json.bind.annotation
* jakarta.json.bind.config
* jakarta.json.bind.serializer
* jakarta.json.bind.spi
* jakarta.json.spi
* jakarta.json.stream
* jakarta.mail
* jakarta.mail.event
* jakarta.mail.internet
* jakarta.mail.search
* jakarta.mail.util
* jakarta.persistence
* jakarta.persistence.criteria
* jakarta.persistence.metamodel
* jakarta.persistence.spi
* jakarta.resource
* jakarta.resource.cci
* jakarta.resource.spi
* jakarta.resource.spi.endpoint
* jakarta.resource.spi.security
* jakarta.resource.spi.work
* jakarta.security.auth.message
* jakarta.security.auth.message.callback
* jakarta.security.auth.message.config
* jakarta.security.auth.message.module
* jakarta.security.enterprise
* jakarta.security.enterprise.authentication.mechanism.http
* jakarta.security.enterprise.credential
* jakarta.security.enterprise.identitystore
* jakarta.security.jacc
* jakarta.servlet
* jakarta.servlet.annotation
* jakarta.servlet.descriptor
* jakarta.servlet.http
* jakarta.servlet.jsp
* jakarta.servlet.jsp.el
* jakarta.servlet.jsp.jstl.core
* jakarta.servlet.jsp.jstl.fmt
* jakarta.servlet.jsp.jstl.sql
* jakarta.servlet.jsp.jstl.tlv
* jakarta.servlet.jsp.tagext
* jakarta.transaction
* javax.transaction.xa
* jakarta.validation
* jakarta.validation.bootstrap
* jakarta.validation.constraints
* jakarta.validation.constraintvalidation
* jakarta.validation.executable
* jakarta.validation.groups
* jakarta.validation.metadata
* jakarta.validation.spi
* jakarta.validation.valueextraction
* jakarta.websocket
* jakarta.websocket.server
* jakarta.ws.rs
* jakarta.ws.rs.client
* jakarta.ws.rs.container
* jakarta.ws.rs.core
* jakarta.ws.rs.ext
* jakarta.ws.rs.sse

