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

John Franey jjfraney at gmail.com
Thu Feb 14 15:02:07 EST 2013 

In any case, either proposal (parallel model or boolean property) is good
enough for me to start with.  Either answer the question and I can proceed.
 If the non-editable interfaces will have the names in place now, and the
editable interfaces will have Editable* as interface names, great.  And, I
can proceed now without dependency on the parallel structure.  Later, when
the Editable interfaces are created, the wrappers I provide will be altered
to remove the inert setters.


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

> I have the same understanding of Lincoln's meaning.   Also, there is
> implication also of EditableJavaType, EditableJavaClass, EditableMember,
> EditableMethod, EditableField, EditableAnnotation, EditableInterface....,
> right?  Isn't he meaning to parallel all of these java model api?  There
> are about 30 now, after there will be 60 or so.  Then the refactoring of
> each interface: setters over there, getters over there.
>
> The condition to check a property is similar to the instanceof check.  I
> agree.  However, its not a clean substitution because the property check is
> one line.  The instanceof check must be followed by a cast and a new
> variable.  The difference can be overcome, and I don't mean to make a big
> thing out of this.  My point is only that the boolean property is simpler.
>
> Some significant work and doubling of classes to support instanceof/cast
> vs. a boolean property.
> 30 new interfaces and changes to 30 existing interfaces vs a single change.
>
> John
>
>
>
>
> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20130214/307a8e77/attachment-0001.html

More information about the forge-dev mailing list