Carey Brown

Create a "manifest.txt" file.

Manifest-Version: 1.0
Main-Class: MyProgram.class

Create jar with manifest: jar cmf manifest.txt MyProgram.class Other.class

Did you add a manifest to the jar file?
Are you double clicking the jar file?

You've built a playpen directory inside of "Program Files", if this isn't what's causing you grief it's still a big no-no.

Evan Bonno wrote:New problem... Prime.class,RunningGame.class : no such file or directory

Use a space instead of the comma.

Nope, my bad, Java should have capital 'J'.

You put in Java with a capital 'J', don't know if that's a problem, but your System Path is missing %JAVA_HOME...........

jar cf Prime.java Prime.class,RunningGame.class

Two problems with this. A jar file usually has a ".jar" suffix, not ".java". You separate class file names with a space not a comma.

In your case, the value should be set to: C:\Program Files\java\jdk-21   <<==  "java" was missing

yes

Generally you create a JAVA_HOME environment variable as a System variable, not a User variable.
In your case, the value should be set to: C:\Program Files\jdk-21
Without the "bin".
Then in the the System environment variable named "Path" the first Value should be: %JAVA_HOME%\bin
Followed by everything else currently in Path. This will then include all of the JDK executable programs.

This topic has come up in a computing forum that I participate in regarding the use of hard disk drives (spinning rust) vs. solid state drives for backups. People are worried that SSDs have a weakness in that if you don't plug them in periodically to refresh the charge that bits can  indiscriminately flip, i.e. bit-rot. This is then followed by a discussion of how often should this refresh be done and how can you tell if bit-rot has taken place. I've personally have never been hit by bit-rot, but on the other hand, how would I know.

I don't know of any off the shelf software for Windows that will detect bit rot. I know that most disk systems implement some variation of CRC validation during reads but this would at least require you to read every allocated byte on the disk.

The application I'm considering is one that detects bit-rot on backup drives. There would be one row per file which would contain full path, date of file, size of file, MD5, last verified date, and maybe one or two others. Verification would probably happen every few days. Verification can be halted part way through (probably the reason I was leaning DB instead of flat file). Possible indexes: by full path, by verified date.

Another route I'm considering is having a $CHECKSUM root directory on the backup drive and under that would be a directory tree that mirrors the tree of the backup drive with one flat file per directory containing all the checksums for all the backup files in the corresponding directory. This way the checksum files would typically be small and manageable. Traversing a  tree of checksums would be no more difficult than trasversing a regular directory tree. This approach might be lighter weight than using a DB.  I was originally thinking if the checksum table could be kept  it a single table along with associated indexes it would be  simpler. As one big DB table random access would be necessary. With multiple small flat files random access might not be necessary. Is this a KISS problem?

P.S.
My current backup drive holds 16TB of which 8TB is  currently filled with 1,613,018 files.
It contains 236,504 directories.

I want a DB that is single user, not multi-threaded or multi-tasked.
Embedded in a Java program using no other external servers, etc..
I'm probably only going to create a single table but it will have tens of thousands of rows though the number of columns will be relatively small.
Data and indexes all stored in a single file (open to alternatives).
SQL. Probably no need for joins (maybe).

I've heard of Glass Fish and Derby but don't know  anything about them, would they  meet my needs?

My background is  with MySQL but it does not meet my "embedded" criteria.

"java" runs a Java program that has been compiled to a .class file
"java -version" prints out the version of Java you've installed. Handy way to see if the install went well.
"dir" is Windows directory program which has a variety of options.
"del" is delete.
You should also be familiar with wild cards for file and directory name pattern matching.