On 02/11/2015 12:55, Jochen Theodorou wrote:
This impression is wrong, Groovy does not need access to all
JDK-internal types.
Okay, I should have said "potentially all" as there are many cases were
the implementation type is not in an exported package.
But this is a dynamic language at heart. If you do not have a static
type, then the runtime type is what counts, and that is the exact
type, which is sometime an internal JDK type. It means Groovy has to
do the same thing it has to do when a security manager doesn't like
access to this class, which is to not use the specific class/method,
but the super class information... or the information of that super
class.. in worst case this will be Object, which means only method
from Object can be called using Groovy in that case.
The current state is, that this issue is now fixed. The example
scripts in the issue are working. That does not mean we can now run
the build on jigsaw of course.
Good to hear, so I'm guess you have to talk the hierarchy of the runtime
time to find the type that is part of the API. With modules then could
this look at the exportness?
-Alan
