<div dir="ltr"><div><br></div>Below:<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 14, 2013 at 10:44 AM, George Gastaldi <span dir="ltr"><<a href="mailto:ggastald@redhat.com" target="_blank">ggastald@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello John,<br>
<br>
First of all thank you for your initative on implementing this feature.<br>
<br>
Your implementation seems consistent to what is needed also.<br>
<br>
Second, I am a bit concerned about performance while searching through the binary in the project dependencies.<br>
<br></blockquote><div><br></div><div style>Me too. However, I really, really want the feature: generate scaffold from an existing jpa library.</div><div style><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I am still not totally sure we can use reflection on that, since it may require loading the class in a classloader to assemble the full class structure. Maybe another tool reading directly from the bytecode may be a better solution, but it's a matter of testing possible scenarios.<br>
<br></blockquote><div><br></div><div style>Indeed. Use of reflection requires loading the classes in the classloader. I'm concerned about this as well.</div><div style>1) the classes may be inadvertently part of the forge classpath. This can be eliminated by using a child classloader of one of the classes in the implementation. Such a classloader is isolated from the rest of the forge classloading.</div>
<div style>2) more permgen memory required. Maybe would require the user to bump up permgen at forge start up.</div><div style>3) churn due to dependencies changing: for example, reload after every: project add-dependency. This is mitigated by clearing the class loader whenever the dependency change event comes in and reloading a classloader only when another query occurs.</div>
<div style><br></div><div style>What other disadvantage to using a classloader for this?</div><div style><br></div><div style>If you open the issue to use of another tool, then that would provide an opening to a question that has been bugging me since I've been looking at the forge java model.....but, I'll leave that unopened for now.</div>
<div style><br></div><div style><br></div><div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I believe that it makes sense to integrate this feature in the Java-parser module.<br>
<br>
Best Regards,<br>
<br>
George Gastaldi<br>
<br>
Em 14/02/2013, ąs 13:22, John Franey <<a href="mailto:jjfraney@gmail.com">jjfraney@gmail.com</a>> escreveu:<br>
<div><div class="h5"><br>
> 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.<br>
><br>
> I have written a prototype:<br>
> 1) an implementation of the forge java api interfaces which delegates to java's reflection, offering a read only perspective of java components.<br>
> 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.<br>
><br>
> These are demonstrable in a unit test.<br>
><br>
> My dilemma now is how to integrate these into the forge project. There are a few different areas, but I'll start with this:<br>
><br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> So, I'm looking for discussion and consensus on the above. Any thoughts?<br>
><br>
> Regards,<br>
> John<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
</div></div>> _______________________________________________<br>
> forge-dev mailing list<br>
> <a href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
<br>
_______________________________________________<br>
forge-dev mailing list<br>
<a href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a></blockquote></div><br></div></div>