Class loaders

Newbie & Debugging Questions
#1

I’ve had some trouble understanding the class loader stuff. I sort of figured it out, and now i wish to post the following as a resource to people new to Class loaders:

Actually I haven’t figured it out whatsoever and this below is related only to WebStart. When you use webstart you access things through JAR’s which are placed locally on your machine without you knowing how the computer will rename them. I think, because of that, i used Class Loaders, but they have other very important uses.

To get a brief correct explanation of the main purpose of Class Loaders read few posts below (Jeff).

Using relative or absulte paths is not enough if you want your application to work on other computers/systems. When making an application it is a very good if not necessary practice to use Class loaders. You use them so that your application (code) can locate outside resources such as images, text files and so on whether it is run on Linux, Windows or using WebStart. So whenever you have a part of your code accessing an outside file (for example, a texture JPG somewhere in you package) you need to replace it with something like the following:

String file = "package/dir/dir/space.JPG";
        URL url = this.getClass().getClassLoader().getResource(file);
        URLConnection conn = url.openConnection();
        InputStream i = conn.getInputStream();
              Image image = BitmapImage.loadImage(i, file); //for images...with Input stream you can read bytes
//OR
             BufferedReader reader = new BufferedReader(new InputStreamReader(i);//for txt files

*BitmapImage is a not a standard class so ignore it here. It reads the bytes out of an InputStream

So what you have to pay attention to is the following

this.getClass().getClassLoader().getResource(file);

I’ve used other ways of getting a hold of the resources but this one worked the best for me. As i understand it, whatever is in the classpath of the class calling this line can be retrived as an URL.

So there it is. I am also beginning to understand this, but i wanted to share the information i gathered with anyone who might need it. Also this is my understanding of ClassLoaders and even though it is very shallow it helped me get my game up using WebStart.

#2

I think if you want it to work on all platforms you will have to replace all the “/” with File.separator 's

#3

Luckily enough, no you don’t - it automatically handles that (file separator issues)

#4

Um, no.

Class loaders exist (1) to allow independant name-spaces for Class data (and related resources) for different parts of a Java program, for instance for dynsmically loaded code modules or mobile code such as when using JNI. and (2) to allow dynamic addition of new class sources to a program at run-time.

Just finding code in a differnt place on differnt file systems cna be done using -classpath on the Java command line.

#5

on another note sometimes people need simple explanations…i read your answer again and I can wipe my *** with it. I’m sure there are experts here that can use it for other things too but simple english works better for newbies. People that understood what you wrote already know what you tried to say.

#6

You do know that Jeff is one of the developers of Java and he works for Sun? – might want to find a way to extract your foot.

#7

he can be whatever he wants all i know is when i read his explanation it was way above my understanding. And my post here was for peeps like me, who need simple hands on explanations. Am i being clear? I hope so…plus i’m a bit tipsy and arrogance always pissed me off. “Um no…”

#8

i’ll gladly modify my post if senor Jeff could support a down to earth explanation of Class loaders.

#9

Look at the PlugIn mechanism in JInput (its actually in JUtils if your looking for the code). It uses dynamic class loaders to load the plug-ins and prevent clash over class names and DLLs. This way if I name my Plugin “Plugin.java” and you name yours “Plugin.java” they can both operate within the same program. The same goes for 2 DLLs both named “pluginjni.dll”. Using independant ClassLoaders with differnt classpaths assures that each plugin loads and links to the right DLL. Furthermore, one plugin can actually use a differnt version of the SAME utility class another plugin does and they will each reference and access the right classes, which can both exist simultaneously within the application.

Any container system, such as an EJB or Servlet server, uses class loaders in order to isolate the seperate applications running within the container.

If you need for any reason to reload classes during run-time, you will also need to isolate those classes in a seperate class loader and create a new class loader to load the new versions of the classes.

When you make a JNI call, the code for passed classes must be loaded by the receiever. Again, this is done with a sepreate class loader in order to avoid a clash with the names and versions of local classes.

Formally, a ClassLoader provides a unique Class name-space associated with a classpath that describes where new classes are loaded from in order to be added to that name space. Thats the definition in proper computer science terms.

If you still don’t get it, then frankly you probably don’t NEED to get it yet. When you need the facilities to solve a real-world problem, it will all become clear to you.

Now as to your attitude…

Ignorance is fine, my friend, thats what Clueless Newbies is for.

Aggressive ignorance though is the pen-ultimate height of stupidity. (Barely superceeded, perhapse, by spelling flames.)

When you wish to learn, by all means come back with your questions. Until then, this really isnt worth any more of my time. I have corrected your misstatement to prevent you from confusing others and thats all I feel a need to do.

#10

By the way.

getClass().getResourceAsStream()

Is the way to get at your resources in a totally installation independant manner.

Thats all you need do so long as the resource is in your classpath or bootclasspath. Also, this formulation will work as written in MIDP wheras getClass().getClassLoader() will not because MIDP does not support dynamic ClassLoaders.

(It gets a bit trickier in an app that actually uses dynamic ClassLoaders. In that case the resource is returned if it is reachable by the
ClassLoader that loaded the class of which the invoker is an instance (the Class returned by getClass()) OR any of its parent ClassLoaders. Prefernce is given to parents first, and the bootclasspath loader is always the root loader with the classpath loader being next down the tree.)

#11

I’m sure you’ll come back to read my response. After all you are human. Although when i read your explanations i start to wonder :slight_smile:

If my english serves me well, Newless Clubies is for n00b’s mostly? I think i also mentioned in my post on top that it is MY understanding of Class Loaders and it might not be correct (I used it for WebStart, jars…). I knew i had it somewhat wrong but i hoped people will correct me. As you did. With a little spice of “Um no”. :slight_smile: I hope we all learned something from this. I did. So as i see class loading is way out there for Java experts, complex applications, and i trust that, as you said jefe, i will really learn it once i really need it. At the moment i need it for Web Start as you probably figured out. I will update my first post and hope it helps someone.

#12

Your biggest mistake was starting out with the statement “This is what class loaders are for.”
That was totally incorrect and neded correction because, as you say, we get a lot of newbs reading these pages. We want to de-confuse them as much
as possible, not the other way around 8)

You got a short, brusque correction there the first time around because, to be pefectly frank, I’m a hugely busy guy right now. That will happen 'round here from time to time as none of us have answering questiosn hre as our primary (or even paid at all) job.

I generally try to take more time to answer when folks ask specific questions because I know then the time spent is of value.

Leave out classloaders, which as I hope I explained are really an entirely different subject, and you werent that far off from what you were really reaching for, which is just a way to load data in an installation independant manner.