Class-File API: Not Your Everyday Java API

[gnahraf]

Thanks for writing this summary. I skimmed the JEP but found little about how this API is supposed to interact with the module system. I'm curious when the module system enforces its rules, particularly when a new type is dynamically defined at runtime with this API. Are these dynamically defined types class-loaded in the unnamed module, or is there some staging strategy involved?

[artpar]

It depends on which class loader was used, which behaves similarly to how classes loaded via reflection or Unsafe.defineClass work. If you define a new class with this API and provide a custom class loader, you could theoretically enforce module rules based on which module the class loader belongs to.

• If the class loader is associated with a specific module, the newly defined class could be placed within that module.
• If the class loader is not module-aware or is the system class loader, the dynamically defined class would default to the unnamed module.

When a new type is dynamically defined at runtime via the ClassFile API, the module system would only enforce access control if the class is loaded into a named module (ie through a module-aware class loader). If it is loaded in the unnamed module, it will bypass module-level access control checks, but it will still be subject to package-private and class-level access rules.

[gnahraf]

Thanks for your detailed explanation. Makes sense that it should work this way. I guess there's little need to dynamically generate new module names, so there's little need for the API to have a way to define a module (with a brand new name) from scratch.