Project   Frame4J   —   a Java framework

Frame4J is a powerful Java infrastructure to build

• standalone and distributed
• applications and tools.

[ download | repository | install | documentation / tools | on Pi | GIT issue ]
 

Frame4J provides

• the fundamental infrastructure for applications
  • I/O handling, logging,
  • properties, parameters,
  • language support.
• comfortable and fast String handling,
• some math support: algorithms, points, complex numbers ..
• time and date handling, extended parsing, ..

and it also brings

• a bundle of ready made tools for
  • developers (including Rasppberry Pi) and
  • administrators of web sites, domains and repositories.

These tools are explicitly suitable for automated (batch) use, also on remote servers. Applications build professionally upon Frame4J are

• comfortable,
• (inter) nationalisable,
• usable in critical infrastructures,
• and used so in 24h*7d process control applications for over 20 years.

Frame4J tools and Frame4J based applications provide (almost) the same behaviour from Windows Server 2003 (and before) to Win10 and on many Linux platforms. This stability, compatibility and (partly astonishing) platform independence are, of course, made possible by exact those virtues of Java from 1.2 to 8.
 

As mentioned Frame4J is an open source project. Project owner is Albrecht Weinert.   Co-workers are welcome — take part.
 

Status / history

July 2024: An extra set of build scripts was made named *22.bat in addition to *.bat like e.g. readyDeploy22.bat. They use the tools (javac.exe, jar.exe javadoc.exe etc.) of Java >= 9, in our case open JDK22, to build Frame4J. In its temporary building copy some classes and tools had to be omitted due to the lack of compatible libraries and extensions as javax.mail to name just one.

For the sake of generating a javadoc for the cut-down 9..22 version all javadoc references to the classes ommited had had to be removed from the remaining classes. This means a slight reduction of the documentation quality for the Java8 version.
For this small price we still have one common set of sources both for Java8 as well as for Java9..22.
Note: A Java 8 compiled .jar may run under Java9..22 but not vice versa.

We tried adding modules in a Java8 compatible fashion and build a “module startable” variant with Java22 – and failed. A file module-info.java with documentation comment drove the IDE (8 based) crazy and the javadoc22 failed to even mention any module. Searching revealed others having similar problems but brought no practicable solution.
 

June 2024: All Frame4J sources were converted to UTF-8. Before there was a mix of just ISO8859-1 and some European Microsoft “code pages” like 850 for sake of Windows. Three decades it worked well for Western European Windows servers and workstations. But in the end Windows refusal to just use ISO8859-1 (or-15) instead of a set of incompatible code pages sometimes caused a mess.
Also, for sake of future compatibility with Java17+, going all UTF-8 was due.

Besides problems with Eclipse ignoring its own settings/conversions and needing complex mending, the conversion also required a lot of code changes. Frame4J contained code for characters and Strings optimised for textual input (like .properties files) being 8 bit code. This had quite noticable effects on servers and workstations 20 years back, but was now ready to be dropped.
 

June 2021: Support for small systems (process) IO added in extra packages de.weAut. The development of this package(s) accompanied by some publications started 2019 outside Frame4J.
When restricting to digital IO, i.e. binary input and output, PWM and servo control, the very same Java program may run on the Raspberry Pi in question as well as on every other machine in the Pi’s (W)LAN.
Supporting Raspberry Pi IO and control applications is (since implementation version 1.21.03) an integral part of Frame4J by adding packages de.weAut… and polishing the de.frame4j… packages.
N.B.: You must have pigpiod on the Pi in question.
 

September 2016: We had a jump in SVN revision numbering from about 160 backwards to ~4 (due to a SVN server [sic!] bug). Specification and implementation version numbers grow slower than SVN revisions but always monotonicaly.
Update to the very last non-commercial itext jars — those used by Michael Schierl’s jpdftweak.
 

August 2016: Major rework / refactoring to

1. )   exploit more Java8 features and improvements,
2. )   to reduce Frame4J's size and
3. )   prepare it for Java9's modularisation (never used).

The first and most obvious change is the removal of the time and date types

• ConstTime, Time,
• TimeRO and TimeST

from package de.frame4j.util. For more than a decade, those have been, of course, much more than a replacement for the horrible java.util time types. But now, much of their benefits were taken to Java8’s java.time package. Frame4J’s better parsing and formatting (with PHP like format symbols) were kept.
Now, TimeHelper helps Java8 time, too. TimeHelper and some new types to improve and support Clock are now found in de.frame4j.time (not ..util).
All (but two) deprecated classes were removed, as was the use of types deprecated in Java8 or to be deprecated in Java9.
rev165 is the youngest version before this conversion. Use this is situations were backward compatibility (e.g. Applet support) is required.
rev186 is the first version afterwards to be used in automated remote server applications. Use this or newer for new missions or development.

February 2016: On February 4th, as root CA, German Telekom revoked next level DFN certificate PCA Global - G01. It would otherwise be valid until July 2019 — and its descendents even beyond that date. A revocation (if perceived) immediately invalidates all that.
Two levels deeper Albrecht Weinert’s certificate and all signed with it is affected. Especially this concerns Frame4J below revision 146 (then).
Revision 147, February 26th 2016, Implementation-Version: 1.11.02, has been signed with a certificate based on valid ones.
Warning: Former versions will probably be good at local installations; r145 is the youngest version with the revocated certificate. r<=145 will almost certainly fail in the context of JNLP, WebStart and the like. You would see a java.security.cert.CertificateRevokedException: Certificate has been revoked, revocation date: Thu Feb 04 13:47:35 CET 2016, authority: CN=Deutsche Telekom Root CA 2 …
Remark: As of now (Dec. 2020) no code signing certificate with a reasonable price and handling for our purposes is in sight. This domain’s certificate cannot be used to sign a .jar’s Java package de.frame4j (and below). And, alas, Let’s Encrypt won’t offer Java code signing certificates attested by the ownership of the package root domains.
 

Spring 2015: Java8_0_40 deprecates installed extensions. Oracle announces to incompatibly drop them with Java9.
From November 2015 until now no real, i.e. working, robust and testable, migrating recipe has been presented.
"Make a module and bundle the libraries with the [one] application" won’t do. Frame4J is a framework + some 15 applications which are available by just having Frame4J installed. 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) would hit Frame4J as many other projects.
Perhaps we will have to climb on the jiggsaw / modularisation bandwagon as soon as all world will do so – which we doubt.
Since November 2018 we have an adaption to use all Frame4J tools with Java 11 (w/o jigsaw).
Until now (June 2021) we have Java8 as standard on (big) Windows (1.8.0_232) and on little Linux (1.8.0_212) machines.

November 2014 we started with using Java8 only for development and deploying. With beginning of 2015 we stopped using and supporting Java 7 and below. That includes the using Java8 features and starting to reduce those parts of frame4j.de that were motivated by pre8 bugs — like time, calendar and more.

November 2012 all Tomcat / Catalina related classes were removed. It was in the end impractical to bridge Tomcat’s code breaking changes in one deployment. Many older Tomcat servers ran on for long time with a suitably old frame4j.jar.

February 2010: Oracle announced Kenai’s shutdown and Frame4J moved to weinert-automation founded by [Albrecht Weinert][enWeHomepg] that year.

March 2009 saw the first successful port of a long run automation (process control) application from the predecessor "aWeinertBib" to Frame4J.

November 2008: Frame4J is open source and one of the very first projects at SUN’s open software platform K≡nai. The software is open but the platform was not. A rigorous submission process had to be undergone to get a project. But, alas, … see February 2010 above.

November 1998: Start of developing a Java framework for process control and (domain) administrative tasks under the Label aWeinertBib. In few years it was spread and (by agreement) copied and modified.

Aims, Strategies

Frame4J is developed on base of the approved predecessor. Both did and do run control / server applications trouble free over many years in uninterrupted 24h7d.

• Hence, backward compatibility is and was important for Frame4J and as it was for Java. Notwithstanding the following breaking changes were made with respect to the predecessor (2007):
  • English only (javaDoc, comments, names) instead of German (except for one banking package used for online transactions available in German speaking countries only)
  • base package mainly de.frame4j (instead of de.a_weinert)
  • using Java8 features (2015, no return ...) and the last with no more reference to versions before Java8
  • adding packages de.weAut.. packages (2021) and thorough polishing de.frame4j for Pi IO support with very few backward in-compatibilities (to be handled easily)
  Since August 2016 this last incompatible conversion was, consequently, driven further; see above.
  For major and minor incompatible breaks, the last revision before will be kept some years for comfortable download.
• Frame4J shall be to a large degree JUnit tested / test driven
• Frame4J conforms to good design rules and the "Guideline for the usage of OO programming in critical systems", (an EWICS TC7 project).
• Frame4J was, is and shall stay a stable consistent and platform independent framwork and toolbox. It is easily available by just making frame4j.jar an installed extension.

[ download | repository | install | documentation / tools | on Pi | GIT issue ]