Hmmm...thanks for your response, and perhaps I don't understand you fully, but if I do, I respectfully think there must be more to it than that. You are saying that one of the reasons is so you can dynamically set your classpath?! That doesn't make sense to me. For one, I don't see that this gains you much (not enough to warrant writing your own class loader), and for two, (for the most part) the way you launch a java app makes this advanatge dubious. The other thing you mentioned about encrypting your classpath...I saw that proposed in another thread and it was rejected as a good use for a class loader. I can't decide if it is or not, but it does seem to me that your class loader itself would have to be unencrypted and that the unecrypted class loader could be "decompiled" and then a hack could see what key you were decrypting with and use that same key. Am I missing something? There must be a more compelling reason to write your own class loader.
Let me take a crack at answering this question... My knowledge on the subject is superficial so don't take anything I say too literally. Here goes... Many of the IDE's such as JBuilder, etc use custom classloaders to encrypt the .exe file so that no one can run them. Once you purchase the product, however, you receive a key. This key is used to decrypt the .exe file so that the .exe can run. There's a pretty good discussion of this in the Core Java 2 (Volume II) book on ppg 862-870.