On 12/2/2015 2:16 AM, Stephane Epardaud wrote:
On 01/12/15 22:04, Alex Buckley wrote:
There shouldn't be any surprise here. In Java SE 8, you can declare a
package-private annotation type and use it to write annotations on
public classes of that package. Going up a level in Java SE 9, you can
declare a module-private annotation type (i.e. public @interface Foo
in a non-exported package) and use it to write annotations on exported
public classes of that module.
But I thought that Java 9 would check that you can't export a type
outside the module without also exporting the types it exposes? Like
public method return and parameter types. Can't remember where I read
that, though… Is that planned or not?
We have not yet determined whether it should be a JLS-specified
compile-time error or a JLS-specified compile-time warning or a
compiler-specific compile-time warning or nothing at all. If you have
concrete experience wrangling a module's exports to support the module's
signatures, please send to jpms-spec-comments.
As for annotations, I understand that's a little less clear because it
doesn't exactly belong to the class' signature. I do wonder if that's
not going to break modular class loaders if for example a module uses
JPA annotations but does not export the dependency, and if another
module scans your module for JPA annotations it won't see them if they
use different ClassLoaders (which is possible in theory since the
dependency was not exported).
A module whose classes have JPA annotations must read some JPA module
which exports the annotations' types.
It's true that at run time, another module that wishes to reflect over
this module may read a different JPA module which exports different
versions of the annotation types. (Some trickery with layers would be
necessary to arrange this.)
The module system's usual guarantee of "No ClassCastExceptions from
modular code" won't apply, just as if a consumer module and a producer
module disagree on the definition of (say) a type used as a return type.
And that's not great.
For some annotations (like HotspotIntrisic) it may be desirable to have
it private, but for "framework" annotations like JPA, I _think_ it makes
more sense to force (and check) the JPA dependency to be exported, no?
(You keep saying "exported", but dependencies are not exported. With
"requires public", a module can set up implied readability on other
modules for its consumers.)
I kinda agree, but again, these points belong on jpms-spec-comments.
Alex
