JEP 411, removal of finalizers, a path forward.

[Chapman Flack]

On 08/03/21 12:40, Sean Mullan wrote:

> It is to the point where I only skim your emails
> quickly. I would take the time to write up your ideas in an external place.
> It may not go anywhere, but at least you would have a single place where
> your proposal, experiments, etc are documented.

I would concur with the value of 'an external place' for such discussion.
I also have a need to salvage a project from the effects of this JEP, and
I have been both psyched that Peter has taken so much initiative in
exploring the repercussions and proposing solutions, and at the same time
a bit hopeful that others similarly affected (like me, of course, and
Alexey Shponarsky who noticed the JSR 233 implications, and others whose
use cases I remember reading about in the last nine weeks but haven't
reviewed just now) will also be getting ideas into the pot to avoid
over-tailoring proposals to one set of particulars.

Naturally, that means I need to be keeping up more with Peter's emails,
and I also am finding the volume and the medium of email to make that a
bit of a challenge.

On 08/03/21 20:19, Peter Firmstone wrote:
> Maybe we should have a mailing list dedicated to this where we can discuss
> and potentially collaborate?

In my experience, for the job of working out ramifications and solutions
for anything as disruptive as this JEP, an email list quickly and inevitably
becomes write-only, when the cognitive burden of connecting today's ideas
to those in somebody else's half-remembered email eight weeks ago just
becomes too much.

On the most productive teams I've served on in the past, a simple wiki
turned out much more conducive to collaboration on identifying issues,
enumerating ramifications, and hammering out solutions. Instead of a
long write-only sequential thread of messages and responses, it would
develop into a steadily more complete and organized reference to the
issues, solutions found, and those yet to be found.

It was never important for that to be a flashy wiki with lots of bells
and whistles; what was important was low procedural burden of editing,
ease of making and linking new pages, and an underlying VCS so that
no history was lost.

Is there any such infrastructure currently available, perhaps hosted
already by OpenJDK, where an area could be provided to start some pages
on the issues and proposals in these email threads? I would be willing
to do some curation and get some of the content from these threads into
some semblance of initial organization there.

I think it would be a natural choice for OpenJDK to host, as the
needed work is forced by the consequences of this JEP, and will
almost certainly have implications for the further development
after 17. (It arguably would have been ideal to host such work
earlier in the conception of this JEP, but that's over the dam now.)

On 08/03/21 08:15, Ron Pressler wrote:
> possibly some callbacks for a small subset of operations that perform
> access checks today, say, System.exit and opening a file or socket. I am
> not saying this is what should be done, but that the effort involved
> is such that I can conceivably see those whose responsibility this
> would be agreeing to consider it

Indeed, something like that is where I was trying to aim in [1]:

Checks that control outwardly-visible effects:

- native actions
- file operations
- socket operations
- process operations
- ... ?

Checks that were necessary "inside baseball" prior to JPMS strong
encapsulation:

- did you ever really want to have to think about suppressAccessChecks,
  enableContextClassLoaderOverride, createAccessControlContext, etc.,
  other than because you had to or the checks you cared about were
  circumventable?

Perhaps JPMS strong encapsulation will now be able to ensure that simpler,
clearer, faster, cheaper designs are possible for implementing controls
over the handful of things one actually wants to control.

So the necessary discussion would be focused on what's the size of the
small set of outwardly-visible actions one could want to control, and
which ones have usable mechanisms existing already (FileSystemProvider,
for example), what gaps or blockers might exist in those mechanisms,
and confirming their reliability given JPMS strong encapsulation.

Probably each of those categories of outwardly-visible ops would be worth
at least a page of its own on a prospective wiki, and each such page
might see quite a bit of revision and development.

It is hard for me to imagine a mailing list discussion in adequate depth
and detail being able to arrive at coherence, or indeed to avoid driving
burnout and unsubscribe requests.

Regards,
-Chap


[1] https://mail.openjdk.java.net/pipermail/security-dev/2021-May/026177.html