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

Thu Feb 14 13:11:41 EST 2013

As I understood it, we need a way of explicitly noting when a JavaSource
instance is mutable or not. Perhaps splitting the API into a JavaSource an
EditableJavaSource parallel.

It was also my understanding that proxies were going to be used to do
lazy-classloading for any JARs brought in via this system. I'm not sure we
need to worry about this just yet. We can get it working then think about
performance implications.

On Thu, Feb 14, 2013 at 12:23 PM, John Franey <jjfraney at gmail.com> wrote:

> 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
>>
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>

-- 
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20130214/c8b147a6/attachment.html 