Currently I'm using this line to load a 3rd party JAR and add its packages/classes to my program
URL [] urls = new URL [] { "http://..." };
new URLClassLoader(urls);
The problem I have with this approach is that the whole JAR is loaded, meaning all packages and all classes are imported.
How can I tell URLClassLoaded to load only a few selected classes?
An example would be a JAR hierarchy like this
package A
class 1
class 2
package B
class 1
class 2
class 3
class 4
I'd like to do something like "import only A.* and B.class2"
Provide a custom implementation of ClassLoader.
Override the findClass() method of the classloader and apply the business logic for selecting the classes that you want to be loaded.
class CustomClassLoader extends ClassLoader {
public Class findClass(String name) {
if(shouldBeLoaded)
return defineClass(name, b, 0, b.length);
}
}
Setting this as the default class loader for loading (optional)
java -Djava.system.class.loader
=com.test.CustomClassLoader
Related
I have a main method that creates custom classloader and instantiates a class, called Test, with it.
public class App {
public static void main(String[] args) throws Exception {
try {
Class.forName("com.mycompany.app2.Test2"); // We ensure that Test2 is not part of current classpath
System.err.println("Should have thrown ClassNotFound");
System.exit(1);
} catch (ClassNotFoundException e) {
// ignore
}
String jar = "C:\\experiments\\classloader-test2\\target\\classloader-test2-1.0-SNAPSHOT.jar"; // Contains Test2
URL[] classPaths = new URL[] { new File(jar).toURI().toURL() };
ClassLoader classLoader = new URLClassLoader(classPaths, App.class.getClassLoader());
Thread.currentThread().setContextClassLoader(classLoader);
Class.forName("com.mycompany.app2.Test2", true, classLoader); // Check that custom class loader can find the wanted class
Test test = (Test) Class.forName("com.mycompany.app.Test", true, classLoader).getDeclaredConstructor().newInstance();
test.ex(); // This throws ClassNotFound for Test2
}
}
This class then itself instantiates another class that is not part of the original classpath, but is part of the custom one.
public class Test {
public void ex() {
new Test2().test();
}
}
In my understanding of classloader, since Test was created with the custom classloader any class loadings within should be done with the same loader. But this does not seem to be the case.
Exception in thread "main" java.lang.NoClassDefFoundError: com/mycompany/app2/Test2
at com.mycompany.app.Test.ex(Test.java:7)
at com.mycompany.app.App.main(App.java:28)
What do I need to do in the main method to make Test#ex work, without changing Test?
I'm using Java 17.
You create the URLClassLoader using App.class.getClassLoader() as the parent class loader. Hence, the request to load Test through the custom class loader is resolved through the parent loader, ending up at exactly the same class you’d get with Test.class in your main method.
You could pass a different parent loader, e.g. null to denote the bootstrap loader, to forbid resolving the Test class though the parent loader but this would result in either of two unhelpful scenarios
If the custom class loader has no com.mycompany.app.Test class on its own, the loading attempt would simply fail.
If the custom class loader has a com.mycompany.app.Test class, i.e. inside classloader-test2-1.0-SNAPSHOT.jar, it would be a different class than the Test class referenced in your main method, loaded by the application class loader. In this case, the type cast (Test) would fail.
In other words, the Test class referenced by you main method can not be affected by another, unrelated class loader at all.
There is an entirely different approach which may work in some scenarios. Do not create a new class loader, when all you want to do, is to inject a new class.
byte[] code;
try(var is = new URL("jar:file:C:\\experiments\\classloader-test2\\target\\" +
"classloader-test2-1.0-SNAPSHOT.jar!/com/mycompany/app2/Test2.class").openStream())
{
code = is.readAllBytes();
}
MethodHandles.lookup().defineClass(code);
Test test = new Test();
test.ex();
This adds the class to the current class loading context, so subsequent linking will succeed. With the following catches:
No previous attempt to link this class must have been made so far
It only works for a classes without dependencies to other absent classes (as there’s no class loader resolving those to the jar file outside the class path).
In some cases, when the dependencies are non-circular or resolved lazily, you could add all the classes with multiple define calls, if you know which you need and in which order.
The class must be in the same package, otherwise, you’d have to move the lookup context to the right package, with the documented restrictions
An entirely different approach to add the classes to the existing environment, would be via Java Agents, as they can add jar files to the class path.
My project structure is the following (very simplified of course):
So under lib-ext i download on a daily basis from a Jenkins server 2 jar files 'jar1 and jar2' to be checked by my program, i need one file from 'jar1' lets call it: "Class2Bloaded".
The issue is that this file implements an interface that is to be found in 'jar2', lets call this 'Dependency'
What i would like to do is, from my class under src "ClassThatLoads.java", load 'Class2Bloaded.class' and tell the class loader to look into 'jar2' to search for the implementing interface "Dependency.class"
My code so far (omitting exceptions handling):
//Create the URL pointing to Jar1
private URL getJarUrl(JarFile jarFile)
{
return new File(jarFile.getName()).toURI().toURL();
}
URL jar1Url = getJarUrl(jar1);
ClassLoader jar1classLoader = new URLClassLoader(new URL[] { jar1Url });
Class<?> Class2Bloaded = Class.forName(fullClassName, false, jar1classLoader );
So the problem happens within the Class.forName invocation, because the class i want to load implements an interface that is in jar 2.
Exception in thread "main" java.lang.NoClassDefFoundError: com/packagewithinJar2/Dependency
So eventually i have prepared another class loader that points to 'jar2', and i have even got the actual Interface i need:
URL jar2Url = getJarUrl(jar2);
ClassLoader jar2classLoader = new URLClassLoader(new URL[] { jar2Url });
Class<?> Interface2Bloaded = Class.forName(fullClassName, false, jar2classLoader );
Where 'fullClassName' in the second case is the fully qualified name of the interface from which 'Class2Bloaded' depends on.
Is just that i cant find anything in the javadocs of ClassLoader that allows me to 'inject' an additional class loader for the dependencies.
I hope my explanation is clear.
The first thing to do would be to add jar2 to the list of jars your URLClassLoader reads:
ClassLoader jarclassLoader = new URLClassLoader(new URL[] { jar1Url, jar2Url });
BUT the normal thing to do would be to add jar1 and jar2 on your classpath from the beginning.
To do so you would use the -cp parameter of the java executable.
for example, if you compile your classes into the bin directory:
java -cp libext/jar1.jar:libext/jar2.jar:bin ClassThatLoads
That way, you could use the classes seamless in your own java source and get rid of the cumbersome loading part :
public class ClassThatLoads {
public static void main(String[] args) {
Class2Bloaded stuff = new Class2Bloaded();
//use stuff from here...
}
}
I am loading classes via ClassLoader:
Class<?> clazz = urlClassLoader.loadClass(name.substring(0, name.length() - 6).replaceAll("/", "."));
System.out.println(clazz);
System.out.println(clazz.isInstance(SkillCast.class));
System.out.println(SkillCast.class.isInstance(clazz));
System.out.println(SkillCast.class.isAssignableFrom(clazz));
System.out.println(clazz.isAssignableFrom(SkillCast.class));
This is my structure:
public class SkillFireball extends SkillCast implements ISkillThrown
public abstract class SkillCast extends Skill
And prints are:
class skills.SkillFireball
false
false
false
false
What I am sure of is that clazz is SkillFireball and I can print field/method names.
How can I check if clazz is child of SkillCast?
EDIT
private static URLClassLoader urlClassLoader;
And code:
ClassLoader cl = Loader.instance().getModClassLoader();
urlClassLoader = URLClassLoader.newInstance(urls.toArray(new URL[urls.size()]), cl);
Where #getModClassLoader() returns:
// The class loader we load the mods into.
private ModClassLoader modClassLoader;
And:
public class ModClassLoader extends URLClassLoader
How it works:
Minecraft Forge API is loading #Mod. My mod is providing SkillCast.class and when loaded is attempting to read game directory and load classes in .jar files. Now - I have not much of an idea what should I do :C
I did it.
Problem was really my lack of knowledge about how classLoader-parenting works and how Java loads classes.
Done it by making new URLClassLoader with parent set to ClassLoader used by Main program itself (the mentioned #Mod).
SkillCast.class is loaded by Mod's ClassLoader therefore when I added new Class (SkillFireball) I also needed to use Mod's one, not new one like I did before.
Class<?> clazz = Loader.instance().getModClassLoader().loadClass(...)
This is not really an "answer" just an closing-problem post.
I'd like to be able to load a class(es) from a known directory whenever a compiled .class file appears in that particular directory. However the I'd like the .class to be loaded regardless of what the package decleration is in its .java file. For example I have this class which I wish to load:
package com.javaloading.test;
public class SomeClassInPackage {
private String name = "The name of this Class is SomeClass.";
public String getName(){
return name;
}
}
And it is in the package com.javaloading.test. I then want to load it using this class:
public class GetPackage {
public static void main(String[] args){
new GetPackage().loadMyClass();
}
public void loadMyClass(){
// Get the current class loader
ClassLoader cl = getClass().getClassLoader();
try {
Object o = cl.loadClass("SomeClassInPackage");
System.out.println("Class loaded!");
} catch (ClassNotFoundException ex){
System.out.println("Could not load class");
}
}
}
If I put the .class files of both the above Classes into the same directory and run GetPackage it results in the error
Exception in thread "main" java.lang.NoClassDefFoundError:
SomeClassInPackage (wrong name:
com/javaloading/test/SomeClassInPackage
I need to be able to load a class (from a file) regardless of it's declared package and without having to actually know its package. I would then examine the loaded class for its package information. Is this possible using the System ClassLoader or a custom ClassLoader or is it impossible without having knowledge of the package structure? If it's possible any advice is appreciated.
It is impossible to load the class without its respective package structure, means if you want to load the class then it must be placed in the folder that is correspond to its packages name or that class is in a jar file but in same folder structure.
But lets say you want to load the classes which is external means not in the class path where this program gets executed from and you want to load it in current class loader during execution. Refer to this link How to load the classes at runtime. This will also gives answer to your next question where you want to load the classes which is selected by the program based on its name or package.
how can I use resources from other maven modules? My goal is to provide a AbstractImportClass as well as the to be imported files in a specific maven module. And use this module within other modules extending this class.
Let's say ModuleA contains src/main/java/MyAbstractImportClass.java, and src/main/resources/MyImport.csv
I now want to use the abstract import class in ModuleB. Or rather, I will extend it, use the abstract-fileimport, and a few custom functions.
Then ModuleC also uses the abstracts' import and some custom functions.
The problem is: the import in abstract class goes with reader and InputStream. When I execute just ModuleA everything is fine.
But when I tried to include the module via maven pom, and then extend the module to call the import, then I get NullPointerException at the line where the reader is used.
So obvious I cannot use foreign module resources this way.
But how could I instead make use of this?
Update:
Module A:
src/main/java/path/to/MyClassA.java
src/main/resources/path/to/test.txt
abstract class MyClassA {
public static String TESTFILE = test.txt;
List<String> doImport(String filename) {
InputStream fileStream = resourceClass.getResourceAsStream(filename);
//some precessing
return list;
}
}
Module B:
src/main/java/path/to/MyClassB.java
class MyClassB implements MyClassA {
List<String> list = doImport(TESTFILE);
}
If I put MyClassB in same dir as A, then everything works fine.
If I build B in a own module I get NullPointer for InputStream, what means the file is not found.
I don't think your problem is related to Maven at all. Class.getResourceAsStream() resolves relative paths as relative to the class object that you call it on. Therefore, if you use that method in an abstract class, every subclass of it could be looking for the resource in a different place.
For example, given three classes:
Super:
package com.foo;
public class Super {
{ System.out.println(getClass().getResourceAsStream("test.properties")); }
}
Sub1, a subclass of Super:
package com.foo.bar;
import com.foo.Super;
public class Sub1 extends Super {}
Sub2, another subclass:
package com.foo.bar.baz;
import com.foo.Super;
public class Sub2 extends Super {}
If you create a Super, it'll look for the classpath resource "/com/foo/test.properties" because that's how the path "test.properties" resolves relative to the class com.foo.Super. If you create a Sub1, it'll look instead in "/com/foo/bar/test.properties", and for a Sub2 instance, it'll look in "/com/foo/bar/baz/test.properties".
You might want to use an absolute path to the resource instead of a relative one, or else have the subclasses specify paths relative to themselves. It depends on your design and what kind of abstraction you're trying to achieve.
It's not exactly clear what your code does. Could you provide sample of how you're reading resource? If you do it properly - by getting InputStream from resource file in classpath there should be no problem. You can start by checking that ModuleA.jar has your resource file inside.
You should check:
Module B depend on Module A in pom.xml
The passed in 'filename' parameter starts with a '/', that is to say, the 'filename' parameter is '/path/to/test.txt' other than 'path/to/test.txt'
You program should work if these two conditions is satisfield.