changing the classpath at runtime in code

[Aryeh M. Friedman]

Is it possible for a java app to change it's classpath at runtime. I
tried:

System.setProperty("java.class.path","foo")

The reason for wanting to try is URLClassLoader will not physically
reread a class file if it is in the classpath. See
http://groups.google.com/group/comp.lang.java.programmer/browse_thread/thread/793a9146df18365a/ceaa154348f6f271#ceaa154348f6f271

[Arne Vajhøj]

Aryeh M. Friedman wrote:
> Is it possible for a java app to change it's classpath at runtime. I
> tried:
>
> System.setProperty("java.class.path","foo")
>
> The reason for wanting to try is URLClassLoader will not physically
> reread a class file if it is in the classpath.

Create a URLClassLoader with a url that are *not* in the parent
classloaders url's.

Arne

[Aryeh M. Friedman]

so just do:

URL[] url={new URL("file://foo")};
URLClassLoader laoder=new URLClassLoader(url);
?

[Arne Vajhøj]

I have a little demo example I often use to illustrate
(subdir test is not in classpath of program).

Arne

===============================

import java.io.*;
import java.net.*;

public class DoubleDynmaic {
private static void dynno(int n) {
(new File("test")).mkdir();
try {
OutputStream os = new FileOutputStream("test/Test.java");
PrintStream ps = new PrintStream(os);
ps.println("public class Test {");
ps.println(" public Test() {");
ps.println(" System.out.println(" + n + ");");
ps.println(" }");
ps.println("}");
ps.close();
os.close();
Runtime.getRuntime().exec("javac -d test
test/Test.java").waitFor();
URL[] url = new URL[1];
url[0] = new URL("file:test/");
URLClassLoader cl = new URLClassLoader(url);
Class.forName("Test", true, cl).newInstance();
} catch (Exception e) {
e.printStackTrace();
}
}
public static void main(String[] args) {
for(int i = 0; i < 10; i++) {
dynno(i);
}
}
}

[Aryeh M. Friedman]

On Oct 24, 9:13 pm, Arne Vajhøj <a...@vajhoej.dk> wrote:
> Aryeh M. Friedman wrote:
> > On Oct 24, 8:16 pm, Arne Vajhøj <a...@vajhoej.dk> wrote:
> >> Aryeh M. Friedman wrote:
> >>> Is it possible for a java app to change it's classpath at runtime. I
> >>> tried:
> >>> System.setProperty("java.class.path","foo")
> >>> The reason for wanting to try is URLClassLoader will not physically
> >>> reread a class file if it is in the classpath.
> >> Create a URLClassLoader with a url that are *not* in the parent
> >> classloaders url's.
>
> > so just do:
>
> > URL[] url={new URL("file://foo")};
> > URLClassLoader laoder=new URLClassLoader(url);
> > ?
>
> I have a little demo example I often use to illustrate
> (subdir test is not in classpath of program).

You posted this in the original thread but as noted in the linked to
thread almost all the classes I am dealing with *WILL* be in the
classpath.... so the question remains if I do the code in my previous
post will it now load from the class path or from "foo".

[Aryeh M. Friedman]

On Oct 24, 9:13 pm, Arne Vajhøj <a...@vajhoej.dk> wrote:
> Aryeh M. Friedman wrote:
> > On Oct 24, 8:16 pm, Arne Vajhøj <a...@vajhoej.dk> wrote:
> >> Aryeh M. Friedman wrote:
> >>> Is it possible for a java app to change it's classpath at runtime. I
> >>> tried:
> >>> System.setProperty("java.class.path","foo")
> >>> The reason for wanting to try is URLClassLoader will not physically
> >>> reread a class file if it is in the classpath.
> >> Create a URLClassLoader with a url that are *not* in the parent
> >> classloaders url's.
>
> > so just do:
>
> > URL[] url={new URL("file://foo")};
> > URLClassLoader laoder=new URLClassLoader(url);
> > ?
>
> I have a little demo example I often use to illustrate
> (subdir test is not in classpath of program).

Perhaps google ate my previous response.... but as I said several
places (including the linked to thread) almost all my classes *WILL*
be in the classpath... btw as mentioned in an other thread your demo
doesn't quite work once divorced from the code to rewrite the class
(see orginial thread)... so the question remains does the code above
load from "foo" or from the classpath when I do loader.loadClass(...)

[Arne Vajhøj]

Aryeh M. Friedman wrote:
> On Oct 24, 9:13 pm, Arne Vajhøj <a...@vajhoej.dk> wrote:
>> Aryeh M. Friedman wrote:
>>> On Oct 24, 8:16 pm, Arne Vajhøj <a...@vajhoej.dk> wrote:
>>>> Aryeh M. Friedman wrote:
>>>>> Is it possible for a java app to change it's classpath at runtime. I
>>>>> tried:
>>>>> System.setProperty("java.class.path","foo")
>>>>> The reason for wanting to try is URLClassLoader will not physically
>>>>> reread a class file if it is in the classpath.
>>>> Create a URLClassLoader with a url that are *not* in the parent
>>>> classloaders url's.
>>> so just do:
>>> URL[] url={new URL("file://foo")};
>>> URLClassLoader laoder=new URLClassLoader(url);
>>> ?
>> I have a little demo example I often use to illustrate
>> (subdir test is not in classpath of program).
>
> You posted this in the original thread but as noted in the linked to
> thread almost all the classes I am dealing with *WILL* be in the
> classpath.... so the question remains if I do the code in my previous
> post will it now load from the class path or from "foo".

If the class get loaded by the parent classloader because it is
in the apps general classpath, then you can (as far as I know)
neither get it unloaded or reloaded.

You need to get those classes of the classpath.

Arne

[Aryeh M. Friedman]

Since this is for a commercial unit testing product this is not
possible in practice (it is not safe to make assumptions about where
people place things). Some one off line suggested forking a process
to do it.... if I can't find a ClassLoader based solution I will have
to do that but it is down right a) not portable b) evil

[Daniel Pitts]

Here's the scoop.
If its ever on the class path, you can't reload it. What you're trying
to do is not possible to do without restricting what's on the class
path. That is not a bad restriction! Just make it happen.

Changing the class path after the fact isn't going to help either.

--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>

[Daniel Pitts]

Once a class is loaded by any class loader, it can not be reloaded by
any other class loader in that same branch of the class-loader tree.

[Daniel Pitts]

Hmm, I think as a publisher of said software, you can say how it should
work. If you can't make any assumptions whatsoever then you're lost.
You'll end up writing this program for clients who want to be able to
bounce a network signal off the moon for some reason.

It's all about making reasonable assumptions. It is reasonable to
assume that you can have a degree of control the environment/context in
which your application starts up. Document the fact that the code to be
tested can't be in the same path as your product.

Also, you seem to make a big deal about this code being "commercial".
This rule applies for any publicly distributed product, whether
commercial or otherwise.

Honestly, I think you're going down the wrong road with this. Have you
looked at other existing test frameworks? What is yours going to offer
that, say, JUnit doesn't?

[Roedy Green]

On Wed, 24 Oct 2007 23:38:10 -0000, "Aryeh M. Friedman"
<Aryeh.F...@gmail.com> wrote, quoted or indirectly quoted someone
who said :

>Is it possible for a java app to change it's classpath at runtime

yes but it requires firing up a new classloader.

See http://mindprod.com/jgloss/classloader.html
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

[Arne Vajhøj]

You do not have any control over where people put their stuff,
but you have control over your stuff.

If the only thing in classpath is your jar file, then you can
create your own classloader for their stuff and unload and reload
as needed.

Arne