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

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&gt; 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&gt; 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&gt; 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&gt; 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&gt;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&gt; 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&gt; 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&gt;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&gt; 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 >>>>>>>>> > 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&gt; 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&gt; 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&gt; >>>>>>>>>>>> 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@lists.jboss.orghttps://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 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> forge-dev mailing listforge-dev@lists.jboss.orghttps://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 >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> forge-dev mailing listforge-dev@lists.jboss.orghttps://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 >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> forge-dev mailing list >>>>>>>>>> forge-dev(a)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 >>>>>>>>> https://lists.jboss.org/mailman/listinfo/forge-dev >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> forge-dev mailing listforge-dev@lists.jboss.orghttps://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 >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> 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 >>>>>> 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 >>>>> >>>> >>>> >>>> >>>> -- >>>> 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 >>> 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 >> > > > > -- > 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 https://lists.jboss.org/mailman/listinfo/forge-dev