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

I need to stop answering emails after immediately waking up. :P Em 19/02/2013, às 01:17, "Lincoln Baxter, III" <lincolnbaxter(a)gmail.com&gt; escreveu: On Mon, Feb 18, 2013 at 10:07 PM, George Gastaldi <ggastald(a)redhat.com&gt;wrote: > What if we refactor the JavaParser API to it's optimal form ? We may > adopt a different package to avoid conflict with what we got, maybe > renaming to a standalone project, since it's very useful to other projects > as well, I guess. > > Em 18/02/2013, às 23:44, "Lincoln Baxter, III" <lincolnbaxter(a)gmail.com&gt; > escreveu: > > 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." _______________________________________________ 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