Originally posted by Stan James:
In short, they read the bytecode produced by the compiler and create an instance of Class in memory.
While that's a concise explanation of what they do, I think one points needs to be elaborated upon: where the classloader gets those bytes that make up a class. For a desktop application, that would be the classpath. For a web app, that would be the WEB-INF/lib and WEB-INF/classses directories. For an
applet it would be a directory on the web server where the applet is hosted, and the access happens through HTTP, not file I/O like with the other above-mentioned classloaders.
In addition there are specialty classloaders that do not read class files, but create bytecode themselves, e.g. the
CompilingClassLoader or
this one, both of which read
Java source code. Or
this one, which constructs classes in memory through an API, where nothing ever gets stored on disk.
Another application would be to use them in conjunction with a SecurityManager in order to restrict what certain code is allowed to do. This is sometimes used if an application can be extended by user-supplied plugins (about which I've
written here, if I may strut my own stuff).
[ April 12, 2007: Message edited by: Ulf Dittmer ]