Re: changing the classpath at runtime in code
Aryeh M. Friedman wrote:
On Oct 24, 9:31 pm, Arne VajhHj <a...@vajhoej.dk> wrote:
Aryeh M. Friedman wrote:
On Oct 24, 9:13 pm, Arne VajhHj <a...@vajhoej.dk> wrote:
Aryeh M. Friedman wrote:
On Oct 24, 8:16 pm, Arne VajhHj <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.
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
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?
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>