<div dir="ltr">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.<br></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Fri, Feb 22, 2013 at 12:28 AM, 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">Wait, JavaCore is or is not related to JDT? <br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 21, 2013 at 7:18 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>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.</div>
<div><br></div><div>javassist's latest release is December 2012 and seems to have jboss backing. Seems a safe choice on the face of it.</div><div><br></div><div>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.</div>
<div><br></div></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 21, 2013 at 6:30 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">What about something like this?<br><br><a href="https://issues.jboss.org/browse/FORGE-795" target="_blank">https://issues.jboss.org/browse/FORGE-795</a><br>
<a href="https://issues.jboss.org/browse/FORGE-796" target="_blank">https://issues.jboss.org/browse/FORGE-796</a><br>
</div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Feb 20, 2013 at 11:11 AM, 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">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.<br>
</div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 19, 2013 at 7:41 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">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?<div>
<br></div><div><br></div></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Feb 18, 2013 at 9:43 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">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.<br>
</div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Mon, Feb 18, 2013 at 9:43 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>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.<br>
<br></div><div>So from the perspective of Migration, it probably makes sense to do something like add a method "isEditable()"<br></div></div><div><div><div class="gmail_extra"><br><br>
<div class="gmail_quote">On Thu, Feb 14, 2013 at 2:19 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>If I understood Lincoln correctly, he
meant adding an interface EditableJavaSource, so no change in the
existing implementations necessary.<br>
So the boolean is substitutable by instanceof, your graceful error
handling would be supported.<br>
<br>
Am 14.02.2013 20:10, schrieb John Franey:<br>
</div><div><div>
<blockquote type="cite">
<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>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><br>
</div>
<div>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><br>
</div>
<div>Regards,</div>
<div>John</div>
<div><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><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><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" 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><br clear="all"><br>-- <br>Lincoln Baxter, III<br><a href="http://ocpsoft.org" target="_blank">http://ocpsoft.org</a><br>
"Simpler is better."
</div>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Lincoln Baxter, III<br><a href="http://ocpsoft.org" target="_blank">http://ocpsoft.org</a><br>"Simpler is better."
</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>-- <br>Lincoln Baxter, III<br><a href="http://ocpsoft.org" target="_blank">http://ocpsoft.org</a><br>
"Simpler is better."
</div>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Lincoln Baxter, III<br><a href="http://ocpsoft.org" target="_blank">http://ocpsoft.org</a><br>"Simpler is better."
</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>-- <br>Lincoln Baxter, III<br><a href="http://ocpsoft.org" target="_blank">http://ocpsoft.org</a><br>
"Simpler is better."
</div>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Lincoln Baxter, III<br><a href="http://ocpsoft.org" target="_blank">http://ocpsoft.org</a><br>"Simpler is better."
</div>