eclipse的classpath(build path)和classpaht几种设置的方式

原文:https://www.cnblogs.com/straybirds/p/8401998.html

1，默认eclipse有自己的classpath的路径并不是环境变量中配置的classpah.

2，eclipse的classpath每个项目不同，一般是在工作区的当前项目的class下。

2.1，可以通过下面代码查看：

 System.out.println(System.getProperty("java.class.path"));  

2.2也可以通过eclipse菜单查看：

Run→Run Configures...在classpath选项卡下就会发现，Eclipse默认是没有导入系统的CLASSPATH路径的

3，可以通过eclipse添加自己指定的classpath路径：

1,在工程上右击→Properties-java build path，在Libraries选项卡下，Add External Class Folder...，选择自己需要导入的类文件夹
2,完成之后你会在工程下面看到Referenced Libraries

4，修改classpah的几种方式：

1，当然就是直接在环境变量设置
2，在dos中使用set classpath=路径
3，在dos使用java -cp 路径
（cp是classpath的缩写，dos环境设置的只是临时的，窗口关闭也就失效了）

3，在代码中设置System.setProperty(“java.library.path”,“classpath路径”)

但是在代码修改有个问题：

那就是classpath对应的是系统类加载器（AppClassLoader)，那就是在代码运行前系统类加载器已经实例化，也就是classpaht已经被确定了。
那么指定的路径可能并不会起作用，路径下的类会出现找不到的异常。

虽然修改了classpath的值，但是类加载器已经启动了，再修改其classpath的值已经对那个已经启动的类加载器或者说是jvm不起作用了。

 

使用java代码动态修改classpath

google关键词:“setting the classpath at runtime” 在此我贴出一些解释
1）The classloader represents (part of) a namespace, and two otherwise identical classes loaded by different classloaders are not “equal”. Which means there are a few dangers lurking in classloading, notably singletons suddenly not being so single anymore as well as casts failing unexpectedly.
2）Classloaders (should) work on a pattern of delegating to the “parent” loader before attempting anything themselves (see above).
3）Class loading and linking are two distinct steps (even though example implementations of a classloader such as may be found in blog posts/online Java articles, will combine the two into one for simplicity) Therefore you should not assume that if a parent loader has loaded a class it has also loaded all dependencies …
4）All this means there is a problem if class A loaded by loader A references a class B which neither loader A nor any of its parents can load: class A may load just fine in loader A but at the point of use it fails because loader A cannot fully resolve (link) it.
5）And you should make sure that your classloader loads classes in a synchronized manner otherwise the issues hinted at in step #1 can leap from duplicates due to classloaders to duplicates from multiple threads using the same classloader as well…