1. Licensing and Copyright

Technology Compatibility Kit User’s Guide for Jakarta JSON Binding

Release 3.1 for Jakarta EE

March 2022

Technology Compatibility Kit User’s Guide for Jakarta JSON Binding, Release 3.1 for Jakarta EE

Copyright © 2017, 2026 Oracle and/or its affiliates. All rights reserved.

This program and the accompanying materials are made available under the terms of the Eclipse Public License v. 2.0, which is available at http://www.eclipse.org/legal/epl-2.0.

SPDX-License-Identifier: EPL-2.0

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

2. Preface

This guide describes how to install, configure, and run the Technology Compatibility Kit (TCK) that is used to test the Jakarta JSON Binding (JSON Binding 3.1) technology.

The JSON Binding TCK is a portable, configurable automated test suite for verifying the compatibility of a vendor’s implementation of the JSON Binding 3.1 Specification (hereafter referred to as the vendor implementation or VI). The JSON Binding TCK uses the Junit framework to run the test suite

Note

Note All references to specific Web URLs are given for the sake of your convenience in locating the resources quickly. These references are always subject to changes that are in many cases beyond the control of the authors of this guide.

Jakarta EE is a community sponsored and community run program. Organizations contribute, along side individual contributors who use, evolve and assist others. Commercial support is not available through the Eclipse Foundation resources. Please refer to the Eclipse EE4J project site (https://projects.eclipse.org/projects/ee4j). There, you will find additional details as well as a list of all the associated sub-projects (Implementations and APIs), that make up Jakarta EE and define these specifications. If you have questions about this Specification you may send inquiries to jsonb-dev@eclipse.org. If you have questions about this TCK, you may send inquiries to jsonb-dev@eclipse.org.

2.1. Who Should Use This Book

This guide is for vendors that implement the JSON Binding 3.1 technology to assist them in running the test suite that verifies compatibility of their implementation of the JSON Binding 3.1 Specification.

2.2. Before You Read This Book

You should be familiar with the JSON Binding 3.1, version 3.1 Specification, which can be found at https://jakarta.ee/specifications/jsonb/.

2.3. Typographic Conventions

The following table describes the typographic conventions that are used in this book.

Convention Meaning Example

Boldface

Boldface type indicates graphical user interface elements associated with an action, terms defined in text, or what you type, contrasted with onscreen computer output.

From the File menu, select Open Project.

A cache is a copy that is stored locally.

machine_name% su
Password:

Monospace

Monospace type indicates the names of files and directories, commands within a paragraph, URLs, code in examples, text that appears on the screen, or text that you enter.

Edit your .login file.

Use ls -a to list all files.

machine_name% you have mail.

Italic

Italic type indicates book titles, emphasis, or placeholder variables for which you supply particular values.

Read Chapter 6 in the User’s Guide.

Do not save the file.

The command to remove a file is rm filename.

2.4. Shell Prompts in Command Examples

The following table shows the default UNIX system prompt and superuser prompt for the C shell, Bourne shell, and Korn shell.

Shell Prompt

C shell

machine_name%

C shell for superuser

machine_name#

Bourne shell and Korn shell

$

Bourne shell and Korn shell for superuser

#

Bash shell

shell_name-shell_version$

Bash shell for superuser

shell_name-shell_version#

3. Introduction

This chapter provides an overview of the principles that apply generally to all Technology Compatibility Kits (TCKs) and describes the Jakarta JSON Binding TCK (JSON Binding 3.1 TCK). It also includes a high level listing of what is needed to get up and running with the JSON Binding TCK.

This chapter includes the following topics:

3.1. Compatibility Testing

Compatibility testing differs from traditional product testing in a number of ways. The focus of compatibility testing is to test those features and areas of an implementation that are likely to differ across other implementations, such as those features that:

  • Rely on hardware or operating system-specific behavior

  • Are difficult to port

  • Mask or abstract hardware or operating system behavior

Compatibility test development for a given feature relies on a complete specification and compatible implementation (CI) for that feature. Compatibility testing is not primarily concerned with robustness, performance, nor ease of use.

3.1.1. Why Compatibility Testing is Important

Jakarta platform compatibility is important to different groups involved with Jakarta technologies for different reasons:

  • Compatibility testing ensures that the Jakarta platform does not become fragmented as it is ported to different operating systems and hardware environments.

  • Compatibility testing benefits developers working in the Jakarta programming language, allowing them to write applications once and then to deploy them across heterogeneous computing environments without porting.

  • Compatibility testing allows application users to obtain applications from disparate sources and deploy them with confidence.

  • Conformance testing benefits Jakarta platform implementors by ensuring a level playing field for all Jakarta platform ports.

3.1.2. TCK Compatibility Rules

Compatibility criteria for all technology implementations are embodied in the TCK Compatibility Rules that apply to a specified technology. Each TCK tests for adherence to these Rules as described in Procedure for Certification

3.1.3. TCK Overview

A TCK is a set of tools and tests used to verify that a vendor’s compatible implementation of a Jakarta EE technology conforms to the applicable specification. All tests in the TCK are based on the written specifications for the Jakarta EE platform. A TCK tests compatibility of a vendor’s compatible implementation of the technology to the applicable specification of the technology. Compatibility testing is a means of ensuring correctness, completeness, and consistency across all implementations developed by technology licensees.

The set of tests included with each TCK is called the test suite. Most tests in a TCK’s test suite are self-checking, but some tests may require tester interaction. Most tests return either a Pass or Fail status. For a given platform to be certified, all of the required tests must pass. The definition of required tests may change from platform to platform.

The definition of required tests will change over time. Before your final certification test pass, be sure to download the latest version of this TCK.

3.1.4. Jakarta EE Specification Process (JESP) Program and Compatibility Testing

The Jakarta EE Specification Process (JESP) program is the formalization of the open process that has been used since 2019 to develop and revise Jakarta EE technology specifications in cooperation with the international Jakarta EE community. The JESP program specifies that the following three major components must be included as deliverables in a final Jakarta EE technology release under the direction of the responsible Expert Group:

  • Technology Specification

  • Compatible Implementation (CI)

  • Technology Compatibility Kit (TCK)

For further information about the JESP program, go to Jakarta EE Specification Process community page https://jakarta.ee/specifications.

3.2. About the TCK

The JSON Binding TCK 3.1 is designed as a portable, configurable, automated test suite for verifying the compatibility of a vendor’s implementation of the JSON Binding 3.1 Specification.

3.2.1. TCK Specifications and Requirements

This section lists the applicable requirements and specifications.

  • Specification Requirements: Software requirements for a JSON Binding implementation are described in detail in the JSON Binding 3.1 Specification. Links to the JSON Binding specification and other product information can be found at https://jakarta.ee/specifications/jsonb/.

  • JSON Binding Version: The JSON Binding 3.1 TCK is based on the JSON Binding Specification, Version 3.1.

  • Compatible Implementation: One JSON Binding 3.1 Compatible Implementation, Eclipse Yasson 3.1 is available from the Eclipse EE4J project (https://projects.eclipse.org/projects/ee4j). See the CI documentation page at https://projects.eclipse.org/projects/ee4j.yasson for more information.

See the JSON Binding TCK Release Notes for more specific information about Java SE version requirements, supported platforms, restrictions, and so on.

3.2.2. TCK Components

The JSON Binding TCK 3.1 includes the following components:

  • JSON Binding TCK signature tests; check that all public APIs are supported and/or defined as specified in the JSON Binding Version 3.1 implementation under test.

  • If applicable, an exclude list, which provides a list of tests that your implementation is not required to pass.

  • API tests for all of the JSON Binding API in all related packages:

    • jakarta.json.bind

    • jakarta.json.bind.adapter

    • jakarta.json.bind.annotation

    • jakarta.json.bind.config

    • jakarta.json.bind.serializer

    • jakarta.json.bind.spi

The JSON Binding TCK tests run on the following platforms:

  • CentOS Linux 7

3.2.3. TCK Compatibility Test Suite

The test suite is the collection of tests to test a particular technology implementation. In this case, it is the collection of tests used by the JSON Binding TCK 3.1 to test a JSON Binding 3.1 implementation. The tests are designed to verify that a vendor’s runtime implementation of the technology complies with the appropriate specification. The individual tests correspond to assertions of the specification.

The tests that make up the TCK compatibility test suite are precompiled and indexed within the TCK test directory structure.

3.2.4. Exclude Lists

Each version of a TCK includes an Exclude List contained in a TCK-Exclude-List.txt file. This is a list of test file URLs that identify tests which do not have to be run for the specific version of the TCK being used. Whenever tests are run, the Junit framework automatically excludes these tests from being executed as those are disabled using '@Ignore' tag in JUnit.

A vendor’s compatible implementation is not required to pass or run any test on the Exclude List. The Exclude List file, {excludeListFileName}, is documented in the JSON Binding TCK. Please note this file is not parsed to exclude any test and is only for documentation purpose.

Note

From time to time, updates to the Exclude List are made available. The exclude list is included in the TCK ZIP archive. Each time an update is approved and released, the version number will be incremented. You should always make sure you are using an up-to-date copy of the Exclude List before running the JSON Binding TCK to verify your implementation.

A test might be in the Exclude List for reasons such as:

  • An error in an underlying implementation API has been discovered which does not allow the test to execute properly.

  • An error in the specification that was used as the basis of the test has been discovered.

  • An error in the test itself has been discovered.

  • The test fails due to a bug in the tools used to run the test.

In addition, all tests are run against the compatible implementations. Any tests that fail when run on a compatible Jakarta platform are put on the Exclude List. Any test that is not specification-based, or for which the specification is vague, may be excluded. Any test that is found to be implementation dependent (based on a particular thread scheduling model, based on a particular file system behavior, and so on) may be excluded.

Note

Vendors are not permitted to alter or modify Exclude Lists. Changes to an Exclude List can only be made by using the procedure described in TCK Test Appeals Steps.

3.2.5. TCK Configuration

You need to set several variables in your test environment, and run the JSON Binding tests, as described in Setup and Configuration.

Note

The Jakarta EE Specification Process support multiple compatible implementations. These instructions explain how to get started with the Eclipse Yasson 3.1 CI. If you are using another compatible implementation, refer to material provided by that implementation for specific instructions and procedures.

3.3. Getting Started With the TCK

This section provides an general overview of what needs to be done to install, set up, test, and use the JSON Binding TCK. These steps are explained in more detail in subsequent chapters of this guide.

  1. Make sure that the following software has been correctly installed on the system:

    • Java SE 17+

    • A CI for JSON Binding 3.1. One example is Eclipse Yasson 3.1.

    • JSON Binding TCK version 3.1, which includes:

    • The JSON Binding 3.1 Vendor Implementation (VI)

    • Any Jupiter API compatible test runner

    See the documentation for each of these software applications for installation instructions. See Installation, for instructions on installing the JSON Binding TCK.

  2. Set up the JSON Binding TCK software.
    See Setup and Configuration, for details about the following steps.

    1. Set up your shell environment.

  3. Test the JSON Binding 3.1 implementation.
    Test the JSON Binding implementation installation by running the test suite. See Executing Tests.

4. Procedure for Certification

This chapter describes the compatibility testing procedure and compatibility requirements for Jakarta JSON Binding. This chapter contains the following sections:

4.1. Certification Overview

The certification process for JSON Binding 3.1 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 of the compatibility requirements, as required by the Eclipse Foundation TCK License.

4.2. Compatibility Requirements

The compatibility requirements for JSON Binding 3.1 consist of meeting the requirements set forth by the rules and associated definitions contained in this section.

4.2.1. Definitions

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

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

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.

Documented

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

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.

Libraries

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

The Libraries for Jakarta JSON Binding 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.

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 can be binary (enable/disable optimization), an enumeration (select from a list of protocols), or a range (set the maximum number of active threads).

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.

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 JSON Binding Version 3.1.

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

4.2.2. Rules for Jakarta JSON Binding Products

The following rules apply for each version of an operating system, software component, and hardware platform Documented as supporting the Product:

JSONB1 The Product must be able to satisfy all applicable compatibility requirements, including passing all Conformance Tests, in every Product Configuration and in every combination of Product Configurations, except only as specifically exempted by these Rules.

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.

JSONB1.1 If an Operating Mode controls a Resource necessary for the basic execution of the Test Suite, testing may always use a Product Configuration of that Operating Mode providing that Resource, even if other Product Configurations do not provide that Resource. Notwithstanding such exceptions, each Product must have at least one set of Product Configurations of such Operating Modes that is able to pass all the Conformance Tests.

For example, a Product with an Operating Mode that controls a security policy (i.e., Security Resource) which has one or more Product Configurations that cause Conformance Tests to fail may be tested using a Product Configuration that allows all Conformance Tests to pass.

JSONB1.2 A Product Configuration of an Operating Mode that causes the Product to report only version, usage, or diagnostic information is exempted from these compatibility rules.

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

JSONB2 Some Conformance Tests may have properties that may be changed. Properties that can be changed are identified in the configuration interview. 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.

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

JSONB4 The Exclude List associated with the Test Suite cannot be modified.

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

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

For example, if a patch to a particular version of a supporting operating system is required for the Product to pass the Conformance Tests, that patch must be Documented and available to users of the Product.

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

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

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

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

4.3. 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 JSON Binding 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.

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

4.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 JSON Binding specification project issue tracker as described in TCK Test Appeals Steps.

All tests found to be invalid will be placed on the Exclude List for that version of the JSON Binding TCK.

4.3.3. TCK Test Appeals Steps

  1. Challenges should be filed via the Jakarta JSON Binding 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.

4.4. Successful Challenges

The following tests are exempt from TCK testing due to challenges:

Class Method Link Version

BasicJavaTypesMappingTest

testLongMapping

https://github.com/jakartaee/jsonb-api/issues/180

1.0.0

BigNumbersMappingTest

testBigNumberMarshalling

https://github.com/jakartaee/jsonb-api/issues/180

1.0.0

CollectionsMappingTest

testEnumSet

https://github.com/jakartaee/platform-tck/issues/103

1.0.0

CollectionsMappingTest

testEnumMap

https://github.com/jakartaee/platform-tck/issues/103

1.0.0

DatesMappingTest

testGregorianCalendarWithTimeMapping

https://github.com/jakartaee/platform-tck/issues/102

1.0.0

RecordsBasicTypeMappingTest

testLongMapping

https://github.com/jakartaee/jsonb-api/issues/180

1.0.0

4.5. Specifications for Jakarta JSON Binding

The Jakarta JSON Binding specification is available from the specification project web-site: https://jakarta.ee/specifications/jsonb/.

4.6. Libraries for Jakarta JSON Binding

The following is a list of the packages comprising the required class libraries for JSON Binding 3.1:

  • jakarta.json.bind

  • jakarta.json.bind.adapter

  • jakarta.json.bind.annotation

  • jakarta.json.bind.config

  • jakarta.json.bind.serializer

  • jakarta.json.bind.spi

For the latest list of packages, also see:

https://jakarta.ee/specifications/jsonb/

5. Installation

This chapter explains how to install the Jakarta JSON Binding TCK software.

After installing the software according to the instructions in this chapter, proceed to Setup and Configuration, for instructions on configuring your test environment.

Note

Although the JSON Binding 3.1 TCK is not depended on any particular build tool, it is convenient to install Apache Maven 3.6.3+ for setup and execution of tests. Any other build tools like Gradle and JUnit 4 Console Runner can also be used that is Jupiter API compatible.

5.1. Obtaining a Compatible Implementation

Each compatible implementation (CI) will provide instructions for obtaining their implementation. Eclipse Yasson 3.1 is a compatible implementation which may be obtained from https://projects.eclipse.org/projects/ee4j.yasson

5.2. Installing the Software

Before you can run the JSON Binding TCK tests, you must install and set up the following software components:

  • Java SE 17+

  • A CI for JSON Binding 3.1, one example is Eclipse Yasson 3.1

  • The JSON Binding 3.1 Vendor Implementation (VI)

  • Any Jupiter API compatible test runner (eg. Apache Maven 3.6.3+)

Follow these steps:

  1. Install the Java SE 17+ software, if it is not already installed.
    Download and install the Java SE 17+ software from http://www.oracle.com/technetwork/java/javase/downloads/index.html. Refer to the installation instructions that accompany the software for additional information.

  2. Install the build tool that will be used to run the TCK, if it is not already installed.
    It will be convenient to use Apache Maven 3.6.3+ for running the tests. The test kit is not depended on Maven, any build tool compatible with Jupiter API is suffitient.

  3. Install the JSON Binding TCK 3.1 software.

    1. Copy or download the JSON Binding TCK software to your local system.
      You can obtain the JSON Binding TCK software from the Jakarta EE site https://jakarta.ee/specifications/jsonb/.

    2. Use the unzip command to extract the bundle in the directory of your choice:
      unzip {TCKPackageName}

  4. Install a JSON Binding 3.1 Compatible Implementation.
    A Compatible Implementation is used to validate your initial configuration and setup of the JSON Binding TCK 3.1 tests, which are explained further in Setup and Configuration.
    The Compatible Implementations for JSON Binding are listed on the Jakarta EE Specifications web site: https://jakarta.ee/specifications/jsonb/.

  5. Install the JSON Binding VI to be tested.
    Follow the installation instructions for the particular VI under test.

6. Setup and Configuration

Note

The Jakarta EE Specification process provides for any number of compatible implementations. As additional implementations become available, refer to project or product documentation from those vendors for specific TCK setup and operational guidance.

This chapter describes how to set up the JSON Binding TCK. Before proceeding with the instructions in this chapter, be sure to install all required software, as described in Installation.

After completing the instructions in this chapter, proceed to Executing Tests, for instructions on running the JSON Binding TCK.

Note

The JSON Binding TCK is not depended on any particular build tool to run the tests. It will be convenient and advisable to create a Apache Maven project to setup and run the TCK. This chapter will henceforth use instructions and steps to provide setup with Apache Maven as a build tool.

6.1. Configuring Your Environment to Run the TCK Against the Reference Implementation

After configuring your environment as described in this section, continue with the instructions in Executing Tests.

Note

In these instructions, variables in angle brackets need to be expanded for each platform. For example, <JAVA_HOME> becomes $JAVA_HOME on Solaris/Linux and %JAVA_HOME% on Windows. In addition, the forward slashes (/) used in all of the examples need to be replaced with backslashes (\) for Windows. Finally, be sure to use the appropriate separator for your operating system when specifying multiple path entries (; on Windows, : on UNIX/Linux).

On Windows, you must escape any backslashes with an extra backslash in path separators used in any of the following properties, or use forward slashes as a path separator instead.

  1. Set the following environment variables in your shell environment:

    1. JAVA_HOME to the directory in which Java SE 17+ is installed

    2. M2_HOME to the directory in which the Apache Maven build tool is installed.

    3. {TechnologyHomeEnv} to the directory in which the JSON Binding 3.1 CI has been installed

    4. PATH to include the following directories: JAVA_HOME/bin, and M2_HOME/bin

  2. Set below Maven/System properties

    1. jimage.dir This property specifies the directory where Java 11+ modules will be expanded by the jimage tool for use in sigTestClasspath

    2. sigTestClasspath This property must be set when running signature tests. This property should be set to a list of jar files and/or directories which contain your Jakarta EE and Java SE classes. Paths must be separated by the appropriate path separator (';' windows, ':' Unixes).

    3. jsonb-impl.groupId property is set to the Maven Group Id of the CI to test.

    4. jsonb-impl.artifactId property is set to the Maven Artifact Id of the CI to test.

    5. jsonb-impl.version property is set to the Maven Version of the CI to test.

  3. Set the below jars to the classpath

    1. JAR file for the JSON Binding 3.1 CI.
      jakarta.json.bind-api.jar.

    2. JUnit 5 jars (5.7.2+)

    3. JSON Binding TCK tests (jakarta.json.bind:jakarta.json.bind-tck)

Example: Maven configuration
    <dependencies>
        <dependency>
          <groupId>CI.group.id</groupId>
          <artifactId>CI.artifact.id</artifactId>
          <version>CI.version</version>
          <scope>test</scope>
        </dependency>
        <dependency>
          <groupId>jakarta.json.bind</groupId>
          <artifactId>jakarta.json.bind-api</artifactId>
          <version>3.0.0</version>
          <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>jakarta.json</groupId>
            <artifactId>jakarta.json-api</artifactId>
            <version>2.1.0</version>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>org.jboss.weld.se</groupId>
            <artifactId>weld-se-core</artifactId>
            <version>5.0.0.Beta1</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>jakarta.json.bind</groupId>
            <artifactId>jakarta.json.bind-tck</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>

6.2. Configuring Your Environment to Run the TCK Against the Vendor Implementation

After configuring your environment as described in this section, continue with the instructions in Executing Tests.

Note

In these instructions, variables in angle brackets need to be expanded for each platform. For example, <JAVA_HOME> becomes $JAVA_HOME on Solaris/Linux and %JAVA_HOME% on Windows. In addition, the forward slashes (/) used in all of the examples need to be replaced with backslashes (\) for Windows. Finally, be sure to use the appropriate separator for your operating system when specifying multiple path entries (; on Windows, : on UNIX/Linux).

On Windows, you must escape any backslashes with an extra backslash in path separators used in any of the following properties, or use forward slashes as a path separator instead.

  1. Set the following environment variables in your shell environment:

    1. JAVA_HOME to the directory in which Java SE 17+ is installed

    2. M2_HOME to the directory in which the Apache Maven build tool is installed.

    3. {TechnologyHomeEnv} to the directory in which the JSON Binding 3.1 CI has been installed

    4. PATH to include the following directories: JAVA_HOME/bin, and M2_HOME/bin

  2. Set below Maven/System properties

    1. jimage.dir This property specifies the directory where Java 11+ modules will be expanded by the jimage tool for use in sigTestClasspath

    2. sigTestClasspath This property must be set when running signature tests. This property should be set to a list of jar files and/or directories which contain your Java EE and Java SE classes. Paths must be separated by the appropriate path separator (';' windows, ':' Unixes).

    3. jsonb-api.groupId property is set to the Maven Group Id of the VI to test.

    4. jsonb-api.artifactId property is set to the Maven Artifact Id of the VI to test.

    5. jsonb-api.version property is set to the Maven Version of the VI to test.

  3. Set the below jars to the classpath

    1. JAR file for the JSON Binding 3.1 VI.
      yasson.jar.

    2. JUnit 5 jars (5.7.2+)

    3. JSON Binding TCK tests (jakarta.json.bind:jakarta.json.bind-tck)

Example: Maven configuration
    <dependencies>
        <dependency>
          <groupId>VI.grou.id</groupId>
          <artifactId>VI.artefact.id</artifactId>
          <version>VI.version</version>
          <scope>test</scope>
        </dependency>
        <dependency>
          <groupId>org.eclipse</groupId>
          <artifactId>yasson</artifactId>
          <version>3.0.0-R1</version>
          <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>jakarta.json</groupId>
            <artifactId>jakarta.json-api</artifactId>
            <version>2.1.0</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.jboss.weld.se</groupId>
            <artifactId>weld-se-core</artifactId>
            <version>5.0.0.Beta1</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>jakarta.json.bind</groupId>
            <artifactId>jakarta.json.bind-tck</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>

6.3. Publishing the Test Applications

Not needed for the JSON Binding TCK.

7. Executing Tests

The JSON Binding TCK uses the Junit framework to execute the tests.

This chapter includes the following topics:

Note

The instructions in this chapter assume that you have installed and configured your test environment as described in Installation and Setup and Configuration respectively.

7.1. Starting the tests

The JSON Binding TCK can be run from the command line in your shell environment by executing tests from the TCK jar.

Note

The mvn command referenced in the following two procedures and elsewhere in this guide is the Apache Maven build tool, which will need to be downloaded separately.

7.1.1. To Run All Tests

To run all tests, enter the following command:

cd ${TechnologyHomeEnv}/bin
mvn verify

7.2. Running a Subset of the Tests

Use the following modes to run a subset of the tests:

7.2.1. To Run a Single Test

To run a single test, enter the following command:

cd ${TechnologyHomeEnv}/bin
mvn verify -Dtest=ee.jakarta.tck.json.bind.api.jsonb.JsonbTest

7.2.2. To Run a Subset of Tests

To run a subset of tests, enter the following command:

cd ${TechnologyHomeEnv}/bin
mvn verify -Dtest=ee.jakarta.tck.json.bind.api

7.2.3. To Run Signature Tests

To run the JSON Binding TCK Signature Tests, enter the following command:

cd ${TechnologyHomeEnv}/bin
mvn verify -Dtest=ee.jakarta.tck.json.bind.signaturetest.jsonb.JSONBSigTest

7.3. Running the TCK Against another CI

Some test scenarios are designed to ensure that the configuration and deployment of all the prebuilt JSON Binding TCK tests against one Compatible Implementation are successful operating with other compatible implementations, and that the TCK is ready for compatibility testing against the Vendor and Compatible Implementations.

  1. Verify that you have followed the configuration instructions in Configuring Your Environment to Run the TCK Against the Reference Implementation.

  2. Run the tests, as described in Starting the tests and, if desired, Running a Subset of the Tests.

7.4. Running the TCK Against a Vendor Implementation

This test scenario is one of the compatibility test phases that all Vendors must pass.

  1. Verify that you have followed the configuration instructions in Configuring Your Environment to Run the TCK Against the Vendor Implementation.

  2. Run the tests, as described in Starting the tests and, if desired, Running a Subset of the Tests.

7.5. Test Reports

A set of report files is created for every test run. These report files can be found in the target directory that the test is run. After a test run is completed, the Junit framework writes reports for the test run.

8. Debugging Test Problems

There are a number of reasons that tests can fail to execute properly. This chapter provides some approaches for dealing with these failures. Please note that most of these suggestions are only relevant when running the test harness in GUI mode.

This chapter includes the following topics:

8.1. Overview

The goal of a test run is for all tests in the test suite that are not filtered out to have passing results. If the root test suite folder contains tests with errors or failing results, you must troubleshoot and correct the cause to satisfactorily complete the test run.

  • Errors: Tests with errors could not be executed by the Junit framework. These errors usually occur because the test environment is not properly configured.

  • Failures: Tests that fail were executed but had failing results.

For every test run, the Junit framework creates a set of report files in the target directory.

If a large number of tests failed, you should read Configuration Failures to see if a configuration issue is the cause of the failures.

If a large number of tests failed, you should read Configuration Failures to see if a configuration issue is the cause of the failures.

8.2. Configuration Failures

Configuration failures are easily recognized because many tests fail the same way. When all your tests begin to fail, you may want to stop the run immediately and start viewing individual test output.

9. Assertion Details

This section lists the total number of assertions in the TCK, and the expected output from a successful run of the TCK.

9.1. Total Assertions

total skipped

358

6

9.2. Expected TCK Output

$ mvn clean test
...
[INFO] --- maven-surefire-plugin:x.x.x:test (default-test) @ tck.runner ---
[INFO] Using auto detected provider org.apache.maven.surefire.junitplatform.JUnitPlatformProvider
[INFO]
[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[INFO] Running ee.jakarta.tck.json.bind.api.annotation.AnnotationTest
[INFO] Tests run: 10, Failures: 0, Errors: 0, Skipped: 0,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.api.annotation.AnnotationTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.api.builder.JsonbBuilderTest
[INFO] Tests run: 8, Failures: 0, Errors: 0, Skipped: 0,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.api.builder.JsonbBuilderTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.api.config.JsonbConfigTest
[INFO] Tests run: 22, Failures: 0, Errors: 0, Skipped: 0,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.api.config.JsonbConfigTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.api.exception.JsonbExceptionTest
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.api.exception.JsonbExceptionTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.api.jsonb.JsonbTest
[INFO] Tests run: 12, Failures: 0, Errors: 0, Skipped: 0,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.api.jsonb.JsonbTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.api.jsonbadapter.JsonbAdapterTest
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.api.jsonbadapter.JsonbAdapterTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.cdi.customizedmapping.adapters.AdaptersCustomizationCDITest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.cdi.customizedmapping.adapters.AdaptersCustomizationCDITest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.cdi.customizedmapping.serializers.SerializersCustomizationCDITest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.cdi.customizedmapping.serializers.SerializersCustomizationCDITest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.customizedmapping.adapters.AdaptersCustomizationTest
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.customizedmapping.adapters.AdaptersCustomizationTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.customizedmapping.binarydata.BinaryDataCustomizationTest
[INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.customizedmapping.binarydata.BinaryDataCustomizationTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.customizedmapping.dateformat.DateFormatCustomizationTest
[INFO] Tests run: 11, Failures: 0, Errors: 0, Skipped: 0,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.customizedmapping.dateformat.DateFormatCustomizationTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.customizedmapping.ijson.IJsonSupportTest
[INFO] Tests run: 9, Failures: 0, Errors: 0, Skipped: 0,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.customizedmapping.ijson.IJsonSupportTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.customizedmapping.instantiation.InstantiationCustomizationTest
[INFO] Tests run: 10, Failures: 0, Errors: 0, Skipped: 0,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.customizedmapping.instantiation.InstantiationCustomizationTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.customizedmapping.instantiation.OptionalCreatorParametersTest
[INFO] Tests run: 5, Failures: 0, Errors: 0, Skipped: 0,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.customizedmapping.instantiation.OptionalCreatorParametersTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.customizedmapping.instantiation.RecordInstantiationTest
[INFO] Tests run: 10, Failures: 0, Errors: 0, Skipped: 0,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.customizedmapping.instantiation.RecordInstantiationTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.customizedmapping.nullhandling.NullHandlingCustomizationTest
[INFO] Tests run: 14, Failures: 0, Errors: 0, Skipped: 0,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.customizedmapping.nullhandling.NullHandlingCustomizationTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.customizedmapping.numberformat.NumberFormatCustomizationTest
[INFO] Tests run: 7, Failures: 0, Errors: 0, Skipped: 0,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.customizedmapping.numberformat.NumberFormatCustomizationTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.customizedmapping.propertynames.PropertyNameCustomizationTest
[INFO] Tests run: 23, Failures: 0, Errors: 0, Skipped: 0,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.customizedmapping.propertynames.PropertyNameCustomizationTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.customizedmapping.propertynames.RecordPropertyNameTest
[INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.customizedmapping.propertynames.RecordPropertyNameTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.customizedmapping.propertyorder.PropertyOrderCustomizationTest
[INFO] Tests run: 12, Failures: 0, Errors: 0, Skipped: 0,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.customizedmapping.propertyorder.PropertyOrderCustomizationTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.customizedmapping.propertyorder.RecordPropertyOrderTest
[INFO] Tests run: 7, Failures: 0, Errors: 0, Skipped: 0,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.customizedmapping.propertyorder.RecordPropertyOrderTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.customizedmapping.records.RecordTransientCustomizationTest
[INFO] Tests run: 6, Failures: 0, Errors: 0, Skipped: 0,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.customizedmapping.records.RecordTransientCustomizationTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.customizedmapping.serializers.SerializersCustomizationTest
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.customizedmapping.serializers.SerializersCustomizationTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.customizedmapping.visibility.VisibilityCustomizationTest
[INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.customizedmapping.visibility.VisibilityCustomizationTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.defaultmapping.arrays.ArraysMappingTest
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.defaultmapping.arrays.ArraysMappingTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.defaultmapping.attributeorder.AttributeOrderMappingTest
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.defaultmapping.attributeorder.AttributeOrderMappingTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.defaultmapping.basictypes.BasicJavaTypesMappingTest
[WARNING] Tests run: 9, Failures: 0, Errors: 0, Skipped: 1,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.defaultmapping.basictypes.BasicJavaTypesMappingTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.defaultmapping.bignumbers.BigNumbersMappingTest
[WARNING] Tests run: 0, Failures: 0, Errors: 0, Skipped: 1,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.defaultmapping.bignumbers.BigNumbersMappingTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.defaultmapping.classes.ClassesMappingTest
[INFO] Tests run: 23, Failures: 0, Errors: 0, Skipped: 0,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.defaultmapping.classes.ClassesMappingTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.defaultmapping.collections.CollectionsMappingTest
[WARNING] Tests run: 20, Failures: 0, Errors: 0, Skipped: 2,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.defaultmapping.collections.CollectionsMappingTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.defaultmapping.dates.DatesMappingTest
[WARNING] Tests run: 24, Failures: 0, Errors: 0, Skipped: 1,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.defaultmapping.dates.DatesMappingTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.defaultmapping.enums.EnumMappingTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.defaultmapping.enums.EnumMappingTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.defaultmapping.generics.GenericsMappingTest
[INFO] Tests run: 7, Failures: 0, Errors: 0, Skipped: 0,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.defaultmapping.generics.GenericsMappingTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.defaultmapping.identifiers.NamesAndIdentifiersMappingTest
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.defaultmapping.identifiers.NamesAndIdentifiersMappingTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.defaultmapping.ignore.MustIgnoreMappingTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.defaultmapping.ignore.MustIgnoreMappingTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.defaultmapping.interfaces.InterfaceMappingTest
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.defaultmapping.interfaces.InterfaceMappingTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.defaultmapping.jsonptypes.JSONPTypesMappingTest
[INFO] Tests run: 10, Failures: 0, Errors: 0, Skipped: 0,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.defaultmapping.jsonptypes.JSONPTypesMappingTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.defaultmapping.nullvalue.NullValueMappingTest
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.defaultmapping.nullvalue.NullValueMappingTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.defaultmapping.polymorphictypes.AnnotationTypeInfoTest
[INFO] Tests run: 6, Failures: 0, Errors: 0, Skipped: 0,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.defaultmapping.polymorphictypes.AnnotationTypeInfoTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.defaultmapping.polymorphictypes.DefaultPolymorphicMappingTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.defaultmapping.polymorphictypes.DefaultPolymorphicMappingTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.defaultmapping.polymorphictypes.MultipleTypeInfoTest
[INFO] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.defaultmapping.polymorphictypes.MultipleTypeInfoTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.defaultmapping.polymorphictypes.TypeInfoExceptionsTest
[INFO] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.defaultmapping.polymorphictypes.TypeInfoExceptionsTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.defaultmapping.records.RecordComponentAccessorCustomizationTest
[INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.defaultmapping.records.RecordComponentAccessorCustomizationTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.defaultmapping.records.RecordDefaultMappingTest
[INFO] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.defaultmapping.records.RecordDefaultMappingTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.defaultmapping.records.RecordInstantiationTest
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.defaultmapping.records.RecordInstantiationTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.defaultmapping.records.RecordVirtualAttributeTest
[INFO] Tests run: 10, Failures: 0, Errors: 0, Skipped: 0,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.defaultmapping.records.RecordVirtualAttributeTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.defaultmapping.records.RecordsBasicTypeMappingTest
[WARNING] Tests run: 9, Failures: 0, Errors: 0, Skipped: 1,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.defaultmapping.records.RecordsBasicTypeMappingTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.defaultmapping.records.RecordsPolymorphicMappingTest
[INFO] Tests run: 6, Failures: 0, Errors: 0, Skipped: 0,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.defaultmapping.records.RecordsPolymorphicMappingTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.defaultmapping.specifictypes.SpecificTypesMappingTest
[INFO] Tests run: 15, Failures: 0, Errors: 0, Skipped: 0,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.defaultmapping.specifictypes.SpecificTypesMappingTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.defaultmapping.uniqueness.PropertyUniquenessTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.defaultmapping.uniqueness.PropertyUniquenessTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.defaultmapping.untyped.UntypedMappingTest
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.defaultmapping.untyped.UntypedMappingTest
[INFO]
[INFO] Running ee.jakarta.tck.json.bind.signaturetest.jsonb.JSONBSigTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0,Time elapsed: y.yy s - in ee.jakarta.tck.json.bind.signaturetest.jsonb.JSONBSigTest
[INFO]
[INFO] Results:
[INFO]
[WARNING] Tests run: 364, Failures: 0, Errors: 0, Skipped: 6
[INFO]
[INFO] -------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] -------------------------------------------------------
[INFO] Total time:  xx.xxx s
[INFO] Finished at: yyyy-mm-ddThh:mm:ss.mmmm
[INFO] -------------------------------------------------------

9.3. Expected Signature Test Output

******************************************************
All package signatures passed.
    Passed packages listed below:
        jakarta.json.bind(static mode)
        jakarta.json.bind(reflection mode)
        jakarta.json.bind.adapter(static mode)
        jakarta.json.bind.adapter(reflection mode)
        jakarta.json.bind.annotation(static mode)
        jakarta.json.bind.annotation(reflection mode)
        jakarta.json.bind.config(static mode)
        jakarta.json.bind.config(reflection mode)
        jakarta.json.bind.serializer(static mode)
        jakarta.json.bind.serializer(reflection mode)
        jakarta.json.bind.spi(static mode)
        jakarta.json.bind.spi(reflection mode)

******************************************************

Appendix A: Frequently Asked Questions

This appendix contains the following questions.

A.1. Where do I start to debug a test failure?

See Debugging Test Problems, for more information.

A.2. How do I restart a crashed test run?

If you need to restart a test run, you can figure out which test crashed the test suite by looking at the logs.

A.3. What would cause tests be added to the exclude list?

The exclude file ({excludeListFileName}) contains all tests that are not required to be run. The following is a list of reasons for a test to be included in the Exclude List:

  • An error in a Compatible Implementation that does not allow the test to execute properly has been discovered.

  • An error in the specification that was used as the basis of the test has been discovered.

  • An error in the test has been discovered.

Appendix B: Rebuild Rules

Rebuild Rules is not used for the JSON Binding TCK.