<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Other frameworks I am aware of that have custom service loading:</div>
<ul data-editing-info="{"orderedStyleType":1,"unorderedStyleType":2}" style="margin-block: 0px;">
<li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); list-style-type: "- ";">
<span style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">hk2</span></li><li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); list-style-type: "- ";">
<span style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">WebLogic</span></li><li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); list-style-type: "- ";">
<span style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">Jersey</span></li><li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); list-style-type: "- ";">
<span style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">Micronaut</span></li></ul>
<div class="elementToProof"><span style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"><br>
</span></div>
<div class="elementToProof"><span style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">Tomas</span></div>
<div id="appendonsend"></div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<hr style="display: inline-block; width: 98%;">
<div dir="ltr" id="divRplyFwdMsg"><span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"><b>Od:</b> Josiah Noel <josiahnoel@gmail.com><br>
<b>Odesláno:</b> středa 31. ledna 2024 2:25<br>
<b>Komu:</b> Tomas Langer <tomas.langer@oracle.com><br>
<b>Kopie:</b> Alex Buckley <alex.buckley@oracle.com>; jigsaw-dev <jigsaw-dev@openjdk.java.net><br>
<b>Předmět:</b> [External] : Re: Java extensibility and JPMS (ServiceLoader)</span>
<div> </div>
</div>
<blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left: 1px solid rgb(204, 204, 204);">
<div style="direction: ltr;">Annotation processing is designed to avoid mutating the elements, so it<br>
would be a fundamental change to allow mutation of module elements </div>
</blockquote>
<div style="direction: ltr;"><br>
</div>
<div style="direction: ltr;">We're well aware that processors shouldn't modify code, we're talking about adding some extension to the service loader that we
<i>can </i>generate. We simply want to regain the ability to register services at compile-time.</div>
<div style="direction: ltr;"><br>
</div>
<blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left: 1px solid rgb(204, 204, 204);">
<div style="direction: ltr;">It's on the framework to post-process<br>
module-info.class so it has `provides` clauses. The framework can use<br>
the ClassFile API to do this.</div>
</blockquote>
<div style="direction: ltr;"><br>
</div>
<div style="direction: ltr;">As Tomas has stated, there are a myriad of build systems so postprocessors are quite a maintenance issue.</div>
<div style="direction: ltr;"><br>
</div>
<div style="direction: ltr;"><br>
</div>
<blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left: 1px solid rgb(204, 204, 204);">
<div style="direction: ltr;"><span style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 16px; color: rgb(0, 0, 0);">The result that other frameworks reached (and I was trying not to do), is to design
our own extensibility approach that is based on resources </span></div>
</blockquote>
<div style="direction: ltr;"><br>
</div>
<div style="direction: ltr;">I wonder what are these other frameworks that have gone this route?</div>
<div class="elementToProof" style="direction: ltr;"><span style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"><br>
</span></div>
<div style="direction: ltr;"><input value="{"email-policy":{"disableCopyPaste":false,"disablePrint":false,"disableForwarding":false,"enableNoauth":false,"expandedWatermarking":false,"expires":false,"sms":false,"expirationNum":1,"expirationUnit":"days","isManaged":false,"persistentProtection":false},"attachments":{},"compose-id":"2","compose-window":{"secure":false}}" type="hidden" name="x_virtru-metadata"></div>
<div style="direction: ltr;"><br>
</div>
<div style="direction: ltr;">On Tue, Jan 30, 2024 at 2:39 PM Tomas Langer <<a href="mailto:tomas.langer@oracle.com" id="OWA752721e5-e900-d6e3-c58d-265d5eedcd90" class="OWAAutoLink" data-loopstyle="linkonly">tomas.langer@oracle.com</a>> wrote:</div>
<blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left: 1px solid rgb(204, 204, 204);">
<div style="direction: ltr;"><span style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">Ad 1 (</span><span style="font-size: 14.6667px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">provider
implementations cannot be code generated without major problems</span><span style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">) </span></div>
<div style="direction: ltr;"><span style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">I understand that annotation processing should not mutate elements, and I never suggested
it should be done. I am looking for a solution provided by the language (whatever that may be).</span></div>
<div style="direction: ltr;"><span style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"><br>
</span></div>
<div style="direction: ltr;"><span style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">I am not sure if you are aware of the complexity of the proposed "</span><span style="font-size: 14.6667px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">It's
on the framework to post-process</span></div>
<div style="direction: ltr;"><span style="font-size: 14.6667px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">module-info.class so it has `provides` clauses</span><span style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">"</span></div>
<div style="direction: ltr;"><span style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"><br>
</span></div>
<div style="direction: ltr;"><span style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">Considering that we currently have multiple build frameworks, and for each of those
the postprocessing must be done differently, we are also opening the possibility of the user not configuring the postprocessing to happen at all. Just the first part (Maven plugins, Gradle plugins, possible other systems) is a major maintenance issue.</span></div>
<div style="direction: ltr;"><span style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">In addition, the compiled code deployed with the application differs from its source
code, making troubleshooting more complicated.</span></div>
<div style="direction: ltr;"><span style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"><br>
</span></div>
<div style="direction: ltr;"><span style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">I understand it is easy to dismiss these problems and let us (as framework owners)
handle it. You are in the end forcing us to do it differently for each framework - which in the end is a problem for our users.</span></div>
<div style="direction: ltr;"><span style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"><br>
</span></div>
<div style="direction: ltr;"><span style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">The result that other frameworks reached (and I was trying not to do), and we will
switch to as well, is to design our own extensibility approach that is based on resources rather than on module-info.java. This makes it once again harder for users, as they cannot use the tools the language provides.</span></div>
<div style="direction: ltr;"><span style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"><br>
</span></div>
<div style="direction: ltr;"><span style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">Pushing us to post-processing the bytecode: if there was an event in the compiler with
extensibility similar to annotation processors (i.e. ClassPostProcessor) using the ClassFile API, I can imagine this being done, as it is still part of a single compilation run (but as far as I know, there is no such possibility).</span></div>
<div id="x_m_-8059755681375717668appendonsend"></div>
<div style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Ad 2 (requires static on provider module)</div>
<div style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
As far as I have seen the analysis of current Maven repository, Helidon is the only bigger framework that has embraced modularization. </div>
<div style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
So "a large number of users" will not find the current rules unworkable, as there is not "a large number of users" using JPMS.</div>
<div style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
As one of the users of it on a larger scale, I can tell you this is a major restriction for using JPMS together with ServiceLoader (and as mentioned above, we will stop using ServiceLoader because of this).</div>
<div style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Ad 3 (public provider)</div>
<div style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
I understand this is not a critical feature</div>
<div style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Ad 4 (duality between module path and classpath)</div>
<div style="direction: ltr;"><span style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">You have mentioned "</span><span style="font-size: 14.6667px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">It's
relatively low risk, but also low reward, so we aren't going to investigate it further.</span><span style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">"</span></div>
<div style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Once again I am not sure whose "low reward" you have in mind. I understand that in the language and for language developers this may not mean much. But for the users, frameworks etc. this is quite a big thing - we are now required to do another post-processing
of our libraries to ensure we have both (module-info provides and META-INF/services). </div>
<div style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
The reward is that new libraries can work both on classpath and on module path. And considering how many people use JPMS, this is quite a critical behavior for anything we create.</div>
<div style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Tomas</div>
<div style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<hr style="direction: ltr; display: inline-block; width: 98%;">
<div id="x_m_-8059755681375717668divRplyFwdMsg" dir="ltr"><span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"><b>Od:</b> jigsaw-dev <<a href="mailto:jigsaw-dev-retn@openjdk.org" id="OWA4c624fc1-a411-7f45-19d6-a1d6b0635eb8" class="OWAAutoLink" data-loopstyle="linkonly">jigsaw-dev-retn@openjdk.org</a>>
za uživatele Alex Buckley <<a href="mailto:alex.buckley@oracle.com" id="OWA10666e88-ce8b-67af-7011-d1d7693731cc" class="OWAAutoLink" data-loopstyle="linkonly">alex.buckley@oracle.com</a>><br>
<b>Odesláno:</b> úterý 30. ledna 2024 20:05<br>
<b>Komu:</b> jigsaw-dev <<a href="mailto:jigsaw-dev@openjdk.java.net" id="OWA1e3fea0c-950f-e289-45b9-7e71b08653ef" class="OWAAutoLink" data-loopstyle="linkonly">jigsaw-dev@openjdk.java.net</a>><br>
<b>Předmět:</b> Re: Java extensibility and JPMS (ServiceLoader)</span>
<div> </div>
</div>
<div style="direction: ltr;"><span style="font-size: 11pt;">On 1/19/2024 5:02 AM, Tomas Langer wrote:<br>
> Helidon currently has around 300 modules with module-info.java. In<br>
> general, this has improved our module structure and design.<br>
> Yet, we are now encountering some major issues related to extensibility.<br>
> I will put down a few points that are problematic, and explain each in<br>
> detail further in the e-mail (it is quite long, sorry about that).<br>
><br>
> 1. provider implementations cannot be code generated without major problems<br>
<br>
Annotation processing is designed to avoid mutating the elements, so it<br>
would be a fundamental change to allow mutation of module elements in<br>
the annotation processing API. It's on the framework to post-process<br>
module-info.class so it has `provides` clauses. The framework can use<br>
the ClassFile API to do this.<br>
<br>
It's not "weird" for a framework to modify module-info.class to ensure<br>
that code in the module has the right execution environment. Another<br>
example would be a tool that injects calls to a logging API into user<br>
code, then has to post-process module-info.class to add `requires<br>
logging.lib;`.<br>
<br>
> 2. the provider interface module MUST be on module path, even if it<br>
> could have `requires static`<br>
<br>
Relaxing module resolution to allow a module to `provides` an interface<br>
that it can't access is do-able, but the implications are unknown. It<br>
would be unfortunate if resolution succeeded but then unforeseen<br>
exceptions occur when faraway code tries to access the missing<br>
interface. We'll leave JDK-8299504 open for now, but we would need<br>
evidence that a large number of users are finding the current rules<br>
unworkable before actively looking at `provides` again.<br>
<br>
> 3. the provider implementation must be public with public constructor<br>
> 4. duality of definition between module path and class path<br>
<br>
These requests for ServiceLoader to (i) support package-private<br>
providers and (ii) inspect module-info.class files for `provides`<br>
clauses in JARs on the classpath both stem from insisting that modular<br>
JARs can be deployed on the classpath without losing functionality. This<br>
is a net-new requirement on the module system. It's relatively low risk,<br>
but also low reward, so we aren't going to investigate it further.<br>
<br>
Alex</span></div>
</blockquote>
</body>
</html>