classloader

My usage case is compiling generated source files from a java program using the ToolProvider and JavaCompiler classes provided in JDK 6. The source files contain references to classes in the context classloader (it runs in a J2EE container), but not in the system classloader. My understanding is that by default the ToolProvider will create the JavaCompiler instance with the system classloader. Is there a way to specify a classloader for JavaCompiler to use? I tried this approach, modified from something on IBM DeveloperWorks: FileManagerImpl fm = new FileManagerImpl(compiler

I have developed an application using the Reflections library for querying all the classes having a particular annotation. Everything was working like a charm until I decided to create an Eclipse plug-in from my application. Then Reflections stop working. Given that my application is working fine when not part of an Eclipse plug-in, I think it should be a class-loader problem. So I added to my Reflections class the classloaders of the plug-in activator class, the context class loader, and all other class loaders I could imagine, without any success. This is a simplified version of my code:

This problem has been bugging me for a while. I have to load a couple files in my java app, and the only way I got working so far looks like this: URL hsURL; if(System.getProperty("os.name").toLowerCase().contains("windows")) { hsURL = new URL("file:/" + System.getProperty("user.dir") + "/helpsets/helpset.hs"); } else { hsURL = new URL("file://" + System.getProperty("user.dir") + "/helpsets/helpset.hs"); } But this is ugly and terrible. For a while I thought I had this working: hsURL = ClassLoader.getSystemResource("helpsets/helpset.hs"); But that no longer works for some reason (I must have

I have a JEE application that runs on WAS 6. It needs to have the class loader order setting to "Classes loaded with application class loader first", and the WAR class loader policy option set to "Single class loader for application". Is it possible to specify these options inside the EAR file, whether in the ibm-web-bnd.xmi file or some other file, so the admin doesn't need to change these setting manually? Since the app is deployed via an automated script, and the guy who is in charge of deployment is off site, and also for some other political reasons, this would greatly help! Thanks to

This question already has an answer here: Unloading classes in java? 7 answers How to unload a class from the class loader, so that I can use the recently changed class on the fly without restarting my application (hot deployment)? Is it possible to do that? Java rebel reloads changed classes on the fly. See the jrebel website for details . I don't know that I would recommend this for a production environment though, because of performance issues. JRebel on occasion bogs things down momentarily when you've recompiled for a server. You can't unload a class that is actually in use. But you might

I've seen this line in a sample application for using a commercial JDBC driver: Class.forName("name.of.a.jcdb.driver") The return value is not used. What purpose does this line serve? It performs a static loading of that class. So anything in the static { } block, will run. Maybe some code snippet will help. This is from Sun's JDBC-ODBC bridge driver, //-------------------------------------------------------------------- // Static method to be executed when the class is loaded. //-------------------------------------------------------------------- static { JdbcOdbcTracer tracer1 = new

Given a jar runs within a JVM would it be possible to unload the current running Jar and remove it from the system. Download a new version and rename it with the same name of the last Jar and then initialise the new Jar, creating a seamless update of the Jar within the JVM. Is it even possible to instruct the JVM to perform this action? Is it even possible to update a Jar whilst its running? Download a new version and rename it with the same name of the last Jar and then initialise the new Jar, creating a seamless update of the Jar within the JVM ... Is it even possible to update a Jar whilst

I think this is a situation every Java programmer runs into if they do it long enough. You're doing some debugging and make a change to class. When you go to re-run the program, these changes don't seem to be picked up but rather the old class still seems to be running. You clean and rebuild everything, same issue. Sometimes, this can come down to a classpath issue, of the same class being on the classpath more than once, but there doesn't seem to be an easy way to figure out where the class being loaded is coming from... Is there any way to find the file path for the class that was loaded?