[forge-dev] reflection to access classes in project dependencies

John Franey jjfraney at gmail.com
Thu Feb 14 11:29:30 EST 2013


Below:


On Thu, Feb 14, 2013 at 10:44 AM, George Gastaldi <ggastald at redhat.com>wrote:

> 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.
>
>
Me too. However, I really, really want the feature: generate scaffold from
an existing jpa library.



> 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.
>
>
Indeed.  Use of reflection requires loading the classes in the classloader.
 I'm concerned about this as well.
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.
2) more permgen memory required.  Maybe would require the user to bump up
permgen at forge start up.
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.

What other disadvantage to using a classloader for this?

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.



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 at 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 at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/forge-dev
>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20130214/20ed4dfb/attachment.html 


More information about the forge-dev mailing list