[hibernate-dev] OpenJDK proposal: JDK 9 modules and reflection

[Yoann Rodiere]

I'll try to jump in. I'm mainly providing an external point of view though,
since I didn't seriously follow the progress of Java 9.

If I understood correctly, modules containing entities would not need to be
weak; they *could* be, as a quick solution to migrating to Java 9, but
ultimately the clean way of (re-)writing them would be:

    module foo.bar {
        exports private com.foo.bar.model; // Exports to anyone, including
hibernate.*
        requires javax.jpa;
    }

(Assuming all classes needed by Hibernate are in `com.foo.bar.model`)

Then public classes of package `com.foo.bar.model` would be exported to any
module, and additionally package-protected classes from this package could
be made accessible by anyone using `AccessibleObject::setAccessible`. Which
seems to solve the issue at least in principle.

What I'm not sure about is if it couldn't be even stricter by using a
qualified export :

    module foo.bar {
        exports private com.foo.bar.model to hibernate.entitymanager;
        exports private com.foo.bar.model to hibernate.core;
        requires javax.jpa;
    }

It has the advantage of not disclosing private code to the entire world,
but the disadvantage of referring to the JPA implementation explicitely,
which is a shame.

In an ideal world, it would be awesome to be able to not reference
Hibernate at all (as below) and still reduce the visibility of the
"private" package to only a select few modules. It doesn't seem to be
possible, and I guess the syntax below is wrong for many reasons. Not the
least being that there's no way for the JVM to connect the dots between JPA
and Hibernate.

    module foo.bar {
        exports private com.foo.bar.model to javax.jpa; // Won't work
        requires javax.jpa;
    }

In the end, isn't the issue also about the lack of a concept of "module
interface", which "implementation modules" may implement? I mean, here, a
developer may not want to say "I'm using Hibernate", just "I'm using JPA",
and let the consumer of the module choose the actual JPA implementation. It
would be a bit like the `uses` and `provides` keywords, except we would be
referring to entire modules instead of classes.
I guess that, of course, the full definition of such a feature might get
quite complex depending on what it provides exactly.

Yoann Rodière <yoann at hibernate.org>
Hibernate NoORM Team

On 16 September 2016 at 19:27, Emmanuel Bernard <emmanuel at hibernate.org>
wrote:

> No one ?
>
> > On 13 Sep 2016, at 10:19, Emmanuel Bernard <emmanuel at hibernate.org>
> wrote:
> >
> > Hi all,
> >
> > Sanne kindly pointed out to me the latest proposal by the OpenJDK team
> > around JDK 9 module and how they would handle frameworks needing access
> > to non exported types (Hibernate, dependency injection, etc).
> >
> > If you are remotely into JDK9, please read it and provide feedback.
> > http://mail.openjdk.java.net/pipermail/jpms-spec-experts/
> 2016-September/000390.html
> >
> > It's better than before for sure. It feels to me that most applications
> > (the core of it) will end up being a weak module for this to work
> > though. I'm not sure whether it is good or bad, at least a isolation
> > concious person has the choice.
> >
> >    export private some.package;
> >
> > Is essentially equivalent to what you can do for a given package in Java
> > 8.
> > What I am less clear about is what relation Hibernate * projects really
> > need with a module containing the entities. Do we still this proposal
> > still mandates to use
> >
> >    requires hibernate.entitymanager;
> >    requires hibernate.core;
> >
> > in the targeted module?
> >
> > Or would this be a usable module
> >
> >    module foo.bar {
> >        exports private com.foo.bar.model;
> >        requires javax.jpa;
> >        // requires hibernate.entitymanager/core; no longer needed thanks
> to export private?
> >    }
> >
> > Mark proposes that in a container (EE or anything controlling module
> loading
> > really), the container adds dynamically the addExports to the relevant
> > framework. But that looks like a solution to limit exports private
> > implications.
> >
> > Comments?
> >
> > Emmanuel
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>