我一直认为类路径是理所当然的，即 - 它是 eclipse、maven、ant 等为我处理的东西。很明显，类路径是 java“查找”与应用程序执行/集成的二进制类的地方。
然而，还有一些错综复杂的问题没有被明确描述。
1）java如何在类路径中“查找”类？
2) javac 在查看类路径时如何处理冲突？
3）当 maven/ant 等工具向类路径添加/忽略元素时，“幕后”发生了什么？这些工具只是简单地包装 javac 程序吗？
4）最后：是否有一个针对java的“手动”复杂构建的示例，它不使用现代生成工具——仅用于教育目的——可用？
I've always taken the classpath for granted, i.e. - its something that eclipse, maven , ant , etc handled for me. Its obvious that the classpath is the place where java "looks" for binary classes which are executed / integrated with an application.
However, there are some intricacies which are not clearly described.
1) How does java "find" classes in the classpath ?
2) How are collisions handled by javac when looking into the classpath ?
3) What is happening "under the hood" when tools like maven/ant add/ignore elements to the classpath ? Do these tools simply wrap the javac program ?
4) Finally : is there an example of a "manual" complicated build for java, that doesnt use the modern generation of build tools --- just for educational purposes -- which is available ?
发布评论
评论（2）
类位置只是按完全限定名称分层。获取字节流取决于后备存储，无论它是在文件系统中（仅读取文件）、在 jar 中（读取 zip 条目）还是在 DB 中（获取字节）。由类加载器将 FQN 转换为字节流。
取决于实现。通常，类路径上的第一个获胜，但这不是必需的，它只是最简单的。
或多或少。
你的意思是像一个基于旧的
Makefile的文件？还是一只大蚂蚁？不确定你在问什么。它主要是构建类路径（这很简单）并创建工件。Class location is just hierarchical by fully-qualified name. Getting the byte stream depends on the backing store, whether it's on the filesystem (just reads the file), in a jar (reads the zip entry), in a DB (gets the bytes). It's up to the classloader to translate the FQN to the byte stream.
Implementation-dependent. Generally first on the classpath wins, but that's not a requirement, it's just the easiest.
More or less.
You mean like an old
Makefile-based one? Or a big ol' Ant one? Not sure what you're asking. It's mostly building up classpaths, which is easy, and creating artifacts.man javac和man java可以回答您的大部分问题。3）他们只是简单地包装它
man javacandman javaanswer most of your questions.3) They do simply wrap it