You can find a patch here...

Thank you, i'll take a close look at that very soon!

which fixes typos, unused imports and other cosmetic changes.

Why does it remove "final" from many functions? The specific intent is that those should not be overrideable.

i won't promise to apply changes such as:

-    affirm("w😃rldhell🤩!🤩".equals(sbuf.toString()));
+    affirm("w😃rldhell🤩!🤩".contentEquals(sbuf));

...

-        String ret = new String();
+        String ret = "";

Those are cases of "six one way and half-a-dozen the other," i.e. they're a matter of coding style, not functionality (and i first learned Java back in 1996, so my style way well differ from that of more modern developers ;)).

It may be a day or three before i get to this, but it will be done soon.

I haven't done Java seriously in a while, but those two seem to be about not unnecessarily generating garbage, not just style.

The first one will allocate and copy a short lived string just to do the comparison. Better JVMs should do escape analysis and allocate on the stack, but they'll probably still do an unnecessary copy.

The second one is required to allocate a new reference to an otherwise identical string. Unless there's some specific smartness to optimize this away, it's also an unnecessary burden (except if you really want a new object that doesn't compare == to anything else, for some reason).

Sorry, I should have given some more explanations.

Why does it remove "final" from many functions? The specific intent is that those should not be overrideable.

You don't need final on methods of a final class.

which fixes typos, unused imports and other cosmetic changes.

Just FYI, i've started work on these and the rest will be addressed within the next couple of days.

Regarding casts like:

-    sqlite3_result_blob(cx, blob, (int)(null==blob ? 0 : blob.length));
+    sqlite3_result_blob(cx, blob, null==blob ? 0 : blob.length);

...

-    sqlite3_result_blob64(cx, blob, (long)(null==blob ? 0 : blob.length));
+    sqlite3_result_blob64(cx, blob, null==blob ? 0 : blob.length);

Such casts are for the maintainer's own benefit, to ensure that it's perfectly clear which types we're using where, so they'll be retained.

After reading https://stackoverflow.com/questions/39408650/syntactic-sugar-for-strings-in-java i'm definitely convinced that new String() should indeed be replaced by "". It had long been my (mis)understanding that "" was just syntactic sugar for new String().

Thank you again for the feedback!