I couldn't put off releasing this any longer; too many users were having problems because I accidentally compiled one of the 3rd-party libraries with Java 11, so their Java 8 runtimes wouldn't allow them to control AGWPE or KISS-over-TCP ports. So, it doesn't have all I wanted in it, but it does have the library compiled for Java 8 to eliminate all those annoying UnsupportedClassVersionError messages.

next beta build#172 of YAAC ("Yet Another APRS Client"), created 2022-Mar-20

downloadable from
? ? ? ? ? ? ? ?or

changes and updates include:
1. fix miscellaneous error messages in APRS parsing.
2. fix error message reporting in the YAAC startup (bootstrap) code. Not all
? ? the information needed to print error messages from the Java-6-compatible
? ? startup code was present in the YAAC.jar, so rearrange so the needed
? ? dependencies were compiled with Java and included in the first Jar file.
? ? Also fix so that the bootstrap code does check for a minimum of Java 8
? ? before allowing the startup to proceed (it was still checking for Java 7).
3. fix blacklist control code so modifying checkboxes on the blacklist table
? ? will be persisted over YAAC restarts.
4. allow panning map with the keyboard faster by using Shift with a cursor
? ? arrow key for larger movement.
5. attempt to speed up map rendering some more (not much improvement, as still
? ? mostly limited by disk reading speed for map data files).
6. not very effective fix for JRE problem on Linux where web browser launching
? ? doesn't happen until YAAC is exited (when selecting Open URL or Email targets
? ? for a station with an URL or email address in their comment text).
7. add read support for some new attributes in OSM data (won't write them until
? ? a later release, because that would invalidate the map data).
8. clean up some (but not enough) OpenStreetMap map data parsing issues.
9. add support for pipelines on OpenStreetMap maps.
10. add ability to sort stations on the stations page of the mini-webserver.
11. clarify the meaning of the NB (narrowband) checkbox on the beacon
? ? ?configuration panel in the documentation.
12. fix all plugin build scripts to use Java 8 as the compiler version.
13. fix date format error in the CallsignDB plugin when reading the US FCC
? ? ?licensee database. Thanks to James Palmer AG5VQ for this fix.
14. rebuild the dnsjava library with the Java 8 compiler, so Java 8 users
? ? ?won't get an UnsupportedClassVersionError upon trying to edit a
? ? ?KISS-over-TCP or AGWPE port configuration.
15. upgrade the OpenMap library to release 5.1.15. This hopefully will fix
? ? ?map rotation issues in the Repeater Finder plugin.
16. fix some NullPointerExceptions in GPSDistributor when using a multi-
? ? ?constellation GPS.
17. fix the SmallScreen plugin to look better on a high-resolution small
? ? ?touch screen (such as a HD monitor of 1920x1080 that's only 10 inches
? ? ?diagonal), including related back-fixes to core YAAC components reused
? ? ?in the SmallScreen plugin.

How embarrassing. The GUI code for the blacklist table forgot to call the checkpoint-to-persistent-storage function when the checkboxes are modified. This will be fixed in the next build.

Andrew, KA2DDO
author of YAAC

________________________________________
From: [email protected] <[email protected]> on behalf of Andrew P. <andrewemt@...>
Sent: Friday, March 4, 2022 9:25 PM
To: [email protected]
Subject: Re: [yaac-users] Problems with persisting blacklisting

This is strange. The code should be checkpointing your blacklist preferences, because all the code to do that for a specific type of blacklisting is there in the latest release of YAAC.

Please export your configuration (File->Configuration->Export to XML) and send it privately to me. Apparently, something is messed up in your configuration data. Possibly, it is because you were using blacklisting before I added the finer granularity, and old callsign records' values are failing to be decoded, so the system is assuming you want all types of blacklisting for those callsign (which is the way it would have worked before the finer granularity).

Andrew, KA2DDO
author of YAAC

________________________________________
From: [email protected] <[email protected]> on behalf of Pascal Charette <ve2pcq@...>
Sent: Wednesday, March 2, 2022 2:21 PM
To: [email protected]
Subject: Re: [yaac-users] How to write a good bug report for YAAC

Hi Andrew,

Just would like to let you know, every time I reset YAAC after a reboot in the BlackList all check go everywhere. Have to uncheck the one I don’t wanted.
[cid:17f4c144d4270a17f621]
Pascal
VE2PCQ


Le mer. 23 févr. 2022 à 14:07, Andrew P. <andrewemt@...<mailto:andrewemt@...>> a écrit :
Greetings.

I appreciate all of you using my program YAAC, and sympathize that you occasionally find problems with it. To make life easier and smoother for all of us, here's how to help me help you with your problems:

1. Always tell me what version of YAAC you are using. There are way too many antique versions of YAAC on websites I have no control over; the only official sites are and . Also, since (unlike many other software vendors) I don't _force_ you to use the latest version, you could be running some old version where I have made incompatible changes in the newer code, map data, or plugins. So please report the version. It can be obtained from the title bar of the map window, the Help->About dialog box, or from the command line using the command

java -jar YAAC.jar -version:all

2. Always tell me what operating system and version thereof you are using. Windowed user interfaces behave totally differently on XWindows on a Linux distro compared to Microsoft Windows or Apple Macintosh OS X, and even between different releases of the same operating system (such as Microsoft Windows 7 versus Windows 11). So tell me the O/S name (and distro for Linux) and version.

3. Always tell me what version of the Java runtime you are using. I've had to drop support for older versions of Java because some of the third-party libraries YAAC is built on are compiled with newer Java versions, and using even newer versions of the Java runtime can introduce problems because of deprecation of older functionality. Java 8 (the common baseline before Java started changing regularly, and the version YAAC is built with) is now 10 (!) releases behind the latest Java release. YAAC is supposed to detect if you are using an obsolete (from YAAC's point of view) version of the Java runtime, but a bug has been found in recent versions of YAAC where it doesn't correctly and clearly report the error of using obsolete Java runtime at startup time, such that you may get the error later at an unexpected time.

4. Tell me _exactly_ what you were doing to get the problem to occur. If you can't tell me how to cause the problem myself, I won't be able to confirm my fix actually solves the problem.

5. Tell me _exactly_ what the error message is that you are getting. I went to considerable effort to ensure YAAC writes out definitive error messages that make it clear what happened and where in the code it happened (which is why errors that aren't user errors commonly appear as stack traces indicating exactly how YAAC got to the line of code where the problem occurred). Saying "I got an error" and not telling me what specific error it was is like telling a doctor "I don't feel good" and refusing to provide symptoms or answer the doctor's questions. And don't edit down the error message; if you knew that only one part of the message was significant, you could probably fix the problem yourself.

To help you with this, YAAC keeps a debugging log file called YAAC.out in your YAAC log files directory. This log file is independent of the APRS packet log files provided for regulatory logging. Instead, it traces what major operations you were performing in YAAC, and records all those ugly stack trace error messages. It also reports all those software version numbers each time you start YAAC. However, if you are going to send me the YAAC.out file (which is really appreciated), copy it right after the problem occurs. To keep from filling up your disk drive, YAAC only keeps the last 128Kb of data in the YAAC.out file, so if too many error messages are occurring, the "first cause" error message might have overflowed out of the file if you wait too long to copy it into an email or bug report. Note this log file generally does not send any personal information about you to me; the most personal data might be the locale your computer is configured to use, such as [for example] American English versus Swiss German, or specific invalid packets you received from someone else. The log file is plain text, so you can read it yourself if you are concerned about privacy issues. P.S. Don't paste the error messages into Microsoft Word or a similar word processing program; these programs will commonly "fix" the text to use the "correct" punctuation marks (according to the word processor's opinion), which can tend to destroy debugging information. Just send the YAAC.out file as-is.

Remember, I'm not lurking behind you watching over your shoulder as you use YAAC, so I don't know what you did to cause a problem to occur. Tell me, so I can help you get it fixed.

Andrew, KA2DDO
author of YAAC

Greetings.

I appreciate all of you using my program YAAC, and sympathize that you occasionally find problems with it. To make life easier and smoother for all of us, here's how to help me help you with your problems:

1. Always tell me what version of YAAC you are using. There are way too many antique versions of YAAC on websites I have no control over; the only official sites are and . Also, since (unlike many other software vendors) I don't _force_ you to use the latest version, you could be running some old version where I have made incompatible changes in the newer code, map data, or plugins. So please report the version. It can be obtained from the title bar of the map window, the Help->About dialog box, or from the command line using the command

java -jar YAAC.jar -version:all

2. Always tell me what operating system and version thereof you are using. Windowed user interfaces behave totally differently on XWindows on a Linux distro compared to Microsoft Windows or Apple Macintosh OS X, and even between different releases of the same operating system (such as Microsoft Windows 7 versus Windows 11). So tell me the O/S name (and distro for Linux) and version.

3. Always tell me what version of the Java runtime you are using. I've had to drop support for older versions of Java because some of the third-party libraries YAAC is built on are compiled with newer Java versions, and using even newer versions of the Java runtime can introduce problems because of deprecation of older functionality. Java 8 (the common baseline before Java started changing regularly, and the version YAAC is built with) is now 10 (!) releases behind the latest Java release. YAAC is supposed to detect if you are using an obsolete (from YAAC's point of view) version of the Java runtime, but a bug has been found in recent versions of YAAC where it doesn't correctly and clearly report the error of using obsolete Java runtime at startup time, such that you may get the error later at an unexpected time.

4. Tell me _exactly_ what you were doing to get the problem to occur. If you can't tell me how to cause the problem myself, I won't be able to confirm my fix actually solves the problem.

5. Tell me _exactly_ what the error message is that you are getting. I went to considerable effort to ensure YAAC writes out definitive error messages that make it clear what happened and where in the code it happened (which is why errors that aren't user errors commonly appear as stack traces indicating exactly how YAAC got to the line of code where the problem occurred). Saying "I got an error" and not telling me what specific error it was is like telling a doctor "I don't feel good" and refusing to provide symptoms or answer the doctor's questions. And don't edit down the error message; if you knew that only one part of the message was significant, you could probably fix the problem yourself.

To help you with this, YAAC keeps a debugging log file called YAAC.out in your YAAC log files directory. This log file is independent of the APRS packet log files provided for regulatory logging. Instead, it traces what major operations you were performing in YAAC, and records all those ugly stack trace error messages. It also reports all those software version numbers each time you start YAAC. However, if you are going to send me the YAAC.out file (which is really appreciated), copy it right after the problem occurs. To keep from filling up your disk drive, YAAC only keeps the last 128Kb of data in the YAAC.out file, so if too many error messages are occurring, the "first cause" error message might have overflowed out of the file if you wait too long to copy it into an email or bug report. Note this log file generally does not send any personal information about you to me; the most personal data might be the locale your computer is configured to use, such as [for example] American English versus Swiss German, or specific invalid packets you received from someone else. The log file is plain text, so you can read it yourself if you are concerned about privacy issues. P.S. Don't paste the error messages into Microsoft Word or a similar word processing program; these programs will commonly "fix" the text to use the "correct" punctuation marks (according to the word processor's opinion), which can tend to destroy debugging information. Just send the YAAC.out file as-is.

Remember, I'm not lurking behind you watching over your shoulder as you use YAAC, so I don't know what you did to cause a problem to occur. Tell me, so I can help you get it fixed.

Andrew, KA2DDO
author of YAAC