当它遍历Class Path时，我如何跟踪Java实际上在寻找的东西？
Java实用程序是如何开始启动一堂课的过程，以“泄露其胆量”，因为它试图加载班级时正在做什么？
特别是，它试图访问什么文件路径，而只是发现它想要的任何内容，至少在解释给出的规范时，它不存在什么？有一种方法可以获取这些信息，但我现在找不到。
请注意，这是Windows 10上的Java版本“ 1.8.0_333”。
我尝试了通过-H和-X标志知道的每个标志正如-x帮助输出警告一样，已删除的标志已被删除。因此，我肯定希望有一个操作系统来弄清楚这一点！
你可能会问为什么？有什么？你想做什么？好吧，这就是这个问题文本的大部分。机智：
作为Java的早期用户之一（我从1.1开始），从90年代开始，我遇到了一个问题，我在Linux上为我的公司编写的应用程序套件到MS Windows，我让它正常工作通过使用Cygwin。在此过程中，同样的问题出现了，我很生动地记得，找到了一种使Java Launcher阐明哪些文件规格的机制 - 路径 - 它实际上是在搜索适当的类时使用的。通过使用此功能，我发现班级路径被错误地指定了，并且通过一些实验，我可以可靠地工作。现在我需要再做一次！
我使用的这个标志对于弄清楚文件规范格式classPath（我们在这里不是在这里谈论的半龙）非常有帮助。经过几个小时的我希望是合理的狩猎，我想知道该功能是否在某个时候被删除了？要么“我正在寻找错误的事情”。哎呀，由于来源可用（我认为！），也许有些勇敢的灵魂被黑客入侵了爪哇实用程序做这样的事情？
可能有助于了解，对于我为公司编写的此应用程序，这是一个主要目标配置文件以告知代码有什么不同。这并不容易弄清楚，但是有了这个标志，也不那么困难。
但是，不幸的是，我不需要这些知识，因为这些年前我已经弄清楚了这一切，而且显然，这种小小的知识内核今天很难找到。或者，它不再与现代版本有关。
我认为这与实际问题无关，但这可能有助于人们认为他们是否了解情况：当前情况是我在Windows 7上可以将此软件的功能齐全地安装为比较如何在Windows 10上配置内容（希望年轻）。 Windows 7正在运行非常现代的Cygwin安装，几乎是最现代的Java - 与上周在Windows 10盒子上的新安装相反。 （新框上的一切都是明亮而闪亮的。）
几乎相同但功能齐全的Windows 7系统上的classPath的所需格式是：
CLASSPATH="C:/opt/OurInstallationDir/lib"
就是这样。
该值在几个地方拾取，因为后来代码需要启动Java本身来做一些不寻常的事情。但是，完成所有操作的Java命令是从C程序启动的 - 对此问题而言并不重要 - 而是C程序（在Cygwin下编译，但可以从任何Windows环境中运行）有助于确保确保Java环境的保护（策略文件内容等）在进入Java之前，否则拒绝。而且Windows 11上的该程序启动Java很好，它只是给它一个class路径，显然，即使文件在那里，它们应该在哪里等等
。命令行。如果它不仅仅是点，则没有指定类Path的版本似乎可以使用。唯一有效的是在开始和使用“ -cp”时在 /lib目录中。 ...但这只是出于许多原因而飞行！更清楚，我尝试使用/cygdrive/c/以及我想到的其他任何东西都尝试逆转斜线。但是，至少我们知道，如果您在目录中并使用-CP，它将找到并启动该程序。因此，Java没有错，只是指着Java实用程序。
再次：如何开始启动课程的Java实用程序，以“泄露其胆量”，因为它正在尝试加载课程时正在做什么？
How is the java utility that begins the process of launching a class told to "spill its guts" on what it's doing as it tries to load classes?
In particular, what file paths is it TRYING to access, only to perhaps discover whatever it's looking for is not there, at least as it interprets the specification given? There was a way to get that information, but I can't find it now.
Note that this is Java version "1.8.0_333" on Windows 10.
I've tried every flag known to me, via the -h and -X flags, and I strongly suspect what I'm looking for is (was) an X flag that's been removed, just as the -X help output warns. And so, there must be an OS way to figure this out, I sure hope!
You might ask why? Whatever for? What are you trying to do? Well, that's the bulk of this question's text. To wit:
As one of the very early users of Java (I started with 1.1) way back in the '90s, I had an issue moving an application suite I'd written for my company on Linux to MS Windows and I got it working by using Cygwin. Along the way, this same sort of issue came up and I quite vividly recall having found a mechanism for getting the Java launcher to articulate just what file specifications - paths - it was actually using in searching for the appropriate class. And through using this, I found that the CLASSPATH was being specified incorrectly, and with some experimentation, I got it working reliably. Now I need to do that again!
This flag I'd used was immensely helpful in figuring out just what the file specification format CLASSPATH needed to be (we're not talking semicolons here) this combination of OS, Java, and Cygwin. After some hours of what I hope was reasonable hunting, I'm wondering if this capability has been removed at some point? Either that or "I'm looking for the wrong thing." Heck, since the source is available (I think!), maybe some brave soul has hacked the java utility to do such a thing?
It may help to understand that for this application I wrote for my company, it was a major goal to have the source work pretty much the same on all Windows and Linux / Unix systems (and at the time, macOS), and just use a configuration file to tell the code what's different. And that wasn't easy to figure out, but with this flag, it wasn't that hard, either.
But, unfortunately, I haven't needed this knowledge since I figured it all out all those years ago, and apparently, this little kernel of knowledge is very hard to find today. Or, it's no longer pertinent to the modern version(s).
I don't think this has anything much to do with the actual problem, but it may help in people's thinking if they understood the scenario: The current situation is that I have a fully functional installation of this software on Windows 7 to use as a comparison for how to configure things on Windows 10 (and hopefully younger). The Windows 7 is running a pretty modern Cygwin installation and very nearly the most modern Java - just a sub-version away from the new installation from last week on a Windows 10 box. (Everything's bright and shiny new on the new box.)
The required format for CLASSPATH on the nearly identical but fully functional Windows 7 system is:
CLASSPATH="C:/opt/OurInstallationDir/lib"
And that's it.
This value is picked up in several places as the code later needs to launch Java itself to do some unusual things. However, the java command that gets it all going is launched from a C program - not that that matters for this problem - but the C program (compiled under Cygwin, but perfectly runnable from any Windows environment) helps ensure that the Java environment is secured (policy file contents and so forth) before getting into Java, else it refuses. And this program on Windows 11 launches Java just fine, it's just giving it a CLASSPATH that isn't useful, apparently, even though the files are there where they should be, etc.
Configuring things as before just doesn't work, even from the command line. No version of specifying CLASSPATH seems to work if it's more than a dot; the only thing that works, is being in the /lib directory when starting and using "-cp ." ... But that's just not going to fly for so many reasons! To be a little more clear, I've tried reversing the slashes, using /cygdrive/c/, and whatever else I could think of. But, at least we know that if you're in the directory and use -cp, it will find and launch the program. So, there's nothing wrong with the Java, just pointing the java utility at it.
Again: How is the java utility that begins the process of launching a class told to "spill its guts" on what it's doing as it's trying to load classes?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您在JVM上使用此构造：
我能够确认Java所使用的不仅是我的类Path，而且可以通过上述使用“内部”。
它回应了我正在做的事情，以及它在某种程度上做的事情，这使我有了洞察力来检查所有内容。 Java本身（如果它都安装在它认为具有链接的位置），并且它自己的提取返回系统磁盘规范，则它根本不起作用。
从中，我发现Windows上的Java不会带有链接的class Path！
只需确保将整棵树“从驱动器的顶部”指定为工作。如果不是，那就不会。
现在使用上述语法愉快地工作。
这与我在Windows上看到的所有其他应用程序都大不相同。但是，嗯，是爪哇！
这确实来自一个来自 Mark Rotteveel 的指针。 /stackoverflow.com/questions/9921081/how-to-track-when-class-is-loaded-and-loaded-and-destroyed-in-jvm">如何跟踪何时在JVM中加载和销毁课程？我学会了如何获取目前使用的JVM支持的所有选项列表。我认为所有Java开发人员都应该意识到这一点，因此要感谢Mark。
You use this construct on the JVM:
I was able to get confirmation of what Java was using, not only for my CLASSPATH, but "internally" by using the above.
The fact that it echoed back both what I was doing and what it was doing somehow gave me the insight to check everything about it. Java itself doesn't work (at all) if it's installed in a location that it thinks has a link in it, and it's own fetches go right back to the system disk specification.
From that I found that Java on Windows won't take a CLASSPATH that has a link in it!
Simply ensuring that the whole tree was specified "from the top" of the drive it's on works. If it's not, it won't.
It's now working happily using the syntax noted above.
This is quite different from every other application I've seen on Windows. But, well, it's Java!
This really came from a pointer from Mark Rotteveel who commented above about this article: How to track when class is loaded and destroyed in jvm? And therein I learned how to get the list of all the options the presently in-use JVM supports. All Java developers should be aware of this in my opinion, so thanks to Mark for that.