We Keep Coding

How do I track what java is actually looking for as it traverses CLASSPATH?

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?

You use this construct on the JVM:
java -XX:+TraceClassPaths -cp "C:\opt\SomeDirectory\lib" myClass
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.

Why does the order in which Netbeans loads Java Libraries cause errors sometimes? and how do I avoid it?

Basic background data: Windows 7, Netbeans 8.0.2, LWJGL 2.9.3, Slick Util.
The rest of the code is my own.
So, periodically, I was having what I thought was a bug, that caused my program to run within the IDE, but would fail when I used "Clean and Build" on the project.
Today, when it happened again, I decided to get to the bottom of it. So, taking a copy of the whole project folder, that was working and otherwise identical, and replacing 1 file at a time, and testing it, I was able to narrow it down to the /nbproject/project.properties file.
Every other file could be replaced and the problem persisted. Replace ONLY this file, and the problem went away. So then I loaded up both files and compared them side by side (using the Netbeans "Diff to..." feature) and narrowed it down to the following lines:
javac.classpath=\
${libs.LWJGL-2.9.3.classpath}:\
${libs.0-Slick_Util.classpath}:\
${libs.0-Loaders_v03.classpath}:\
${libs.0-Text2D_v03.classpath}:\
${libs.0-Foundation_v04.classpath}:\
${libs.0-Abstracts_v04.classpath}
Now this code, looks like it is telling the compiler the ORDER in which the libraries should be loaded (I may be wrong).
With that in mind, I decided to test it. I copied this block from the working file, to the non-working file, and it worked just fine. The working code btw is this:
javac.classpath=\
${libs.LWJGL-2.9.3.classpath}:\
${libs.0-Slick_Util.classpath}:\
${libs.0-Foundation_v04.classpath}:\
${libs.0-Abstracts_v04.classpath}:\
${libs.0-Loaders_v03.classpath}:\
${libs.0-Text2D_v03.classpath}
The only differences, you may notice, is the ORDER. Continuing my test, I went into the non-working project's Library properties page, and simply re-ordered the libraries to match the working list. PROBLEM WENT AWAY! If I simply moved the Foundation and Abstracts libraries down in the list, the PROBLEM CAME BACK!
I must have tried a dozen different order combinations, and got about 2/3 that failed, and 1/3 that worked. The ones that worked all involved Foundation and/or Abstracts to be near the top.
Why is this happening? How can I know what order my libraries need to be loaded to avoid the error?
The error btw is this:
F:\Dropbox\2-Documents\4-Java Programming\Library\0-LoadingScreen_v04-Copy\src\A_Library\Test_LoadingScreen.java:94: error: cannot find symbol
Lib_Foundation .setConfigLocation(configLocation);
symbol: method setConfigLocation(String)
location: class Lib_Foundation
Any information that can help me avoid this problem in the future will be appreciated.

It would appear that either “Loaders_v03” or “Text2D_v03” contains its own version of Foundation, including an incompatible Lib_Foundation class. A classpath is searched in order, so your current solution—reordering javac.classpath—will always work, assuming NetBeans doesn’t mess with it the next time you make any change to your project.
Whether that will break Loaders and Text2D depends upon how well Foundation adheres to object-oriented design: public classes and their public members are never supposed to be changed or removed in successive versions. (That is why 20-year-old code written for Java 1.1 will still compile in Java 8.)

How do I run/debug a Netbeans Platform application with a specific Working Directory?

Goal
I'm currently developing an application in Netbeans using the Netbeans Platform on Windows (a cross-platform solution would be wonderful but something hacky for Windows if required is fine for now). The application communicates with a native C++ DLL through JNA. The DLL sits in a specified directory which I cannot control or change - say C:\DLL.
The DLL itself loads some files for reading in values etc. but it does this using relative paths. So it requires the "current" directory to be C:\DLL. Again, this is something I can't change in this project. The DLL is something I have to communicate with as is (unfortunately).
Problem
For regular JAVA applications I've had the option in Netbeans to set the working directory of the launched application like shown below:
http://i.imgur.com/3HuQKS8.png
But in the Netbeans Platform framework/template there are no such options. For the most part it looks like Netbeans just makes the directory of the current file I have focused in the Editor pane to be the Current Working Directory.
So how do I go about doing this? I might be able to run the application through a shortcut that sits in C:\DLL but this doesn't help when I'm debugging the application through Netbeans.
I want to know how I can run/debug this Netbeans Platform application with the current working directory set.
Clarifying Netbeans Platform
The Netbeans Platform is an application framework of sorts. Has a pre-defined structure based on "modules" that interact to form the full application. The whole thing is hosted inside the Netbeans Platform environment which provides each of your modules with tabbed/docking windows. Kind of nice to develop larger applications.
More information here: https://netbeans.org/kb/trails/platform.html

I've resorted to using chdir as #technomage (I can't seem to upvote his/her comment with my current account status) has also suggested.
To do this, I used the following piece of code before I load up my C++ DLL through JNA.
NativeLibrary clib = NativeLibrary.getInstance(null);
int result = clib.getFunction("_chdir").invokeInt(new Object[]{"<PATH GOES HERE>"});
Source: https://www.java.net/node/643965#comment-821128
You can also check the result by checking the result variable. Should be zero if everything went well.
I am not quite sure why null works for NativeLibrary.getInstance. The documentation doesn't say anything specifically about this and I haven't been able to glean anything from the source here: https://github.com/twall/jna/blob/master/src/com/sun/jna/NativeLibrary.java - But passing null does seem to get you the default libc or equivalent for your platform.
Note also that I had to add an _ (underscore) to the function name. This has to do with how function calls get mangled when compiled on Windows. As far as I know, this isn't required on other platforms, but I don't have the ability to test this right now.
Since I was unsure about whether my call was actually working, I did the following first:
Function f = clib.getFunction("_chdir");
This returns a function "pointer" f that you can trace/debug to see if you have a valid reference. Luckily, in my case, all I had to do was add the underscore as was suggested in the source link above.
After this call to chdir, the C++ DLL I need to access has been happily accessing files relative to the location specified in chdir.

Java Updater Game Launcher

I'm trying to make a Java game updater launcher for my game. Similar to how minecraft works. However, minecraft has only a few .jar's to download wheras I would need to redownload all of my game assets. Is there any easy way for Java to check a file for which operations need to be taken? One idea I had was using .7z files since those can be compressed really small. That wouldn't work though because I can't seem to get Java to hook onto 7zip operations. Another idea I had was if it determined if an update was needed it would read a file with a set of commands like this:
remove assets/models/malecharacter.obj
add assets/models/alien.obj
...etc
But I'm not sure this is very efficient and I am also not able to find a lot of help with managing files. Any help and ideas would be appreciated.

I made a Game Launcher in Java recently, I still have a few problems to solve like how to update the launcher itself.
Anyhow, for the game updates/versions I just have a "versions" folder with a folder for each downloaded version, it might not be the prettiest of solutions but it works for multiple versions and it's easy to make.
My launcher checks a URL from my dedicated server which has all available versions, which I call it versionlist, then since the versions folder on the server obeys a path order I can call any versions which are in the versionlist. I download the selected version and extract it to a separate version folder on the user's pc.

How to put java code into an application format?

I made a simple command-line based game in java, only two classes (using Eclipse). But I was wondering how I can make this into a usable application for anyone, without running it through eclipse (ie send it to someone who knows nothing about java but would still be able to play the game)? Thanks!

You want to create a runnable jar file.
Eclipse has an option for this in the "Export" menu. For more options, search for "executable jar file" here or on Google.
You want to make sure that you also include any jar files your code depends on as well (Eclipse can also do that for you).
Users will be able to start this by double-clicking on the file on most platforms. If you need better integration (such as a custom icon), you will need to bundle it up further into an OS-specific executable. But for starters, a simple runnable jar works fine.
send it to someone who knows nothing about java
You need to get them to at least install the Java runtime on their machine (if it is not already there).

Just to be clear, "command-line" and "knows nothing about java" are probably not going to work very well for you given that:
java is OS agnostic, therefore, if you send (presumably) a jar file to say...your grandma and she has a mac and you have a PC chances are her getting it to work is not going to be "out of the box easy" so to speak.
Left with this, I think you have a couple choices...first off, you do need to package your classes - a runnable jar will work fine. Aside from that, you will most likely have to build OS specific scripts (batch scripts for Windows, shell scripts for unix, etc.) and you will have to hand these out with your jar file. That being said, the intended user will still need to have java installed, and the batch scripts themselves are not likely to be trivial endeavors.
Your next option would be to use JNLP. However, I don't think JNLP has a command line mode, so you will likely have to simulate a console with something like a JTextArea.
As far as I see it, your last option it to use one of the many products (not sure if there are any free ones) that package java into native code. I think Exe4j is one such example - but, like I said, I am not sure if there are any free ones and I am not sure how hard they are to use.
Best of luck, and if you can't get your jar to work you should probably move that to its own question.