Java class loaders: a good interview question?
Tuesday, October 23rd, 2007Java is widely regarded as easier to develop for than C++, etc. I tend to agree with that. In C++ it’s easy to find some nasty question to separate the decent developers from the amateurs (for example, ask them how a vtable works).
But even Java has some “low-level” lurking features which only the better Java developer understands. One of these is the class loader. Java normally has a class loader which will search the CLASSPATH environment variable, and/or any JAR file specified, when asked to load a given class. But this can be replaced – and often is.
For example, in Eclipse, each plugin has its own class loader. This means that plugins cannot conflict by having two classes with the same name; it also means that Eclipse can enforce a clear dependency tree on the plugins (the classloaders interact to allow downstream plugins to load classes from upstream plugins).
More or less the same applies to J2EE environments on web servers. Again, this is done so that the different… errr… web thingies have separate environments.
Still other classloaders – such as for good old Java applets – load classes dynamically across a network.
I’m hardly an expert on this stuff, but it seems I know more than some. The vendors of a library I wanted to use load their configuration files using getResourceAsStream(), which is delegated to the class loader. I explained this wasn’t very convenient for people whose class loaders didn’t refer to useful directories. They said that I should just edit the CLASSPATH and insisted that “all Java environments have a CLASSPATH” despite me repeatedly telling them it’s not true. For Eclipse and web applications, at least, the CLASSPATH is irrelevant.
The library is popular and otherwise appears well-designed and reasonably well-written.
All of which makes me think that any decent Java developer would be able to answer an interview question such as “what are some advantages of using a different class loader?” as a good filter at interview for Java developers.
Having said that, I’ve always been rubbish at interviewing so don’t listen to me.
