Java is our "strategic language"

Since it’s advent more than thirty years ago (1992) Java has had a tremendous success in industrial and business (web, server) applications.
It’s a first choice OO (object oriented) language. Notwithstanding the complexity behind OO, multi-threading, memory model etc. it’s semantic and syntactic definiteness make Java – up to version Java8 inclusive – an excellent choice for teaching the first programming language.
Even the loss of confidence by Oracle’s take over and some clumsy handling of security issues afterwards couldn’t spoil Java’s success yet.

Java is predestined for distributed applications, also in the field of automation and process control. At the beginnings of Java the syntactic resemblance to C (even when going too far) as well as the (then) popularity of moving Applets to animate web pages fuelled the the first marketing successes of Java. These aspects are of no more importance, luckily. Java became the number one programming language for serious business and control applications, even very large and mission critical ones.

The enduring success of Java in these critical field was also supported by the immense progress in compiler technology, multi threading and processing, and deployment techniques — turning Java’s rumoured slowness to express speed. And there are also the facts of platform independence and scalability from the biggest mainframe to the tiniest card.
 

Strategic language since then means
“If we do some programming or development we take Java.”
This does not exclude other languages, down to assembler, provided there are some very good reasons for it.

But:   What can be done successfully with Java, we do neither in C++, C, …
  … nor, without pressure, do we take C#, MSdotNet, Ruby, Python, Lua …
The only exception are our growing µController-based automation development activities. Here the (embedded) software is almost 100% C.
 

In Albrecht Weinert’s university lab and firm many Java applications and class libraries were made. Most of this work was done in the context of a powerful framework Frame4J (respectively its predecessor aWeinertBib). Some of these appliances — including industrial automation with Java, also of foreign users — did and do run uninterrupted for years, without causing any troubles. In between we do Raspberry IO with Java endurance tests, also.

The framework Frame4J is an open source project since September 2008. Most tools and applications were ported from the mentioned approved predecessor.
[ documentation | sources (rev…) | binaries, resources | install | tools ]
You’ll also find there programmes supporting the generation and deployment of java software and of web-site content

• FuR for putting the building blocks together,
• SVNkeys for aesthetic and problem-free export out of version control systems (both CVS or SVN),

as well as some others. If you install (Java and) Frame4J, you’ve got all that — and much much more.

Some hints

 
  1.) File name’s case

Case plays an important role in Java’s case sensitive syntax and as important in Java style — for human programmers and for tools. Names of classes, interfaces and packages have to be mirrored exactly in the names of (sub-) directories and files. But case in file names, still causes trouble in the Internet: If just one server, proxy, router, browser or whatever in the chain thinks it knows better and changes case in an URL, you may get in troubles by a wrongly named file. Therefore single Java source or class files are rarely offered for direct download. The alternatives are access via version control (SVN) or providing archives (.zip or .jar).

 
  2.) About .jar und .zip

Regarding their archive and compression functions both are equal. SUN just used the "world standard" .zip unchanged for .jar. (Alas, if only everybody would leave established standards untangled.) SUN just put some semantics on top; as the meaning of certain directories and files for the java runtime.
But some browser reject the downloading of Java archives even with "Save as" by right mouse.
If you had the framework Frame4J installed the tool UCopy gets you all types of files (including .class. .jar .css .var etc.).

 
  3.) About Java - prerequisites (JDK, JRE)

Most of todays Java code requires at least "Java 2" as JRE / JDK1.4.x or higher. No substantial objection is left against just using Java8 since some years and, hence, all the (substantial) efforts and restrictions for Java2 or 6 backward compatibility have been dropped. They are now just waste.
Frame4J requires Java8. Java8, also, is the final version without module/jigsaw fuss and with installed extensions.

 
  4.) About the framework’s installation

To use Frame4J just put the archive frame4j.jar into the jre-directory lib\ext\ of your Java installation as a so called "installed extension". (See downloads.)
If you just extract the (newest) file erg.zip into the base directory of your JDK installation (should be something like C:\programme\JDK) you get the actual framework and all accessories, like CommAPI, javaMail, linked documentation etc., in one step.

 
  5.) Tools

After the framework installation according to hint 4 some useful framework based tools are available: Update, AskAlert, UCopy, FuR, SVNkeys, ShowProps, ShowPorts etc.
Warning: Java8 started deprecating installed extensions — Java’s standard deployment for libs and programmes since decades — and Java9 has dropped it. There’s a documented workaround to run Frame4J tools with Java>8.

 
  6.) On XML

Since JDK / JRE 1.4.x XML support belongs to Java’s basic equipment. One exception was XSLT 2.0, that can be supplemented as Saxon 9. Since Java6 this seems mended.
 

This article is translated to Serbo-Croatian language by Anja Skrba and to Ukrainian by Dmutro Nechuporyk.
More hints may be found in Java-Tips in the document folder and in modern text books.
Beginners might still find the 2001 textbook “Java für Ingenieure” useful.