<div dir="ltr">Hi All,<br><br>I just read through the early discussion on the condenser concept.<br><br>A brain-worm I can't dispose of[1] is that the concept of time shifting could be used to allow language level shading.<br><br>That is, if a user can say that none of the classes in a module will be reflected upon using dynamically constructed values.[2]<br><br>     <font face="monospace">Class.forName(f()); // X<br></font><br>Then it would be a "safe" operation to change the package name of all of those classes and bundle them inside of a module which requires them.[3]<br><br>    <font face="monospace">shadeable module org.example {<br></font>    <font face="monospace">    exports org.example;<br></font>    <font face="monospace">    exports org.example.abc;</font><br>    <font face="monospace">}<br></font><br>    <font face="monospace">module org.other {<br>      requires shaded org.example;</font><br><font face="monospace">  }</font><br><br>Now, this is not in Leyden's mission statement. Nothing about startup time is improved by renaming packages and classes. But the set of information you'd need to allow shading seems to overlap with the set of information you'd need to allow for making a static executable.<br><br>So in the same way Valhalla is converging towards <font face="monospace">T! + value + implicit constructor = inline-ability </font><font face="arial, sans-serif">there might be a </font><font face="monospace">"can make static exe"</font><font face="arial, sans-serif"> that falls out of other features like this.</font><br><br>[1]: And one I feel I should bring up considering that the set of condensers might start out or remain closed to keep a consistent platform definition.<br>[2]: + some other restrictions I am sure<br>[3]: There might be a place other than modules which could work, but module-info declarations are currently the only place where users explicitly mark reflect-ability constraints today, so it <br><br></div>