<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>The current JEP 411 plan of action, if left unchanged, will leave
developers who adopted the SM architecture as an authorization
layer unable to upgrade to later versions of Java, until
finalizers and the finalizer attack defensive methods in
constructors are removed. JEP 411 has the potential to cause
significant disruption for a small proportion of Java developers,
but doesn't have to if managed appropriately.<br>
</p>
<p>The blocker is the ability to implement guard checks using Agents
on public API, due to finalizer attack defensive private static
methods in constructors.</p>
<p>Allan has advised when finalizers are removed, it will be
practical to use Agents to instrument public API to implement an
authorization layer, this is try, so can it be coordinated with
JEP 411 et al?<br>
</p>
<p>Furthermore, as developers must support multiple Java releases, I
propose the following amendments, to ease difficulties of multiple
release support (with multi release jars):</p>
<ul>
<li>AccessController, AccessControlContext, DomainCombiner and
related Subject and Executors methods, remain until Java 8 is
EOL in 2030. Also consider un-deprecation of these methods, as
their removal causes shotgun surgery (used in 1000's of
locations in my software alone) and they are required for
preservation of Subject, used for obtaining TLS and Kerberos
connection credentials on all existing versions of Java.<br>
</li>
<li>AccessControlContext - remove inherited thread context,
replace it with an unprivileged ProtectionDomain, such that
doPrivileged methods are required for authorization checks and
only the current thread stack needs to be walked when checks
occur, and stack walks aren't unnecessarily performed when
creating new threads. This is compatible with Loom, update
loom to allow the use of AccessControlContext to be used, to
establish TLS and Kerberos connections. Loom will be very
useful for network connections, especially long latency
connections over the internet, which are typically secured using
TLS. This removes the problem of viral checks, and Executor
task privilege escalation.</li>
<li>Modules that are mapped to the boot loader should get a unique
PD that includes a useful code source rather than using a
"shared" PD, this allows us to reduce the privileged footprint
of the Java platform libraries, to allow privileges to be
granted to users, not code, or users and code. This is useful
to limit data parsing privileges to authenticated users on
servers (a practise that should be more widely encouraged).<br>
</li>
<li>Remove finalizers, and defensive methods in constructors where
permissions check points occur as these cause problems for
Agents, prior to removal of SecurityManager.</li>
<li>Deprecate for removal Permission implementations, then remove
them in a following release.<br>
</li>
<li>Remove SecurityManager.<br>
</li>
</ul>
<p>This allows a forward migration path for poor sod's like myself
who are currently using SM infrastructure as an authorization
layer, and to establish TLS conenctions, this or at least some
sort of compromise is far preferable to the thermonuclear option
currently planned.</p>
<p>What I would like OpenJDK to consider, is to allow developers
like myself to continue to stay current with Java, by coordinating
the removal of finalizers and defensive methods in constructors,
with JEP 411, so we have a workable future migration path.
Without these considerations, options are; go back to Java 8, and
plan to redevelop existing software, if forced to do so, Java is
unlikely to be on the list for redevelopment, simply because
development costs are lower in newer languages, such as automated
unit tests, <a class="moz-txt-link-freetext" href="https://hackage.haskell.org/package/QuickCheck">https://hackage.haskell.org/package/QuickCheck</a>, no
need to worry about null pointers and less boilerplate.</p>
<p>Don't get me wrong, I like Java and have many years experience
with it, but I have to be pragmatic, it won't just be me, many
other developers, when Java 8 is EOL, will work for companies
stuck on that platform, simply due to the number of changes
required, because they haven't kept up (eg budgets) with the
current release cadence and pace of development, will be looking
at redevelopment and replacement instead of migration. Clearly
the current pace of development is a good thing for Java, but the
overall strategy could be tweaked a little, to ensure migration
doesn't become insurmountable. A healthy and vibrant Java
community is essential for the survival of Java, Java has already
shed phone and client markets, lets not shed too many more.</p>
<p>Thanks,<br>
</p>
<pre class="moz-signature" cols="72">
Peter</pre>
</body>
</html>