Getting Started With Programming in Java

Conventions

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. Consistency is key and following standards 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. Most things you can imagine working can generally work in software.

Basics

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.

A Basic ClassPath Tutorial

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.

Environment

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.

Unpacking and Making Projects

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 the inverse is not true, newer version compiled code will need to be recompiled for older Java Runtime Environment (JRE) versions.

Finding Import(s)

You can use FindImports in the ca.tecreations.FindImports.java code.

SecurityTool is due to be re-written, primarily due to the change in Bouncy Castle accepted version. Exceptions should now be thrown early and caught late. When source is a failed password, that should propogate to the UI delegate.

I've been toying with the idea of Class.Method lookup, similar to IntelliJ IDEA, but only if set to "PREFERRED" and only if, in background. I shouldn't have to wait to run code, especially, on my own machine, unless dependant upon the new artifacts, but that's an easy y/n type evaluation.

My dependencies are "in-place", so, it, #works.

Excluding Artifacts

If you are running TestDependencyViewer, you simply have to deselect the artifact you wish to exclude. The code is correct.

You'll #probably, #haveTo. ? #TryExclude. #tim. #Delete. #ExcludeJars.java. #ThatList. #Retry. #Ithink? jakarta.servlet-5.0.0.jar

I'll try to post. /java/downloads/release/spring/**/xxx.xxx. My keys are stale. I haven't used them much lately. Need to revoke, start over. Re-Implement, Re-Test.

Re-Document, #CALLITRECYCLE