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