Re: Starting build-system work (Windows/Mac users please speak up)

On 05/27/20 12:42, Kartik Ohri wrote:
>> -ea:org.postgresql.pljava... -Xcheck:jni
>>
>> The -Xcheck:jni makes big output and big slowdown; it might be ok to
>> include that in a subset of the tested configurations rather than all
>> of them.
>>
> I think this is the major option left to be added to builds for Linux and
> macOS. To which builds should I add the -Xcheck:jni flag

I don't think it will make much difference ... maybe start with a build
that's against the latest supported PG. Once things are going, maybe we
can get a better sense of which outputs from -Xcheck:jni are innocuous
and which ones really deserve attention, and write a filter that cuts
down that volume effectively, then it might be desirable to add the option
to more of the builds.

> Also, I do not know about the -ea:org.postgresql.pljava... flag

Good question, you got me to look again at the 'java' manual page
and see that there is a long form for the option, -enableassertions.
I have been using the -ea form by habit because it is shorter to type,
but when putting it into a CI script the length doesn't matter, and it
would be better to say -enableassertions:org.postgresql.pljava...
and then it will not be as puzzling to the next person reading the CI
script.

If the idea of assertions isn't familiar, there's a very good
explanation in [1].

In a lot of programming languages, there will be something like

assert <condition>;

where you are saying you are certain <condition> will be true
at that point in the program, because your analysis of the
possibilities leaves no way it can be false. So it is a check on
whether you've made an analytical mistake (or maybe a dumb typo
five lines earlier). It does nothing at all if the condition is
true (as it should be), and signals an error if it is false, so
you know there is a problem.

In production, after you're happy with testing results, sometimes
you don't want the overhead of checking assertions anymore; after all,
they are all testing conditions that are supposed to be true every time,
and doing nothing else useful.

Historically, in a language like C, 'assert' was provided
as a macro [2], and you could compile the code for production
with the macro defined to be nothing at all, so all your 'assert's
just disappear and there is no cost in the running code.

The disadvantage was that if some rare bug only showed up in
production, you would not have any of the assertions there
potentially showing where things went wrong. You would have to go
back and completely recompile with assertions enabled, and run
that version of the program, and hope the bug showed up again.

Because Java does just-in-time compilation in the JVM, they can
get the same efficiency when you don't want assertions checked,
but without that disadvantage. The assertions are always written
into the .class files, and you can decide at run time to give the
-enableassertions option or not, and if you don't, the JIT compiler
just leaves them out of the compiled code, but you can get them back
whenever you want by just running again with -enableassertions.

And as you can see, the option can be selective; you can
-enableassertions:org.postgresql.pljava... for testing all the
packages and subpackages in PL/Java but not in other libraries
or Java itself.

Naturally, CI testing is a context where we definitely want
to be running with assertions enabled.

Regards,
-Chap

[1] https://docs.oracle.com/javase/7/docs/technotes/guides/language/assert.html
[2] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/assert.h.html