Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] module-info tests

I agree with what you are saying, but I don't see the discussion as trying to prescribe how an implementation is written other than to point out if compatibility testing is relevant, there are certain aspects required if you are providing your own API jar. I know Apache releases independent implementations of all Jakarta API jars, and JBoss/Red Hat has certainly proved our own versions of key API jars in the past. There cannot be an expectation that apps are only compiled against the API jars coming from the Jakarta projects, hence the requirements around signature testing.

On Oct 7, 2021 at 8:36:44 AM, Thomas Watson <tjwatson@xxxxxxxxxx> wrote:
Something that concerns me with this discussion is that we seem to be dictating the exact way an implementation is formed and how they package their implementation with the API.  I think the ideal implementation would only give applications access to supported APIs.  But how that is accomplished should not be prescribed by the specification.
I think we have two areas of concern here:
1) What JARs/Modules does an application developer compile against.
2) Does an implementation of a Jakarta Specification provide the correct Jakarta API package content to applications at runtime.
For Jakarta EE 10 my understanding is that we are in agreement that module-info usage at runtime is not required and therefore the presence or lack thereof does not matter for an implementation that does not load the API classes from a module layer.  In that case the API classes will have an unnamed module at runtime, and the actual module-info.class content will not matter at all.
What application developers compile against is a different matter.  I think most developers would want to compile against the spec'ed JARs the Jakarta EE project produces and publishes to maven central.  These JARs must have the correct module-info as defined by the specification and also have the correct API package content according to the specification.
If an implementation chooses to also provide JARs containing the Jakarta EE APIs for developers to compile against then these JARs should also have the same module-info and API package content as the corresponding API JARs published by the Jakarta EE project.  But are implementations required by the specification to provide such API JARs for developers to compile against?
If implementations are required to have the correct module-infos and distinct API JARs at runtime will that not prevent an implementation from doing something like provide a single implementation JAR that does everything required for the Web Profile, for example?

----- Original message -----
From: "Scott Marlow" <smarlow@xxxxxxxxxx>
Sent by: "jakartaee-platform-dev" <jakartaee-platform-dev-bounces@xxxxxxxxxxx>
To: "jakartaee-platform developer discussions" <jakartaee-platform-dev@xxxxxxxxxxx>, "Scott Stark" <starksm64@xxxxxxxxx>
Subject: [EXTERNAL] Re: [jakartaee-platform-dev] module-info tests
Date: Thu, Oct 7, 2021 7:53 AM


On 10/6/21 6:19 PM, Scott Stark wrote:
Theoretically that is true, but we are not requiring that JPMS be used in EE containers, so the signature tests would not validate that level of visibility. The other general issue is that one can always choose to not use modules, and so everything is visible.
Certainly for EE10 having public classes in an API jar that are meant to be internal will fail the signature tests.
+1 as signature testing does not allow super-setting.
On Oct 6, 2021 at 4:06:27 PM, Thiago Henrique Hupner <thihup@xxxxxxxxx> wrote:
Another question would be:
Can an API module include public classes that are not exported? It shouldn't be considered part of the API, but I don't know exactly
how the rules apply to an implementation, if it only can use package-private/inner classes to implement the code or if it
can delegate a class in other package that is not part of the API.
But if it is in other package, the class needs to be public. In the JDK there is a lot of API classes that uses public classes in an internal package,
like the implementation of java.lang.module.ModuleDescriptor is in jdk.internal.module.ModuleInfo, and it is a public class.
jakartaee-platform-dev mailing list
To unsubscribe from this list, visit
jakartaee-platform-dev mailing list
To unsubscribe from this list, visit

jakartaee-platform-dev mailing list
To unsubscribe from this list, visit

Back to the top