Toward Condensers

[Paul Sandoz]

On Aug 14, 2023, at 1:40 PM, Dan Heidinga <heidinga at redhat.com> wrote:



On Mon, Aug 14, 2023 at 2:52 PM Paul Sandoz <paul.sandoz at oracle.com<mailto:paul.sandoz at oracle.com>> wrote:


> On Aug 1, 2023, at 2:00 PM, Brian Goetz <brian.goetz at oracle.com<mailto:brian.goetz at oracle.com>> wrote:
>
>
>
> On 8/1/2023 4:34 PM, Dan Heidinga wrote:
>
>> * In the "Data model" section, how are duplicate classes on the classpath handled?  Are Containers representing JARs on the classpath explicitly ordered so as to linearize them to ensure the earliest definition of a class wins?  Does the model need to expose the classpath ordering?
>
> The application model gives us a list of modules and a list of classpath entries.  Since multi-valued attributes preserve their order, this should be enough to preserve the existing story: that modules represent a partition of packages, and we resolve conflicts on the classpath with "first wins".  (We can also have condensers that assert properties like "no duplicates".)
>
>> Is ContainerKind missing a "directory" type as well?  It might be possible to pretend a filesystem directory on the CP is a JAR for model purposes, but that doesn't feel quite right.  Did you consider directories when making the model? If they were deliberately excluded it might help to expand on why in the document.
>
> I'll defer this one to Paul.
>

The model deliberately did not try to model the tree structure of packages/resources. It’s not a file system and modeling it as such would I think be misleading. A tree structure could be produced, if needed, as a view of the model from the names of container elements (and potentially for other kinds of views).

An exploded jar (bad name) or the equivalent (zipped) jar are indistinguishable in the model (same for exploded modular jar and modular jar).

Exploded jars have a META-INF directory.  Explored modules have a module-info.class.  A directory on the classpath can still provide classfiles or resources without having metadata that maps it to an exploded jar/module.

The case I'm interested in is extra config files / property files / resources that are commonly added to the classpath and looked up with ClassLoader::getResourceAsStream or various ::getResource apis as those are the ones that could be used by condensers to customize the application.

It should be possible. Any file of a jar-based container that is not a class file will be modeled as a resource key whose name is the path to the file contents e.g., a service file whose relative path is “META-INF/services/my.service.interface” will be modeled as a resource key whose name is that path (in the same form as that of the name parameter for ClassLoader::getResourceAsStream etc).

A similar approach also applies to JMODs (exploded or otherwise) which have a richer category of resources.






>> Should the Data model include "classloader" as a member? With modules we can map which module will be loaded by which classloader and can guess for most classpath entries.  For more complicated classloading schemes (including self-first), it might be beneficial to model the classloader network in the model as well.  This may be something that a non-standard condenser could augment the model / analysis with.
>
> Good question!  Not sure yet.
>

Me neither. What do you envisage a condenser might do with such knowledge?

While parent-first is a very common class loading strategy, as we all know other policies are possible.  Being able to express the classloader in the model would provide a hook for condensers to be made aware of classloading policies.

So far, our experiments have been done in jlink which only supports modules and modules are easy to map to classloaders if necessary.  When working on Class.forName -> ldc transformations, we used the module graph to determine if cross-module transformations would succeed and only transformed those that would.  Without knowing the classloading strategy, transformations like Class.forName ->ldc are less safe for the classpath resources.


Ok, I see now, you want to overlay a graph that models the runtime class loader dependencies to reason about visibility.

Paul.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230814/3bac4dba/attachment.htm>