Hi Peter.
- JEP 411, like every spec-changing JEP, is meant to allow those that use the removed functionality a migration path forward. The API elements that are deprecated for removal have some years before they are actually removed, so there’s nothing too urgent other than beginning to think of a migration path. I think it’s still too soon to consider concrete suggestions for change, especially non-trivial ones. - If by Java 8 EOL you mean the time when the last vendor offers extended support for it, then 2030 is, I believe, the *earliest* possible date that is guaranteed *now. It’s possible that support would be extended until 2130. Such offerings have no bearing on the development of current JDK versions. - The number of significant code changes required since JDK 8 to keep up with current JDK releases is, for the vast majority of Java users, low (what’s affected most users is reliance on non-spec-compliant libraries, and the need to import the external artefacts for EE). The most impactful change has probably been the removal of some client deployment technologies from the Oracle JDK, but as far as OpenJDK is concerned, the affected areas have been CORBA, pack200, Nashorn, and now the process to remove SM is starting. The number of people using any one of these is low, and the number of those who need to work hard for alternatives is very low. I think that advance warning, and then support offerings by multiple vendors for those who have not managed to migrate in the advance warning period is reasonable; always offering ways to support removed technologies together with new features in current releases with the same code base is not. When compared with other ecosystems, Java’s strategy is exceptionally tolerant of those that prefer slow change. - Property-based testing is wonderful, I wish more people would use it, and I hope to see it used in the JDK as well. Java has several PBT tools, but I believe the most popular one these days is https://jqwik.net/. As long as you’re still with Java, give it a try. — Ron > On 31 Jul 2021, at 04:04, Peter Firmstone <peter.firmst...@zeus.net.au> wrote: > > 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. > > The blocker is the ability to implement guard checks using Agents on public > API, due to finalizer attack defensive private static methods in constructors. > > 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? > > Furthermore, as developers must support multiple Java releases, I propose the > following amendments, to ease difficulties of multiple release support (with > multi release jars): > > * 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. > * 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. > * 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). > * Remove finalizers, and defensive methods in constructors where > permissions check points occur as these cause problems for Agents, > prior to removal of SecurityManager. > * Deprecate for removal Permission implementations, then remove them > in a following release. > * Remove SecurityManager. > > 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. > > 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, > https://hackage.haskell.org/package/QuickCheck, no need to worry about null > pointers and less boilerplate. > > 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. > > Thanks, > > Peter >
