Frontiers of Access Controls: Modules and Nestmates
summary
Java SE 9 implements a module system that enforces type accessibility by checking module reads + exports checked at runtime during bytecode resolution and preserves performance via shortcuts for same-module or same-package cases; the unnamed module reads everything and exports to all for backward compatibility. Jigsaw tooling includes module-info.java, javac and jlink and a module path versus classpath model. JEP 181 proposes nestmates allow private access by adding classfile attributes (NestHost/NestMembers) and a dynamic route via MethodHandles.Lookup private defineClass to eliminate synthetic accessors and tighten security.
AI-written summary · about
chapters (20)
- 0:00Intro
- 4:49What is a Module?
- 6:12How do you define a Module? - Module Descriptor
- 10:15Reliable Configuration: The module graph
- 11:34Where do you deploy Modules?
- 12:23Class Path vs. Module Path
- 16:45Backward Compatibility: Unnamed Module
- 18:21Type Access Check: Java SE 9 Target Type T is accessible to Type S if
- 20:20Bytecode Resolution and Access Controls - Sample Bytecodes that resolve symbolic Type References
- 22:49JVM Method Resolution: Access Checks
- 24:12Java SE Library Access Checking
- 28:38Nestmates Use Case: Nested Class Trampolines
- 31:19Proposed JVMS 55.4.4 Access Control Changes
- 32:32Member Access Check: Proposal for Nestmates
- 34:09Nestmates Use Case: Unsafe.defineAnonymousClass
- 35:42Exploring Evolution: Not based on unsafe
- 38:10Nestmates Access: Implementation changes required
- 39:27Invokespecial Examples: , super, local I
- 40:35JVMS 9 Invokespecial Restrictions (non.)
- 44:35Nestmates Open Issues
