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

Lincoln Baxter, III lincolnbaxter at gmail.com
Fri Feb 22 00:30:53 EST 2013 

The Forge JavaParser already uses JDT :) I think we are talking about the
same thing. We haven't looked at the compilation stuff yet, that's actually
an interesting idea.


On Fri, Feb 22, 2013 at 12:28 AM, Lincoln Baxter, III <
lincolnbaxter at gmail.com> wrote:

> Wait, JavaCore is or is not related to JDT?
>
>
> On Thu, Feb 21, 2013 at 7:18 PM, John Franey <jjfraney at gmail.com> wrote:
>
>> Apache bcel hasn't had a release since 2006.  I'm wondering if the class
>> file format has moved on beyond bcel's reach.  Its last official release is
>> 5.2 in Feb 2006. Java 1.6 was released in December 2006, and nothing new
>> from bcel project.  Java 1.7 in 2011, and still silence.  I wonder if it
>> can support later class file formats somehow.
>>
>> javassist's latest release is December 2012 and seems to have jboss
>> backing.  Seems a safe choice on the face of it.
>>
>> Then, there is eclipse JavaCore.  I wonder if JavaCore can be used
>> without an eclipse workbench.  If so, JavaCore can provide a single api for
>> both source and binary classes, so it could replace the forge java source
>> parser, too.  I also wonder if forge could be a headless eclipse
>> application - imagine the eclipse plugins available via forge's command
>> line shell.
>>
>>
>>
>> On Thu, Feb 21, 2013 at 6:30 PM, Lincoln Baxter, III <
>> lincolnbaxter at gmail.com> wrote:
>>
>>> What about something like this?
>>>
>>> https://issues.jboss.org/browse/FORGE-795
>>> https://issues.jboss.org/browse/FORGE-796
>>>
>>>
>>> On Wed, Feb 20, 2013 at 11:11 AM, Lincoln Baxter, III <
>>> lincolnbaxter at gmail.com> wrote:
>>>
>>>> Hmm... I'm not sure. I think it would probably still be slightly
>>>> misleading to have mutable interfaces for immutable objects, without some
>>>> kind of indicator. For instance, if someone were to pass the object beyond
>>>> its "intended" scope.
>>>>
>>>>
>>>> On Tue, Feb 19, 2013 at 7:41 PM, John Franey <jjfraney at gmail.com>wrote:
>>>>
>>>>> Thinking out loud, would isEditable still be needed if there were a
>>>>> lookup that returned only editable java resources, and another query that
>>>>> could return both binary and source resources?  Plugins that operate as
>>>>> editors would use the former to find resources it knows it will edit, and
>>>>> will use the latter in order to inspect other classes (to resolve super
>>>>> class or throws declarations).  Plugins that operate as readers (like
>>>>> scaffold plugins) would use only the latter.  Hmm...even with isEditable,
>>>>> does it make sense to have these two kinds of methods?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Feb 18, 2013 at 9:43 PM, Lincoln Baxter, III <
>>>>> lincolnbaxter at gmail.com> wrote:
>>>>>
>>>>>> 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."
>>>>
>>>
>>>
>>>
>>> --
>>> 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."
>



-- 
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/20130222/0043060d/attachment-0001.html

More information about the forge-dev mailing list