Procedure for Jakarta Platform, Enterprise Edition 10.0 Certification
Previous Next Contents

2 Procedure for Jakarta Platform, Enterprise Edition 10.0 Certification

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

This chapter contains the following sections:

2.1 Certification Overview

The certification process for Jakarta EE 10.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 Section 2.2, "Compatibility Requirements," below.

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

2.2 Compatibility Requirements

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

2.2.1 Definitions

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

Table 2-1 Definitions 
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 JAR file) and deployed at the same time using a Deployment Tool.

Computational Resource

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 on the published Exclude List 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, a Java-to-WSDL Tool, a WSDL-to-Java Tool, and an RMI Compiler.

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

Exclude List

The most current list of tests, released and distributed by the Eclipse Foundation, that are not required to be passed to certify conformance. The Jakarta EE Specification Committee may add to the Exclude List for that Test Suite as needed at any time, in which case the updated TCK version supplants any previous Exclude Lists for that Test Suite.

Java-to-WSDL Output

Output of a Java-to-WSDL Tool that is required for Web service deployment and invocation.

Java-to-WSDL Tool

A software development tool that implements or incorporates a function that generates web service endpoint descriptions in WSDL and XML schema format from Source Code as specified by the JAXWS Specification.

Jakarta Server Page

A text-based document that uses Jakarta Server 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

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 10 are listed at the end of this chapter.

Location Resource

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

Operating Mode

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 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 verified 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 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

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

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

WSDL-to-Java Output

Output of a WSDL-to-Java tool that is required for Web service deployment and invocation.

WSDL-to-Java Tool

A software development tool that implements or incorporates a function that generates web service interfaces for clients and endpoints from a WSDL description as specified by the JAXWS Specification.

2.2.2 Rules for Jakarta Platform, Enterprise Edition Version 10 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 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 Exclude List 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:

  1. The Operating Modes must not violate the Java Platform, Standard Edition Rules.

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

  3. The functional programmatic behavior of any binary class or interface in the above defined subset must be that defined by the Specifications.

  4. 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 10.0 consists of running Jakarta EE 10.0 TCK and the following Technology Compatibility Kits (TCKs). Version details are defined in the Platform EE Specification document (https://jakarta.ee/specifications/platform/10/), 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 Debugging Support for Other Languages

  • Jakarta Dependency Injection

  • Jakarta Faces

  • Jakarta JSON Binding

  • Jakarta JSON Processing

  • Jakarta Mail

  • Jakarta RESTful Web Services

  • Jakarta Security

  • Jakarta XML Binding (If XML Binding is supported)

In addition to the compatibility rules outlined in this TCK User’s Guide, Jakarta EE 10.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 10 implementation uses a runtime which has already been validated by the Technology Compatibility Kit, the Jakarta EE 10 implementation may use result of such validation to claim its compliance with the Technology Compatibility Kit.

EE22 Source Code in WSDL-to-Java Output when compiled by a Reference Compiler must execute properly when run on a Reference Runtime.

EE23 Source Code in WSDL-to-Java Output must be in source file format defined by the Java Language Specification (JLS).

EE24 Java-to-WSDL Output must fully meet W3C requirements for the Web Services Description Language (WSDL) 1.1.

EE25 A Java-to-WSDL Tool must not produce Java-to-WSDL Output from source code that does not conform to the Java Language Specification (JLS).

2.3 Jakarta Platform, Enterprise Edition Test Appeals Process

Jakarta has a well established process for managing challenges to its TCKs. Any implementor may submit a challenge to one or more tests in the Jakarta EE TCK as it relates to their implementation. Implementor means the entity as a whole in charge of producing the final certified release. Challenges filed should represent the consensus of that entity.

2.3.1 Valid Challenges

Any test case (e.g., test class, @Test method), test case configuration (e.g., deployment descriptor), test beans, annotations, and other resources considered part of the TCK may be challenged.

The following scenarios are considered in scope for test challenges:

  • Claims that a test assertion conflicts with the specification.

  • Claims that a test asserts requirements over and above that of the specification.

  • Claims that an assertion of the specification is not sufficiently implementable.

  • Claims that a test is not portable or depends on a particular implementation.

2.3.2 Invalid Challenges

The following scenarios are considered out of scope for test challenges and will be immediately closed if filed:

  • Challenging an implementation’s claim of passing a test. Certification is an honor system and these issues must be raised directly with the implementation.

  • Challenging the usefulness of a specification requirement. The challenge process cannot be used to bypass the specification process and raise in question the need or relevance of a specification requirement.

  • Claims the TCK is inadequate or missing assertions required by the specification. See the Improvement section, which is outside the scope of test challenges.

  • Challenges that do not represent a consensus of the implementing community will be closed until such time that the community does agree or agreement cannot be made. The test challenge process is not the place for implementations to initiate their own internal discussions.

  • Challenges to tests that are already excluded for any reason.

  • Challenges that an excluded test should not have been excluded and should be re-added should be opened as a new enhancement request

Test challenges must be made in writing via the {TechnologyShortName} specification project issue tracker as described in Section 2.3.3, "TCK Test Appeals Steps."

All tests found to be invalid will be placed on the Exclude List for that version of the {TechnologyShortName} TCK.

2.3.3 TCK Test Appeals Steps

  1. Challenges should be filed via the Jakarta EE Platform specification project’s issue tracker using the label challenge and include the following information:

    • The relevant specification version and section number(s)

    • The coordinates of the challenged test(s)

    • The exact TCK and exclude list versions

    • The implementation being tested, including name and company

    • The full test name

    • A full description of why the test is invalid and what the correct behavior is believed to be

    • Any supporting material; debug logs, test output, test logs, run scripts, etc.

  2. Specification project evaluates the challenge.
    Challenges can be resolved by a specification project lead, or a project challenge triage team, after a consensus of the specification project committers is reached or attempts to gain consensus fails. Specification projects may exercise lazy consensus, voting or any practice that follows the principles of Eclipse Foundation Development Process. The expected timeframe for a response is two weeks or less. If consensus cannot be reached by the specification project for a prolonged period of time, the default recommendation is to exclude the tests and address the dispute in a future revision of the specification.

  3. Accepted Challenges.
    A consensus that a test produces invalid results will result in the exclusion of that test from certification requirements, and an immediate update and release of an official distribution of the TCK including the new exclude list. The associated challenge issue must be closed with an accepted label to indicate it has been resolved.

  4. Rejected Challenges and Remedy.
    When a`challenge` issue is rejected, it must be closed with a label of invalid to indicate it has been rejected. There appeal process for challenges rejected on technical terms is outlined in Escalation Appeal. If, however, an implementer feels the TCK challenge process was not followed, an appeal issue should be filed with specification project’s TCK issue tracker using the label challenge-appeal. A project lead should escalate the issue with the Jakarta EE Specification Committee via email (jakarta.ee-spec@eclipse.org). The committee will evaluate the matter purely in terms of due process. If the appeal is accepted, the original TCK challenge issue will be reopened and a label of appealed-challenge added, along with a discussion of the appeal decision, and the challenge-appeal issue with be closed. If the appeal is rejected, the challenge-appeal issue should closed with a label of invalid.

  5. Escalation Appeal.
    If there is a concern that a TCK process issue has not been resolved satisfactorily, the Eclipse Development Process Grievance Handling procedure should be followed to escalate the resolution. Note that this is not a mechanism to attempt to handle implementation specific issues.

2.4 Specifications for Jakarta Platform, Enterprise Edition Version 10.0

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

2.5 Libraries for Jakarta Platform, Enterprise Edition Version 10.0

The following list constitutes the complete list of packages that are required for Jakarta EE 10.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.ejb

  • jakarta.ejb.embeddable (removed from Jakarta EE 10 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

  • jakarta.xml.bind (optional)

  • jakarta.xml.bind.annotation (optionsl)

  • jakarta.xml.bind.annotation.adapters (optional)

  • jakarta.xml.bind.attachment (optional)

  • jakarta.xml.bind.util (optional)

Previous Next Contents
Eclipse Foundation Logo  Copyright © 2017, 2021 Oracle and/or its affiliates. All rights reserved.