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

Thu Feb 14 12:23:15 EST 2013

I have no intention of providing a way to modify the class definition of a
java class defined within a dependency of the user's project.

Putting the question another way:

To date, the forge java model today supports only modifiable java
components.  This effort introduces non-modifiable java components to the
forge java model.   This raises the question:  Would the non-modifiable
java components be inspected with the same api that supports the modifiable
java components (JavaClass, and others).  If no, what api is used to
inspect the non-modifiable java components?

My naive answer is: the non-modifiable java components would be inspected
using the same api as the modifiable java components.  Methods of that api
that expressly modify the java component would be inert for non-modifiable
java components.

John

On Thu, Feb 14, 2013 at 12:05 PM, Thomas Frühbeck <fruehbeck at aon.at> wrote:

>  Hmm, I expect loading of JARs not to the problem, is it? So the loading
> and reflecting on the "external" class should be possible.
> I was thinking of the next step, implementing kind of writable JavaClass
> not just ignoring the changes, but making the modified class available to
> the project.
> Sorry if I misunderstood your quest? =)
>
> Thomas
>
> Am 14.02.2013 17:37, schrieb John Franey:
>
> Thomas,
>
>  I have minimal exposure to proxy due to experience with hibernate, but
> my understanding is not adequate to understand how they would apply.  Do I
> understand correctly that the benefit of a dynamic proxy is high when a
> temporary class implementation is needed, and when a method of the proxy is
> invoked, some action is taken, perhaps instantiating another implementation
> of the interface.  In this use case, we don't need to invoke the methods of
> a project's class, we need to inspect the methods (and other members) of
> the class, right?
>
>  John
>
>
>
>
> On Thu, Feb 14, 2013 at 11:22 AM, Thomas Frühbeck <fruehbeck at aon.at>wrote:
>
>>  exactly what I was looking for :-))
>> Thanks George!
>>
>> Am 14.02.2013 16:55, schrieb George Gastaldi:
>>
>> Hi Thomas,
>>
>>  Have a look in Forge 2.0 source code. We're using javassist at it's
>> best in the proxy module
>>
>>
>>
>> Em 14/02/2013, às 13:53, Thomas Frühbeck <fruehbeck at aon.at> escreveu:
>>
>>   Hi John,
>>
>> my two cents:
>>     - this feature is a must-have, if Forge should be more than a tool to
>> iniitialize projects, really great idea
>>     - being pragmatic I would say this calls for proxy classes, similar
>> to CDI decorators or the copy-on-write strategy
>>
>> (AFAIK the downside to CDI decorators is that they need interfaces on the
>> base classes, thus again requiring changes of the classes if they hadnt
>> been designed for it firstplace.)
>>
>> I have a very similar problem I am currently trying to solve with silly
>> wrapper classes and was starting to think about dynamic proxy generation -
>> unfortunately I have _no_ experience with such technology other than being
>> simple user :-/
>>
>> Have you thought about javassist? Is it an option at all?
>>
>> Thomas
>>
>>
>> Am 14.02.2013 16:21, schrieb John Franey:
>>
>> 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 listforge-dev at lists.jboss.orghttps://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
>>
>>
>>
>> _______________________________________________
>> forge-dev mailing listforge-dev at lists.jboss.orghttps://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
>>
>
>
>
> _______________________________________________
> forge-dev mailing listforge-dev at lists.jboss.orghttps://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/abf7b448/attachment-0001.html 