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

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 >>>>>>> > 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