classloader

Why is the setContextClassLoader() method placed on Thread ? What different thread have different classloaders? The question is what if I extended a ClassLoader , loaded there some new classes. to the my custom classloader. Now , I want it to be the context classloader , so I call the method Thread.currentThread().setContextClassLoader(loader) . Are these new classes awailable only in the context of the current thread ? Or how does it work? Thanks The Context class loader is the class loader that the thread will use to find classes. You primarily care about this when you are writing an

I got some java-byte-code (so compiled java-source) which is generated in my program. Now I want to load this byte-code into the currently running Java-VM and run a specific function. I'm not sure how to accomplish this, I digged a little bit into the Java Classloaders but found no straight way. I found a solution which takes a class-file on the harddisk, but the bytecode I got is in a Byte-Array and I dont want to write it down to the disk but use it directly instead. Thanks! Nikolaus Gradwohl you need to write a custom class loader that overloads the findClass method public Class findClass

I have a class that takes a bit of time to start up (makes some JNI calls and what not), so it is not feasable to initialize this class everytime a page loads. Is it possible to initialize this class on application startup, then access its methods as pages are being served up? For Example: I have MyClass. When the application (tomcat) starts up I would like it to initialze my calss as follows: MyClass myClassInstance = new MyClass("arg1", "arg2"); Then when a page is called, say /testpage, I would like to make calls to myClassInstance: import java.io.*; import javax.servlet.*; import javax

While analyzing a heap dump using jhat I have observed many instances of DelegatingClassLoader created although they were not called explicitly in code. I expect this to be some sort of reflection optimization mechanism. Does anybody know the details? Yes, it is probably a reflection optimisation. On the Sun JVM, reflective access to properties and methods is initially performed by calling through JNI into the JVM implementation. If the JVM notices that a method or field is being accessed by reflection a lot, it will generate bytecode to do the same thing -- a mechanism that it calls