Question about jdk.internal.HotSpotIntrinsicCandidate
Alex Buckley
alex.buckley at oracle.com
Wed Dec 2 19:44:07 UTC 2015
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
More information about the jigsaw-dev
mailing list