OK. What I can do is to completely replace the findClass method by
using the URLCassLoader.findResource.
aehem... please don't copy-and-paste.
AFAIK we cannot do this because of
sun's license restrictions.
It won't be able to support package sealing nor can it easily
define
Torsten Curdt wrote:
OK. What I can do is to completely replace the findClass method by
using the URLCassLoader.findResource.
aehem... please don't copy-and-paste.
AFAIK we cannot do this because of
sun's license restrictions.
I believe I only cut-and-paste from AntClassLoader, not
aehem... please don't copy-and-paste.
AFAIK we cannot do this because of
sun's license restrictions.
I believe I only cut-and-paste from AntClassLoader, not
URLClassLoader, but now that you mentioned it, I'm no longer too
sure. Did you spot any code that look like from URLClassLoader?
I
they actually prove a violation when you're writing code that essentially
does the same exact thing?
-Original Message-
From: Torsten Curdt [mailto:[EMAIL PROTECTED]
Sent: Monday, August 15, 2005 2:19 PM
To: Jakarta Commons Developers List
Subject: Re: [javaflow] class loader
aehem... please
Out of curiosity, how would Sun know if you copy/pasted rather than
writing
from scratch, assuming you use the same variable/method names or you
actually did copy/paste and changed some variable/method names? I
don't
know the legality of how that all works. I'm just wondering. How
Torsten Curdt wrote:
aehem... please don't copy-and-paste.
AFAIK we cannot do this because of
sun's license restrictions.
I believe I only cut-and-paste from AntClassLoader, not
URLClassLoader, but now that you mentioned it, I'm no longer too
sure. Did you spot any code that look like
Aaa, there's always something new to learn.
...there always is :)
Actually I think we should *replace* the old
one. We should make sure the API does not
provide too many options.
I generally agree with this.
Good :)
I'd say:
if it does what it should - replace it.
OK, I will do
Torsten Curdt wrote:
Couldn't we then maybe also extend from URLClassLoader?
It would have been great if I could have done this, but no, as far
as I can tell, URLClassLoader doesn't have a hook we can use to
insert the class file transformation.
We could completely override the methods.
Torsten Curdt wrote:
java -Djava.system.class.loader=name of the class
see http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ClassLoader.html
Aaa, there's always something new to learn.
No worries ...just go ahead
I implemented this and put this back as
ContinuationURLClassLoader. I'm
Kohsuke Kawaguchi wrote:
I'd say:
if it does what it should - replace it.
OK, I will do this. But you are aware that it doesn't completely subsume
the functionality of the current ContinuationClassLoader, right?
In particular, I don't think I can easily replace the unit test set up
with
Torsten Curdt wrote:
I don't think we can even install ContinuationClassLoader as the
system class loader. I thought the system class loader is set up by
JVM before any Java code runs.
I have been using other code rewriting classloaders
as system classloaders. No problem. I think what
you
I have been using other code rewriting classloaders
as system classloaders. No problem. I think what
you are referring to is the bootstrap classloader.
I'd love to know how you do this.
java -Djava.system.class.loader=name of the class
see
I don't think we can even install ContinuationClassLoader as the
system class loader. I thought the system class loader is set up by
JVM before any Java code runs.
I have been using other code rewriting classloaders
as system classloaders. No problem. I think what
you are referring to is
I noticed that in ContinuationClassLoader you aren't actually using
the marker interface to decide what to instrument any more. Is this
by design? I also noticed a similar comment in the TODO file.
Yes, I am no big fan of empty marker interfaces.
I'd prefer a configuration approach.
If
Torsten Curdt wrote:
I noticed that in ContinuationClassLoader you aren't actually using
the marker interface to decide what to instrument any more. Is this
by design? I also noticed a similar comment in the TODO file.
Yes, I am no big fan of empty marker interfaces.
I'd prefer a
I noticed that in ContinuationClassLoader you aren't actually using the
marker interface to decide what to instrument any more. Is this by
design? I also noticed a similar comment in the TODO file.
If so, I can remove the Continuable interface.
I still see some value in retaining the
16 matches
Mail list logo
