To: pljava-dev@lists.postgresql.org
From: Chapman Flack <chap@anastigmatix.net>
Subject: Please welcome Kartik Ohri, for Google Summer of Code 2020!
Message-ID: <5EBE06AE.9070603@anastigmatix.net>
Date: Thu, 14 May 2020 23:04:14 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

Under the auspices of the PostgreSQL organization, some PL/Java work
was proposed for Google Summer of Code 2020.

Please welcome Kartik Ohri, who will be working on several improvements
to the way PL/Java is built.

In the early stages of the work, we should at last have Continuous
Integration in place at GitHub, testing on multiple platforms, which
should make releasing new PL/Java versions much less anxiety-prone.

In response to a long history of requests, we should at last have the
pljava-api jar deployed to Maven's central repository, where it can
be automatically fetched as a dependency for building PL/Java user code.

In the most ambitious part of the work, Kartik will be tackling the
longstanding awkwardness of the native-code part of the build, which
is currently done using the nar-maven-plugin. Other than being an
existing plugin capable of building C code, that plugin has never
been a particularly comfortable fit for this project:

- It was designed to build a particular kind of 'native archive'
  that PL/Java doesn't need.

- It does not automatically pick up the same compiler options via
  pg_config that were used to build PostgreSQL (for which our issue #152
  has been open a long time).

- In particular, it does not use the same warning-suppression options
  that are used in the PostgreSQL build, and is very noisy with warnings
  in upstream PostgreSQL's .h files that are not of concern upstream
  because PostgreSQL's build suppresses them. This annoys everyone,
  and the single most common build problem reported for PL/Java involves
  some simple real error, like a missing dependency, that is too hard
  to pick out from the torrent of needless warnings.

- It is unable to properly quote, on Windows, arbitrary arguments to
  be passed to a spawned compiler (our issue #190).

- It improperly quotes names of source files if PL/Java is being built
  in a directory whose path contains a space (our very recent issue #261).

The result of addressing these points will probably be a new Maven plugin
to be used in PL/Java's build, in place of the nar-maven-plugin. (Thanks
to Ken Olson's earlier contributions, we know it is also possible to
embed JavaScript to good effect in a Maven build, but the combination of
issues to be solved here will probably weigh in favor of a new,
purpose-built plugin.)

The quoting-for-Windows issue is one of unexpected depth, as the root of
the problem is not in Maven or any Maven plugin, but in Java's Process
API itself, which is well suited to the POSIX exec behavior that preserves
a list of distinct arguments, and has no provision for the actual situation
on Windows, where the distinct arguments must be joined into one string,
with quoting added according to the lexical rules of the program that will
receive them, which are not universally consistent!

It turns out that the history of pain in the wider Java community from
that API design is long, numerous related Java bug reports exist, and the
code itself shows a history of reactive tweaks rather than a systematic
reconsideration. In one extreme example, in response to a report of command
injection that was possible because of incorrect quoting, the quoting
rules were made to be different when a Java security manager is in place!

The import of all that is that a good solution developed here could be
of benefit to the wider Java community (on Windows anyway) as well as
to the immediate goal of improving PL/Java's build.

Because Google Summer of Code guidelines call for project communication
to be on public and archived channels, you should expect to see more
traffic on this list than in the recent past. I hope some of it will be
interesting. I will also be setting up access for Kartik to the project
wiki, so that evolving design documents, etc., can be there, to find a
balance that does not put too much traffic on this list.

I am looking forward to significant improvements in the experience of
building PL/Java thanks to this project!

Regards,
-Chap