Copyright © 2021-2022 by Keith Fenske. All rights reserved.
These programs were written for my own use, cleaned up, documented, and released to the public (GPL). They won't solve the big problems in your life, but may help with smaller ones. I am often asked the same questions:
This was a reasonable choice in 2004 for applets and complete applications with no dependencies. I should have switched to Java 5.0 when it was stable, and maybe the Apache License with fewer restrictions. I do find "generics" in Java 5.0 and later to be ugly. Many of my design choices were for consistency in projects over what became fifteen years. All of the programs run correctly in Java 8, the current public run-time environment as of late 2021.
The license is difficult to change. At least 200 files and 50 packages have legal notices. Each package would take a couple hours to rebuild (assuming no mistakes are made). There are numerous tedious details. The web page applets can only be fully tested on a clean copy of Windows XP or earlier. The BIOS date was 2008 for the last computer here that could run the original development tools: Java 1.4.2 SDK, Microsoft Word 2000, NetBeans 3.5.1 IDE, OpenOffice.org 1.1.5 (PDF generator), Paint Shop Pro 5.03, etc. Too much history, not enough time.
There is no perfect software license. The GNU GPL is good for end users. The Apache License is better for bits and pieces that will be re-used. A dozen similar licenses disagree.
Permission is hereby granted to convert the web page applets to the Apache License (version 2.0 or later) or to GNU GPLv2 from the original GPLv3 or later. Applets are in the following five folders (repositories): Dots and Boxes Game, Life Game, Maze Fog Game, Reversi Game, Tic-Tac-Toe Game. It is impossible to change the license without also changing the binary class files, which can't be properly tested anymore. All others have been converted to a dual license of Apache plus GPL. Yes, it really did take as long as estimated above.
Having twice the features would require ten times the effort. Open-source software does not need to provide all solutions for all people. You leave hooks for expansion, and let other people make the changes.
The DOCX format didn't exist until 2007 and wasn't common for several more years. The ODT or "Open Document" format also took a while to get accepted. Documentation appears as plain text in the program source code, as a Microsoft Word DOC file, and in Adobe Acrobat PDF format. The code comments will be readable long after DOC and PDF files have become obsolete. Whether or not the code itself will run is another question!
Again, because that's the way it was. GIF files were lossless, but limited to 256 colors. JPEG files always have some compression. PNG files are now better for screen images.
This is an index page on a web site for downloads of open-source software. The page is fast, clean, and direct -- and works on almost all web browsers at most font sizes. It even works with style sheets (CSS) turned off, which is important for accessibility, and doesn't use JavaScript, which many people disable as a security precaution. The more sophisticated a web page is, the more easily it breaks.
I don't know. This is not social media where you rank yourself by the number of followers. What is important is that people can download and use the programs. When pushed for a number, I proudly report an average of zero point zero visitors per day.
Old habits die hard. Another choice that stands out in hindsight.
All computer programs are written in some programming language. Which one depends upon what is available for the target machine. Java ran on multiple operating systems (IBM, Linux, Macintosh, Solaris, Windows) and had a graphical user interface (GUI). Other languages had their own application programming interface (API), some with short lifetimes. A desktop API was often obsolete before ten years, a mobile API (cell phones and tablets) in maybe five years. Then you rewrote for a newer API or a newer version of the same API. Old Java programs had an unusually long lifetime of around twenty years. I wish I could say we knew this in 2005, but it was just a guess. There is something to be said for programs that have a single source file, no dependencies (additional libraries), and stick to API calls as documented.
Several companies had strong opinions about the future of Java in the mid 2000s, chief among them IBM, Oracle, and Sun Microsystems (the originator). Java 1.4 Standard Edition seemed to be the only thing they could agree on. The situation was somewhat unsettled until a year or two after Oracle acquired Sun. Java 5.0 (2004) was good, Java 6 (2006) was not, and Java 7 (2011) was good again. Meanwhile, Java 1.4 programs keep running through to Java 8 (2014) and later. Not bad for a language that has changed so much, I don't recognize code from some newer versions.
My Java applications have around ten files for the program and a few more for licenses and advice. The most common package is a ZIP archive: everybody everywhere does this format. Great for people who know how to run Java, but not for people who need an "installer" or setup program. Those, unfortunately, are specific to each operating system. Assume you need one installer for 32-bit Windows, another for 64-bit Windows, one for MacOS, at least one for Linux, etc. A self-installer for Windows adds about 2 MB of overhead. Say you have five distribution packages of 2 MB each for one ZIP file that was less than 300 KB. That's 30 times more storage space and now you're building a program five ways, plus the original ZIP. How many programs are on my web site? Oh, dear. This is free, open-source software. I'm not getting paid to do this, and any web host would be unhappy if I suddenly started using gigabytes of data.
A long word for supporting many languages. The more "international" you make a program, the dumber the error messages get. I like good error messages. I only speak one language well, so I can't personally translate program messages or documentation into another language. On-line services such as Google Translate come close when dealing with straight-forward "declarative" sentences. Then you have to implement message loading by language, generic substitution of parameters, etc. To avoid too much work, you dumb down the messages -- exactly what I want to avoid. Again, this is something you do if you have an interest in only one or two programs.
There should be a better license for material that is not part of a program package. Apache and GPL aren't suitable for this FAQ, the index page, etc. Yes, I looked at other licenses. No, I'm not going to post negative reviews. Copyright with all rights reserved may be best here.
A clean and consistent programming style is necessary for open-source software. Bad code can be embarrassing for years to come. Bad documentation makes even good code look like garbage. Proper grammar, spelling, and punctuation are important: you can't communicate if people don't understand you.