Does this have to drift away from ClassLoader relationships? What’s driving this to include another instance of relationship? Is it about confusion with ClassLoader parents not being defined, or reachable or “viewable” from other class loaders because of disparate code sources not being loaded from a common class loader that can build and organize something usable? In the days of JINI, before you guys killed security manager, we just built all relationships from a common parent class loader and the used the SM to limit what was accessible from what URLClassLoader instance. This allowed us to share objects between disparate code bases readily, because we could easily expose the “data” class loader(s), as parents of the “service” class loader(s) and limit, via permissions, what “activities” could be performed by each service.
It seems like we are now coming back around to this notion and finding out that what was ripped out, may have actually had attributes of what we need... Gregg > On Sep 2, 2024, at 3:44 AM, Alan Bateman <alan.bate...@oracle.com> wrote: > > > > On 02/09/2024 09:19, PavelTurk wrote: >> Hello everyone, >> >> I have a question about https://bugs.openjdk.org/browse/JDK-8322302 >> >> Can someone let us know approximately when this bug will be fixed? It is >> causing us a lot >> of problems, and having an estimated timeline would help us develop the >> right strategy. > > No ETA on this. There is some design work required to decide how readability > should work with automatic modules in child layers. There are trade-offs to > consider on the question as to whether a module in a child layer can depend > on (and thus read) an automatic module in a parent layer. > > -Alan
