Java uses camel case to specify things such as class names, variables, annotations, etc. The best way to understand how it is used is to start reading and writing code. Typically, package names are written as tld.domain.package.name, classes are written as ClassName and variables are written as variableName. Constants are typically all UPPERCASE, however there are some exceptions, for example in the class java.awt.Color where both upper and lowercase are used. Consistency is key and following common patterns will help you become more proficient.
Formatting of code text varies from institution to institution and developer to developer. Everyone seems to prefer their own way of formatting, however there exist tools to do this programmatically. It isn't about nomenclature, rather, probably, preference. Some things are stylistic. Most things you can imagine working can generally work in software.
In case you aren't aware, there are two major file system separators. On Windows it is the backslash character (\) and on Apple products and Linux distributions it is the foreslash character (/). Windows also uses drive letters with a colon, so A: refers to the 'A' drive, the path A:\ refers to the root directory on drive A. Mac/Linux use a foreslash character to represent the root, so that is / by itself. (Drives and partitions are referred to in a different fashion on, so called, POSIX systems.) After a drive, we can specify multipe directories, for example, /java/jars or A:\java\jars. I would assume there is a limit to the maximum length.
In code (especially when performing String manipulation), I prefer to signify the difference between directories and files by specifying a trailing path separator, ie /java/jars/ or A:\java\jars\.
There are also network drives. For example, on Windows they declare a network drive similar to \\computername\\letter:\path\to\filename.extension, however we don't discuss them. It is sufficient to know that Java operates on a correct identifier.
That is beyond the scope of this FYI.
The Java class path is a special variable. It is a list which can contain multiple path or file members. These members are separated by the path separator. On Windows it is the semicolon ";" and on Mac/Linux, it is the colon ":".
In essence, you must specify all of an application's sources within this variable, or provide the loading functionality yourself. My preference;? I prefer to rely upon their work. I'm sure they're better at it than me. I use the shortest version they allow.
It is also possible to specify individual file paths, for example, for use with HotSwapAgent.properties.
An example may be similar to something like this: java -cp tec_nutshell.jar;C:\java\jars\*; someclass arg1
In the tecreations nutshell, there is ca.tecreations.lang.java.GetClassPath which should be used to programmatically create a classpath for use with the JDK/JRE runtime applications.
To begin working with Java, we need a Java Development Kit. The options for which manufacturer, what version to run, as well as what version to compile with or to, are many. To use Hotswap Agent, we need to install the Java Development Kit by Digital Code Evolution, as well as the HotSwap jar for the version we will run. Some of the older code (particularly 0.2.0) used the Hotswap Agent, but I have mostly stuck to just manual restarts to ensure a fresh copy of the code is run. Because I rely heavily on the SystemCompiler utility, my code is somewhere near the latest version, compiled (generally) to the lowest compatible, in the current case (tecreations-0.3.0), Java version 8 (class version 52.0).
A "basic" tecreations.ca Project may contain a tec.xml file, to be used with ca.tecreations.pomdeps.DependencyViewer. That should be your main reference item.
You can unpack and build a project using WinRar or your favorite Zip utility as .jar files are an extension of .zip files. Just unpack to a directory and build/compile.
All the tecreations* packages include source, binaries and dependency jars. You may use Launcher (discussed in the tecreations Main Package) to operate on a .jar or class path to effect operable code. You may need to compile, as well, depending on your JDK version. Newer JDK versions will run older code, however newer version compiled code will need to be recompiled for older Java Runtime Environment (JRE) versions.
You can use FindImports to find an import within your projects /jars/ path by using the class ca.tecreations.FindImports