[forge-dev] reflection to access classes in project dependencies
ggastald at redhat.com
ggastald at redhat.com
Fri Feb 22 10:14:34 EST 2013
Hi !
This seems like a good way to go.
I've updated the JIRA in https://issues.jboss.org/browse/FORGE-795 with
this info.
Thanks !
On 02/22/2013 12:01 PM, John Franey wrote:
> Yes. AST is a component of javacore, but javacore is more than AST.
> So, it would be more accurate to say: forge already uses a subset of
> JDT, the ast parser. Here is a short
> tutorial: http://www.vogella.com/articles/EclipseJDT/article.html
>
> JavaCore's features seems to be a union of forge's source code
> features, and the class inspection features (either from reflection or
> javaassit), and JavaCore component has very close proximity to the
> eclipse AST parser already put to use by forge, and assuming the
> requirements of forge java plugin can be met by eclipse javacore, and,
> I think I read somewhere, there is prototype to integrate forge into
> eclipse, and also, the forge team is open to refactoring the forge
> java model. It is my opinion, that a more than a casual look into
> javacore, as either the implementation of, or a replacement to, the
> forge java model api, is reasonable.
>
> Here is the javacore project
> page: http://www.eclipse.org/jdt/core/index.php
> Here is the javacore api
> pages: http://help.eclipse.org/juno/index.jsp?topic=/org.eclipse.jdt.doc.isv/reference/api/org/eclipse/jdt/core/JavaCore.html
>
>
>
>
>
>
>
>
> On Fri, Feb 22, 2013 at 12:30 AM, Lincoln Baxter, III
> <lincolnbaxter at gmail.com <mailto:lincolnbaxter at gmail.com>> wrote:
>
> 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 <mailto: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 <mailto: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 <mailto: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
> <mailto: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 <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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
>> <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 <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."
>
>
>
>
> --
> 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
> <mailto: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
> <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."
>
>
>
>
> --
> 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
--
*George Gastaldi* | /Senior Software Engineer/
JBoss Forge Team
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20130222/27c1534a/attachment-0001.html
More information about the forge-dev
mailing list