I don't see why not, it's pretty simple. You are calling urlCl.loadClass() and throwing away the result. You are loading a class but never using it. What is the point? If you're trying to run out of memory, this would be a good way to do it, but it has no other point that I can see.not quite sure I understood your point.urlCl.loadclass(classname);why are you calling loadClass() and then throwing away the result?
jopensource wrote:The difference is that an application server actually uses the classes after it loads them, instead of just loading them and ignoring them. Is there a reason you are doing that?
@ejp: I am sorry , not quite sure I understood ur point.But what I am trying to do is load the class files dynamically from the jar files, like a web/app sever container does.
jopensource wrote:Computers are fixed size systems. There is no way to load an infinite number of anything into them.
I monitored using the jconsole which shows the no of classes loaded ,unload and total no if classes loaded.For 1 iteration, i would see an increase of 100,000 classes in the classes loaded and total classes loaded.Increasing the permgen space size at startup might only be a temporary fix , since we are not fixing the flaw and eventually would run into the same issue after a sometime.
since we are not fixing the flawSounds like a bad idea. Price a 64 bit system with 64 CPUs and 32 terabytes of physical memory and tell whoever came up with the idea that fixing the "flaw" isn't a good idea that you will need 4 of those systems to support the current system: 2 for prod, 1 for QA and 1 for development.
jopensource wrote:Why? I doubt you're using entirely separate JAX-WS implementations, so what jars are changing?
Yes. the URLs (jar files) would be changing.