Re: [jakartaee-platform-dev] module-info tests

[Thiago Henrique Hupner <thihup@xxxxxxxxx>]

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.

On Out 6 2021, at 5:29 pm, Thiago Henrique Hupner <thihup@xxxxxxxxx> wrote:

Hi.

It is possible to read a module using the ModuleDescriptor::read (https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/module/ModuleDescriptor.html#read(java.io.InputStream)). Maybe that is useful.

One thing that might be tricky to answer is:

Can API modules depend on other libraries?

I have a use case: My library JoEL is a _expression_ Language implementation. Currently, I'm using the JDK.Dynalink module in the API, as an implementation detail, as most of the API requires to provide an implementation of it in the same class (like jakarta.el.BeanELResolver). However, if a user wants to use it, their JDK has to contain the JDK.Dynalink module.

In this case, it is a module that comes with the Standard JDK, but it is not an official module, but I guess the same rules would apply for 3rd party dependencies.

What do you think?

On Out 6 2021, at 5:06 pm, Scott Stark <starksm64@xxxxxxxxx> wrote:

It was brought up that some api jars like bean-validation need to be updated to include a module-info.class, but it was unclear what requirements are needed to verify this. TCKs do not run with modules enabled. I just did a basic test of accessing the java.lang.Module information for a class loaded via the class path from a jar with a module-info.class, and of course the class was loaded from the unnamed module.

It seems like the baseline validation of module-info.class for api jars will have to be some check for existence as part of the specification pull request review. This is something that can be added to the existing automation work.

If other projects want to add additional TCK tests, I suppose they could, but since it is not a requirement for implementations to run with modules enabled, it probably won't work. For the next platform call we need to clarify exactly what module-info.class validation is required, and whether projects like bean-validation can simply put out a service release that includes only the api jar, no TCK and obviously no spec updates.

_______________________________________________

jakartaee-platform-dev mailing list

jakartaee-platform-dev@xxxxxxxxxxx

To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev