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

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&gt;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."