Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] [External] : Re: module-info tests 
On 10/6/21 11:06 PM, Thiago Henrique Hupner wrote:

Another question would be:

Can an API module include public classes that are not exported?
My answer is no. The reason is: APIs are expected to be the same regardless of whether they are loaded from the classpath or from the module path.
...if the API jar contains public non-exported class and one puts such API jar on the classpath, this public non-exported class becomes accessible to clients leading to different APIs available in different runtime environments. How can this be captured in the javadoc of such API jar? How can one avoid "leaking" this public non-exported class through classpath? 

 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.
I do not think there is an option to use JDK provided modules via classpath to break the encapsulation there. 

thanks,
--lukas




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
        <https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!f_OVk7bgEwjHPDoAmOaZhJMErc-WXN27fgyLRXgqjPXyvjSh30pXpLhPFe6JAIko3SY$>

Sent from Mailspring

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!f_OVk7bgEwjHPDoAmOaZhJMErc-WXN27fgyLRXgqjPXyvjSh30pXpLhPFe6JAIko3SY$

Back to the top