Re: [forge-dev] reflection to access classes in project dependencies
Hello John,
First of all thank you for your initative on implementing this feature.
Your implementation seems consistent to what is needed also.
Second, I am a bit concerned about performance while searching through the binary in the
project dependencies.
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.
I believe that it makes sense to integrate this feature in the Java-parser module.
Best Regards,
George Gastaldi
Em 14/02/2013, às 13:22, John Franey <jjfraney(a)gmail.com> escreveu:
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.
I have written a prototype:
1) an implementation of the forge java api interfaces which delegates to java's
reflection, offering a read only perspective of java components.
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.
These are demonstrable in a unit test.
My dilemma now is how to integrate these into the forge project. There are a few
different areas, but I'll start with this:
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.
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.
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.
So, I'm looking for discussion and consensus on the above. Any thoughts?
Regards,
John
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev