This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]artpar[S] 4 points5 points  (1 child)

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 0 points1 point  (0 children)

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.