什么'；Eclipse和javac的构建功能有什么不同？

我发现Eclipse中的项目有自己的类路径

如果我使用maven创建一个新的web项目

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

当我打印结果时， 我发现类路径包含G:\newtool\workspace\springmvc\target\classes

谁能解释它背后的原理。为什么类路径是这个目录。 Eclipse的构建功能与命令javac-classpath相同吗

我发现了另一个问题

public class KnightMain {
public static void main(String[] args) throws Exception {
    System.setProperty("java.class.path","G:/newtool/workspace;G:/newtool");
    ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext("knight.xml");
    Knight knight = context.getBean(Knight.class);
    knight.embarkOnQuest();
    String s[] = System.getProperty("java.class.path").split(";");
    for (String string : s) {
        System.out.println(string);
    }
    context.close();
}

}

虽然我将类路径设置为knight.xml不存在的其他目录。但是ClassPathXmlApplicationContext最终找到了它。为什么

System.setProperty("java.class.path","G:/newtool/workspace;G:/newtool");

没有区别。尽管打印结果是：

G:/newtool/workspace G:/newtool

---

两种不同的工具，两种不同的概念

首先，eclipse有自己的java编译器。它没有以任何方式使用javac。eclipse编译器使用的类路径出乎意料地是您告诉它的

换句话说：当您创建eclipse项目时，您需要配置它的构建路径。生成路径决定了哪些库、其他项目。。。应该是进口的，出口的。。。等等

然而，当您像shell一样打开命令并直接调用javac时，类路径基于您在那里进行的设置；比如打电话

javac -classpath /some/directory/with/classes:/some/bla.jar

或者在您的例子中：您使用的是maven，它附带了预定义的规则、项目依赖项等等。因此，那里的类路径取决于maven应用于“JavaWeb项目”的约定/规则。因此：如果你想了解maven为你做了什么：你必须研究maven文档中你正在使用的特性

编辑：我认为你实际上所尝试的是行不通的。我认为这个特定的系统属性更像是一个“只读”值。意思：你可以用它来理解当前的类路径。但是写入属性将而不是更改当前运行的JVM的类路径。

---

事实上，这很有道理：如果任何一段java代码都能动态地更改类路径，那么到处都是“安全问题”！因为这将允许您完全改变JVM从何处加载其类。

两种不同的工具，两种不同的概念

首先，eclipse有自己的java编译器。它没有以任何方式使用javac。eclipse编译器使用的类路径出乎意料地是您告诉它的

换句话说：当您创建eclipse项目时，您需要配置它的构建路径。生成路径决定了哪些库、其他项目。。。应该是进口的，出口的。。。等等

然而，当您像shell一样打开命令并直接调用javac时，类路径基于您在那里进行的设置；比如打电话

javac -classpath /some/directory/with/classes:/some/bla.jar

或者在您的例子中：您使用的是maven，它附带了预定义的规则、项目依赖项等等。因此，那里的类路径取决于maven应用于“JavaWeb项目”的约定/规则。因此：如果你想了解maven为你做了什么：你必须研究maven文档中你正在使用的特性

编辑：我认为你实际上所尝试的是行不通的。我认为这个特定的系统属性更像是一个“只读”值。意思：你可以用它来理解当前的类路径。但是写入属性将而不是更改当前运行的JVM的类路径。

---

事实上，这很有道理：如果任何一段java代码都能动态地更改类路径，那么到处都是“安全问题”！这将允许您完全更改JVM加载其类的位置。

JVM使用java.class.path属性来定位要加载的类和JAR文件。此系统属性对于大多数可用JVM（包括Oracle和IBM实现）都是通用的。此属性由默认类加载器使用，但不是所有自定义类加载器都使用。您可以实现自己的类加载器，它忽略java.class.path，并使用其他一些属性来定位特定于加载器的包。Eclipse就是一个例子。Eclipse core有一个自定义类加载器，它不使用java.class.path。

JVM使用java.class.path属性来定位要加载的类和JAR文件。此系统属性对于大多数可用JVM（包括Oracle和IBM实现）都是通用的。此属性由默认类加载器使用，但不是所有自定义类加载器都使用。您可以实现自己的类加载器，它忽略java.class.path，并使用其他一些属性来定位特定于加载器的包。Eclipse就是一个例子。Eclipse core有一个自定义类加载器，它不使用java.class.path。

谢谢！在我编辑后，你能帮我看看这个问题吗？因为我发现了另一个问题。对不起；我不是maven/spring本身的专家；恐怕我无法帮助您完成这一特定部分。您可以忽略Spring。ClassPathXmlApplicationContext类将在类路径中找到xml。我对类路径没有更改的原因感到困惑。请参阅我的更新答案。我想你想做的是。。。一般来说，GhostCat所说的是正确的：默认类加载器在构建JVM时初始化，并且在初始化期间只读取一次java.class.path。如果以后更改属性，则不会影响默认加载程序。如果在修改属性后创建另一个加载程序，则它取决于加载程序实现。现在，我不是Spring方面的专家，但我认为类似的规则也适用。如果您可以在更改属性后重新加载整个spring框架，这可能会起作用。谢谢！在我编辑后，你能帮我看看这个问题吗？因为我发现了另一个问题。对不起；我不是maven/spring方面的专家