I did not intent to suggest that apps are only allowed to be compiled against the API JARs from Jakarta projects. I was asking if implementations are required to provide to such JARs for development purposes? Don't get me wrong, implementations should be allowed to provide such JARs to allow them to provide various developer experiences as they see fit. Open Liberty certainly does provide such JARs for developers to compile against also. I do think such JARs should conform to the module-info requirements from Jakarta. But I don't think the specification requires an implementation to provide such JARs for the developer to compile against.
If implementations are not required to provide API JARs for compilation/development purposes then I do not see the point of the TCK testing for module-info classes against the implementation. On the other hand the Jakarta build of the API JARs should contain a test that validates they are providing the correct things.
Tom
----- Original message ----- From: "Scott Stark" <starksm64@xxxxxxxxx> Sent by: "jakartaee-platform-dev" <jakartaee-platform-dev-bounces@xxxxxxxxxxx> To: "jakartaee-platform developer discussions" <jakartaee-platform-dev@xxxxxxxxxxx> Cc: Subject: [EXTERNAL] Re: [jakartaee-platform-dev] module-info tests Date: Thu, Oct 7, 2021 9:08 AM
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.
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?
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.
