Hi Alan, > On 22 Nov 2021, at 21:37, Alan Bateman <alan.bate...@oracle.com> wrote: > > On 22/11/2021 07:23, Michał Kłeczek wrote: >> >> Would it be too much to ask for accepting a patch adding a reference to >> ML.Controller to ModuleLayer? >> It wouldn’t require changes to the spec I think as the lifetime of >> ML.Controller is unspecified. >> > Assuming it's not exposed, and that there is no reference to the > ML.Controller for the boot layer, then it might be okay but I think it would > be useful to understand the use-case first. As I assume you know, the > ML.Controller allows containers to do the equivalent of --add-reads, > --add-exports, and --add-opens in child layers. Since you want to retain the > reference to the ML.Controller around then it may be some other reason, maybe > opening packages to descendants beyond the child layer?
Yes. As a hobby project I am revisiting my old idea briefly described here (it’s been sooo long ago :) ): https://markmail.org/message/kte6z7kcgaqcayor <https://markmail.org/message/kte6z7kcgaqcayor> In short: it is Jini/RMI with codebase annotations being “smart” installers of code necessary to deserialise an object. At that time it wasn’t really feasible to transfer arbitrary objects graphs due to hierarchical class loading model. The general idea is that upon serialisation of an object its class is annotated with another object representing the closure of this class’ module and its dependencies (subgraph of the application module graph). To annotate the annotation object I use null (actually the recursion level allowed when reading annotations is configurable). When deserialising I recreate the module graph on the receiving side. Some nodes in the dependency graph are replaced with local modules so that the receiving side can cast deserialised object to a known type. Equal annotations (as defined by Object.equals) - even received from different sources - always map to the same module on the receiving side. In non-modular pre-jigsaw world two jar files (server.jar and server-dl.jar) were provided: server-dl.jar contained a subset of server.jar classes implementing Smart proxy. In post-jigsaw world Smart proxy and Server reside in different modules. The (canonical) structure of a server application is: Server module --- depends on ---> Smart proxy module ----> depdends on ---> one or more API modules To make things more encapsulated Proxy module exports its smart proxy class package only to the Server module (Smart proxy class has to be public in contrast to pre-jigsaw world because split packages are disallowed). What I would like to support is also (rare) scenario that a superset of already instantiated module graph is received and one of the previously downloaded modules exports a package to a named module downloaded at a later time. (Imagine scenario when a server can be migrated and is transferred after its smart proxy). That’s why I need to keep ML.Controller for later. Hope that makes it clear :) -- Michal
