what about it looks dangerous to you? sure, it ties you to certain versions of the API, and forces you to re-test your code every time a new version of the API is released, but other than that i see nothing platform-specific about it at all. using it would be a burden on testing and maintenance, but honestly, i see little real danger in it. i'd be interested in hearing what about it scares you.
sure, it ties you to certain versions of the API, and forces you to re-test your code every time a new version of the API is released, but other than that i see nothing platform-specific about it at all.
WTF? Every time you write a J2SE application, you're tied to a specific version of the API Specification. There is no need to test (in theory) since reverse compatibility is "guaranteed". This case is no different. Though what has been suggested is a very nasty hack that I've seen attempted 43 trillion times, and I've seen fail 43 trillion times. This is the whole reason why java.lang.ClassLoader exists. Check it out http://java.sun.com/j2se/1.5.0/docs/api/java/lang/ClassLoader.html [ July 07, 2005: Message edited by: Tony Morris ]
what are the most common ways in which this approach fails? how does your recommendation for using java.lang.ClassLoader avoid those failures, and how does it answer the original question concerning adding items to the system classpath? what if i want to modify the behaviour of the default class loader?
I've used the ClassPathHacker in the extension mechanism in my Wiki to add Fit, UDB and other packages. No problems to date. I'm using a method that Sun didn't intend me to use, but it's the same one they use so I'd guess it's pretty well tested. I'm emotionally prepared for it to fail one day and force me to do something trickier with ClassLoader, but if it ain't broke ...
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
It's not terribly hard to just use an instance of URLClassLoader, which makes it easy to supply your own classpath at runtime. But that said: what Stan's showing is perfectly OK for test harnesses and other internal code, but it would indeed be scary to ship it unless the user was definitely not able to replace the JVM.
But Apache is working on a JVM and maybe some day others will develop something like that too. These methods will not be available there. I'd prefer the supported path of using my own classloader. Why would I use a hack when I can use a perfectly supported method.