question on exports to

[Jochen Theodorou]

On 03.06.2016 22:20, Alex Buckley wrote:
[...]
> Why don't you believe it? The "Under The Hood" presentation shows that
> layer creation makes the JVM aware of modules and their relationships.

because I was thinking it will lower performance. Sure, benchmarks are 
often driven by code of callsites, that are actually no moving much, and 
in such benchmarks there will be no problem. And yes, this checkc has to 
be done only once, unless the callsite has to be reevaluated... Still it 
will increase the one time cost, unless you meet one of those callsites, 
that require the JVM to regularly deopt. But on the other hand the JVM 
is not good at recovering from a deopt anyway (at least that is my 
perception)... so maybe it does not really matter in the end.

> Later, when the JVM resolves the descriptor of an invokevirtual
> instruction, it checks that the current class (containing invokevirtual)
> can access the class referenced in the descriptor, and this check takes
> module membership, exports, and readability into account. Can the
> current class's module read the target class's module, and does the
> target class's module export the target class to (at least) the current
> class's module?

I see.. and I assume that counts for get/setField and all invoke 
instructions including invokeSpecial and newinstance.

> There's a clear contrast between the two-way check performed by the JVM,
> and the one-way check (exports only, readability "for free") performed
> by Core Reflection.

so... odes reflection code still produce runtime helper classes for 
invocation? That is then a dynamic module based solution?

bye Jochen