Modularized Jars

For the EE10 release, the following conventions have been adopted by the platform group for the production of API JARs from the specification projects:

• module-info must be placed in the root of the JAR
  • If your spec is not updating the API and producing a service release that needs to support Java SE 8, run two passes of the compiler-plugin to produce the SE 8 based content, followed by a pass to produce the SE 9 based module-info.class. Examples of producing such a jar with two compilation passes can be found in the JAF maven-compiler-plugin configuration at https://github.com/eclipse-ee4j/jaf/blob/master/api/pom.xml
  • Specs that have used this approach since EE8 are: Activation, XML Binding, XML web services, SOAP attachment, JSONP, mail, persistence, JSONB
• In case a spec wants/needs to support previous versions of Java, and needs integration with Java SE APIs from later releases, a multi-release JAR may be required for that spec. JAXB has done this since EE 9/9.1
  • A multi-release JAR should be used to produce a modularized JAR if that is the only change being made

Testing Requirements

For specification projects, it is up to the project to add any unit tests they want. There cannot be TCK/signature level tests as there is no requirement for Jakarta EE run-times to support JPMS. The specification committee will define the requirements for validation of the module-info.class as part of the API jar validation when the final specification is ratified.

For implementation/vendor provided API jars, there are NO requirements. An implementation does not need to provide a module-info, and they may provide an alternate module-info. It will not be validated as part of compatibility testing.