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

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/ref... On Fri, Feb 22, 2013 at 12:30 AM, Lincoln Baxter, III <lincolnbaxter(a)gmail.com <mailto:lincolnbaxter@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(a)gmail.com <mailto:lincolnbaxter@gmail.com>> wrote: Wait, JavaCore is or is not related to JDT? On Thu, Feb 21, 2013 at 7:18 PM, John Franey <jjfraney(a)gmail.com <mailto:jjfraney@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(a)gmail.com <mailto:lincolnbaxter@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(a)gmail.com <mailto:lincolnbaxter@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(a)gmail.com <mailto:jjfraney@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(a)gmail.com <mailto:lincolnbaxter@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(a)gmail.com <mailto:lincolnbaxter@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(a)aon.at <mailto:fruehbeck@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(a)gmail.com > <mailto:lincolnbaxter@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(a)gmail.com > <mailto:jjfraney@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(a)aon.at > <mailto:fruehbeck@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(a)aon.at >> <mailto:fruehbeck@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(a)aon.at >>> <mailto:fruehbeck@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(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> >>>>> https://lists.jboss.org/mailman/listinfo/forge-dev >>>> >>>> _______________________________________________ >>>> forge-dev >>>> mailing list >>>> forge-dev(a)lists.jboss.org >>>> <mailto:forge-dev@lists.jboss.org> >>>> https://lists.jboss.org/mailman/listinfo/forge-dev >>> >>> >>> _______________________________________________ >>> forge-dev mailing list >>> forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/forge-dev >> >> >> _______________________________________________ >> forge-dev >> mailing list >> forge-dev(a)lists.jboss.org >> <mailto:forge-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/forge-dev >> >> >> >> >> _______________________________________________ >> forge-dev mailing list >> forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/forge-dev > > > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org > <mailto:forge-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org > <mailto:forge-dev@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(a)lists.jboss.org > <mailto:forge-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/forge-dev _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org <mailto:forge-dev@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(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/forge-dev _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org <mailto:forge-dev@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(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/forge-dev _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org <mailto:forge-dev@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(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/forge-dev _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev