We Keep Coding

How to load a java class outside the classpath?

I have a program where I want the user to be able to choose a .java class file from the file system, and then have that class loaded into the program.
I'm using a JFileChooser to allow the user to select a file. Then, I tried converting that file to a URL, and using a URLClassLoader to load the class (as suggested by these answers).
The problem is that, when I want to use the loadClass() method, I don't know the "full class name" of the class (e.g. java.lang.String). So, I don't know how to make this method work. Is there a way to get this class name? Or is there another way to do this?
Here is a sample of my code:
// Open the file chooser
JFileChooser fileChooser = new JFileChooser();
fileChooser.showOpenDialog(null);
File obtainedFile = fileChooser.getSelectedFile();
// Create the class loader from the file
URL classPath = obtainedFile.toURI().toURL();
URLClassLoader loader = new URLClassLoader(new URL[] {classPath});
// Get the class from the loader
Class<?> theClassIWant = loader.loadClass("the file name"); // What do I put here??

Load a single class file is generally completely useless. Said class file isn't alone; it has more class files that are relevant. Even if you think 'nah, there is just one source file, do not worry about this', note that a single java file can easily generate multiple class files.
Thus, two options:
Don't load class files. Load jar files.
Use the usual mechanisms (META-INF/services or META-INF/MANIFEST.MF) to put some sort of class name in there so you know what to load. Then create a new classloader with the provided jar, load the manifest, figure out the main class, load that, and run it.
Attempt to determine the 'root' for the loaded class file and include that on the classpath.
This is quite difficult - the problem is, to 'load' a class file you need to tell the loader what the fully qualified name is of that class before it is loaded. But how do you know the fully qualified name? You can surmise the class name from the file (not quite always true, but usually), but the package is a more difficult issue.
You can open the class file yourself as a binary stream and write a basic class file format parser to get the fully qualified class name. Easy for an experienced java programmer. Quite tricky for someone new to java (which I gather you are, if you think this is a good idea).
You can also use existing tools to do this, such as bytebuddy or asm.
Finally, you can try a spaghetti-at-the-wall method: Keep travelling up the directory until it works. You know it isn't working if exceptions occur.
For example, to load C:\MyDir\Whatever\com\foo\MyApp.class, You first try creating a new classloader (see the API of URLClassLoader which is part of core java) using as root dir C:\MyDir\Whatever\com\foo, and then you ask it to load class MyApp.
If that works, great (but usually trying to load package-less classes is simply a non-starter, you're not supposed to do that, the CL API probably doesn't support it, intentionally, there is no fixing that).
If it doesn't, instead try C:\MyDir\Whatever\com, and load class foo.MyApp. If that doesn't work, try C:\MyDir\Whatever and load class com.foo.MyApp, and so on.
The considerable advantage is, if there is another class sitting right next to MyApp.class, and MyApp needs it, this will work fine.
You'll need to write a while loop (traversing the path structure using Paths.get and p.getParent()), catch the right exception, manipulate the path into the class name (using .replace and +), and, of course, create a class loader (URLClassLoader), load classes with it (invoke loadClass), and if you intend on running it, something like thatClass.getConstructor().newInstance() and then thatClass.getMethod("someMethod", String.class, /* all the other args here */).invoke(theInstanceYouJustMade, "param1", /*all other params */) to actually 'run' it, more to be found in the java.lang.reflect package.

Android Am I using multiple ClassLoader/PathClassLoaders?

I am having issues with ClassLoaders in Android. At least I think it has to do with ClassLoaders. So here is the issue... I have a project that utilizes a custom widget library, lets call it CustomDialogView. It is a subclass of an android View object. I have a dialog that I created that extends CustomDialogView... So its important to mention the structure of how views are created and setup within this process (and eventually the activity).
My project is an Android service that registers Views to another process via a ContentResolver. The other process then pulls this data and will create the views based off of the classes sent. So, the view is eventually created and inflated in this other process (in an activity). I know, that is confusing but that is the method that is used for our application. So, in the view code eventually I may need to show a dialog. They give me a standard Object and it uses reflection to call the show dialog method. So here is the code snippet:
private static void showTheDialog(Object mainActivity, CustomDialogView view, boolean isModal) {
try {
mainActivity.getClass().getMethod("showDialog", View.class, Boolean.TYPE).invoke(mainActivity, view, isModal);
} catch (Exception var4) {
Log.w(TAG, var4.getClass().getName(), var4);
}
}
So on their end, they have this method within that object of interest:
public void showDialog(View dialogView, boolean isModal)
So here is where the issue comes in. In the method mentioned above (showDialog). They try to cast the dialogView, into a CustomDialogView so:
CustomDialogView dialogContent = (CustomDialogView)dialogView;
I get a ClassCastException as a result. I confirmed that I am using the same version of library that implements the CustomDialogView between both projects. I print the class loaders when I call showTheDialog and I get:
dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/com.this.is.project.myproject-1.apk"],nativeLibraryDirectories=[/data/app-lib/com.this.is.project.myproject-1, /vendor/lib, /system/lib]]]
I print out the class loader in the showDialog (in thier project) and I get:
dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/com.this.is.thier.project.thierproject-1.apk", zip file "/data/data/com.this.is.thier.project/code_cache/secondary-dexes/com.this.is.thier.project.thierproject-1.apk.classes2.zip", zip file "/data/data/com.this.is.thier.project/code_cache/secondary-dexes/com.this.is.thier.project.thierproject-1.apk.classes3.zip", zip file "/data/data/com.this.is.thier.project/code_cache/secondary-dexes/com.this.is.thier.project.thierproject-1.apk.classes4.zip", zip file "/data/data/com.this.is.thier.project/code_cache/secondary-dexes/com.this.is.thier.project.thierproject-1.apk.classes5.zip", zip file "/data/data/com.this.is.thier.project/code_cache/secondary-dexes/com.this.is.thier.project.thierproject-1.apk.classes6.zip"],nativeLibraryDirectories=[/data/app-lib/com.this.is.thier.project.thierproject-1, /vendor/lib, /system/lib]]]
So, we are using two different class loaders right? I have a hard time understanding this concept. Please let me know if you have any other questions if needed.

So, it appears that I am using multiple class loaders. As you may know, this can cause the class cast exception to occur. To solve, I can use reflection on the passed object. So here is a small snippit:
obj.getClass().getMethod("getterMethod").invoke(obj);
Above is the example of taking in the passed object (obj), using reflection to obtain its class then calling the method that I need. I hope this helps others. No class loader issues now. Thanks.

Java NoSuchMethodError when Method Exists

I am referencing PlayerUtil.getMovementSpeed(player); in my Speed class, and in my PlayerUtil class, I have the method defined as:
public static double getMovementSpeed(Player player) {
//my code here
}
But whenever the getMovementSpeed method is referenced in my other classes, it throws this error:
java.lang.NoSuchMethodError: net.Swedz.util.PlayerUtil.getMovementSpeed(Lorg/bukkit/entity/Player;)D
I thought it may be that Eclipse was exporting incorrectly, but I rebooted it and tried again with no avail.
EDIT: I did try decompiling the exported jar, and the public static double getMovementSpeed(Player player) method does exist in the exported jar.
EDIT: My friend is also having a similar issue, and is using IntelliJ, so Eclipse is not the issue.
EDIT: Class definition for PlayerUtil:
package net.Swedz.util;
public class PlayerUtil implements Listener {
//getMovementSpeed is defined in here
}
Class definition for Speed:
package net.Swedz.hack.detect.move;
public class Speed implements Hack, Listener {
//my detection methods and method containing PlayerUtil.getMovementSpeed(player);
}
SOLUTION: I found on my own that I had classes conflicting between two plugins on my server. I had one jar with net.Swedz.util.PlayerUtil and another with net.Swedz.util.PlayerUtil both with different contents. I added my project name in all lower case after the net.Swedz and it seems to have fixed it!
Thanks!

This is a very simple to troubleshoot.
you have used that method and you were able to compile that class which uses this method.
so that means at compile time it reefers the class PlayerUtil which has this method.
But runtime class loader has loaded the class PlayerUtil which doesn't contain this method.
now what you have to do is just find out where that class has been loaded from (at run time)
if you can recreate the problem while it is running using eclipse/IDEA follow these steps.
(if it runs in in application server or standalone application, then start the application server or application with debug enabled.and you can do remote debug from your IDE).
put a break-point where exception was thrown (where you call this method).
start to debug , it will hit the break-point.
then evaluate this expression PlayerUtil.class.getResource("PlayerUtil.class")
4.you can find the path where the class was loaded from.
now you have two options , decompile the class and check whether that method is these (same return type, same name , same args).
or in debug , you can evaluate PlayerUtil.class.getDeclaredMethods() to find out.
So you can solve the problem by rectifying the class path entries if it was loaded from a wrong place.

URLClassLoader finding X but not Y in same folder

General idea: I'm writing on a loader for java that allows dynamically reloading classes to allow for changing the implementation, without restarting the entire program to keep the main application running and minimize downtimes. Every external piece of code is grouped by "modules", each module has a main class with a "onEnable, postEnable, onDisable" entry/exit point and can consist of any amount of classes. To load a module, the class containing the entry point is specified, then loaded. I'll reference them as "modules" and "additional classes" in the following, "module" being the class containing the above mentioned functions by implementing the "public interface Module", "additional classes" refer to everything the module would use on runtime but isn't a Module by itself (e.g. we have a Module called "Car implements Module", and that module requires a class "Engine" to function -> "Car" is the module, "Engine" is an additional class")
Code of what I'm doing to load a module initially (name is a String containing the full classname including path, example given later):
Class<?> clazz = mainLoader.loadClass(name);
Module module = (Module) clazz.newInstance();
addLoadedModule(module);
enableLoadedModule(module);
And here's how I reload the module when it's already existing, so that I can override the implementation. "m" is an instance of the current implementation of the Module that is supposed to be reloaded.
boolean differs = false;
Class<?> newClass = null;
try (URLClassLoader cl = new URLClassLoader(urls, mainLoader.getParent()))
{
// Try to load the class and check if it differs from the already known one
newClass = cl.loadClass(m.getClass().getName());
differs = m.getClass() != newClass;
}
catch (IOException | ClassNotFoundException e)
{
// Class couldn't be found, abort.
e.printStackTrace();
return;
}
if (!differs)
{
// New class == old class -> no need to reload it
return;
}
Module module = null;
try
{
// Try to instantiate the class
module = (Module) newClass.newInstance();
}
catch (InstantiationException | IllegalAccessException e)
{
// Can't instantiate, abort
e.printStackTrace();
return;
}
// Check versions, only reload if the new implementation's version differs from the current one. Version is a custom annotation, don't worry about that; the version check works fine
Version oldVersion = m.getClass().getAnnotation(Version.class);
Version newVersion = module.getClass().getAnnotation(Version.class);
if (oldVersion.equals(newVersion))
{
return;
}
// And if everything went well, disable and remove the old module from the list, then add and enable the new module.
disableModule(m);
modules.remove(m);
modules.put(module, false);
enableLoadedModule(module);
This is the mainLoader, urls is an URL[] pointing to the location containing the external classes to load:
mainLoader = new URLClassLoader(urls, this.getClass().getClassLoader());
The problem arises when I try to RE-load an implementation, that requires multiple classes:
Module of class A requires class B to function. This is what happens when I try to dynamically load, then reload class A:
load A -> "Sure, but I'll need B with it." -> automatically loads B -> "Here ya go, A works fine now."
reload A -> "Sure, but I'll need B with it." -> crashes because B couldn't be found
Both classes are located in the exact same folder, structure like this:
Class A implements Module: com/foo/bar/A.class
Class B: com/foo/bar/B.class
urls: ["com/foo/bar/"]
I call the function with load("com.foo.bar.A"), which works when attempting to load it the first time, but fails when trying to reload it as described above.
It works fine when trying to load a "single class module", the problem arises when the module relies on an additional external class. I tried using different classloaders to use as the parent for the URLClassLoader in the reloading process, those being the sysloader, Module.class.getClassLoader(), mainLoader (using that one, it won't ever find the new class definition because it already knows about it and therefor won't even attempt to load it from the drive again) and the mainLoader.getParent(), the classloader of the old module, and the parent of the modules classloader.
I'm probably just overseeing something obvious, but I can't figure out why it would manage to load the "extra" classes the first time, but fail when I reload the base class...
If you need any debug outputs or exact errors let me know, I replaced the debug outputs with comments explaining what does what so I got a fairly detailed log of what's happening when, but I didn't seem it to be necessary as it goes through the entire "check and then load" process just fine, it crashes when trying to enable the module. The "onEnable" method of the module requires the additional class B, that's where it fails. As I said, if you need the implementation of the classes A and B, Module, any other code or the debug outputs let me know and I'll add them in as requested.

There's a few things you can try:
Create an extension of UrlClassLoader so that you can track when it loads a class and what class loader is used to load the class.
Your other issue is make sure none of these classes are available on the "default" class path as that will cause that version to use. You are not overriding the default class loading behaviour which is to check the parent for the class first.
The other issue you're probably facing relates to the way the VM caches classes - I'm not entirely sure how this works - but from what I've experienced it seems that once a class is loaded it puts it in a shared storage space so that it does not load the class again. This shared space class will not be unloaded until the class loader that loaded it goes unreachable.

The solution lies in the classloader being closed and deleted as soon as the loading of the initial class is done, due to the class loader being only existant in the try/catch clause. I solved the issue by storing the classloader in a map until a new implementation of the module is loaded, then I can discard the old loader and store the new one instead.

Dynamically loaded Class cannot access Applet loaded Class

My StartApplet is small to keep startup quick.
It then downloads various classes in various jars using (URLClassLoader)getSystemClassLoader().
The problem I am experiencing is that there are several interfaces defined in the StartApplet which are passed to the dynamically downloaded classes using method invoke. I always get class not defined.
It seems the system class loader does not contain any StartApplet loaded classes including the interfaces.
So, I try loading in the interfaces into the systemClassLoader using a downloaded jar but I still get class not defined and I guess this is because the same class has been loaded in twice using difference class loaders and therefore is seen as two difference classes.
I tried loading the downloaded jars using the classloader of one of the interfaces(StartApplet) but there were errors.
I tried forgetting about the system class loader and instead creating a new URLClassLoader using the classloader of the interfaces(StartApplet) as the parant class loader but again errors occurred.
I have tried loading the dynamic jars into Thread.currentThread().getContextClassLoader() but again errors occurred.
My question...
Is there a way to dynamically load classes in jars using (URLClassLoader)getSystemClassLoader() and allow them to see/access and use the classes that have already been loaded by the instantiating applet??
some code example would be really nice.
Many Thanks.
The crux is the system class loader doesnt reference the applet class loader.
The applet cannot start with any external jars so whatever classes it passes have to be loaded in with the applet.
I just need the dynamically loaded classes in the systemclassloader to be able to use the classes loaded with the applet.
please help.
ps. here are some snipets...
private void addPath(String _path)
{
try{
File f=new File(_path);
if(!f.exists())return;
if(!f.isDirectory())return;
Method method=SYSTEM_CLASS_LOADER_CLASS.getDeclaredMethod("addURL",parameters);
method.setAccessible(true);
method.invoke(SYSTEM_CLASS_LOADER,new Object[]{f.toURI().toURL()});
}catch(Throwable _t){
handle(_t);
disconnect();}
}
private void addLibrary(String _name)
{
try{
Method method=SYSTEM_CLASS_LOADER_CLASS.getDeclaredMethod("addURL",parameters);
method.setAccessible(true);
method.invoke(SYSTEM_CLASS_LOADER,new Object[]{ClassLoader.getSystemResource(_name)});
}catch(Throwable _t){handle(_t);}
}
SYSTEM_CLASS_LOADER=(URLClassLoader)ClassLoader.getSystemClassLoader(); // DOESNT WORK
SYSTEM_CLASS_LOADER=(URLClassLoader)MyInterface.class.getClassLoader(); // DOESNT WORK
SYSTEM_CLASS_LOADER=(URLClassLoader)Thread.currentThread().getContextClassLoader(); // DOESNT WORK
private void callWithInterface(MyInterface _myI)
{
Class<?> myClass=Class.forName("dynamic.MyClass",true,SYSTEM_CLASS_LOADER);
Constructor<?> myConstructor=myClass.getConstructor();
Object myInstance=myConstructor.newInstance();
Method m=myClass.getMethod("MyTest",new Class<?>[]{MyInterface.class});
String s=(String)m.invoke(myInstance,new Object[]{_myI});
}
last line causes...
Thread=Thread[Thread-17,4,http://MyDomain/-threadGroup]
java.lang.ClassNotFoundException: MyInterface
java.net.URLClassLoader$1.run(-1)
java.net.URLClassLoader$1.run(-1)
java.security.AccessController.doPrivileged(-2)
java.net.URLClassLoader.findClass(-1)
java.lang.ClassLoader.loadClass(-1)
sun.misc.Launcher$AppClassLoader.loadClass(-1)
java.lang.ClassLoader.loadClass(-1)
java.lang.Class.forName0(-2)
java.lang.Class.forName(-1)
StartApplet.run(23759)
java.lang.Thread.run(-1)

I have figured it out..
The problem I had was caused by a jar name conflict causing the required classes to fail at loading. Once I realised this and corrected the problem I successfully enabled the dynamically loaded classes to access the applet loaded classes by loading the dynamically loaded classes using the applet class loader instead of the system class loader.
I modified my code using the following lines and other adjustments to suit...
MyDynamicClassLoader=new URLClassLoader(new URL[0],MyAppletLoadedInterface.class.getClassLoader());
method.invoke(MyDynamicClassLoader,new Object[]{MyDynamicClassLoader.getResource(DynamicJarName)});
MyDynamicClassLoader now holds references to all applet loaded classes and dynamically loaded classes with the ability to reference each other. For some reason the system class loader does not hold the applet loaded classes.
Regards
Penny