Frame4J’s installation is quite simple.
The minimum requirement is having the file
added as so called installed extension to your Java
development kit (JDK) or runtime environment (JRE). This is done by
putting it to something like
C:\programme\jdk\jre\lib\ext\ (on Windows)
/usr/lib/jvm/jdk/jre/lib/ext/ (on Linux *)).
This simple step will get you almost all of the tools and libraries working, also for Eclipse and else if using that augmented JDK. Missing in this minimalistic variant are the javaDoc and the extras for (serial) interfaces, pdf, mail and else.
[ download | repository |
install | documentation /
on Pi |
GIT issue ]
Note: To have the benefits of Frame4J and installed extensions you have to have Java 8. Java 8 deprecates the 20 year old widely used and still propagated deployment via installed extensions. Thankfully a deprecation can be ignored.
Java 9 killed them by 2017 (as did all later versions). Since November 2018 we have an adaption (w/o jigsaw) to use all Frame4J tools except those requiring proven installed .jars (like pfd or RS232/485/usb handling). This branch isn’t maintained any longer as we and others stayed with Java 8 on big Windows machines down to little Linux ones, like e.g. Raspberries. See also the 9 problems paragrah below.
All in one step
The easy way to have it all is
- download the newest file erg.zip (containing frame4j.jar)
- Go to your JDK directory; that is something like
/usr/lib/jvm/jdk/jre/lib/ext/(on Linux *)).
jar.exe xfv whereYouDownloadedIt\erg.zip
sudo ./bin/jar xfv whereYouDownloadedIt/erg.zip
That’s it for Windows — and mostly for Linux also.
The Linux’ extra
The JDK installation may, of course, be elsewhere. "java" in one
Linux $PATH directory almost never is the programme — the .exe
equivalent — but
one (first) link in an often long chain to the real thing, the JDK
installation we deal with. Nowadays it’s often something like
Since Oracle’s sundown Linux will usually have the open JDK and JRE. If you
also/only want have the Oracle Java, you may have four or
more places to handle Java extensions and the like consistently.
Tipp: Additionally said link nightmare most often handles javac and java only, forgetting all else JDK tools. Hence, it might be wise to stop the link orgy and put the only the Java actually wanted on the Linux path. (That won’t make the system slower, btw.)
To have the serial interfaces working on Linux also you’ll have to move some
You may of course delete
../bib/bsDoesItNative.dll — the
javax.comm.properties (from SUN’s commAPI or
repository). They go to something like
/usr/lib/jvm/jdk/jre/lib/. In the meantime RXTX is beyond
its premature state and has supporters for Win64 also.
Frame4J will move to it.
See also Java IO on a Raspberry
The minimal test
If these conditions are met,
- your JDK is installed correctly
- the path environment variable points to jdk/bin (Linux and Windows) and
- you installed Frame4J completely (from erg.zip as described),
the following will work from any directory within a shell:
The first will open a window saying something on
Frame4J’s version etc.
The second will display all system properties visible to your JDK and
the third will list the computer’s (serial and may be parallel) interfaces available for Java.
Note: Since Sun dropped the support for serial I/O ShowPorts will list those interfaces only when the extra .dll or .so are correctly installed. Otherwise it will tell what it thinks is missing. If you don’t want to use RS232 or RS485 with Java don’t bother with the subject.
The help texts are available in English or German depending on the system’s
language or by options -de respectively -en.
The 9 problem
As might have come clear from the above, since 18 years
Frame4J and its predecessor will be deployed as
installed extensions. Oracle announced to kill installed extensions with
Java9. Since Java8_0_40 they’re deprecated.
As one side effect an automated or manual JDK update deletes installed
extensions on the workstation or server. This breaks running applications
(when not immediately repaired) and may be considered as a bug. Lines like
java.exe Tool parameters
dwelling in server scripts and commit hooks, e.g., won’t get called any more.
Since the advent of Java9 in 2015 no real working recipe for migrating
installed extensions to the jigsaw concepts has been presented.
"Make a module and bundle the libraries with the [one] application" is the the only advice found. It won’t do. Frame4J is a framework + some 15 applications which are all available as one installation. Those tools are widely used on own and customers servers for automated processes, for example in SVN hooks, since years.
Breaking this "Java standard deployment procedure" (since Java1.2, 1998) will hit Frame4J and may hit many others.
Let’s hope for a viable solution that won’t break customer installations and is ready before Java9 or critical Java8 updates that may come.
With openjdk version “1.8.0_232” (Windows 2021) or openjdk version “1.8.0_212” (Raspbian Linux), e.g., all is well.
The 9 solution
Frame4J’s program Exec would
- recognise all other Frame4J tools both by their simple or fully qualified class name (example: de.frame4j.SVNkeys or SVNkeys) as first parameter
- start it (de.frame4j.SVNkeys in the example) and
- pass the remaining parameters to it
Main-Class: de.frame4j.Exec, Exec is Frame4J.jar’s
main class. Hence, one may have a batch script java18.bat, e.g., on the PATH:
@REM @echo java(18).exe -jar frame4j.jar %* @C:\util\jdk-18\bin\java.exe -jar C:\util\jdk\jre\lib\ext\frame4j.jar %*
Yes, but it’s no real substitute for installed extensions.
One needs an extra script with all extra sources of errors in itself.
And Windows treats scripts (.bat) and programs (.exe) differently – a rich source of surprises.
Revision: 81 (2020-12-27)