Proposal: #ReflectiveAccessToNonExportedTypes: `exports dynamic`

[forax at univ-mlv.fr]

----- Mail original -----
> De: "mark reinhold" <mark.reinhold at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: jpms-spec-experts at openjdk.java.net
> Envoyé: Jeudi 30 Juin 2016 02:35:59
> Objet: Re: Proposal: #ReflectiveAccessToNonExportedTypes: `exports dynamic`
> 

[...]

> 
> > but i'm not sure this proposal support it's own weight.
> > 
> > Without dynamic, a 'classical' export works the same way at runtime so
> > adding 'dynamic' to an export only restrict the usage at compile time.
> > Given that we can already selectively export packages to some chosen
> > modules which hide them for the rest of the other modules at compile
> > time, adding dynamic to the spec adds little value.
> 
> Qualified exports aren't really a satisfactory substitute for dynamic
> exports.  They still export packages at compile time, thereby tempting
> unwanted usage.  They're also really meant only for use within a group
> of tightly-associated modules, where hashing can be used to ensure
> integrity, rather than amongst unrelated modules, between which names
> can all too easily be spoofed.
> 
> More to the point, qualified exports are not adequate for all use cases.
> If you want to write a module that uses JPA but is independent of JPA
> implementation then you'll need to make your entity classes available
> to whichever JPA implementation you do wind up using (Hibernate or
> EclipseLink or ...), but you don't know the name of that
> implementation's module.  In other words, you can't write
> 
>     exports com.foo.app.model to jpa;
> 
> because `jpa` is not an actual module, it's a stand-in.
> 
> We could introduce a level of indirection so that you could do that sort
> of thing, say some notion of "abstract module", but that'd be a very,
> very deep change and it doesn't fit at all well with existing practices
> around JAR files.

Ok, qualified export to a specific module is a bad idea here,
export to anybody seems a better fit.


> 
> The nice thing about `exports dynamic` is that it lets you say "just
> make the types in this package available for reflection by anybody, I'm
> okay with that".

There are two differences between unqualified export and exports dynamic:
 - exported types are only available at runtime not at compile time,
 - exported types are available by anybody so a module like hibernate doesn't have to requires a user module.

I fail to see why these two guys are bundled together, i may want to have exported types available to anybody and visible at compile time. 
but i understand that having a way to say i want to export a package to anybody is interesting especially for library like hibernate.

Moreover, i don't like the fact that Java the language has a new way to interact with the reflection. The more we introduce such coupling the less we will be able to move in the future.

so instead of exports dynamic i propose to introduce a way to say i want to export a package to anybody,
an exports to * (star).
  
Using the example of the initial proposal, the module-info will be
    module com.foo.app {
        requires hibernate.core;
        requires hibernate.entitymanager;
        exports com.foo.app.model to *;
    }

> 
> > And it has several drawbacks, the main one is that it weaken the
> > compiletime/runtime fidelity story, with a dynamic export the runtime
> > world is not the compiletime world anymore.  The main motivation to
> > add dynamic seems to be for backward compatibility during the
> > transition between the classpath world and the full module world, for
> > several other cases, we use the command line for that, i don't see why
> > this case is so special that it should not work like the other
> > compatibility issues.
> 
> Yes, it does weaken the fidelity story in order to accommodate existing
> practice, but at least it does so in an explicit manner so that what's
> going on is apparent just from reading the code.
> 
> I don't think, however, that this change is just about compatibility and
> migration.  Even in an idealistic, Utopian, fully-modular world I expect
> that we'll still want to use frameworks that use reflection on our own
> types to help us be more productive.

yes, that's very true. Reflection allows to write meta object protocols but making a special case for the reflection seems wrong to me.

> 
> > Moreover, an agent, an annotation processor and a jlink plugin are all
> > able to implement the same trick, add export after the compilation and
> > before the runtime, so i don't think it's a good idea to change the
> > spec for that.
> 
> Then how do you express, in your source code, that you want an export to
> be added at run time?
> 
> You could use an annotation, but that would require anybody who wants
> to do this sort of thing to configure their environment to include the
> module that defines that annotation and to add the required annotation
> processor at the appropriate point.  Do we really want to tell people
> to do that when we can solve the problem for them so simply?
> 
> - Mark
> 

Rémi