You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bcel-user@jakarta.apache.org by Masahji Stewart <ma...@masahji.com> on 2003/05/26 19:44:33 UTC
Anonymous Inner Class @ runtime
Hello,
I am trying to create an anonymous inner class at runtime that
implements the following interface:
interface Foo {
public Object getValue(Object instance);
}
If the class were hand written, it might look like the following:
class FooImpl implements Foo {
FooImpl() {}
public Object getValue(Object instance) {
return ((SomeNamingClass)instance).getName();
}
}
Instead, I would like to implement this class at runtime (for various
reasons).
Also,
* I don't want to write the class to a file, but still load it and
create an instance of it.
* Because I don't want to manage dynamic class names, I want to rely
on the VM to create dynamic class names for me.
So, is there a way to create an anonymous inner class and load it into
the current VM at runtime?
Thanks in advance,
-masahji
---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-user-help@jakarta.apache.org
Re: jcoverage/gpl
Posted by Peter Morgan <pm...@jcoverage.com>.
[I didn't mean to hijack this list for a licensing discussion. Sorry]
On Thu, 2003-05-29 at 21:16, David Hovemeyer wrote:
> On Thu, May 29, 2003 at 08:49:47PM +0100, Peter Morgan wrote:
> > As the copyright holder we specifically make exceptions to the GPL where
> > the instrumented application is either licensed under the GPL or
> > licensed under an OSI license. Our licensing policy is described here:
> > http://jcoverage.com/license.html.
>
> According to the GPL:
>
> "The act of running the Program is not restricted"
> (item 0 in "Terms and Conditions")
>
> "You may not impose any further restrictions on the recipients'
> exercise of the rights granted herein."
> (item 6 in "Terms and Conditions")
>
> Therefore, it seems to me that you cannot license your application
> under the GPL *and* impose restrictions on the use of your program.
>
> > The principle reason for choosing the GPL is for revenue protection.
> > While we are happy for any OSI licensed application to be instrumented
> > with jcoverage, we do not want commercial licensed applications to be
> > instrumented without having purchased the commercially licensed version
> > of jcoverage.
>
> I don't think the GPL will allow you to do this. You should probably
> write your own license.
The model that we are basically trying to follow is that of MySQL. Could
you please explain why
http://www.mysql.com/products/licensing.html is any different to our
model.
Thanks,
Peter.
--
Peter Morgan
jcoverage ltd
+44 1423 526 426
---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-user-help@jakarta.apache.org
Re: jcoverage/gpl
Posted by David Hovemeyer <da...@cs.umd.edu>.
On Thu, May 29, 2003 at 08:49:47PM +0100, Peter Morgan wrote:
> As the copyright holder we specifically make exceptions to the GPL where
> the instrumented application is either licensed under the GPL or
> licensed under an OSI license. Our licensing policy is described here:
> http://jcoverage.com/license.html.
According to the GPL:
"The act of running the Program is not restricted"
(item 0 in "Terms and Conditions")
"You may not impose any further restrictions on the recipients'
exercise of the rights granted herein."
(item 6 in "Terms and Conditions")
Therefore, it seems to me that you cannot license your application
under the GPL *and* impose restrictions on the use of your program.
> The principle reason for choosing the GPL is for revenue protection.
> While we are happy for any OSI licensed application to be instrumented
> with jcoverage, we do not want commercial licensed applications to be
> instrumented without having purchased the commercially licensed version
> of jcoverage.
I don't think the GPL will allow you to do this. You should probably
write your own license.
-Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-user-help@jakarta.apache.org
Re: jcoverage/gpl
Posted by Peter Morgan <pm...@jcoverage.com>.
On Thu, 2003-05-29 at 19:10, Berin Loritsch wrote:
> Its a neat idea, but GPL mixed with BCEL makes me shiver. If you
> automatically alter my compiled code, does that mean I have to release
> my code using GPL?
As the copyright holder we specifically make exceptions to the GPL where
the instrumented application is either licensed under the GPL or
licensed under an OSI license. Our licensing policy is described here:
http://jcoverage.com/license.html.
In no way is it our intention to prevent any OSI licensed application
from being instrumented with the GPL version of jcoverage. Instrumenting
an OSI licensed application with the GPL version of jcoverage does not
cause that instrumented application to be licensed under the GPL.
> If JCoverage is using BCEL, does that pose a problem for BCEL?
I am no lawyer, I write code :), but my reading of
http://www.gnu.org/licenses/gpl-faq.html#InterpreterIncompat, is that we
can link with "GPL-incompatible" libraries, without causing that library
to become GPL. As the copyright holder we can make exceptions to the GPL
for such purposes, jcoverage is specifically designed to work with BCEL,
log4j, junit, oro and getopt.
> What about at the very least using LGPL? It is far lest strict.
The principle reason for choosing the GPL is for revenue protection.
While we are happy for any OSI licensed application to be instrumented
with jcoverage, we do not want commercial licensed applications to be
instrumented without having purchased the commercially licensed version
of jcoverage.
Regards,
Peter.
--
Peter Morgan
jcoverage ltd
+44 1423 526 426
---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-user-help@jakarta.apache.org
Re: jcoverage/gpl
Posted by Berin Loritsch <bl...@apache.org>.
Peter Morgan wrote:
> Hi,
>
> We have released a GPL Java Code Coverage tool, called: jcoverage.
> Available from, http://jcoverage.com. Why is this of interest to the
> subscribers of bcel-user? jcoverage is written using the BCEL library,
> it is GPL software, and could be an interesting example for BCEL users
> to study.
Its a neat idea, but GPL mixed with BCEL makes me shiver. If you
automatically alter my compiled code, does that mean I have to release
my code using GPL?
If JCoverage is using BCEL, does that pose a problem for BCEL?
What about at the very least using LGPL? It is far lest strict.
>
> We use BCEL to insert instrumentation into every instruction that has an
> associated line number. We also record the position of conditional
> branches so that we can determine branch coverage.
>
> Our GPL source code is available from:
> http://jcoverage.com/download/jcoverage.html. You can browse our source
> repository via http://jcoverage.bkbits.net/. We welcome, comments and/or
> contributions.
>
> jcoverage is also available under a commercial license for the
> instrumentation of non-GPL applications.
>
> Regards,
> Peter.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-user-help@jakarta.apache.org
Re: jcoverage/gpl
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Peter Morgan wrote:
> We have released a GPL Java Code Coverage tool, called: jcoverage.
The web site reads
Commercial users may evaluate jcoverage for a period not exceeding
15 days using the GPL version. Thereafter commercial users must
either stop using the GPL version of jcoverage, or purchase the
non-GPL licensed version.
While the intent is understandable, the license for the program
with these strings attached is no longer GPL. You should consult
a real and experienced lawyer on this, the FSF can become quite
unhappy about misuse of the term "GPL".
Also the need to have a *commercial* tool (read: pay money) in order
to get the source can be seen as a contradiction to GPL terms, you
might want to think about this too.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-user-help@jakarta.apache.org
jcoverage/gpl
Posted by Peter Morgan <pm...@jcoverage.com>.
Hi,
We have released a GPL Java Code Coverage tool, called: jcoverage.
Available from, http://jcoverage.com. Why is this of interest to the
subscribers of bcel-user? jcoverage is written using the BCEL library,
it is GPL software, and could be an interesting example for BCEL users
to study.
We use BCEL to insert instrumentation into every instruction that has an
associated line number. We also record the position of conditional
branches so that we can determine branch coverage.
Our GPL source code is available from:
http://jcoverage.com/download/jcoverage.html. You can browse our source
repository via http://jcoverage.bkbits.net/. We welcome, comments and/or
contributions.
jcoverage is also available under a commercial license for the
instrumentation of non-GPL applications.
Regards,
Peter.
--
Peter Morgan
jcoverage ltd
+44 1423 526 426
---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-user-help@jakarta.apache.org
Re: Anonymous Inner Class @ runtime
Posted by Juozas Baliuka <ba...@centras.lt>.
see cglib.sourceforge.net, MethodProxy class does something like this
without reflection, you can modify it for your use case
or use Enhancer.
I use adapters in voruta.sourceforge.net see
http://voruta.sourceforge.net/xref/net/sf/voruta/DbUtils.html#84, this code
uses
cglib to generate adapter factories for JDBC stuff.
----- Original Message -----
From: "Masahji Stewart" <ma...@masahji.com>
To: "BCEL Users List" <bc...@jakarta.apache.org>
Sent: Tuesday, May 27, 2003 1:25 AM
Subject: Re: Anonymous Inner Class @ runtime
> I am sorry. I realized that I was been very unclear in my past two
> emails.
> Basically, I am looking to BCEL for an implementation that would
> replace a reflective method call by generating a class that wraps the
> method (that returns some value) with a known method name. Of course,
> this can be done by creating an adapter for every getter of every used
> class. But, even if I did that new classes that come along would not
> work with my framework unless I created an adapter for every getter
> method.
> If I used the java.lang.reflect.Proxy class that you suggested,
> reflection would still be used (underneath the hood) to retrieve the
> data that I am looking for.
>
> So, just to make things more clear, I would like to dynamically create
> an adapter instance for any method that retrieves an Object.
> It might look like the following:
>
> interface RetrieverAdapter {
> // o is an instance of the class that contains the getter for this
> retriever.
> public Object getValue( Object o );
> }
>
> // a hand made implementation would look like the following
> RetrieverAdapter retriever = new RetrieverAdapter() {
> public Object getValue( Object o ) {
> return ((SomeClass)o).getName();
> }
> };
>
>
> The class that I would like to implement using BCel has the following
> basic "reflective" implementation.
>
> // m would be something like that "getName" method that you see above.
> public RetrieverAdapter createRetrieverAdapter(final Method m) {
> // ignore the lack of consistency checks
> return new RetrieverAdapter() {
>
> public Object getValue(Object o) {
> return m.invoke( o, new Object[] {} );
> }
> };
> }
>
>
> Again, sorry for my lack of clarity in the last two emails.
> I hope this clears things up. I tried to implement this myself,
> following the provided HelloWorld example,
> but I am running into a boatload of problems. One is, how do I load a
> class without having to write it to a file
> first.
>
> Thanks in advance, again.
>
>
> masahji
>
>
>
> On Monday, May 26, 2003, at 11:59 AM, Toby Reyelts wrote:
>
> >
> > You can do this without BCEL using the standard java.lang.reflect.Proxy
> > class.
> >
> > God bless,
> > -Toby Reyelts
> >
> > ----- Original Message -----
> > From: "Masahji Stewart" <ma...@masahji.com>
> > To: <bc...@jakarta.apache.org>
> > Sent: Monday, May 26, 2003 1:44 PM
> > Subject: Anonymous Inner Class @ runtime
> >
> >
> >> Hello,
> >>
> >> I am trying to create an anonymous inner class at runtime that
> >> implements the following interface:
> >>
> >> interface Foo {
> >> public Object getValue(Object instance);
> >> }
> >> ...
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: bcel-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: bcel-user-help@jakarta.apache.org
> >
> >
> -masahji
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: bcel-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: bcel-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-user-help@jakarta.apache.org
Re: Anonymous Inner Class @ runtime
Posted by Masahji Stewart <ma...@masahji.com>.
I am sorry. I realized that I was been very unclear in my past two
emails.
Basically, I am looking to BCEL for an implementation that would
replace a reflective method call by generating a class that wraps the
method (that returns some value) with a known method name. Of course,
this can be done by creating an adapter for every getter of every used
class. But, even if I did that new classes that come along would not
work with my framework unless I created an adapter for every getter
method.
If I used the java.lang.reflect.Proxy class that you suggested,
reflection would still be used (underneath the hood) to retrieve the
data that I am looking for.
So, just to make things more clear, I would like to dynamically create
an adapter instance for any method that retrieves an Object.
It might look like the following:
interface RetrieverAdapter {
// o is an instance of the class that contains the getter for this
retriever.
public Object getValue( Object o );
}
// a hand made implementation would look like the following
RetrieverAdapter retriever = new RetrieverAdapter() {
public Object getValue( Object o ) {
return ((SomeClass)o).getName();
}
};
The class that I would like to implement using BCel has the following
basic "reflective" implementation.
// m would be something like that "getName" method that you see above.
public RetrieverAdapter createRetrieverAdapter(final Method m) {
// ignore the lack of consistency checks
return new RetrieverAdapter() {
public Object getValue(Object o) {
return m.invoke( o, new Object[] {} );
}
};
}
Again, sorry for my lack of clarity in the last two emails.
I hope this clears things up. I tried to implement this myself,
following the provided HelloWorld example,
but I am running into a boatload of problems. One is, how do I load a
class without having to write it to a file
first.
Thanks in advance, again.
masahji
On Monday, May 26, 2003, at 11:59 AM, Toby Reyelts wrote:
>
> You can do this without BCEL using the standard java.lang.reflect.Proxy
> class.
>
> God bless,
> -Toby Reyelts
>
> ----- Original Message -----
> From: "Masahji Stewart" <ma...@masahji.com>
> To: <bc...@jakarta.apache.org>
> Sent: Monday, May 26, 2003 1:44 PM
> Subject: Anonymous Inner Class @ runtime
>
>
>> Hello,
>>
>> I am trying to create an anonymous inner class at runtime that
>> implements the following interface:
>>
>> interface Foo {
>> public Object getValue(Object instance);
>> }
>> ...
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: bcel-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: bcel-user-help@jakarta.apache.org
>
>
-masahji
---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-user-help@jakarta.apache.org
Re: Anonymous Inner Class @ runtime
Posted by Toby Reyelts <to...@reyelts.com>.
You can do this without BCEL using the standard java.lang.reflect.Proxy
class.
God bless,
-Toby Reyelts
----- Original Message -----
From: "Masahji Stewart" <ma...@masahji.com>
To: <bc...@jakarta.apache.org>
Sent: Monday, May 26, 2003 1:44 PM
Subject: Anonymous Inner Class @ runtime
> Hello,
>
> I am trying to create an anonymous inner class at runtime that
> implements the following interface:
>
> interface Foo {
> public Object getValue(Object instance);
> }
> ...
---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-user-help@jakarta.apache.org
Re: Anonymous Inner Class @ runtime
Posted by Juozas Baliuka <ba...@centras.lt>.
Inner classes are "normal" java classes, but they must be listed in outers
class constant pool to access private members and
inner class names are generated by compiler, not by JVM.
----- Original Message -----
From: "Masahji Stewart" <ma...@masahji.com>
To: "BCEL Users List" <bc...@jakarta.apache.org>
Sent: Monday, May 26, 2003 7:51 PM
Subject: Re: Anonymous Inner Class @ runtime
> Oops,
>
> The concrete anonymous inner class that i referred to in my last email
> would actually look like this:
>
> Foo foo = new Foo() {
> public Object getValue(Object o) {
> return ((SomeClass)o).getName();
> }
> };
>
> sorry about that
>
> thanks in advance again
>
> masahji
> On Monday, May 26, 2003, at 10:44 AM, Masahji Stewart wrote:
>
> >
> > If the class were hand written, it might look like the
> -masahji
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: bcel-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: bcel-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-user-help@jakarta.apache.org
Re: Anonymous Inner Class @ runtime
Posted by Masahji Stewart <ma...@masahji.com>.
Oops,
The concrete anonymous inner class that i referred to in my last email
would actually look like this:
Foo foo = new Foo() {
public Object getValue(Object o) {
return ((SomeClass)o).getName();
}
};
sorry about that
thanks in advance again
masahji
On Monday, May 26, 2003, at 10:44 AM, Masahji Stewart wrote:
>
> If the class were hand written, it might look like the
-masahji
---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-user-help@jakarta.apache.org