<div dir="ltr">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.....<div>
<br></div><div style>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.</div>
<div style><br></div><div style>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.<br>
</div><div style><br></div><div style>Regards,</div><div style>John</div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 14, 2013 at 1:11 PM, Lincoln Baxter, III <span dir="ltr"><<a href="mailto:lincolnbaxter@gmail.com" target="_blank">lincolnbaxter@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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.<br>
<br></div>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.<br>
</div><div class="gmail_extra"><div><div class="h5"><br><br><div class="gmail_quote">On Thu, Feb 14, 2013 at 12:23 PM, John Franey <span dir="ltr"><<a href="mailto:jjfraney@gmail.com" target="_blank">jjfraney@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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.</div>
<div><br></div><div>Putting the question another way:</div>
<div><br></div><div>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?</div>
<div><br></div><div>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.</div>
<span><font color="#888888">
<div><br></div><div>John</div><div><br></div></font></span></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 14, 2013 at 12:05 PM, Thomas Frühbeck <span dir="ltr"><<a href="mailto:fruehbeck@aon.at" target="_blank">fruehbeck@aon.at</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>Hmm, I expect loading of JARs not to
the problem, is it? So the loading and reflecting on the
"external" class should be possible. <br>
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.<br>
Sorry if I misunderstood your quest? =)<br>
<br>
Thomas<br>
<br>
Am 14.02.2013 17:37, schrieb John Franey:<br>
</div><div><div>
<blockquote type="cite">
<div dir="ltr">Thomas,
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>John</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Thu, Feb 14, 2013 at 11:22 AM,
Thomas Frühbeck <span dir="ltr"><<a href="mailto:fruehbeck@aon.at" target="_blank">fruehbeck@aon.at</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>exactly what I was looking for :-))<br>
Thanks George!<br>
<br>
Am 14.02.2013 16:55, schrieb George Gastaldi:<br>
</div>
<div>
<div>
<blockquote type="cite">
<div>Hi Thomas,</div>
<div><br>
</div>
<div>Have a look in Forge 2.0 source code. We're
using javassist at it's best in the proxy module</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
Em 14/02/2013, às 13:53, Thomas Frühbeck <<a href="mailto:fruehbeck@aon.at" target="_blank">fruehbeck@aon.at</a>>
escreveu:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div>Hi John,<br>
<br>
my two cents: <br>
- this feature is a must-have, if Forge
should be more than a tool to iniitialize
projects, really great idea<br>
- being pragmatic I would say this calls
for proxy classes, similar to CDI decorators
or the copy-on-write strategy<br>
<br>
(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.)<br>
<br>
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 :-/<br>
<br>
Have you thought about javassist? Is it an
option at all?<br>
<br>
Thomas<br>
<br>
<br>
Am 14.02.2013 16:21, schrieb John Franey:<br>
</div>
<blockquote type="cite">
<div dir="ltr">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.
<div><br>
</div>
<div>I have written a prototype:</div>
<div>1) an implementation of the forge java
api interfaces which delegates to java's
reflection, offering a read only
perspective of java components.</div>
<div>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.</div>
<div><br>
</div>
<div>These are demonstrable in a unit test.</div>
<div><br>
</div>
<div>My dilemma now is how to integrate
these into the forge project. There are a
few different areas, but I'll start with
this:</div>
<div><br>
</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>So, I'm looking for discussion and
consensus on the above. Any thoughts?</div>
<div><br>
</div>
<div>Regards,</div>
<div>John</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
forge-dev mailing list
<a href="mailto:forge-dev@lists.jboss.org" target="_blank">forge-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a></pre>
</blockquote>
<br>
</div>
</blockquote>
<blockquote type="cite">
<div><span>_______________________________________________</span><br>
<span>forge-dev mailing list</span><br>
<span><a href="mailto:forge-dev@lists.jboss.org" target="_blank">forge-dev@lists.jboss.org</a></span><br>
<span><a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a></span></div>
</blockquote>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
forge-dev mailing list
<a href="mailto:forge-dev@lists.jboss.org" target="_blank">forge-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a></pre>
</blockquote>
<br>
</div>
</div>
</div>
<br>
_______________________________________________<br>
forge-dev mailing list<br>
<a href="mailto:forge-dev@lists.jboss.org" target="_blank">forge-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
forge-dev mailing list
<a href="mailto:forge-dev@lists.jboss.org" target="_blank">forge-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a></pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
forge-dev mailing list<br>
<a href="mailto:forge-dev@lists.jboss.org" target="_blank">forge-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
forge-dev mailing list<br>
<a href="mailto:forge-dev@lists.jboss.org" target="_blank">forge-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br></blockquote></div><br><br clear="all"><br></div></div><span class="HOEnZb"><font color="#888888">-- <br>
Lincoln Baxter, III<br><a href="http://ocpsoft.org" target="_blank">http://ocpsoft.org</a><br>
"Simpler is better."
</font></span></div>
<br>_______________________________________________<br>
forge-dev mailing list<br>
<a href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br></blockquote></div><br></div>