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
