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 https://lists.jboss.org/mailman/listinfo/forge-dev

Me too. However, I really, really want the feature: generate scaffold from an existing jpa library.

Max, I didn't know hibernate tools had a reveng plugin to forge. It did not occur to me to look because I was too focused on generating gui from entities which we developed manually. I'll try it to see what results.

Thanks, On Fri, Feb 15, 2013 at 11:52 AM, Max Rydahl Andersen <max.andersen(a)redhat.com&gt; wrote: > Me too. However, I really, really want the feature: generate scaffold from an existing jpa library. one way of doing this is just to use hibernatetools to get that model.... /max _______________________________________________ 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

> Max, > > I didn't know hibernate tools had a reveng plugin to forge. It did not occur to me to look because I was too focused on generating gui from entities which we developed manually. I'll try it to see what results. I actually send that email to early not explaining well what I meant ;) The current forge hibernate tools is 100% "read via jbdc from a database and generate entities". But hibernate tools core which forge hibernate tools is using actually don't have to start with just a database; it can also be "take existing classes and generate artifacts from that". As long as hibernate core can understand the mappings hibernate tools can load it. The limitation of this is of course you don't have the full Forge API available to you (since hibernate tools was done pre-forge) but at least it is an alternative that could be looked into using in the short time. Just a thought. /max > > Thanks, > > > > > > On Fri, Feb 15, 2013 at 11:52 AM, Max Rydahl Andersen < max.andersen(a)redhat.com&gt; wrote: > > > Me too. However, I really, really want the feature: generate scaffold from an existing jpa library. > > one way of doing this is just to use hibernatetools to get that model.... > > /max > _______________________________________________ > 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 _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev

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 https://lists.jboss.org/mailman/listinfo/forge-dev

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 >> 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 https://lists.jboss.org/mailman/listinfo/forge-dev

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 https://lists.jboss.org/mailman/listinfo/forge-dev

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

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 https://lists.jboss.org/mailman/listinfo/forge-dev

I have the same understanding of Lincoln's meaning. Also, there is implication also of EditableJavaType, EditableJavaClass, EditableMember, EditableMethod, EditableField, EditableAnnotation, EditableInterface...., right? Isn't he meaning to parallel all of these java model api? There are about 30 now, after there will be 60 or so. Then the refactoring of each interface: setters over there, getters over there. The condition to check a property is similar to the instanceof check. I agree. However, its not a clean substitution because the property check is one line. The instanceof check must be followed by a cast and a new variable. The difference can be overcome, and I don't mean to make a big thing out of this. My point is only that the boolean property is simpler. Some significant work and doubling of classes to support instanceof/cast vs. a boolean property. 30 new interfaces and changes to 30 existing interfaces vs a single change. John 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 >

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

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

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

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

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

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

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

wrote:

wrote:

wrote:

wrote:

wrote:

wrote:

wrote:

wrote:

wrote:

wrote:

wrote:

wrote:

wrote: