<div dir="ltr">My motivation for this email is to satisfy FORGE-773. However, this is also related to FORGE-563 and FORGE-424, and resolution could enable other features.<div><br></div><div style>I have written a prototype:</div>
<div style>1) an implementation of the forge java api interfaces which delegates to java's reflection, offering a read only perspective of java components.</div><div style>2) a forge module, currently a facet, to search for a given binary class in the project's dependencies and returns the result wrapped in the above delegate.</div>
<div style><br></div><div style>These are demonstrable in a unit test.</div><div style><br></div><div style>My dilemma now is how to integrate these into the forge project. There are a few different areas, but I'll start with this:</div>
<div style><br></div><div style><br></div><div style>For some callers, a java class is a java class, whether it originates as source code (from the current forge project) or is a class from the dependency set. For example, scaffolding primarily is a read only operation. In this use case, it would be simpler for these clients to have a single interface to resolve classes because whether a class is source or binary is not relevant to the use case.</div>
<div style><br></div><div style>On the other hand, there is a set of classes in a user's project that are modifiable. In these cases, a java class is not a java class. Forge components might want the distinction somehow. There ought the be some distinction of which class is modifiable and which is not.</div>
<div style><br></div><div style>Naively, I took the first thinking that the existing forge java model would be adequate. To have separate java api for read-only and read-write java model objects seems a fundamental addition to the java model which requires much more effort. In absence of such a model, I though to implement 'no-op' for those code changing methods (e.g., Named.setName() would be inert). I assumed that forge component that change source code would have necessary context to know when it is operating on a source code module, avoiding attempts to modify a binary class.</div>
<div style><br></div><div style>So, I'm looking for discussion and consensus on the above. Any thoughts?</div><div style><br></div><div style>Regards,</div><div style>John</div><div style><br></div><div style><br></div>
<div style><br></div><div style><br></div><div style><br></div><div style><br></div><div style><br></div><div style><br></div></div>