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

Tue Feb 19 01:01:54 EST 2013

Hehe. I couldn't resist :)

On Tue, Feb 19, 2013 at 12:57 AM, George Gastaldi <ggastald at redhat.com>wrote:

> I need to stop answering emails after immediately waking up.
> :P
>
> Em 19/02/2013, às 01:17, "Lincoln Baxter, III" <lincolnbaxter at gmail.com>
> escreveu:
>
>
>
> On Mon, Feb 18, 2013 at 10:07 PM, George Gastaldi <ggastald at redhat.com>wrote:
>
>> What if we refactor the JavaParser API to it's optimal form ? We may
>> adopt a different package to avoid conflict with what we got, maybe
>> renaming to a standalone project, since it's very useful to other projects
>> as well, I guess.
>>
>> Em 18/02/2013, às 23:44, "Lincoln Baxter, III" <lincolnbaxter at gmail.com>
>> escreveu:
>>
>> I don't like it because it's not really optimal, but... I don't really
>> see a better way forward that doesn't break every API we have.
>>
>>
>> On Mon, Feb 18, 2013 at 9:43 PM, Lincoln Baxter, III <
>> lincolnbaxter at gmail.com> wrote:
>>
>>> Well, I actually meant refactor the entire JavaParser so that the types
>>> are immutable by default, but modifiable when desired by doing an intanceof
>>> and cast. This would, as John said, be a fairly invasive, with a fair
>>> amount of downstream API impact, since all users of these APIs would now
>>> need to reference these new types instead. It would mean refactoring all of
>>> Forge.
>>>
>>> So from the perspective of Migration, it probably makes sense to do
>>> something like add a method "isEditable()"
>>>
>>>
>>> On Thu, Feb 14, 2013 at 2:19 PM, Thomas Frühbeck <fruehbeck at aon.at>wrote:
>>>
>>>>  If I understood Lincoln correctly, he meant adding an interface
>>>> EditableJavaSource, so no change in the existing implementations necessary.
>>>> So the boolean is substitutable by instanceof, your graceful error
>>>> handling would be supported.
>>>>
>>>> Am 14.02.2013 20:10, schrieb John Franey:
>>>>
>>>> I would follow my object-oriented instinct to agree that a
>>>> editable/non-editable parallel of the model would make sense.  After all,
>>>> an editable java source is kind of a non-editable java source, and adds
>>>> editing behavior.....
>>>>
>>>>  However, the parallel model seems to be a significant undertaking,
>>>> and has a negative characteristic, in my opinion.   Lets say there exists a
>>>> method to search for and return a JavaClass, editable or not.  In a use
>>>> case where the JavaClass is to be modified, this method is inadequate. 1)
>>>>  The caller would have to check if the result is instance of
>>>> EditableJavaClass, then cast, or 2) an alternate query method would be
>>>> provided to return only EditableJavaClass and since methods cannot be
>>>> overridden by return type the alternate query method would have to be
>>>> defined in a different interface.  Not taht either of these are difficult
>>>> to overcome, but I think the parallel model would increase overall
>>>> complexity a little and add to the level of effort, and the benefit gained
>>>> is merely type protection against the runtime error of attempting to modify
>>>> a non-editable java component.
>>>>
>>>>  To go against that impulse just a second, consider the option of a
>>>> property on the base class, a boolean: editable.  This would avoid the
>>>> parallel model, avoid casting and support polymorphic calls.   The runtime
>>>> error of attempting to modify a non-editable component can be handled in a
>>>> few different ways: 1) a runtime exception, 2) a quiet no-op.  Without the
>>>> editable property, I would not use a runtime exception.  There would be no
>>>> chance for the forge plugin programmer to avoid the error gracefully.  With
>>>> the property, the error is the programmer's and a runtime exception could
>>>> be appropriate.
>>>>
>>>>  Regards,
>>>> John
>>>>
>>>>
>>>>
>>>> On Thu, Feb 14, 2013 at 1:11 PM, Lincoln Baxter, III <
>>>> lincolnbaxter at gmail.com> wrote:
>>>>
>>>>>  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."
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>
>>>
>>>
>>> --
>>> Lincoln Baxter, III
>>> http://ocpsoft.org
>>> "Simpler is better."
>>>
>>
>>
>>
>> --
>> Lincoln Baxter, III
>> http://ocpsoft.org
>> "Simpler is better."
>>
>> _______________________________________________
>> 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."
>
> _______________________________________________
> 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/20130219/a6748883/attachment-0001.html 