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?
Tom
----- 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> Cc: 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.
