How does a Java ClassLoader load imports like import java.util.*? I am asking, because I have a custom classloader which sometimes is asked to load a package instead of a class. Example:
public Class<?> loadClass(String className) throws ClassNotFoundException
{
System.out.println(className);
return parent.loadClass(className);
}
Example output:
org.test.model.User
org.test.model
org.test.model
So it seems like the whole package is requested (may be due to import org.test.model.* ?) I am not sure if the imports are causing this (and how to handle it) or if everything is fine and should be this way. Thanks in advance!
Note: This question seems to be the root of my actual problem.
EDIT
Out of the answer below I do understand that classes are loaded when referenced and the import statement is not what is important. Anyhow, why are packages (like "org.test.model" in the example above) being loaded? Or what would such a request mean?
'import' is simply syntactic sugar. When your code gets compiled to bytecode, all classes are referenced by their complete package.name
The thing here to understand is that ClassLoader don't resolve imports,they resolve classes lazily as they are referenced .They may be resolved eagerly by using Class.forName(String className).
So basically if you are using import myclasses.unusedPackage.* ,it doesn't go for resolving all the classes present in the package but will only load a Class as it is referenced.
Related
OK so this is some kind of theoretical question for you guys.
I am experimenting with cglib's Enchancer - creating a proxy for a class.
My code is running in a Felix OSGi container.
The hierarchy looks kind of similar to that:
// Bundle A;
// Imports-Package: javax.xml.datatype
// Exports-Package: a.foo
package a.foo;
public class Parent {
protected javax.xml.datatype.XMLGregorianCalendar foo;
... -> getter/setter;
}
// Bundle B
// Imports-Package: a.foo
// DOES NOT IMPORT PACKAGE javax.xml.datatype !!!
package b.bar;
import a.foo.Parent;
public class Child extends Parent {
protected String bar;
... -> getter/setter;
}
// Bundle B
// Code extracted from https://github.com/modelmapper/modelmapper/blob/master/core/src/main/java/org/modelmapper/internal/ProxyFactory.java#L59
public Child enchance() {
Enhancer enhancer = new Enhancer();
enhancer.setSuperclass(Child.class);
enhancer.setUseFactory(true);
enhancer.setUseCache(true);
enhancer.setNamingPolicy(NAMING_POLICY);
enhancer.setCallbackFilter(METHOD_FILTER);
enhancer.setCallbackTypes(new Class[] { MethodInterceptor.class, NoOp.class });
try {
return enhancer.createClass();
} catch (Throwable t) {
t.printStackTrace();
}
}
From OSGi point of view - the two bundles - Bundle A and Bundle B are fully functional.
The package imports/exports are bnd generated. Although BundleA does not import explicitly the javax.xml.datatype package - I can create instances of Child without any problem.
So far so good.
But when I try to call the enchance() method and create a Child proxy - cglib throws a NoClassDefFoundError: javax.xml.datatype.XMLGregorianCalendar
OK, I get this - BundleB's classloader indeed cannot load this class and in fact - cglib's Enchancer seems to be using BundleB's classloader (Child's class type classloader) in order to create the proxy.
On the other hand - for handling modularity the OSGi container is doing the so called classloading delegation - instead of BundleB's classloader, the OSGi runtime delegates the loading of the parent class Parent to BundleA's classloader, which knows how to load all of its fields.
This is why BundleB does not need to explicitly import the javax.xml.datatype package and does not need to know how to load the XMLGregorianCalendar class and still be able to work with Child objects.
I was wondering - isn't such "delegating" approach suitable in the cglib's use case as well?
Please note that I don't know ANYTHING about byte code manipulation and that might sound like a very stupid question to some.
But I really don't understand - why isn't cglib able to delegate loading of the Parent to Parent's own classloader?
Is such mechanism really not available in cglib? Why? Is cglib not used in combination with OSGi? If so then why?
The Child class does not need to import javax.xml.datatype so long as it does not access the javax.xml.datatype.XMLGregorianCalendar field and you are just using the Child class in the normal way. However in order to generate a proxy class, CGLib will need to have visibility of the internals of the full inheritance hierarchy including the javax.xml.datatype.XMLGregorianCalendar in order to generate the bytecode for the new type. Therefore an import of the package will be required.
Unfortunately bnd cannot predict that you will be doing bytecode generation on the Child class so it does not add the import of javax.xml.datatype – it only add the imports required for normal usage.
In general it is a bad idea to inherit from a class imported from another bundle. Java inheritance creates a very tight coupling from the subclass to the superclass, which means you are exposed to the internals of the superclass.
To your last question: CGLib is fairly widely used in OSGi for things like mocking objects during testing. It is less used in production because there is nearly always a better solution than bytecode generation, such as proper usage of the service registry.
I tried combining the OSGi Class Loader Bridge idea that is described here:
https://www.infoq.com/articles/code-generation-with-osgi
... that solves a similar problem with code generation frameworks running within OSGi, with another idea that came to me recently.
The idea is to keep track of class loaders of class types that are found in the parent type hierarchy of the user's type. We can later use these class loaders as fallback for loading types that are otherwise unknown to the Bundle's class loader of the user's type.
We can then tell CGLIB's Enhancer to use this new class loader for resolving.
The idea is presented here:
https://github.com/modelmapper/modelmapper/pull/294
I would love to hear the opinion of experienced OSGi specialists about this though.
But so far this seems to work.
Until proven wrong, I accept my own answer.
I'm developing an android test app and i'm going to access all internal class of android.view package. android.view is a package that is present in jar file. I tried by loading package name but it doesn't display the classes if any one tried
this already, please help.
Here's what I tried so far:
public static void main() throws ClassNotFoundException{
Class o =Class.forName("android.view");
Class[] C=o.getDeclaredClasses();
for(int i=0;i<C.length;i++) {
Classname = C[i].getName();
ClassesDisplayActivity.your_array_list3.add(Classname);
Log.i("Ramu","classname "+ C[i].getName());
}
}
}
It is not possible to determine at runtime all of the classes that are in a package using a standard class loader.
You might have some luck with this library though:
https://code.google.com/p/reflections/
Package is not a class. You cannot call Class.forName() for package and access classes that belong to class using getDelcaredClasses().
I do not know what do you really need, so I'd recommend you to explain this in separate question. probably you will receive better solutions.
However if you really need this you have to do the following:
Get your classpath by calling System.getProperty(java.class.path)
split this property to its elements by colon
iterate over the list and read each resource. If resource is jar you can use ZipInputStream, if it is a directory use File class.
filter list of resources you got at #3.
Fortunately you can use 3rd party library named Reflections that helps you to do all this without writing code.
I am using reflection to get all methods from a specific class.
This class has references to class that not in my class path so I get an exception:
java.lang.NoClassDefFoundError:
On this:
Method methods[] = theClass.getDeclaredMethods();
Is it possible, somehow,to "skip" everything that is not in classpath?
Class.forName() will not load a class, whether it is or isn't in the classpath. It will only return a handle to a class that is already loaded.
A class gets loaded in one of 2 main ways:
1.)The class is referenced in the import statements(java.lang.* is imported automatically so every class in java.lang package is class-loaded from the start)
2.)A class is loaded using a call from a ClassLoader, in which case all of its dependencies are resolved. and loaded as well
So if you are trying to load a class outside of the classpath, or with dependencies outside the classpath, you need to subclass ClassLoader and tell it how to load your classes and their dependencies.
See ClassLoader specification here: http://docs.oracle.com/javase/1.4.2/docs/api/java/lang/ClassLoader.html
Also, there are ready made subclasses of ClassLoader that may do what you want such as URL ClassLoader which will let you simply point the ClassLoader instance at the path, and load any classes in that path.
I get this error:
Exception in thread "http-server" java.lang.NoClassDefFoundError: org/w3c/jigmonitor/ReplyServer
but I don't undestand why. Could someone explain why does this happen?
This is the class that causes the problem:
public class ReplyServer implements Serializable
{
public ReplyServer()
{
super();
}
}
It looks like the class you're defining isn't being found by something that's trying to load it. In my experience this is caused by one of three problems:
Your package declaration for the class is not correct. In this case something on the http-sever thread is expecting your class to be declared in the package org.w3c.jigmonitor.
Your source file is not located in the correct directory. In this case, your source file should be located in a directory structure like "org/w3c/jigmonitor/", providing that's the package you actually want.
The path of the compiled class for ReplyServer is not in the classpath of your JVM. You can check this by looking at the classpath used to start your JVM and seeing if the class is actually there or not. In most generic setups servlet setups there will be a "WEB-INF/classes" folder for you to go poke around in.
Good luck!
(The link David posted gives a ton of information on this type of issue and the possible causes. I would recommend tucking that away for later)
I know this is a common question asked but I've been searching and I've included the class into eclipse through the buildpath. I start to write the import statement and it autocompletes options for me so I know it's finding the class.
My problem is how come it's giving this error when I'm reading the docs and it says the constructor method is MimeUtil2() ?
http://www.jarvana.com/jarvana/view/eu/medsea/mimeutil/mime-util/2.1/mime-util-2.1-javadoc.jar!/eu/medsea/mimeutil/MimeUtil2.html#MimeUtil2()
package com.jab.app;
import java.io.File;
import eu.medsea.mimeutil.*;
public class CheckFileType {
private void GetMimeType(File filename){
MimeUtil2 test = new MimeUtil2(); //Produces the error saying java type cannot be resolved
}
I think you need to import
import eu.medsea.mimeutil.*;
According to the documentation, the type is eu.medsea.mimeutil.MimeUtil2
I ended up finding out that I was using the test-source.jar not the main jar file itself. The sourceforge page made the default as the source file instead of the main jar file.
It was buried inside of the files page.