Nested Git repositories can appear as phantom submodules

Tonight I helped a student who was trying to publish a project to GitHub with Android Studio but only got one subfolder in the resulting GitHub repository. git status showed that the published subfolder was a submodule with pending changes. Strangely, there was no .gitmodules file for submodule registration. There was, however, another .git directory inside that folder - it was actually a nested repository. To fix that accident, we:

1. Deleted the subfolder's .git directory
2. Removed the submodule from the outer repository's Git index with git rm --cached theFolder
3. Committed the change
4. Added the subfolder back, now as a plain directory, with git add theFolder
5. Committed the change

Exposing a Kotlin function only to Java code

I'm involved in a Kotlin project that's intended to be used from both Kotlin and Java code. Because Java doesn't have optional/default-value parameters, we use @JvmOverloads to generate overloads with subsequences of parameters, but we also end up writing a lot of overloads manually to remove optional parameters in the middle. These pollute Kotlin autocomplete lists, so I wanted to hide from from Kotlin code.

The @SinceKotlin annotation is meant to hide a member from sufficiently old versions of Kotlin. Specifying a bogus, extremely large version number hides the member from Kotlin in general. I defined a JAVA_ONLY string constant with a large version like 999.0, so the hiding annotation looks like @SinceKotlin(JAVA_ONLY), which is nice enough. This annotation doesn't mean anything to the Java compiler, so it's perfectly happy to use the function.

FMod - v2.11.2

Today I did some final testing on the new Abiathar version comprised of my long-languishing beta and my tweaks from the past week. I noticed a discrepancy between the default side tile properties' names in freshly created projects vs. older ones using generic tile property definitions. I fixed that and published the new version as v2.11.2 for the first update of 2020. Somehow it had been almost two years since v2.11.1!

FMod - Less VeriMaps advertisement

A long time ago, I introduced a levels signing feature to Abiathar, mostly for fun and to recognize people who contributed. However, it doesn't actually seem to have been used despite being almost always mentioned in the status bar. To avoid confusing new users, I've now changed the status bar text to not mention VeriMaps unless the levels are signed.

FMod - Unknown configuration section detection

For a long time, Abiathar has allowed extensions to save additional information on a project by adding another configuration section to the project file. While this has never been used to my knowledge (except by my as-yet-unreleased Abiathar Live Studio extension), I happened to be thinking about it recently. When Abiathar sees a configuration section, it asks all loaded extensions whether they recognize it. If an extension claims it, the configuration template provided by the extension is used to load the section.

If no extension claimed a section, it was silently ignored. This could be a problem if a project was opened without the extension used to create some important information, since the section would be lost upon saving. So I added a confirmation/warning when an unclaimed section is loaded.

FMod - More color customizability

I've had some Abiathar progress sitting in a beta release for a long time now. Since I've heard no reports of problems from that beta's user, I figured I might as well get a release out including those Tile Property Modifier updates and a few tiny tweaks.

A long time ago I added brightly colored bars to active planes' bays so that you can tell at a glance which ones are active. I tried to keep the three colors distinguishable from each other without looking garish and repelling new users. They ended up different shades of blue to match the overall Abiathar color scheme. But some users might want to sacrifice an attractive color scheme for more distinguishability, so the colors of those bars are now customizable on the Colors tab of the Settings. The bold blue color of the label "Active" can now also be changed, e.g. in case someone wants the very noticeable but eye-searing red of the Abiathar 1.x series.

When Java exceptions don't include a stack trace or message

I was helping someone investigate a crash in their Android Studio project's tests today. One exception totally lacked all context: it was just the exception class name, no message, no stack trace. It turns out Java has a performance feature that skips generating the stack trace in certain cases for common exceptions. The feature can be disabled by adding -XX:-OmitStackTraceInFastThrow to the JVM command-line arguments. That brought the stack trace back, which was very helpful for finding the bug.

JavaCompiler Diagnostic objects might not include a source

Today I was working with a project that uses the JavaCompiler API for in-memory compilation of Java sources. It accesses the compiler's Diagnostics to report compilation errors. It assumed that getSource would return a source file for each diagnostic, but that is not the case and it choked on a warning about a lack of annotation processor for a certain annotation. Initially I just wrote an inert annotation processor to squelch the warning, but then I went through the project that was the direct cause and fixed it to not assume a specific source for each diagnostic.