[forge-dev] reflection to access classes in project dependencies
Thomas Frühbeck
fruehbeck at aon.at
Thu Feb 14 14:19:53 EST 2013
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 <mailto: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
> <mailto: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 <mailto: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 <mailto: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 <mailto: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 list
>>>>> forge-dev at lists.jboss.org <mailto:forge-dev at lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>
>>>> _______________________________________________
>>>> forge-dev mailing list
>>>> forge-dev at lists.jboss.org
>>>> <mailto:forge-dev at lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>
>>>
>>> _______________________________________________
>>> forge-dev mailing list
>>> forge-dev at lists.jboss.org <mailto:forge-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>
>>
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev at lists.jboss.org
>> <mailto:forge-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>
>>
>>
>>
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev at lists.jboss.org <mailto:forge-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/forge-dev
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org <mailto:forge-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org <mailto: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 <mailto: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/2879770f/attachment-0001.html
More information about the forge-dev
mailing list