On 6/2/2016 10:22 AM, Mike Samuel wrote:
It sounds like the tech lead, specialists, and build master can
exercise oversight using tools that just
1. look at the exports...to... relationships which should be apparent
from module declarations in bytecode per
http://openjdk.java.net/projects/jigsaw/spec/sotms/#qualified-exports
Yes, the qualified exports should drive everything, since they're
bulletproof. (A module can choose to augment its own exports at run
time, but hopefully the overseers recognize that more as a "feature" for
Sally to use judiciously than as a "bug" which weakens the authority of
the static white-list.)
2. check that sensitive packages are only contained in modules defined
in build artifacts signed by the right group.
Yes, this is a job for the build system. The placement of packages in
modules is something that the module system has to take on trust.
What about JSR 223 style script engines?
Can an embedder of an interpreter or bytecode compiler create a module
that includes the scripting engine and just the stuff that the scripts
need and be sure that, whether the script engine uses reflection under
the hood, or compiles to bytecode? Or does all that stuff tend to end
up in the unnamed module?
The way that frameworks use the module system is a deep topic, but
ultimately a JSR-223 ScriptEngineFactory is just a service provider, so
you can create a module which 'provides' a class implementing
ScriptEngineFactory and which 'requires' java.scripting + the other
modules it needs. The module can't access anything which isn't exported
to it, regardless of whether the access is from bytecode or via Core
Reflection or via the Language Model or via MethodHandle lookup.
Alex
