• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Add classpath programmatically

 
Hui Ge
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Is there anyway we can add classpath programmatically?
I tried something like this:

String jarFile = "c:\\tmp.jar";

Properties sysProp = System.getProperties();
sysProp.list(System.out);
String sep = sysProp.getProperty("path.separator");
String javaClassPath = System.getProperty("java.class.path");
if (javaClassPath == null || javaClassPath.trim().length() == 0) {
javaClassPath = jarFile;
}else {
System.out.println(javaClassPath);
javaClassPath = javaClassPath + sep + jarFile;
}
System.setProperty("java.class.path", javaClassPath);
sysProp = System.getProperties();
System.out.println(sysProp.getProperty("java.class.path"));
 
Manuel Moons
Ranch Hand
Posts: 229
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you want to dynamically load classes you should write your own classloader. You will not be able to change the classpath.
[ July 07, 2005: Message edited by: Manuel Moons ]
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, you can but not in a supported way. I'd probably recommend the class loader approach instead.
 
Manuel Moons
Ranch Hand
Posts: 229
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ouch, so I was wrong about being able to add classes to the classpath. But I'd never use this piece of code, to dangerous for me! Has it ever been tested on multiple platforms? Linux, Windows, Mac?
 
M Beck
Ranch Hand
Posts: 323
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Tony Morris
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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 ]
 
M Beck
Ranch Hand
Posts: 323
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ...
 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24212
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Manuel Moons
Ranch Hand
Posts: 229
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok, so you haven't had problems until now.

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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic