Java 编译、包和相对路径

发布于 2024-12-12 11:27:17 字数 591 浏览 0 评论 0原文

在使用 jGRASP 时,我注意到包中程序的输出与正常情况略有不同,特别是程序名称似乎是从类顶部开始的相对路径。

例如,对于包含语句 package ch01.stacks; 的 Java 程序,编译输出如下所示:

 javac -g ch01\stacks\ArrayStack.java

运行输出也类似。

我想知道是否有一种相对简单的方法可以在其他程序(例如 Notepad++ 或 gedit)中模拟这种行为,用户可以在其中设置脚本来编译程序。

编辑:我很抱歉,我忘了提及我正在谈论的编译脚本本质上是传递给 javac 的程序文件名。我宁愿不使用绝对路径,如果可能的话,我希望我的脚本以类似于 jGRASP 的方式工作。

为了进一步澄清当前的问题,对于我当前的脚本,我相信包结构给我带来了问题,因为它是在程序的当前目录中编译的。我正在寻找一种方法来相对编译我的Java程序的包结构。

也就是说,是否有任何方法可以检测编译所需的顶级目录(上例中的 ch01),而不必深入程序寻找 package

While using jGRASP I noticed that the output for programs in packages was slightly different than normal, specifically the program names appeared to be relative paths starting from the top of the class.

For example, for a Java program that includes the statement package ch01.stacks;, the compile output looks like:

 javac -g ch01\stacks\ArrayStack.java

and the run output appearing similarly.

I was wondering if there was a relatively straightforward way to simulate this behavior in other programs such as Notepad++ or gedit where users can set up scripts to compile programs.

EDIT: I apologize, I forgot to mention that the compilation scripts I'm talking about are essentially the program filename passed to javac. I would rather not use absolute paths, I would like my scripts to work in a way similar to jGRASP if at all possible.

To further clarify the issue at hand, with my current scripts I believe the package structure is giving me issues, since it is compiling in the current directory of the program. I am looking for a way to relatively compile my Java programs with respect to package structure.

That is, is there any way to detect the top directory needed for the compile (ch01 in the previous example) without having to dig through the program looking for package?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

沉睡月亮 2024-12-19 11:27:18

我仍然不确定你想要什么,这不适合评论。

jGRASP 的行为完全是正常行为。 Java 类文件(源文件和编译类)都位于反映其包名称的文件层次结构中。任何 Java IDE 或命令行构建工具 (AntMavenGradle 等等)都理解这一点,并且相应地表现。

如果您真的希望重新发明这些轮子,您的代码也需要这样做。如果您的 Java 源代码确实不存在于规范的包/文件层次结构中,那么是的,您需要询问每个文件的 package 声明的源代码,并将编译后的 .class 文件复制到适当的目录中。

javac-d 选项设置输出目录。编译后的类将根据其包名称放置在正确的位置。但是,在编译时,所有导入都必须在类路径上可用,无论是您自己的类还是第三方库的类(通常在 jar 中)。

简而言之:不要做你所要求的事情。我想不出这样做的充分理由。 (这并不意味着没有任何充分的理由,但我......非常怀疑。)甚至可以使用相对固定的 make 文件来构建 Java 项目;一个比你提出的更好的解决方案,但仍然是一个可怕的想法。

注意:当您运行 Java 应用程序时,类文件必须出现在预期的层次结构中,无论是否打包在 jar(或 war)中文件或文件系统上。

I'm still not sure what you want, and this wouldn't fit into a comment.

jGRASP's behavior is precisely normal behavior. Java class files, both the source, and compiled classes, live in a file hierarchy that mirrors their package names. Any Java IDE or command-line build tool (Ant, Maven, Gradle, whatever) understands this, and behaves accordingly.

If you genuinely wish to re-invent those wheels, your code needs to do the same. If your Java source seriously doesn't live in the canonical package/file hierarchy, then yes, you'll need to interrogate the source for each file's package declaration, and put the compiled .class file into the appropriate directory.

javac's -d option sets the output directory. Compiled classes will be placed in their correct location based on their package name. However when compiling, all imports must be available on the classpath, whether your own classes, or those of a third-party library (generally in a jar).

In short: do not do what you're asking about. I can think of no good reason to do so. (This doesn't mean there aren't any good reasons, but I'm... highly skeptical.) It's even possible to use relatively-canned make files to build Java projects; a better solution that what you're proposing, but still a horrible idea.

Note: When you run a Java application, the class files must be present in the expected hierarchy, whether packaged in a jar (or war) file, or on the filesystem.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文