<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 14, 2023 at 2:52 PM Paul Sandoz <<a href="mailto:paul.sandoz@oracle.com">paul.sandoz@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On Aug 1, 2023, at 2:00 PM, Brian Goetz <<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@oracle.com</a>> wrote:<br>
> <br>
> <br>
> <br>
> On 8/1/2023 4:34 PM, Dan Heidinga wrote:<br>
> <br>
>> * 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?<br>
> <br>
> 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".)<br>
> <br>
>> 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.<br>
> <br>
> I'll defer this one to Paul.<br>
> <br>
<br>
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). <br>
<br>
An exploded jar (bad name) or the equivalent (zipped) jar are indistinguishable in the model (same for exploded modular jar and modular jar).<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
<br>
>> 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.<br>
> <br>
> Good question!  Not sure yet.<br>
> <br>
<br>
Me neither. What do you envisage a condenser might do with such knowledge?</blockquote><div><br></div><div>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.  </div><div><br></div><div>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.</div><div><br></div><div>--Dan</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br>
<br>
<br>
>> * In "Example: Lambda forms" contains the following sentence<br>
>> > After condensing we can update the java.base module on the file system from the updated application model.<br>
>> <br>
>> which should probably delegate the updating of the file system to the Distiller.  Given the prohibition against filesystem access in the "The application model" section, talking about the filesystem here seems odd.<br>
> <br>
> This seems like an error in the doc.  Will investigate.<br>
> <br>
>> I'm looking forward to seeing the prototype and trying to port my pregenerate lambdas jlink plugin to be a condenser.  I think it should be a fairly smooth process.<br>
> <br>
> Indeed, I think that will be a good validation test, and I expect it will go smoothly.<br>
> <br>
<br>
Yes, it should slot right in.<br>
<br>
Paul.</blockquote></div></div>