From peter.firmstone at zeus.net.au Sun Aug 1 02:14:34 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Sun, 1 Aug 2021 12:14:34 +1000 Subject: JEP 411, removal of finalizers, a path forward. In-Reply-To: References: Message-ID: Hi Ron, So far we have dealt with CORBA (external library), pack200 (working on an external lib) and to support Java 17, removed some Activation class dependencies (we don't use RMID, so grabbed the missing Activation classes from Apache Harmony), thankfully these were not challenging, although replacement of some Activation classes will require downstream developers to edit their imports and recompile their code, some are still stuck on Jini 2.1 api compatibility, I have a Jini 2.1 compatibility layer, that allows them to use JGDMS without re-compiling, they will be impacted by the changes.? There are a number of projects that use the Jini 2.1 api still. We have a number of our own permission implementations of course, such as DeSerialzationPermission and one that's misnamed called DownloadPermission, which should have been called "ClassLoadingPermission", because it doesn't prevent code downloads, URLPermission does that. These are actually external defenses, and are best granted to authenticated services (dynamically granted incrementally following successful authentication), these are gates in the process of loading a service proxy. We only let the good guys through the door, but we still have a gun safe to stop the kids from accidentally shooting each other. So we've figured out that we can recreate most of the authentication layer, the challenges will be implementing Java platform level guards. That's why we still need authorization controls on things like ClassLoading, network, filesystems and properties, once we allow the service proxy to load code.? It appears unlikely that OpenJDK will provide hooks here, so we need to wait for finalizers to be removed, so we can instrument constructors (we don't want to inadvertently open any holes to the outside by making ClassLoader sensitive to finalizer attacks). Perhaps with ClassLoader, we should instead guard the actual methods that load classes instead of the constructor, it's not practical to do that with network connections however as it would take a big performance hit, same with filesystems.?? Our reimplementation of URLClassLoader is much faster because it doesn't make unnecessary DNS calls, so a small impact with guards, we may still be faster anyway. The policy tool currently used for auditing to establish trust will need to be replaced by new tools that OpenJDK is providing in future.?? Clearly auditing needs to increase to offset missing permission checks.? Once we do that, then we can use SHA hashes to identify codebases and allow their classes to be loaded. It's still a moving target, with potentially significant implications if we get it wrong. Whether we continue developing in Java will depend on a number of factors: 1. How successful we are at navigating JEP 411. 2. Other future JEP disruptors (assuming we succeed with JEP 411). 3. Overall cost of development and maintenance in Java, v's another language. 4. Cost / benefit of using another language. 5. API stability of other languages. 6. Longevity of other languages v's Java. I'm working on the assumption that OpenJDK will close any external holes currently defended by permission checks.? It would be good if the JDK was secure by default, with properties required to be set for allowing such things as agents, management, parsing xml and serialization. We still need some authorization layer controls for trusted users and services, and balance it with increased auditing of code. It's not possible with static analysis to determine the intended use of reflection, so we'll need new observability tools to replace the current policy tools.?? Perhaps we can link the observability tools to a service watchdog, if a service proxy misbehaves, then, it gets blacklisted and the affected JVM is immediately restarted. Our code is dynamic, so we might need to create an audit service that provides a list of audited proxy codebases and their SHA-256 hashes. Keep in mind this is all completely experimental and subject to change. Regards, Peter. On 31/07/2021 6:22 pm, Ron Pressler wrote: > 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 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 >> -- Regards, Peter Firmstone 0498 286 363 Zeus Project Services Pty Ltd. From Rony.Flatscher at wu.ac.at Sun Aug 1 13:01:56 2021 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Sun, 1 Aug 2021 15:01:56 +0200 Subject: Fate of {System|Runtime}.runFinalization (Re: Ad removing finalize eventually (Re: JEP 411 Headaches: Instrumenting private methods in the JDK for authorization checkpoints. In-Reply-To: <67886c79-aef1-bc41-0057-9acb943a0e0f@wu.ac.at> References: <19858490-648a-d539-2429-b1999f597658@zeus.net.au> <8d6f394d-f0a8-fa41-24ec-f8437af99d4f@oracle.com> <8f9e9e58-d5bb-0a99-7f3e-937a33c9e2b8@zeus.net.au> <0ae93ef1-3416-9cc0-d6e3-2fe1ccb1df4f@oracle.com> <67886c79-aef1-bc41-0057-9acb943a0e0f@wu.ac.at> Message-ID: <3b555f81-2cb5-73dd-90d4-e37d9549cb56@wu.ac.at> Maybe a last question in this context: is it planned that {System|Runtime.getRuntime()}.runFinalization() gets removed when finalize() gets removed? If so, would there be an equivalent? ---rony On 27.07.2021 12:01, Rony G. Flatscher wrote: > Ad Alan's remark about eventually removing finalize in this thread: > > On 25.07.2021 16:44, Alan Bateman wrote: > > ... cut ... >> That said, there is strong desire to eventually remove finalization too. Finalization was >> deprecated several years ago and the Java platform defines APIs that provide much more flexible >> and efficient ways do run cleanup actions when an object becomes unreachable. So another >> multi-year/multi-release effort to remove a problematic feature, just nothing to do with this JEP. > ... cut ... > > A question: what alternatives are you thinking of? > > Background of the question: in an ooRexx-Java bridge for each Java object an ooRexx peer object gets > created and needs to exist as long as the Java object exists. Once the Java object gets garbage > collected the ooRexx peer object needs to be freed as well. The bridge between ooRexx (an > interpreted, message based, dynamically typed language) and Java is realized via JNI. Currently > (actually since 20 years) on the Java side the finalize method gets employed to signal to ooRexx > that its ooRexx peer object needs to be removed. > > So when you think of removing finalize and think of replacements for it, is there already a > replacement devised which can be used for determining that a Java "object became unreachable"/is not > referred to anymore/about to be garbage collected (or not being interacted with anymore for good) > and be able to communicate that fact/event? What would that be? Are there already discussions, ideas > about this somewhere? > > ---rony > > P.S.: I remember the comment back then that finalize although deprecated for use (not for removal) > for Java programs will not be removed as such use cases as described above need to use it. From adinn at redhat.com Sun Aug 1 13:15:29 2021 From: adinn at redhat.com (Andrew Dinn) Date: Sun, 1 Aug 2021 14:15:29 +0100 Subject: JEP 411, removal of finalizers, a path forward. In-Reply-To: References: Message-ID: <4257646b-6678-5419-13ae-5b470d4c510d@redhat.com> On 01/08/2021 03:14, Peter Firmstone wrote: > I'm working on the assumption that OpenJDK will close any external holes > currently defended by permission checks.? It would be good if the JDK > was secure by default, with properties required to be set for allowing > such things as agents, management, parsing xml and serialization. You need to stop repeating this canard. There is no absolute need for OpenJDK to retain a security mechanism to deal with problems that for almost every use case are better solved by using non-OpenJDK alternatives (such as OS security measures). Indeed, it's the other way round: there is an imperative for the project to spend precious resources on alternative capabilities (not necessarily security related). The fact that your software can no longer profit from this specific mechanism is a /special case/ which means any loss incurred is a /special loss/ not a general one. Users who rely on your software for the security guarantees you claim it provides may well no longer be able to do so once this mechanism is removed. However, claiming that this implies Java is no longer secure by default is a /gross/ misrepresentation of what is at stake. Java can be used perfectly well to implement secure applications without the security manager. That's evidenced by two facts: on the one hand experience has shown that most programs that rely on the security manager are not actually more secure because of using it; on the other hand there are many highly secure Java programs out there in the field. The fact that your software will no longer provide a specific route to implementing a certain type of security capability may be a great loss to you but it is not a significant loss, never mind some absolute loss in kind, to Java and Java application developers. I recommend you stop repeating this distorted opinion. It's only effect will be squander the goodwill of those currently trying to help you, people whose driving interest is nothing other than to make OpenJDK a better product. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From uschindler at apache.org Sun Aug 1 14:28:16 2021 From: uschindler at apache.org (Uwe Schindler) Date: Sun, 1 Aug 2021 16:28:16 +0200 Subject: JEP 411, removal of finalizers, a path forward. In-Reply-To: <4257646b-6678-5419-13ae-5b470d4c510d@redhat.com> References: <4257646b-6678-5419-13ae-5b470d4c510d@redhat.com> Message-ID: <000001d786e1$7885b0b0$69911210$@apache.org> Hi Andrew, > > I'm working on the assumption that OpenJDK will close any external holes > > currently defended by permission checks. It would be good if the JDK > > was secure by default, with properties required to be set for allowing > > such things as agents, management, parsing xml and serialization. > > You need to stop repeating this canard. There is no absolute need for > OpenJDK to retain a security mechanism to deal with problems that for > almost every use case are better solved by using non-OpenJDK > alternatives (such as OS security measures). Indeed, it's the other way > round: there is an imperative for the project to spend precious > resources on alternative capabilities (not necessarily security related). Sorry, as another open source project affected by the stupid JEP 411 desaster I would like to fully confirm to EVERYTHING that Peter said. It is not a canard, it is the reality and I am really disappointed what happened. What I figured out: You intend to remove SecurityManager because it does not fit your latest ideas how Java threads should behave. I know the main problem is not "SecurityManager is too complex / too slow / wrongly used /..." -- the main problem of some OpenJDK people around the Loom project is that it won't work correctly with those new type of threads. You are now always arguing against use cases of SecurityManager for the purpose of secuirty because you just want to hide that the new "light" threads (aka fibers) in project Loom are incompatible to the stack-based access control provided by AccessController and SecurityManager. So the only canard is Project Loom - sorry! So I will do the same: repeat the same story like Peter's over an over. Two large projects affected by your changes are Apache Solr and Elasticsearch. Both use security manager not only for security purposes, but also to control access to resources and classloading! Speed is also no issue if you use security manager correctly. In Apache Lucene/Solr/Elasticsearch there is NO slowdown visible as the hooks into security manager are only called for uncritical places (like opening a file before mmapping it, open a listening socket, loading a class...). The problem is: you deprecate for removal without offering any API to replace the main pain points: - preventing exit of JDK - an API to control class loading and prevent code from calling Method/Field/Constructor#setAccessible(true) for specific cases (e.g., you want a scripting language like Groovy to not allow caling sun.misc.Unsafe,...). Those things can never be done with code outside of the JVM! - Allow to hook into the I/O system. Unfortunately the java.nio FileSystem API is not enough: it does not cover java.io.File (why is this the case?) nor does the FileSystem API allows to hook in everywhere. We figured out that for example the new Panama interface to get a MemorySegment from a file path is not calling any API in the Filesystem abstraction! - Disable damn java serialization completely > The fact that your software can no longer profit from this specific > mechanism is a /special case/ which means any loss incurred is a > /special loss/ not a general one. Users who rely on your software for > the security guarantees you claim it provides may well no longer be able > to do so once this mechanism is removed. However, claiming that this > implies Java is no longer secure by default is a /gross/ > misrepresentation of what is at stake. The name "SecurityManager" is a legacy name. In fact "AccessController" and "Policy" is much better and exactly suits our needs and what we expect from it. We don't want security, we want access control and corresponding policies. That 2 different things! > Java can be used perfectly well to implement secure applications without > the security manager. That's evidenced by two facts: on the one hand > experience has shown that most programs that rely on the security > manager are not actually more secure because of using it; on the other > hand there are many highly secure Java programs out there in the field. That might be true, but the current state does not allow this for all use cases. Most projects use Security Manager not for security. Look at the code out there! > The fact that your software will no longer provide a specific route to > implementing a certain type of security capability may be a great loss > to you but it is not a significant loss, never mind some absolute loss > in kind, to Java and Java application developers. I recommend you stop > repeating this distorted opinion. It's only effect will be squander the > goodwill of those currently trying to help you, people whose driving > interest is nothing other than to make OpenJDK a better product. It is a great loss for many people, not only Peter. In Apache Lucene, Solr and Elastisearch, usage of SecurityManager will stay alive as long as possible (possible till Java version 27 or later). If it won't work anymore without a replacement to address the above painpoints Please revert the deprecation of SecurityManager and possibly delay the release of Java 17. In Java 18 work on new APIs like proposed in the JEP and then in Java 19 you can do a second try to deprecate/remove SecurityManager. Deprecating something without a proper replacement for the pain point is a bad idea. We have seen this in Java 9 already: Suddenly the module system was weakened shortly before release: because there was no replacement for sun.misc.Unsafe. Kind regards, Uwe From mbien42 at gmail.com Sun Aug 1 16:35:21 2021 From: mbien42 at gmail.com (Michael Bien) Date: Sun, 1 Aug 2021 18:35:21 +0200 Subject: JEP 411, removal of finalizers, a path forward. In-Reply-To: <000001d786e1$7885b0b0$69911210$@apache.org> References: <4257646b-6678-5419-13ae-5b470d4c510d@redhat.com> <000001d786e1$7885b0b0$69911210$@apache.org> Message-ID: <5f51d3c5-8377-daa1-324e-a918a8835a1c@gmail.com> On 01.08.21 16:28, Uwe Schindler wrote: > The problem is: you deprecate for removal without offering any API to replace the main pain points: > ... > - Disable damn java serialization completely JDK 9+ JVM flag / security property, see JEP 290 -Djdk.serialFilter=!* regards, michael From mbien42 at gmail.com Sun Aug 1 16:58:42 2021 From: mbien42 at gmail.com (Michael Bien) Date: Sun, 1 Aug 2021 18:58:42 +0200 Subject: JEP 411, removal of finalizers, a path forward. In-Reply-To: <5f51d3c5-8377-daa1-324e-a918a8835a1c@gmail.com> References: <4257646b-6678-5419-13ae-5b470d4c510d@redhat.com> <000001d786e1$7885b0b0$69911210$@apache.org> <5f51d3c5-8377-daa1-324e-a918a8835a1c@gmail.com> Message-ID: On 01.08.21 18:35, Michael Bien wrote: > On 01.08.21 16:28, Uwe Schindler wrote: >> The problem is: you deprecate for removal without offering any API to >> replace the main pain points: >> ... >> - Disable damn java serialization completely > > JDK 9+ JVM flag / security property, see JEP 290 > > -Djdk.serialFilter=!* > > regards, > > michael > (for deserialization only) -michael From Alan.Bateman at oracle.com Sun Aug 1 18:48:37 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 1 Aug 2021 19:48:37 +0100 Subject: JEP 411, removal of finalizers, a path forward. In-Reply-To: <000001d786e1$7885b0b0$69911210$@apache.org> References: <4257646b-6678-5419-13ae-5b470d4c510d@redhat.com> <000001d786e1$7885b0b0$69911210$@apache.org> Message-ID: <7e56d243-843c-47b1-53fb-383cade3cd7e@oracle.com> On 01/08/2021 15:28, Uwe Schindler wrote: > : > What I figured out: You intend to remove SecurityManager because it does not fit your latest ideas how Java threads should behave. I know the main problem is not "SecurityManager is too complex / too slow / wrongly used /..." -- the main problem of some OpenJDK people around the Loom project is that it won't work correctly with those new type of threads. You are now always arguing against use cases of SecurityManager for the purpose of secuirty because you just want to hide that the new "light" threads (aka fibers) in project Loom are incompatible to the stack-based access control provided by AccessController and SecurityManager. So the only canard is Project Loom - sorry! This isn't right, I don't know where you got that. The only connection to threads is the unspecified capturing of an access control context at Thread create time. Loom has been betting that it will be irrelevant and eventually removed so doesn't capture it. For the interim it just specifies that virtual threads have "no permissions". > : > > > - Allow to hook into the I/O system. Unfortunately the java.nio FileSystem API is not enough: it does not cover java.io.File (why is this the case?) nor does the FileSystem API allows to hook in everywhere. We figured out that for example the new Panama interface to get a MemorySegment from a file path is not calling any API in the Filesystem abstraction! There are bootstrapping and compatibility issues, this isn't the right place to go into all that. > We have seen this in Java 9 already: Suddenly the module system was weakened shortly before release: because there was no replacement for sun.misc.Unsafe. This isn't right either. Critical internal APIs, including sun.misc.Unsafe, were never encapsulated. So no change to the accessibility of Unsafe when relaxed strong encapsulated was introduced in Java 9. -Alan From Alan.Bateman at oracle.com Sun Aug 1 19:02:07 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 1 Aug 2021 20:02:07 +0100 Subject: Fate of {System|Runtime}.runFinalization (Re: Ad removing finalize eventually In-Reply-To: <3b555f81-2cb5-73dd-90d4-e37d9549cb56@wu.ac.at> References: <19858490-648a-d539-2429-b1999f597658@zeus.net.au> <8d6f394d-f0a8-fa41-24ec-f8437af99d4f@oracle.com> <8f9e9e58-d5bb-0a99-7f3e-937a33c9e2b8@zeus.net.au> <0ae93ef1-3416-9cc0-d6e3-2fe1ccb1df4f@oracle.com> <67886c79-aef1-bc41-0057-9acb943a0e0f@wu.ac.at> <3b555f81-2cb5-73dd-90d4-e37d9549cb56@wu.ac.at> Message-ID: <39c357e2-dc51-32ae-71fa-c8aebde1aeb5@oracle.com> On 01/08/2021 14:01, Rony G. Flatscher wrote: > Maybe a last question in this context: is it planned that > {System|Runtime.getRuntime()}.runFinalization() gets removed when finalize() gets removed? If so, > would there be an equivalent? > There isn't a proposal or JEP yet for the next steps for finalization. The runFinalization method should probably be deprecated. It might be that the method is eventually "degraded" to do nothing or throw an exception, too early to say. Aside from System.gc, there isn't an API exposed to "help" reference processing. -Alan From peter.firmstone at zeus.net.au Mon Aug 2 06:00:48 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Mon, 2 Aug 2021 16:00:48 +1000 Subject: JEP 411, removal of finalizers, a path forward. In-Reply-To: <7e56d243-843c-47b1-53fb-383cade3cd7e@oracle.com> References: <4257646b-6678-5419-13ae-5b470d4c510d@redhat.com> <000001d786e1$7885b0b0$69911210$@apache.org> <7e56d243-843c-47b1-53fb-383cade3cd7e@oracle.com> Message-ID: <99e07440-81e7-216a-5d15-17a51501146f@zeus.net.au> On 2/08/2021 4:48 am, Alan Bateman wrote: > On 01/08/2021 15:28, Uwe Schindler wrote: >> : >> What I figured out: You intend to remove SecurityManager because it >> does not fit your latest ideas how Java threads should behave. I know >> the main problem is not "SecurityManager is too complex / too slow / >> wrongly used /..." -- the main problem of some OpenJDK people around >> the Loom project is that it won't work correctly with those new type >> of threads. You are now always arguing against use cases of >> SecurityManager for the purpose of secuirty because you just want to >> hide that the new "light" threads (aka fibers) in project Loom are >> incompatible to the stack-based access control provided by >> AccessController and SecurityManager. So the only canard is Project >> Loom - sorry! > This isn't right, I don't know where you got that. The only connection > to threads is the unspecified capturing of an access control context > at Thread create time. Loom has been betting that it will be > irrelevant and eventually removed so doesn't capture it. For the > interim it just specifies that virtual threads have "no permissions". Alternatively for loom virtual threads; use an unprivileged context instead of inherited context.? A good choice for all threads actually, not just virtual.? Fixes viral permissions, Executor task vulnerabilities, it requires downstream developers to add doPrivileged methods before an application can do something that's privileged and reduces pain for people more focused on granting privileges to Principals. Developers who use SM are reading JEP 411 and interpreting it as biased towards SM removal, so are looking for an underlying motivation for SM removal not stated there.? I also suspected that Loom might be the reason at one point. From our discussions, my interpretation is that OpenJDK is constrained by corporate security policy; any issues with SecurityManager infrastructure will be treated as confidential security issues and have to be fixed with internal resources. Community volunteers won't be allowed to handle them.? Hence it's the maintenance burden.? I see this maintenance cost as a bureaucratic management issue, rather than an issue with SM per se. I have previously suggested that SM infrastructure bugs not be handled as security issues, instead reported as authorization layer bugs, with any support for sandboxing removed.? If it is true what Andrew Dinn suggests, that OS measures are more appropriate, then these bugs don't need to be treated as security issues and can be downgraded, to allow the community using it, to maintain SM infrastructure instead.? This way, it doesn't impact other developers who don't use it.?? If Andrew is correct, we can downgrade bugs in SM code, they are not security bugs in the traditional sense, if that isn't the case, then Andrew is likely incorrect. Uwe, thanks for speaking up, the more people who speak up about their use of SM, as an authorization layer, rather than a sandbox for code with malicious intent, the less OpenJDK will consider this use of SM is a /special case/. Regards, Peter. From fweimer at redhat.com Mon Aug 2 06:23:43 2021 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 02 Aug 2021 08:23:43 +0200 Subject: JEP 411, removal of finalizers, a path forward. In-Reply-To: <99e07440-81e7-216a-5d15-17a51501146f@zeus.net.au> (Peter Firmstone's message of "Mon, 2 Aug 2021 16:00:48 +1000") References: <4257646b-6678-5419-13ae-5b470d4c510d@redhat.com> <000001d786e1$7885b0b0$69911210$@apache.org> <7e56d243-843c-47b1-53fb-383cade3cd7e@oracle.com> <99e07440-81e7-216a-5d15-17a51501146f@zeus.net.au> Message-ID: <8735rstle8.fsf@oldenburg.str.redhat.com> * Peter Firmstone: > From our discussions, my interpretation is that OpenJDK is constrained > by corporate security policy; any issues with SecurityManager > infrastructure will be treated as confidential security issues and > have to be fixed with internal resources. Community volunteers won't > be allowed to handle them.? Hence it's the maintenance burden.? I see > this maintenance cost as a bureaucratic management issue, rather than > an issue with SM per se. The dynamics would likely change if the community started fixing issues. A starting point could be speculative execution vulnerabilities, which are currently out of scope for the OpenJDK security process: Java and Speculative Execution Vulnerabilities I think any use of the security manager for isolation purposes would have to address those issues. Thanks, Florian From peter.firmstone at zeus.net.au Mon Aug 2 07:49:33 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Mon, 2 Aug 2021 17:49:33 +1000 Subject: JEP 411, removal of finalizers, a path forward. In-Reply-To: <8735rstle8.fsf@oldenburg.str.redhat.com> References: <4257646b-6678-5419-13ae-5b470d4c510d@redhat.com> <000001d786e1$7885b0b0$69911210$@apache.org> <7e56d243-843c-47b1-53fb-383cade3cd7e@oracle.com> <99e07440-81e7-216a-5d15-17a51501146f@zeus.net.au> <8735rstle8.fsf@oldenburg.str.redhat.com> Message-ID: Thanks Florian, 1. If I fix that bug, will JEP 411 be cancelled??? BTW. Sparc isn't vulnerable. 2. My primary use case is for SM is for authorization decisions for remote users and services. JSR-121: Java Application Isolation API Specification. http://apt.cs.manchester.ac.uk/intranet/csonly/jamaica/j2se_isolate-1_0-prd-spec/docs/java/lang/isolate/package-summary.html People keep confusing isolation with authorization, these aren't the same thing, Isolates were designed for Isolation, which never made it into Java SE and AccessController was designed for authorization access controls.? Other access controls are part of the language, such as public, private, protected modifiers etc. Applets had a weak form of isolation using ClassLoader's, and had permissions to connect to their originating network address.? I don't think anyone has developed Applets for at least 10 years? I'm talking about currently maintained software that uses SM for authorization decisions and am looking for ways to re-implement authorization in JDK libraries using Agents. Often constructors contain permission guard checks, but due to finalizer defenses, these cannot be instrumented without instrumenting private static methods.? The alternative is to instrument object methods instead, however these would impact performance (although I'm considering instrumenting ClassLoader object methods). An example of a generated grant, note how the SHA-384 signature of the file is captured, along with the User?? This doesn't include dynamically granted permissions which occur during authorization, then downloading, class loading and unmarshalling of a service proxy. grant codebase "httpmd://${HOST}:9080/${mercury-dl.jar};sha-384=041531e5e3de288c121e865af8a46f7af86172ee0127dc4aff4f551c73a0ad604f51cb1c53076140fd415f957c14e8dd", ??? principal javax.security.auth.x500.X500Principal "CN=Outrigger" { ??? permission org.apache.river.api.io.DeSerializationPermission "MARSHALL"; ??? permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Outrigger\" peer javax.security.auth.x500.X500Principal \"CN=Phoenix\"", "connect"; }; Without SM, everyone is authorized, our network connections will allow everyone and anyone in, so I need to re-implement an authorization layer, however OpenJDK has a monopoly on Java libraries. An alternative that isn't being considered at this stage is to remove support for TLS and Kerberos connections from the JDK, and use private virtual networks and a VM instead, however that stops global service discovery over IPv6, and constrains the software in many other areas as well, so it's not being considered at this time. Regards, Peter. On 2/08/2021 4:23 pm, Florian Weimer wrote: > * Peter Firmstone: > >> From our discussions, my interpretation is that OpenJDK is constrained >> by corporate security policy; any issues with SecurityManager >> infrastructure will be treated as confidential security issues and >> have to be fixed with internal resources. Community volunteers won't >> be allowed to handle them.? Hence it's the maintenance burden.? I see >> this maintenance cost as a bureaucratic management issue, rather than >> an issue with SM per se. > The dynamics would likely change if the community started fixing issues. > > A starting point could be speculative execution vulnerabilities, which > are currently out of scope for the OpenJDK security process: > > Java and Speculative Execution Vulnerabilities > > > I think any use of the security manager for isolation purposes would > have to address those issues. > > Thanks, > Florian > From adinn at redhat.com Mon Aug 2 09:17:04 2021 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 2 Aug 2021 10:17:04 +0100 Subject: JEP 411, removal of finalizers, a path forward. In-Reply-To: <000001d786e1$7885b0b0$69911210$@apache.org> References: <4257646b-6678-5419-13ae-5b470d4c510d@redhat.com> <000001d786e1$7885b0b0$69911210$@apache.org> Message-ID: <391deb02-68ba-4d67-7475-e13534dfd97d@redhat.com> On 01/08/2021 15:28, Uwe Schindler wrote: >>> I'm working on the assumption that OpenJDK will close any >>> external holes currently defended by permission checks. It would >>> be good if the JDK was secure by default, with properties >>> required to be set for allowing such things as agents, >>> management, parsing xml and serialization. >> >> You need to stop repeating this canard. There is no absolute need >> for OpenJDK to retain a security mechanism to deal with problems >> that for almost every use case are better solved by using >> non-OpenJDK alternatives (such as OS security measures). Indeed, >> it's the other way round: there is an imperative for the project to >> spend precious resources on alternative capabilities (not >> necessarily security related). > > Sorry, as another open source project affected by the stupid JEP 411 > desaster I would like to fully confirm to EVERYTHING that Peter said. > It is not a canard, it is the reality and I am really disappointed > what happened. Sorry, Uwe, but the canard *is* right there in the comment I quoted from Peter's email i.e. the bogus implication that without the security manager the JDK is not 'secure by default'. Irrespective of how useful the security manager is to your project it is utter steer manure to claim that without it there is a serious security hole. That's not to say different measures may need to be taken by some applications, yours included. I'm not denying that. However, I'm not going to back down when it comes to objecting to the lack of proportionality in Peter's claims. I believe Alan has answered your rather speculative follow-up comments so I'll rest on that clarification. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From ron.pressler at oracle.com Mon Aug 2 10:21:40 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Mon, 2 Aug 2021 10:21:40 +0000 Subject: [External] : RE: JEP 411, removal of finalizers, a path forward. In-Reply-To: <000001d786e1$7885b0b0$69911210$@apache.org> References: <4257646b-6678-5419-13ae-5b470d4c510d@redhat.com> <000001d786e1$7885b0b0$69911210$@apache.org> Message-ID: Hi. JEP 411 says that there is a feature whose value in fulfilling its purpose no longer justifies its high cost, and so it should be removed. What you?re saying is, that?s true, but you should keep it, anyway. Why? Because it can be put to some other, more modest, accidental uses. Now, the "disaster" of removing any feature is directly felt by those who use it, but the "disaster" of *not* removing it is less visible, even though it may be the bigger disaster, as we believe is the case here. Sure, we must consider those applications that use it and how they use it, but we must also consider all those that do not. By not acknowledging those who lose from keeping that mechanism, you're not appreciating the problem that the JEP tries to address. For example, you say you care about non-security uses of SM, but maintaining it comes at the cost of other security measures, and we believe that removing it would improve Java's security overall. While some of the features you say you want could well be addressed by cheaper mechanisms that could reasonably be added, it's possible that some cannot (or not fully). Thankfully, the JDK is flexible and hackable enough ? through things like Java Agents ? that the cost of some capabilities could be borne by those who need them. It's perfectly reasonable to explain what functionality would be helpful to you. It is not reasonable to demand keeping some functionality regardless of its cost. The reality is that to adapt to changing circumstances, the JDK must both add new capabilities as well as drop old ones, or its complexity, and, with it, its maintenance cost would grow without bound. Of course, any help in finding the right balance of cost and benefit in consideration of the needs of the *entire* ecosystem would be appreciated. P.S. Loom has nothing to do with JEP 411. I might have mentioned it when pointing out that virtually all relevant Java features developed in the past decade -- like parallel streams, CompletableFuture, and Loom -- have chosen not to integrate with SM. ? Ron > On 1 Aug 2021, at 15:28, Uwe Schindler wrote: > > Hi Andrew, > >>> I'm working on the assumption that OpenJDK will close any external holes >>> currently defended by permission checks. It would be good if the JDK >>> was secure by default, with properties required to be set for allowing >>> such things as agents, management, parsing xml and serialization. >> >> You need to stop repeating this canard. There is no absolute need for >> OpenJDK to retain a security mechanism to deal with problems that for >> almost every use case are better solved by using non-OpenJDK >> alternatives (such as OS security measures). Indeed, it's the other way >> round: there is an imperative for the project to spend precious >> resources on alternative capabilities (not necessarily security related). > > Sorry, as another open source project affected by the stupid JEP 411 desaster I would like to fully confirm to EVERYTHING that Peter said. It is not a canard, it is the reality and I am really disappointed what happened. > > What I figured out: You intend to remove SecurityManager because it does not fit your latest ideas how Java threads should behave. I know the main problem is not "SecurityManager is too complex / too slow / wrongly used /..." -- the main problem of some OpenJDK people around the Loom project is that it won't work correctly with those new type of threads. You are now always arguing against use cases of SecurityManager for the purpose of secuirty because you just want to hide that the new "light" threads (aka fibers) in project Loom are incompatible to the stack-based access control provided by AccessController and SecurityManager. So the only canard is Project Loom - sorry! > > So I will do the same: repeat the same story like Peter's over an over. Two large projects affected by your changes are Apache Solr and Elasticsearch. Both use security manager not only for security purposes, but also to control access to resources and classloading! Speed is also no issue if you use security manager correctly. In Apache Lucene/Solr/Elasticsearch there is NO slowdown visible as the hooks into security manager are only called for uncritical places (like opening a file before mmapping it, open a listening socket, loading a class...). > > The problem is: you deprecate for removal without offering any API to replace the main pain points: > - preventing exit of JDK > - an API to control class loading and prevent code from calling Method/Field/Constructor#setAccessible(true) for specific cases (e.g., you want a scripting language like Groovy to not allow caling sun.misc.Unsafe,...). Those things can never be done with code outside of the JVM! > - Allow to hook into the I/O system. Unfortunately the java.nio FileSystem API is not enough: it does not cover java.io.File (why is this the case?) nor does the FileSystem API allows to hook in everywhere. We figured out that for example the new Panama interface to get a MemorySegment from a file path is not calling any API in the Filesystem abstraction! > - Disable damn java serialization completely > >> The fact that your software can no longer profit from this specific >> mechanism is a /special case/ which means any loss incurred is a >> /special loss/ not a general one. Users who rely on your software for >> the security guarantees you claim it provides may well no longer be able >> to do so once this mechanism is removed. However, claiming that this >> implies Java is no longer secure by default is a /gross/ >> misrepresentation of what is at stake. > > The name "SecurityManager" is a legacy name. In fact "AccessController" and "Policy" is much better and exactly suits our needs and what we expect from it. We don't want security, we want access control and corresponding policies. That 2 different things! > >> Java can be used perfectly well to implement secure applications without >> the security manager. That's evidenced by two facts: on the one hand >> experience has shown that most programs that rely on the security >> manager are not actually more secure because of using it; on the other >> hand there are many highly secure Java programs out there in the field. > > That might be true, but the current state does not allow this for all use cases. Most projects use Security Manager not for security. Look at the code out there! > >> The fact that your software will no longer provide a specific route to >> implementing a certain type of security capability may be a great loss >> to you but it is not a significant loss, never mind some absolute loss >> in kind, to Java and Java application developers. I recommend you stop >> repeating this distorted opinion. It's only effect will be squander the >> goodwill of those currently trying to help you, people whose driving >> interest is nothing other than to make OpenJDK a better product. > > It is a great loss for many people, not only Peter. In Apache Lucene, Solr and Elastisearch, usage of SecurityManager will stay alive as long as possible (possible till Java version 27 or later). If it won't work anymore without a replacement to address the above painpoints > > Please revert the deprecation of SecurityManager and possibly delay the release of Java 17. In Java 18 work on new APIs like proposed in the JEP and then in Java 19 you can do a second try to deprecate/remove SecurityManager. Deprecating something without a proper replacement for the pain point is a bad idea. We have seen this in Java 9 already: Suddenly the module system was weakened shortly before release: because there was no replacement for sun.misc.Unsafe. > > Kind regards, > Uwe > From peter.firmstone at zeus.net.au Mon Aug 2 10:33:31 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Mon, 2 Aug 2021 20:33:31 +1000 Subject: JEP 411, removal of finalizers, a path forward. In-Reply-To: <391deb02-68ba-4d67-7475-e13534dfd97d@redhat.com> References: <4257646b-6678-5419-13ae-5b470d4c510d@redhat.com> <000001d786e1$7885b0b0$69911210$@apache.org> <391deb02-68ba-4d67-7475-e13534dfd97d@redhat.com> Message-ID: <64671073-b67c-4a83-5949-7a97273349eb@zeus.net.au> Hello Andrew, I think you may be misinterpreting my comment, let me clarify: I'm assuming that during the process of removal of security manager, any external ports or process hooks that we can only turn off now by not granting a permission will be replaced by a command line property or something similar?? Eg, Agents, Management, etc. If this is the case, it would be nice if they were set to off by default, such that they needed to be enabled from the command line.? It's a suggestion. ? So configuration is secure by default.? Eg, similar to how OpenBSD is configured secure by default, is that something RedHat does??? I used RedHat back in the 90's, it was my first Linux distro, on sparc. :) For example, the permissions granted in this policy file: https://github.com/pfirmstone/JGDMS/blob/trunk/qa/harness/policy/defaultsecurephoenix.policy.new Ensure that anything that isn't specifically granted, is switched off, eg agents, management, etc. This file is generated by a policy writing tool, the comments in the policy file, indicate the tests that were run to generate the policy.? It's important to note that we aren't using sandboxing, or isolation, we are simply running with privileges we don't require switched off.?? All network entry points to the JVM require authentication and classes loaded, or data parsed requires authentication first. In my software without SM, authentication isn't required, and there are no defenses against parsing un-trusted data or downloading and loading malicious classes.? Although you've made it clear, you think this is a /special case/ and /special loss/ you needn't concern yourself with and that's fine, you've made your point. In future it will not be possible to switch these features off using policy files, so I imagine that OpenJDK must be considering alternative methods to switch off features that may be security sensitive? We already know de-serialization can be switched off from the command line using: -Djdk.serialFilter=!*, However if you switch off java de-serialization, you best be sure to initialize the serialization framework when starting your JVM, as SM won't be there to stop it being turned back on, if it's not used, it's not initialized, then the property can be changed and is potentially a link in a gadget chain attack where serialization can be re-enabled. :)? Just saying. Not sure what canard you're referring to, is the JDK config secure by default?? If so, then it won't be possible for a malicious java attachment in an email (or an image file) to be run inadvertently and use the attach API to steal secrets.? Although it's processor could be subject to speculative execution attacks. A good reason to use OpenBSD (or Solaris perhaps) on Sparc for secure systems??? I know RedHat is into supporting military application in a big way, but I'm surprised if they're not concerned about speculative execution vulnerabilities. Speculative execution attacks will eventually be addressed in processor architectures, they are trying, we shouldn't assume that we don't need to program defensively because the underlying architecture has speculative execution bugs.? If we do that, then were do we stop? Anyway, if possible I would like to get back to discussing how to instrument the Java API using Agents, and whether we can coordinate removal of finalizers with SM removal. Of course if you'd like to keep SM and cancel JEP 411, as Uwe suggested, I'd support that.? I'm also grateful that Uwe spoke up, and I hope others do as well, so this topic receives further productive discussion.? It would be nice to sort the use cases prior to SM removal.?? JEP 411 appears symbolic at this stage anyway, more JEP's will be created for it's disablement I believe. Regards, Peter. On 2/08/2021 7:17 pm, Andrew Dinn wrote: > On 01/08/2021 15:28, Uwe Schindler wrote: >>>> I'm working on the assumption that OpenJDK will close any >>>> external holes currently defended by permission checks.? It would >>>> be good if the JDK was secure by default, with properties >>>> required to be set for allowing such things as agents, >>>> management, parsing xml and serialization. >>> >>> You need to stop repeating this canard. There is no absolute need >>> for OpenJDK to retain a security mechanism to deal with problems >>> that for almost every use case are better solved by using >>> non-OpenJDK alternatives (such as OS security measures). Indeed, >>> it's the other way round: there is an imperative for the project to >>> spend precious resources on alternative capabilities (not >>> necessarily security related). >> >> Sorry, as another open source project affected by the stupid JEP 411 >> desaster I would like to fully confirm to EVERYTHING that Peter said. >> It is not a canard, it is the reality and I am really disappointed >> what happened. > > Sorry, Uwe, but the canard *is* right there in the comment I quoted > from Peter's email i.e. the bogus implication that without the > security manager the JDK is not 'secure by default'. Irrespective of > how useful the security manager is to your project it is utter steer > manure to claim that without it there is a serious security hole. > > That's not to say different measures may need to be taken by some > applications, yours included. I'm not denying that. However, I'm not > going to back down when it comes to objecting to the lack of > proportionality in Peter's claims. > > I believe Alan has answered your rather speculative follow-up comments > so I'll rest on that clarification. > > regards, > > > Andrew Dinn > ----------- > Red Hat Distinguished Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill > From ron.pressler at oracle.com Mon Aug 2 11:00:09 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Mon, 2 Aug 2021 11:00:09 +0000 Subject: [External] : Re: JEP 411, removal of finalizers, a path forward. In-Reply-To: <64671073-b67c-4a83-5949-7a97273349eb@zeus.net.au> References: <4257646b-6678-5419-13ae-5b470d4c510d@redhat.com> <000001d786e1$7885b0b0$69911210$@apache.org> <391deb02-68ba-4d67-7475-e13534dfd97d@redhat.com> <64671073-b67c-4a83-5949-7a97273349eb@zeus.net.au> Message-ID: <75A781C9-9A0D-4A3B-8E59-352CDCF088BE@oracle.com> Our path to making Java more secure is, indeed, similar to what you?re proposing. The general direction is that the application, rather than the libraries, will have the final say on security-sensitive capabilities. Just as strong encapsulation is now on by default, other things, such as native code, some dynamic Agent capabilities, and perhaps others, will likely require explicit permission by the application on the command line. I don?t know the details about management, but I believe that remote management requires explicit permission already. I am not aware, however, of plans to restrict class loading. The idea is that code is trusted to do what it says it does, and what?s restricted is the ability to manipulate it (without permission) to do something else through transformation or circumvention of its declared API. The default security policy today is already more restrictive than it was a couple of versions ago, and we expect it to become even more restrictive. ? Ron > On 2 Aug 2021, at 11:33, Peter Firmstone wrote: > > Hello Andrew, > > I think you may be misinterpreting my comment, let me clarify: > > I'm assuming that during the process of removal of security manager, any external ports or process hooks that we can only turn off now by not granting a permission will be replaced by a command line property or something similar? Eg, Agents, Management, etc. If this is the case, it would be nice if they were set to off by default, such that they needed to be enabled from the command line. It's a suggestion. So configuration is secure by default. Eg, similar to how OpenBSD is configured secure by default, is that something RedHat does? I used RedHat back in the 90's, it was my first Linux distro, on sparc. :) > > For example, the permissions granted in this policy file: > > https://urldefense.com/v3/__https://github.com/pfirmstone/JGDMS/blob/trunk/qa/harness/policy/defaultsecurephoenix.policy.new__;!!ACWV5N9M2RV99hQ!cVJkwzysH02ZFZWT3rnO_o5viWUCBTm9nnM50QaJ5G9hsg9B3p2naDVYknIrqSNURQ$ > Ensure that anything that isn't specifically granted, is switched off, eg agents, management, etc. > > This file is generated by a policy writing tool, the comments in the policy file, indicate the tests that were run to generate the policy. It's important to note that we aren't using sandboxing, or isolation, we are simply running with privileges we don't require switched off. All network entry points to the JVM require authentication and classes loaded, or data parsed requires authentication first. > > In my software without SM, authentication isn't required, and there are no defenses against parsing un-trusted data or downloading and loading malicious classes. Although you've made it clear, you think this is a /special case/ and /special loss/ you needn't concern yourself with and that's fine, you've made your point. > > In future it will not be possible to switch these features off using policy files, so I imagine that OpenJDK must be considering alternative methods to switch off features that may be security sensitive? > > We already know de-serialization can be switched off from the command line using: -Djdk.serialFilter=!*, > > However if you switch off java de-serialization, you best be sure to initialize the serialization framework when starting your JVM, as SM won't be there to stop it being turned back on, if it's not used, it's not initialized, then the property can be changed and is potentially a link in a gadget chain attack where serialization can be re-enabled. :) Just saying. > > Not sure what canard you're referring to, is the JDK config secure by default? If so, then it won't be possible for a malicious java attachment in an email (or an image file) to be run inadvertently and use the attach API to steal secrets. Although it's processor could be subject to speculative execution attacks. > > A good reason to use OpenBSD (or Solaris perhaps) on Sparc for secure systems? I know RedHat is into supporting military application in a big way, but I'm surprised if they're not concerned about speculative execution vulnerabilities. > > Speculative execution attacks will eventually be addressed in processor architectures, they are trying, we shouldn't assume that we don't need to program defensively because the underlying architecture has speculative execution bugs. If we do that, then were do we stop? > > Anyway, if possible I would like to get back to discussing how to instrument the Java API using Agents, and whether we can coordinate removal of finalizers with SM removal. > > Of course if you'd like to keep SM and cancel JEP 411, as Uwe suggested, I'd support that. I'm also grateful that Uwe spoke up, and I hope others do as well, so this topic receives further productive discussion. It would be nice to sort the use cases prior to SM removal. JEP 411 appears symbolic at this stage anyway, more JEP's will be created for it's disablement I believe. > > Regards, > > Peter. > > On 2/08/2021 7:17 pm, Andrew Dinn wrote: >> On 01/08/2021 15:28, Uwe Schindler wrote: >>>>> I'm working on the assumption that OpenJDK will close any >>>>> external holes currently defended by permission checks. It would >>>>> be good if the JDK was secure by default, with properties >>>>> required to be set for allowing such things as agents, >>>>> management, parsing xml and serialization. >>>> >>>> You need to stop repeating this canard. There is no absolute need >>>> for OpenJDK to retain a security mechanism to deal with problems >>>> that for almost every use case are better solved by using >>>> non-OpenJDK alternatives (such as OS security measures). Indeed, >>>> it's the other way round: there is an imperative for the project to >>>> spend precious resources on alternative capabilities (not >>>> necessarily security related). >>> >>> Sorry, as another open source project affected by the stupid JEP 411 >>> desaster I would like to fully confirm to EVERYTHING that Peter said. >>> It is not a canard, it is the reality and I am really disappointed >>> what happened. >> >> Sorry, Uwe, but the canard *is* right there in the comment I quoted from Peter's email i.e. the bogus implication that without the security manager the JDK is not 'secure by default'. Irrespective of how useful the security manager is to your project it is utter steer manure to claim that without it there is a serious security hole. >> >> That's not to say different measures may need to be taken by some applications, yours included. I'm not denying that. However, I'm not going to back down when it comes to objecting to the lack of proportionality in Peter's claims. >> >> I believe Alan has answered your rather speculative follow-up comments so I'll rest on that clarification. >> >> regards, >> >> >> Andrew Dinn >> ----------- >> Red Hat Distinguished Engineer >> Red Hat UK Ltd >> Registered in England and Wales under Company Registration No. 03798903 >> Directors: Michael Cunningham, Michael ("Mike") O'Neill >> From adinn at redhat.com Mon Aug 2 13:07:15 2021 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 2 Aug 2021 14:07:15 +0100 Subject: JEP 411, removal of finalizers, a path forward. In-Reply-To: <64671073-b67c-4a83-5949-7a97273349eb@zeus.net.au> References: <4257646b-6678-5419-13ae-5b470d4c510d@redhat.com> <000001d786e1$7885b0b0$69911210$@apache.org> <391deb02-68ba-4d67-7475-e13534dfd97d@redhat.com> <64671073-b67c-4a83-5949-7a97273349eb@zeus.net.au> Message-ID: On 02/08/2021 11:33, Peter Firmstone wrote: > I think you may be misinterpreting my comment, let me clarify: Really? I'd suggest only if you stretch the meaning of your words beyond their elastic limit. > I'm assuming that during the process of removal of security manager, any > external ports or process hooks that we can only turn off now by not > granting a permission will be replaced by a command line property or > something similar?? Eg, Agents, Management, etc. If this is the case, it > would be nice if they were set to off by default, such that they needed > to be enabled from the command line.? It's a suggestion. . . . They might be or they might not be replaced -- and, indeed, you are welcome to help the project to make that a possibility. However, even if they were not replaced or enabled as default behaviours the platform would not fail to be 'secure by default'. At worst, it might be lacking belt and braces when it comes to available means for enforcing some specific forms of control over execution -- controls that can be used to resolve some security problems, but not exclusively. Yet, you keep using language that implies the loss of the security manager is a significant threat to the security of OpenJDK/Java. Claiming now that all you meant was that you would like to have APIs that give you similar mechanisms to what is being removed does not was and will not validate the use of such exaggerated language. Nor do such statements give anyone confidence that you are able to identify clear and compelling requirements and assess the effort that might be needed to satisfy them and maintain an implementation. So, maybe you should just stop making out that your concerns are a major problem to most developers and that they threaten the integrity of the platform and instead concentrate on identifying simple and maintainable APIs that we can feasibly add to OpenJDK without incurring an unjustifiable maintenance burden. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From Rony.Flatscher at wu.ac.at Mon Aug 2 13:12:17 2021 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Mon, 2 Aug 2021 15:12:17 +0200 Subject: Fate of {System|Runtime}.runFinalization (Re: Ad removing finalize eventually In-Reply-To: <39c357e2-dc51-32ae-71fa-c8aebde1aeb5@oracle.com> References: <19858490-648a-d539-2429-b1999f597658@zeus.net.au> <8d6f394d-f0a8-fa41-24ec-f8437af99d4f@oracle.com> <8f9e9e58-d5bb-0a99-7f3e-937a33c9e2b8@zeus.net.au> <0ae93ef1-3416-9cc0-d6e3-2fe1ccb1df4f@oracle.com> <67886c79-aef1-bc41-0057-9acb943a0e0f@wu.ac.at> <3b555f81-2cb5-73dd-90d4-e37d9549cb56@wu.ac.at> <39c357e2-dc51-32ae-71fa-c8aebde1aeb5@oracle.com> Message-ID: <19cc0c9c-1b93-8af9-28db-a07f2b9c71e5@wu.ac.at> On 01.08.2021 21:02, Alan Bateman wrote: > On 01/08/2021 14:01, Rony G. Flatscher wrote: >> Maybe a last question in this context: is it planned that >> {System|Runtime.getRuntime()}.runFinalization() gets removed when finalize() gets removed? If so, >> would there be an equivalent? >> > There isn't a proposal or JEP yet for the next steps for finalization. The runFinalization method > should probably be deprecated. It might be that the method is eventually "degraded" to do nothing > or throw an exception, too early to say. Aside from System.gc, there isn't an API exposed to > "help" reference processing. Thank you very much for clarifying, so it is safest to remove its usage! ---rony From aph at redhat.com Mon Aug 2 15:27:54 2021 From: aph at redhat.com (Andrew Haley) Date: Mon, 2 Aug 2021 16:27:54 +0100 Subject: Ad removing finalize eventually (Re: JEP 411 Headaches: Instrumenting private methods in the JDK for authorization checkpoints. In-Reply-To: <67886c79-aef1-bc41-0057-9acb943a0e0f@wu.ac.at> References: <19858490-648a-d539-2429-b1999f597658@zeus.net.au> <8d6f394d-f0a8-fa41-24ec-f8437af99d4f@oracle.com> <8f9e9e58-d5bb-0a99-7f3e-937a33c9e2b8@zeus.net.au> <0ae93ef1-3416-9cc0-d6e3-2fe1ccb1df4f@oracle.com> <67886c79-aef1-bc41-0057-9acb943a0e0f@wu.ac.at> Message-ID: <7e0768d2-4afd-23be-8bb4-e66e6f1c3eed@redhat.com> On 7/27/21 11:01 AM, Rony G. Flatscher wrote: > Background of the question: in an ooRexx-Java bridge for each Java object an ooRexx peer object gets > created and needs to exist as long as the Java object exists. Once the Java object gets garbage > collected the ooRexx peer object needs to be freed as well. The bridge between ooRexx (an > interpreted, message based, dynamically typed language) and Java is realized via JNI. Currently > (actually since 20 years) on the Java side the finalize method gets employed to signal to ooRexx > that its ooRexx peer object needs to be removed. One problem is that there's no guarantee that peers ever get removed until a Java program ends, and maybe not even then, so if you actually need that to happen finalizers are not what you need. And if you don't need cleanups to happen, you won't be affected. The "more flexible and efficient" ways to do it are ReferenceQueues, but they'll still suffer from the same problem. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From Rony.Flatscher at wu.ac.at Mon Aug 2 18:39:15 2021 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Mon, 2 Aug 2021 20:39:15 +0200 Subject: Ad removing finalize eventually (Re: JEP 411 Headaches: Instrumenting private methods in the JDK for authorization checkpoints. In-Reply-To: <7e0768d2-4afd-23be-8bb4-e66e6f1c3eed@redhat.com> References: <19858490-648a-d539-2429-b1999f597658@zeus.net.au> <8d6f394d-f0a8-fa41-24ec-f8437af99d4f@oracle.com> <8f9e9e58-d5bb-0a99-7f3e-937a33c9e2b8@zeus.net.au> <0ae93ef1-3416-9cc0-d6e3-2fe1ccb1df4f@oracle.com> <67886c79-aef1-bc41-0057-9acb943a0e0f@wu.ac.at> <7e0768d2-4afd-23be-8bb4-e66e6f1c3eed@redhat.com> Message-ID: On 02.08.2021 17:27, Andrew Haley wrote: > On 7/27/21 11:01 AM, Rony G. Flatscher wrote: >> Background of the question: in an ooRexx-Java bridge for each Java object an ooRexx peer object gets >> created and needs to exist as long as the Java object exists. Once the Java object gets garbage >> collected the ooRexx peer object needs to be freed as well. The bridge between ooRexx (an >> interpreted, message based, dynamically typed language) and Java is realized via JNI. Currently >> (actually since 20 years) on the Java side the finalize method gets employed to signal to ooRexx >> that its ooRexx peer object needs to be removed. > One problem is that there's no guarantee that peers ever get removed until > a Java program ends, and maybe not even then, so if you actually need that > to happen finalizers are not what you need. And if you don't need cleanups > to happen, you won't be affected. > > The "more flexible and efficient" ways to do it are ReferenceQueues, but > they'll still suffer from the same problem. The same is the case with ooRexx that it is not guaranteed that object's uninit-methods (if present) run, although the interpreter does its best to run them once ooRexx objects are not referenced anymore. An important use case for being able to become active at the time that objects (with bound resources) are not referenced anymore are long running applications where resources should get freed as soon as they are not needed anymore. This should work either way. Imagine e.g. a Java based web server where scripts in ooRexx (or in any other language) are running, then it becomes important to be able to release resources that are not needed anymore on either side. E.g. the ooRexx-Java bridge when being used by Java via the Java scripting framework will create a new ooRexx interpreter instance each time a new ScriptEngine gets created, serving as the peer for the ScriptEngine (one could create dozens, even hundreds of such engines, and instrumentate them in parallel, as long as enough resources are available). If the Java ScriptEngine goes out of scope at the Java side its peer ooRexx interpreter instance should be terminated, the same is true for peer objects for either side (Java peer objects for Rexx objects, i.e. Rexx objects being boxed in Java proxy objects, and vice versa, ooRexx peer objects for Java objects such that one can send messages to an ooRexx peer to the Java side where with reflection the appropriate methods get invoked in the corresponding Java object). In the meantime I have a test implementation based on the PhantomReference class (thanks to Peter to point them out) which I will be using for testing different scenarios. One observation (in this case on Java 8) is that if running System.runFinalization() the finalize methods get excercised earlier (it seems at the point in time where objects are finalizable while the runFinalization method executes) and more reliable than the PhantomReference objects showing up on the reference queue (which they may or may not be the case depending on the test circumstances). It would be desirable if finalizable objects (whether they have a finalize method or not) being referred to by PhantomReferences would be put on the reference queue at the point in time runFinalization() executes (in that case it may even make sense to keep runFinalization()). ---rony From hboehm at google.com Mon Aug 2 20:52:35 2021 From: hboehm at google.com (Hans Boehm) Date: Mon, 2 Aug 2021 13:52:35 -0700 Subject: Fate of {System|Runtime}.runFinalization (Re: Ad removing finalize eventually In-Reply-To: <19cc0c9c-1b93-8af9-28db-a07f2b9c71e5@wu.ac.at> References: <19858490-648a-d539-2429-b1999f597658@zeus.net.au> <8d6f394d-f0a8-fa41-24ec-f8437af99d4f@oracle.com> <8f9e9e58-d5bb-0a99-7f3e-937a33c9e2b8@zeus.net.au> <0ae93ef1-3416-9cc0-d6e3-2fe1ccb1df4f@oracle.com> <67886c79-aef1-bc41-0057-9acb943a0e0f@wu.ac.at> <3b555f81-2cb5-73dd-90d4-e37d9549cb56@wu.ac.at> <39c357e2-dc51-32ae-71fa-c8aebde1aeb5@oracle.com> <19cc0c9c-1b93-8af9-28db-a07f2b9c71e5@wu.ac.at> Message-ID: I think we will eventually need something analogous to runFinalization() for Cleaners and/or References. If you are out of some resource managed by Cleaners and want to allocate another one, how do you wait for resources of that kind to be reclaimed? What do you do if you're testing code using Cleaners or References to reclaim resources? This may also be a great opportunity to resolve the long-standing issue of whether it's safe to call runFinalization() with user-visible locks held. What happens when runFinalization's caller holds a lock needed by a finalizer? This should be more tractable for Cleaners and References, since it's easier to maintain separate queues for different classes. On Mon, Aug 2, 2021 at 6:12 AM Rony G. Flatscher wrote: > On 01.08.2021 21:02, Alan Bateman wrote: > > On 01/08/2021 14:01, Rony G. Flatscher wrote: > >> Maybe a last question in this context: is it planned that > >> {System|Runtime.getRuntime()}.runFinalization() gets removed when > finalize() gets removed? If so, > >> would there be an equivalent? > >> > > There isn't a proposal or JEP yet for the next steps for finalization. > The runFinalization method > > should probably be deprecated. It might be that the method is eventually > "degraded" to do nothing > > or throw an exception, too early to say. Aside from System.gc, there > isn't an API exposed to > > "help" reference processing. > > Thank you very much for clarifying, so it is safest to remove its usage! > > ---rony > > > From erik.osterlund at oracle.com Mon Aug 2 21:34:32 2021 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Mon, 2 Aug 2021 21:34:32 +0000 Subject: Fate of {System|Runtime}.runFinalization (Re: Ad removing finalize eventually In-Reply-To: References: <19858490-648a-d539-2429-b1999f597658@zeus.net.au> <8d6f394d-f0a8-fa41-24ec-f8437af99d4f@oracle.com> <8f9e9e58-d5bb-0a99-7f3e-937a33c9e2b8@zeus.net.au> <0ae93ef1-3416-9cc0-d6e3-2fe1ccb1df4f@oracle.com> <67886c79-aef1-bc41-0057-9acb943a0e0f@wu.ac.at> <3b555f81-2cb5-73dd-90d4-e37d9549cb56@wu.ac.at> <39c357e2-dc51-32ae-71fa-c8aebde1aeb5@oracle.com> <19cc0c9c-1b93-8af9-28db-a07f2b9c71e5@wu.ac.at>, Message-ID: Hi Hans, > On 2 Aug 2021, at 22:53, Hans Boehm wrote: > > ?I think we will eventually need something analogous to runFinalization() > for Cleaners and/or References. If you are out of some resource managed by > Cleaners and want to allocate another one, how do you wait for resources of > that kind to be reclaimed? What do you do if you're testing code using > Cleaners or References to reclaim resources? I thought that?s the purpose ish for java.lang.ref.Reference.enqueue(). It lets the cleanup run before the GC gets around to it. If you need more precise synchronization, that can seemingly be managed by the queue owner. /Erik > This may also be a great opportunity to resolve the long-standing issue of > whether it's safe to call runFinalization() with user-visible locks held. > What happens when runFinalization's caller holds a lock needed by a > finalizer? This should be more tractable for Cleaners and References, since > it's easier to maintain separate queues for different classes. > > >> On Mon, Aug 2, 2021 at 6:12 AM Rony G. Flatscher >> wrote: >>> On 01.08.2021 21:02, Alan Bateman wrote: >>> On 01/08/2021 14:01, Rony G. Flatscher wrote: >>>> Maybe a last question in this context: is it planned that >>>> {System|Runtime.getRuntime()}.runFinalization() gets removed when >> finalize() gets removed? If so, >>>> would there be an equivalent? >>> There isn't a proposal or JEP yet for the next steps for finalization. >> The runFinalization method >>> should probably be deprecated. It might be that the method is eventually >> "degraded" to do nothing >>> or throw an exception, too early to say. Aside from System.gc, there >> isn't an API exposed to >>> "help" reference processing. >> Thank you very much for clarifying, so it is safest to remove its usage! >> ---rony From hboehm at google.com Mon Aug 2 23:27:07 2021 From: hboehm at google.com (Hans Boehm) Date: Mon, 2 Aug 2021 16:27:07 -0700 Subject: Fate of {System|Runtime}.runFinalization (Re: Ad removing finalize eventually In-Reply-To: References: <19858490-648a-d539-2429-b1999f597658@zeus.net.au> <8d6f394d-f0a8-fa41-24ec-f8437af99d4f@oracle.com> <8f9e9e58-d5bb-0a99-7f3e-937a33c9e2b8@zeus.net.au> <0ae93ef1-3416-9cc0-d6e3-2fe1ccb1df4f@oracle.com> <67886c79-aef1-bc41-0057-9acb943a0e0f@wu.ac.at> <3b555f81-2cb5-73dd-90d4-e37d9549cb56@wu.ac.at> <39c357e2-dc51-32ae-71fa-c8aebde1aeb5@oracle.com> <19cc0c9c-1b93-8af9-28db-a07f2b9c71e5@wu.ac.at> Message-ID: Thanks for all your helpful responses! I was talking about a somewhat different problem. Let's assume you're using References to manage some type of limited resource S, e.g. a certain type of graphics memory, or file descriptors, or whatever. Each S has a PhantomReference that is enqueued when S is dropped, and the code processing the queue will deallocate the corresponding hardware or native resource. (This of course should be avoided when possible, but it isn't always possible.) When I try to allocate an S, and there aren't any more, I really want to wait until the following have happened to either free one up or convince myself I'm really out of resources: 1) The garbage collector has run at least once. I can do (a sufficient approximation of) that with System.gc() or the like. 2) PhantomReferences with a dead Referent have been enqueued. It's not clear to me that there is a portable way to do this. (System.gc() might sometimes do that. If not, System.gc(); System.runFinalization() probably does. But it's not 100% clear to me what the intent was.) 3) The entire associated ReferenceQueue has been processed once. If my cleanup code is built directly on PhantomReferences, I can implement that. If I use Cleaners, this at least seems to get inelegant. I can't explicitly enqueue anything, since I still don't know what has been dropped. I just know that I appear to be out of S's, possibly because my machine has a zillion bytes of memory, and there's no real reason to actually run the garbage collector to reclaim memory. So my concern is really how to do (2) and (3) in the new world, i.e. wait until unreachable objects found by the last GC have been cleaned. With finalizers, System.runFinalization() effectively did the equivalent of that (potentially modulo the deadlock questions). Hans On Mon, Aug 2, 2021 at 2:34 PM Erik Osterlund wrote: > Hi Hans, > > > On 2 Aug 2021, at 22:53, Hans Boehm wrote: > > > > ?I think we will eventually need something analogous to runFinalization() > > for Cleaners and/or References. If you are out of some resource managed > by > > Cleaners and want to allocate another one, how do you wait for resources > of > > that kind to be reclaimed? What do you do if you're testing code using > > Cleaners or References to reclaim resources? > > I thought that?s the purpose ish for java.lang.ref.Reference.enqueue(). It > lets the cleanup run before the GC gets around to it. If you need more > precise synchronization, that can seemingly be managed by the queue owner. > > /Erik > > > This may also be a great opportunity to resolve the long-standing issue > of > > whether it's safe to call runFinalization() with user-visible locks held. > > What happens when runFinalization's caller holds a lock needed by a > > finalizer? This should be more tractable for Cleaners and References, > since > > it's easier to maintain separate queues for different classes. > > > > > >> On Mon, Aug 2, 2021 at 6:12 AM Rony G. Flatscher < > Rony.Flatscher at wu.ac.at> > >> wrote: > >>> On 01.08.2021 21:02, Alan Bateman wrote: > >>> On 01/08/2021 14:01, Rony G. Flatscher wrote: > >>>> Maybe a last question in this context: is it planned that > >>>> {System|Runtime.getRuntime()}.runFinalization() gets removed when > >> finalize() gets removed? If so, > >>>> would there be an equivalent? > >>> There isn't a proposal or JEP yet for the next steps for finalization. > >> The runFinalization method > >>> should probably be deprecated. It might be that the method is > eventually > >> "degraded" to do nothing > >>> or throw an exception, too early to say. Aside from System.gc, there > >> isn't an API exposed to > >>> "help" reference processing. > >> Thank you very much for clarifying, so it is safest to remove its usage! > >> ---rony > From peter.firmstone at zeus.net.au Tue Aug 3 00:28:51 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Tue, 3 Aug 2021 10:28:51 +1000 Subject: JEP 411, removal of finalizers, a path forward. In-Reply-To: References: <4257646b-6678-5419-13ae-5b470d4c510d@redhat.com> <000001d786e1$7885b0b0$69911210$@apache.org> <391deb02-68ba-4d67-7475-e13534dfd97d@redhat.com> <64671073-b67c-4a83-5949-7a97273349eb@zeus.net.au> Message-ID: Hello Andrew, Loss of SM is a significant threat to my software, if left unresolved. Your interpretations are your own, I make no apologies for your interpretation.? I am describing the difficulties that I am experiencing with JEP 411 migration and how it applies to my situation, it appears that others are having difficulties that they have also expressed on OpenJDK lists, please understand that it is not a trouble free experience, and as such some of my frustrations may leak through into my writing.? In my world, more developers are affected, than are unaffected, but those are my associations, not yours, your experiences may differ from mine. What I have stated, is that existing deployed software that uses SM for authorization access controls, has been designed around SM and will become insecure if SM is removed.?? I refer you to the following book, which our software security architecture is designed around, I have not done research on the number of developers or projects affected (I do not have the time or resources).? I do see quite a number of developers from various projects have stated they will be affected in some way or another on OpenJDK lists, have you followed any up off list, to understand how they're impacted??? Or have you written them off as /special case/ /special loss/ ? https://www.oracle.com/java/technologies/javaee/api-design-implementation.html In JGDMS without SM, at least the following must be addressed to maintain security: 1. TLS and Kerberos connections cannot be established.? (My software is littered with doPrivileged calls that preserve the Subject, we don't have anon TLS connections, we require client certificates). 2. All remote connections are authorized to load classes. 3. All remote connections are authorized to perform deserialization. This doesn't take into account user authorization, with SM gone, it also means that all users and services now have all privileges.? I'm only documenting the major ones here. With SM all the above require authorization and authentication, such that all remote connections are trusted and without malicious intent. I have also presented a number of different compromises, that I thought might address some of the maintenance cost burdens around SM OpenJDK has, so that we might retain the most expensive components to replace. Having established that OpenJDK is not yet willing to compromise, I have been attempting to create an authorization layer using Agents, so that I can restore perimeter security following the removal of SM and support future versions of Java.?? It is my hope that either I will be successful in recreating an authorization layer, or that enough people come forward and OpenJDK decides there are enough affected developers to find a compromise that either makes migration practical, or less expensive. I have previously offered to donate code to OpenJDK, but I was unable to get clarification on whether I could include AL2.0 licensed code from other authors, as my code is not my sole works, two of whom have since passed away (only one at the time).? The remaining authors, I can still get in touch with and request them to sign a contributor agreement, which I myself have signed.?? I can separate out the parts which I am the sole author.? For example my RFC 3986 & RFC 5952 URI implementation is derived from Apache Harmony under AL2.0.?? This work has been in production for many years, and had no issues with the modules added in Java 9, which allowed me to use common policy files in my tests for all supported Java versions.? It's used in both a ClassLoader and a Policy implementation to avoid unnecessary DNS calls.? I have noticed that OpenJDK contains code under the AL2.0 license. This has been a very frustrating experience, I'd suggest, if you haven't got anything of value to add, or cannot be part of the solution, please don't become part of the problem.? I'm doing the best I can to work within constraints to find a solution and am trying not to be part of the problem by allowing my frustration leak through, I've deleted more than I've posted, I suggest you do the same and direct your attack onto problems, rather than people. Thank you. Peter. On 2/08/2021 11:07 pm, Andrew Dinn wrote: > On 02/08/2021 11:33, Peter Firmstone wrote: >> I think you may be misinterpreting my comment, let me clarify: > > Really? I'd suggest only if you stretch the meaning of your words > beyond their elastic limit. > >> I'm assuming that during the process of removal of security manager, >> any external ports or process hooks that we can only turn off now by >> not granting a permission will be replaced by a command line property >> or something similar? Eg, Agents, Management, etc. If this is the >> case, it would be nice if they were set to off by default, such that >> they needed to be enabled from the command line.? It's a suggestion. >> . . . > They might be or they might not be replaced -- and, indeed, you are > welcome to help the project to make that a possibility. However, even > if they were not replaced or enabled as default behaviours the > platform would not fail to be 'secure by default'. At worst, it might > be lacking belt and braces when it comes to available means for > enforcing some specific forms of control over execution -- controls > that can be used to resolve some security problems, but not > exclusively. Yet, you keep using language that implies the loss of the > security manager is a significant threat to the security of OpenJDK/Java. > > Claiming now that all you meant was that you would like to have APIs > that give you similar mechanisms to what is being removed does not was > and will not validate the use of such exaggerated language. Nor do > such statements give anyone confidence that you are able to identify > clear and compelling requirements and assess the effort that might be > needed to satisfy them and maintain an implementation. > > So, maybe you should just stop making out that your concerns are a > major problem to most developers and that they threaten the integrity > of the platform and instead concentrate on identifying simple and > maintainable APIs that we can feasibly add to OpenJDK without > incurring an unjustifiable maintenance burden. > > regards, > > > Andrew Dinn > ----------- > Red Hat Distinguished Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill > From peter.firmstone at zeus.net.au Tue Aug 3 01:30:38 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Tue, 3 Aug 2021 11:30:38 +1000 Subject: [External] : Re: JEP 411, removal of finalizers, a path forward. In-Reply-To: <75A781C9-9A0D-4A3B-8E59-352CDCF088BE@oracle.com> References: <4257646b-6678-5419-13ae-5b470d4c510d@redhat.com> <000001d786e1$7885b0b0$69911210$@apache.org> <391deb02-68ba-4d67-7475-e13534dfd97d@redhat.com> <64671073-b67c-4a83-5949-7a97273349eb@zeus.net.au> <75A781C9-9A0D-4A3B-8E59-352CDCF088BE@oracle.com> Message-ID: <69e09a94-0717-0ac0-74c2-8b0fd78fbc78@zeus.net.au> Thanks Ron, What we do now is dynamic, so we need to figure out how to replicate that post SM.? Things we don't grant dynamically are good candidates for command line argument options. We basically authenticate, then authorize class loading dynamically at runtime, along with other things, such as deserialization (not to be confused with Java Serialization) and network connections. The dynamic grants are removed by garbage collection. Dynamic grants are probably very rare for most developers, although OSGi also supports dynamic grants also, I had a discussion with Peter Kriens around OSGi dynamic grants some years ago. I am still hopeful that OpenJDK might create some hooks for us and keep the AccessController, AccessControlContext and Subject.doAs methods to make supporting all Java versions easier. Also replacing thread inherited context, with an unprivileged context would be good too.? Then remove all the permission implementations and we could use the hooks we need.? The hooks could simply be an empty static method that's not subject to change, so we can instrument it with our own implementation and it gets optimized out at runtime if not used by hotspot.? Clearly if there are alternative mechanisms available from the command line that we don't need to dynamically enable, then they are preferable to adding clutter to policy files.?? The existing policy provider can be removed, so we can strip it down to just the essential minimum components, which removes much of the testing required by OpenJDK. Just curious, when using Agents, what are the recommendations for line numbers in code, for exceptions etc, how are these affected when instrumenting? Quite happy to contribute time to adding hooks and removing other components. Regards, Peter. On 2/08/2021 9:00 pm, Ron Pressler wrote: > Our path to making Java more secure is, indeed, similar to what you?re proposing. > > The general direction is that the application, rather than the libraries, will have the final say on security-sensitive capabilities. > Just as strong encapsulation is now on by default, other things, such as native code, some dynamic Agent capabilities, and > perhaps others, will likely require explicit permission by the application on the command line. I don?t know the details about > management, but I believe that remote management requires explicit permission already. > > I am not aware, however, of plans to restrict class loading. The idea is that code is trusted to do what it says it does, and > what?s restricted is the ability to manipulate it (without permission) to do something else through transformation or > circumvention of its declared API. > > The default security policy today is already more restrictive than it was a couple of versions ago, and we expect it to become > even more restrictive. > > ? Ron > >> On 2 Aug 2021, at 11:33, Peter Firmstone wrote: >> >> Hello Andrew, >> >> I think you may be misinterpreting my comment, let me clarify: >> >> I'm assuming that during the process of removal of security manager, any external ports or process hooks that we can only turn off now by not granting a permission will be replaced by a command line property or something similar? Eg, Agents, Management, etc. If this is the case, it would be nice if they were set to off by default, such that they needed to be enabled from the command line. It's a suggestion. So configuration is secure by default. Eg, similar to how OpenBSD is configured secure by default, is that something RedHat does? I used RedHat back in the 90's, it was my first Linux distro, on sparc. :) >> >> For example, the permissions granted in this policy file: >> >> https://urldefense.com/v3/__https://github.com/pfirmstone/JGDMS/blob/trunk/qa/harness/policy/defaultsecurephoenix.policy.new__;!!ACWV5N9M2RV99hQ!cVJkwzysH02ZFZWT3rnO_o5viWUCBTm9nnM50QaJ5G9hsg9B3p2naDVYknIrqSNURQ$ >> Ensure that anything that isn't specifically granted, is switched off, eg agents, management, etc. >> >> This file is generated by a policy writing tool, the comments in the policy file, indicate the tests that were run to generate the policy. It's important to note that we aren't using sandboxing, or isolation, we are simply running with privileges we don't require switched off. All network entry points to the JVM require authentication and classes loaded, or data parsed requires authentication first. >> >> In my software without SM, authentication isn't required, and there are no defenses against parsing un-trusted data or downloading and loading malicious classes. Although you've made it clear, you think this is a /special case/ and /special loss/ you needn't concern yourself with and that's fine, you've made your point. >> >> In future it will not be possible to switch these features off using policy files, so I imagine that OpenJDK must be considering alternative methods to switch off features that may be security sensitive? >> >> We already know de-serialization can be switched off from the command line using: -Djdk.serialFilter=!*, >> >> However if you switch off java de-serialization, you best be sure to initialize the serialization framework when starting your JVM, as SM won't be there to stop it being turned back on, if it's not used, it's not initialized, then the property can be changed and is potentially a link in a gadget chain attack where serialization can be re-enabled. :) Just saying. >> >> Not sure what canard you're referring to, is the JDK config secure by default? If so, then it won't be possible for a malicious java attachment in an email (or an image file) to be run inadvertently and use the attach API to steal secrets. Although it's processor could be subject to speculative execution attacks. >> >> A good reason to use OpenBSD (or Solaris perhaps) on Sparc for secure systems? I know RedHat is into supporting military application in a big way, but I'm surprised if they're not concerned about speculative execution vulnerabilities. >> >> Speculative execution attacks will eventually be addressed in processor architectures, they are trying, we shouldn't assume that we don't need to program defensively because the underlying architecture has speculative execution bugs. If we do that, then were do we stop? >> >> Anyway, if possible I would like to get back to discussing how to instrument the Java API using Agents, and whether we can coordinate removal of finalizers with SM removal. >> >> Of course if you'd like to keep SM and cancel JEP 411, as Uwe suggested, I'd support that. I'm also grateful that Uwe spoke up, and I hope others do as well, so this topic receives further productive discussion. It would be nice to sort the use cases prior to SM removal. JEP 411 appears symbolic at this stage anyway, more JEP's will be created for it's disablement I believe. >> >> Regards, >> >> Peter. >> >> On 2/08/2021 7:17 pm, Andrew Dinn wrote: >>> On 01/08/2021 15:28, Uwe Schindler wrote: >>>>>> I'm working on the assumption that OpenJDK will close any >>>>>> external holes currently defended by permission checks. It would >>>>>> be good if the JDK was secure by default, with properties >>>>>> required to be set for allowing such things as agents, >>>>>> management, parsing xml and serialization. >>>>> You need to stop repeating this canard. There is no absolute need >>>>> for OpenJDK to retain a security mechanism to deal with problems >>>>> that for almost every use case are better solved by using >>>>> non-OpenJDK alternatives (such as OS security measures). Indeed, >>>>> it's the other way round: there is an imperative for the project to >>>>> spend precious resources on alternative capabilities (not >>>>> necessarily security related). >>>> Sorry, as another open source project affected by the stupid JEP 411 >>>> desaster I would like to fully confirm to EVERYTHING that Peter said. >>>> It is not a canard, it is the reality and I am really disappointed >>>> what happened. >>> Sorry, Uwe, but the canard *is* right there in the comment I quoted from Peter's email i.e. the bogus implication that without the security manager the JDK is not 'secure by default'. Irrespective of how useful the security manager is to your project it is utter steer manure to claim that without it there is a serious security hole. >>> >>> That's not to say different measures may need to be taken by some applications, yours included. I'm not denying that. However, I'm not going to back down when it comes to objecting to the lack of proportionality in Peter's claims. >>> >>> I believe Alan has answered your rather speculative follow-up comments so I'll rest on that clarification. >>> >>> regards, >>> >>> >>> Andrew Dinn >>> ----------- >>> Red Hat Distinguished Engineer >>> Red Hat UK Ltd >>> Registered in England and Wales under Company Registration No. 03798903 >>> Directors: Michael Cunningham, Michael ("Mike") O'Neill >>> -- Regards, Peter Firmstone 0498 286 363 Zeus Project Services Pty Ltd. From peter.firmstone at zeus.net.au Tue Aug 3 05:48:40 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Tue, 3 Aug 2021 15:48:40 +1000 Subject: [External] : Re: JEP 411, removal of finalizers, a path forward. In-Reply-To: <69e09a94-0717-0ac0-74c2-8b0fd78fbc78@zeus.net.au> References: <4257646b-6678-5419-13ae-5b470d4c510d@redhat.com> <000001d786e1$7885b0b0$69911210$@apache.org> <391deb02-68ba-4d67-7475-e13534dfd97d@redhat.com> <64671073-b67c-4a83-5949-7a97273349eb@zeus.net.au> <75A781C9-9A0D-4A3B-8E59-352CDCF088BE@oracle.com> <69e09a94-0717-0ac0-74c2-8b0fd78fbc78@zeus.net.au> Message-ID: <8416aaae-8d12-eb33-fb50-7e861d1c6cbd@zeus.net.au> Just thought I'd share some thoughts around a couple of statements in JEP 411: *|java.security.{AccessController, AccessControlContext, AccessControlException, DomainCombiner}|* ? The primary APIs for the access controller, which is the default implementation to which the Security Manager delegates permission checks. These APIs do not have value without the Security Manager, since certain operations will not work without both a policy implementation and access-control context support in the VM. *|javax.security.auth.SubjectDomainCombiner|* and *|javax.security.auth.Subject::{doAsPrivileged, getSubject}|* ? APIs for user-based authorization that are dependent on Security Manager APIs such as |AccessControlContext| and |DomainCombiner|. We plan to provide a replacement API for |Subject::getSubject| since it is commonly used for use cases that do not require the Security Manager, and to continue to support use cases involving |Subject::doAs| (see below ). We can still use these without an SM, Policy or Permissions for authorization decisions, as mentioned previously I'd replace the inherited thread context with an unprivileged context, and also allow the stack walk to be disabled for people only using Subject. The advantage of retaining these methods, is that where these are used to preserve context for establishing TLS and Kerberos connections, they continue to function, even without SM or policy. They are also a standard API for an authorization layer, for those wishing to re-implement it. Just performed a search for java.security.AccessController on GitHub, got 1,398,418 results for Java: https://github.com/search?l=Java&o=desc&p=3&q=java.security.AccessController+extension%3A.java+language%3AJava+language%3AJava+language%3AJava+language%3AJava&s=indexed&type=Code An example of how DomainCombiner provides access to the underlying ProtectionDomain's on the stack.? We don't need to call ProtectionDomain::Implies(Permission) to make authorization decisions. https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/security/CombinerSecurityManager.java -- Regards, Peter On 3/08/2021 11:30 am, Peter Firmstone wrote: > Thanks Ron, > > What we do now is dynamic, so we need to figure out how to replicate > that post SM.? Things we don't grant dynamically are good candidates > for command line argument options. > > We basically authenticate, then authorize class loading dynamically at > runtime, along with other things, such as deserialization (not to be > confused with Java Serialization) and network connections. The dynamic > grants are removed by garbage collection. Dynamic grants are probably > very rare for most developers, although OSGi also supports dynamic > grants also, I had a discussion with Peter Kriens around OSGi dynamic > grants some years ago. > > I am still hopeful that OpenJDK might create some hooks for us and > keep the AccessController, AccessControlContext and Subject.doAs > methods to make supporting all Java versions easier. Also replacing > thread inherited context, with an unprivileged context would be good > too.? Then remove all the permission implementations and we could use > the hooks we need.? The hooks could simply be an empty static method > that's not subject to change, so we can instrument it with our own > implementation and it gets optimized out at runtime if not used by > hotspot.? Clearly if there are alternative mechanisms available from > the command line that we don't need to dynamically enable, then they > are preferable to adding clutter to policy files.?? The existing > policy provider can be removed, so we can strip it down to just the > essential minimum components, which removes much of the testing > required by OpenJDK. > > Just curious, when using Agents, what are the recommendations for line > numbers in code, for exceptions etc, how are these affected when > instrumenting? > > Quite happy to contribute time to adding hooks and removing other > components. > > Regards, > > Peter. > > On 2/08/2021 9:00 pm, Ron Pressler wrote: >> Our path to making Java more secure is, indeed, similar to what >> you?re proposing. >> >> The general direction is that the application, rather than the >> libraries, will have the final say on security-sensitive capabilities. >> Just as strong encapsulation is now on by default, other things, such >> as native code, some dynamic Agent capabilities, and >> perhaps others, will likely require explicit permission by the >> application on the command line. I don?t know the details about >> management, but I believe that remote management requires explicit >> permission already. >> >> I am not aware, however, of plans to restrict class loading. The idea >> is that code is trusted to do what it says it does, and >> what?s restricted is the ability to manipulate it (without >> permission) to do something else through transformation or >> circumvention of its declared API. >> >> The default security policy today is already more restrictive than it >> was a couple of versions ago, and we expect it to become >> even more restrictive. >> >> ? Ron >> >>> On 2 Aug 2021, at 11:33, Peter Firmstone >>> wrote: >>> >>> Hello Andrew, >>> >>> I think you may be misinterpreting my comment, let me clarify: >>> >>> I'm assuming that during the process of removal of security manager, >>> any external ports or process hooks that we can only turn off now by >>> not granting a permission will be replaced by a command line >>> property or something similar?? Eg, Agents, Management, etc. If this >>> is the case, it would be nice if they were set to off by default, >>> such that they needed to be enabled from the command line.? It's a >>> suggestion.?? So configuration is secure by default.? Eg, similar to >>> how OpenBSD is configured secure by default, is that something >>> RedHat does??? I used RedHat back in the 90's, it was my first Linux >>> distro, on sparc. :) >>> >>> For example, the permissions granted in this policy file: >>> >>> https://urldefense.com/v3/__https://github.com/pfirmstone/JGDMS/blob/trunk/qa/harness/policy/defaultsecurephoenix.policy.new__;!!ACWV5N9M2RV99hQ!cVJkwzysH02ZFZWT3rnO_o5viWUCBTm9nnM50QaJ5G9hsg9B3p2naDVYknIrqSNURQ$ >>> >>> Ensure that anything that isn't specifically granted, is switched >>> off, eg agents, management, etc. >>> >>> This file is generated by a policy writing tool, the comments in the >>> policy file, indicate the tests that were run to generate the >>> policy.? It's important to note that we aren't using sandboxing, or >>> isolation, we are simply running with privileges we don't require >>> switched off.?? All network entry points to the JVM require >>> authentication and classes loaded, or data parsed requires >>> authentication first. >>> >>> In my software without SM, authentication isn't required, and there >>> are no defenses against parsing un-trusted data or downloading and >>> loading malicious classes.? Although you've made it clear, you think >>> this is a /special case/ and /special loss/ you needn't concern >>> yourself with and that's fine, you've made your point. >>> >>> In future it will not be possible to switch these features off using >>> policy files, so I imagine that OpenJDK must be considering >>> alternative methods to switch off features that may be security >>> sensitive? >>> >>> We already know de-serialization can be switched off from the >>> command line using: -Djdk.serialFilter=!*, >>> >>> However if you switch off java de-serialization, you best be sure to >>> initialize the serialization framework when starting your JVM, as SM >>> won't be there to stop it being turned back on, if it's not used, >>> it's not initialized, then the property can be changed and is >>> potentially a link in a gadget chain attack where serialization can >>> be re-enabled. :)? Just saying. >>> >>> Not sure what canard you're referring to, is the JDK config secure >>> by default?? If so, then it won't be possible for a malicious java >>> attachment in an email (or an image file) to be run inadvertently >>> and use the attach API to steal secrets. Although it's processor >>> could be subject to speculative execution attacks. >>> >>> A good reason to use OpenBSD (or Solaris perhaps) on Sparc for >>> secure systems??? I know RedHat is into supporting military >>> application in a big way, but I'm surprised if they're not concerned >>> about speculative execution vulnerabilities. >>> >>> Speculative execution attacks will eventually be addressed in >>> processor architectures, they are trying, we shouldn't assume that >>> we don't need to program defensively because the underlying >>> architecture has speculative execution bugs.? If we do that, then >>> were do we stop? >>> >>> Anyway, if possible I would like to get back to discussing how to >>> instrument the Java API using Agents, and whether we can coordinate >>> removal of finalizers with SM removal. >>> >>> Of course if you'd like to keep SM and cancel JEP 411, as Uwe >>> suggested, I'd support that.? I'm also grateful that Uwe spoke up, >>> and I hope others do as well, so this topic receives further >>> productive discussion.? It would be nice to sort the use cases prior >>> to SM removal.?? JEP 411 appears symbolic at this stage anyway, more >>> JEP's will be created for it's disablement I believe. >>> >>> Regards, >>> >>> Peter. >>> >>> On 2/08/2021 7:17 pm, Andrew Dinn wrote: >>>> On 01/08/2021 15:28, Uwe Schindler wrote: >>>>>>> I'm working on the assumption that OpenJDK will close any >>>>>>> external holes currently defended by permission checks.? It would >>>>>>> be good if the JDK was secure by default, with properties >>>>>>> required to be set for allowing such things as agents, >>>>>>> management, parsing xml and serialization. >>>>>> You need to stop repeating this canard. There is no absolute need >>>>>> for OpenJDK to retain a security mechanism to deal with problems >>>>>> that for almost every use case are better solved by using >>>>>> non-OpenJDK alternatives (such as OS security measures). Indeed, >>>>>> it's the other way round: there is an imperative for the project to >>>>>> spend precious resources on alternative capabilities (not >>>>>> necessarily security related). >>>>> Sorry, as another open source project affected by the stupid JEP 411 >>>>> desaster I would like to fully confirm to EVERYTHING that Peter said. >>>>> It is not a canard, it is the reality and I am really disappointed >>>>> what happened. >>>> Sorry, Uwe, but the canard *is* right there in the comment I quoted >>>> from Peter's email i.e. the bogus implication that without the >>>> security manager the JDK is not 'secure by default'. Irrespective >>>> of how useful the security manager is to your project it is utter >>>> steer manure to claim that without it there is a serious security >>>> hole. >>>> >>>> That's not to say different measures may need to be taken by some >>>> applications, yours included. I'm not denying that. However, I'm >>>> not going to back down when it comes to objecting to the lack of >>>> proportionality in Peter's claims. >>>> >>>> I believe Alan has answered your rather speculative follow-up >>>> comments so I'll rest on that clarification. >>>> >>>> regards, >>>> >>>> >>>> Andrew Dinn >>>> ----------- >>>> Red Hat Distinguished Engineer >>>> Red Hat UK Ltd >>>> Registered in England and Wales under Company Registration No. >>>> 03798903 >>>> Directors: Michael Cunningham, Michael ("Mike") O'Neill >>>> From Alan.Bateman at oracle.com Tue Aug 3 06:32:19 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 3 Aug 2021 07:32:19 +0100 Subject: Fate of {System|Runtime}.runFinalization (Re: Ad removing finalize eventually In-Reply-To: References: <19858490-648a-d539-2429-b1999f597658@zeus.net.au> <8d6f394d-f0a8-fa41-24ec-f8437af99d4f@oracle.com> <8f9e9e58-d5bb-0a99-7f3e-937a33c9e2b8@zeus.net.au> <0ae93ef1-3416-9cc0-d6e3-2fe1ccb1df4f@oracle.com> <67886c79-aef1-bc41-0057-9acb943a0e0f@wu.ac.at> <3b555f81-2cb5-73dd-90d4-e37d9549cb56@wu.ac.at> <39c357e2-dc51-32ae-71fa-c8aebde1aeb5@oracle.com> <19cc0c9c-1b93-8af9-28db-a07f2b9c71e5@wu.ac.at> Message-ID: On 02/08/2021 21:52, Hans Boehm wrote: > I think we will eventually need something analogous to > runFinalization() for Cleaners and/or References. If you are out of > some resource managed by Cleaners and want to allocate?another one, > how do?you wait for?resources of that kind to be reclaimed? What do > you do if you're testing code using Cleaners or References to reclaim > resources? > > This may also be a great opportunity to resolve the long-standing > issue of whether it's safe to call runFinalization() with user-visible > locks held. What happens when runFinalization's caller holds a lock > needed by a finalizer? This should be more tractable for Cleaners and > References, since it's easier to maintain separate queues for > different classes. When using cleaners or references then the typical response to resource exhaustion will be System.gc with back-off/retry in a loop until the resource can be allocated. Privileged ops in the JDK can do a bit better by polling the pending reference list to see if there is still work to do. So all a bit primitive. It's not clear to me that it's worth trying to do anything with runFinalization now. Yes, it is deadlock prone. It might help if it were changed from an untimed to a timed-wait when waiting for the secondary finalizer thread but that may just move the problem for finalizers that interact with locking. -Alan From ron.pressler at oracle.com Tue Aug 3 08:31:23 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Tue, 3 Aug 2021 08:31:23 +0000 Subject: [External] : Re: JEP 411, removal of finalizers, a path forward. In-Reply-To: <69e09a94-0717-0ac0-74c2-8b0fd78fbc78@zeus.net.au> References: <4257646b-6678-5419-13ae-5b470d4c510d@redhat.com> <000001d786e1$7885b0b0$69911210$@apache.org> <391deb02-68ba-4d67-7475-e13534dfd97d@redhat.com> <64671073-b67c-4a83-5949-7a97273349eb@zeus.net.au> <75A781C9-9A0D-4A3B-8E59-352CDCF088BE@oracle.com> <69e09a94-0717-0ac0-74c2-8b0fd78fbc78@zeus.net.au> Message-ID: <03F9EEDF-CEE9-490D-832D-877FD3B6D9C3@oracle.com> > On 3 Aug 2021, at 02:30, Peter Firmstone wrote: > > > I am still hopeful that OpenJDK might create some hooks for us and keep the AccessController, AccessControlContext and Subject.doAs methods to make supporting all Java versions easier. When I mentioned ?hooks? I was referring to something along the lines of a callback when a file is accessed. > > Just curious, when using Agents, what are the recommendations for line numbers in code, for exceptions etc, how are these affected when instrumenting? When you transform a class, you basically replace its content with new content, so the short answer is that what happens to line numbers is whatever you want. If you?re using ASM for your transformation and ignore line numbers, which ASM represents as a kind of no-op instructions, then what would usually happen is that if original instruction X is mapped to line N and when transforming the stream you replace X with YXZ, then all of YXZ will remain mapped to line N. From peter.firmstone at zeus.net.au Tue Aug 3 08:39:39 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Tue, 3 Aug 2021 18:39:39 +1000 Subject: [External] : Re: JEP 411, removal of finalizers, a path forward. In-Reply-To: <03F9EEDF-CEE9-490D-832D-877FD3B6D9C3@oracle.com> References: <4257646b-6678-5419-13ae-5b470d4c510d@redhat.com> <000001d786e1$7885b0b0$69911210$@apache.org> <391deb02-68ba-4d67-7475-e13534dfd97d@redhat.com> <64671073-b67c-4a83-5949-7a97273349eb@zeus.net.au> <75A781C9-9A0D-4A3B-8E59-352CDCF088BE@oracle.com> <69e09a94-0717-0ac0-74c2-8b0fd78fbc78@zeus.net.au> <03F9EEDF-CEE9-490D-832D-877FD3B6D9C3@oracle.com> Message-ID: <29eb60aa-14ab-e3d1-eb30-7970b0f798b3@zeus.net.au> On 3/08/2021 6:31 pm, Ron Pressler wrote: > >> On 3 Aug 2021, at 02:30, Peter Firmstone wrote: >> >> >> I am still hopeful that OpenJDK might create some hooks for us and keep the AccessController, AccessControlContext and Subject.doAs methods to make supporting all Java versions easier. > When I mentioned ?hooks? I was referring to something along the lines of a callback when a file is > accessed. Can you elaborate??? A Runnable, similar to registering a shutdown hook? > >> Just curious, when using Agents, what are the recommendations for line numbers in code, for exceptions etc, how are these affected when instrumenting? > When you transform a class, you basically replace its content with new content, so the short answer is > that what happens to line numbers is whatever you want. If you?re using ASM for your transformation and > ignore line numbers, which ASM represents as a kind of no-op instructions, then what would usually happen > is that if original instruction X is mapped to line N and when transforming the stream you replace X with > YXZ, then all of YXZ will remain mapped to line N. Ok, Currently my experience with ASM is finding dependencies, and unpacking the pack200 format. I hadn't stopped to consider what it might do to line numbers. Cheers, Peter. From ron.pressler at oracle.com Tue Aug 3 08:48:44 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Tue, 3 Aug 2021 08:48:44 +0000 Subject: [External] : Re: JEP 411, removal of finalizers, a path forward. In-Reply-To: <8416aaae-8d12-eb33-fb50-7e861d1c6cbd@zeus.net.au> References: <4257646b-6678-5419-13ae-5b470d4c510d@redhat.com> <000001d786e1$7885b0b0$69911210$@apache.org> <391deb02-68ba-4d67-7475-e13534dfd97d@redhat.com> <64671073-b67c-4a83-5949-7a97273349eb@zeus.net.au> <75A781C9-9A0D-4A3B-8E59-352CDCF088BE@oracle.com> <69e09a94-0717-0ac0-74c2-8b0fd78fbc78@zeus.net.au> <8416aaae-8d12-eb33-fb50-7e861d1c6cbd@zeus.net.au> Message-ID: <47D86F98-369E-4B25-84BE-185931B99E53@oracle.com> > On 3 Aug 2021, at 06:48, Peter Firmstone wrote: > > > We can still use these without an SM, Policy or Permissions for authorization decisions, as mentioned previously I'd replace the inherited thread context with an unprivileged context, and also allow the stack walk to be disabled for people only using Subject. > I think what you mean is that you can envision using the same API points for a different, but reasonably similar role to the one they have. But that would mean changing the behaviour of existing classes, possibly making some final classes non-final, in non-trivial ways. > > Just performed a search for java.security.AccessController on GitHub, got 1,398,418 results for Java: > The plan is to degrade these into no-ops until such time as most of those usages disappear, not to imbue those lines of code with new meaning. The actual removal of the API elements might be a long way off, but, becoming no-ops before then, the JDK and libraries will be free to remove those usages. From ron.pressler at oracle.com Tue Aug 3 08:54:54 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Tue, 3 Aug 2021 08:54:54 +0000 Subject: [External] : Re: JEP 411, removal of finalizers, a path forward. In-Reply-To: <29eb60aa-14ab-e3d1-eb30-7970b0f798b3@zeus.net.au> References: <4257646b-6678-5419-13ae-5b470d4c510d@redhat.com> <000001d786e1$7885b0b0$69911210$@apache.org> <391deb02-68ba-4d67-7475-e13534dfd97d@redhat.com> <64671073-b67c-4a83-5949-7a97273349eb@zeus.net.au> <75A781C9-9A0D-4A3B-8E59-352CDCF088BE@oracle.com> <69e09a94-0717-0ac0-74c2-8b0fd78fbc78@zeus.net.au> <03F9EEDF-CEE9-490D-832D-877FD3B6D9C3@oracle.com> <29eb60aa-14ab-e3d1-eb30-7970b0f798b3@zeus.net.au> Message-ID: <5A96508F-7313-4089-B09E-F70C7628D796@oracle.com> > On 3 Aug 2021, at 09:39, Peter Firmstone wrote: > > > > Can you elaborate? A Runnable, similar to registering a shutdown hook? > Maybe, but there have been no specifics beyond saying that something like that, and which requires that level of effort, might, after the dust settles and no one is rushing to decisions, possibly be something that we could contemplate thinking about considering as possibly not being obviously completely unreasonable, and might, perhaps, be worthy of another look. From aph at redhat.com Tue Aug 3 09:06:14 2021 From: aph at redhat.com (Andrew Haley) Date: Tue, 3 Aug 2021 10:06:14 +0100 Subject: Fate of {System|Runtime}.runFinalization (Re: Ad removing finalize eventually In-Reply-To: References: <19858490-648a-d539-2429-b1999f597658@zeus.net.au> <8d6f394d-f0a8-fa41-24ec-f8437af99d4f@oracle.com> <8f9e9e58-d5bb-0a99-7f3e-937a33c9e2b8@zeus.net.au> <0ae93ef1-3416-9cc0-d6e3-2fe1ccb1df4f@oracle.com> <67886c79-aef1-bc41-0057-9acb943a0e0f@wu.ac.at> <3b555f81-2cb5-73dd-90d4-e37d9549cb56@wu.ac.at> <39c357e2-dc51-32ae-71fa-c8aebde1aeb5@oracle.com> <19cc0c9c-1b93-8af9-28db-a07f2b9c71e5@wu.ac.at> Message-ID: On 8/3/21 12:27 AM, Hans Boehm wrote: > So my concern is really how to do (2) and (3) in the new world, i.e. wait > until unreachable objects found by the last GC have been cleaned. With > finalizers, System.runFinalization() effectively did the equivalent of that > (potentially modulo the deadlock questions). I did once manage to solve the problem of running out of native resources by, instead of using a small object as a handle to the native resource, using a multi-megabyte thought of it as being like attaching a brick to that key people keep losing. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From adinn at redhat.com Tue Aug 3 09:11:12 2021 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 3 Aug 2021 10:11:12 +0100 Subject: [External] : Re: JEP 411, removal of finalizers, a path forward. In-Reply-To: <69e09a94-0717-0ac0-74c2-8b0fd78fbc78@zeus.net.au> References: <4257646b-6678-5419-13ae-5b470d4c510d@redhat.com> <000001d786e1$7885b0b0$69911210$@apache.org> <391deb02-68ba-4d67-7475-e13534dfd97d@redhat.com> <64671073-b67c-4a83-5949-7a97273349eb@zeus.net.au> <75A781C9-9A0D-4A3B-8E59-352CDCF088BE@oracle.com> <69e09a94-0717-0ac0-74c2-8b0fd78fbc78@zeus.net.au> Message-ID: On 03/08/2021 02:30, Peter Firmstone wrote: > Just curious, when using Agents, what are the recommendations for line > numbers in code, for exceptions etc, how are these affected when > instrumenting? For Byteman I use ASM to inject bytecode sequences into methods without any (significant) modification to existing bytecodes. ASM successfully adjusts line number info to allow for the injected code without the need for my agent to take any action. I also add extra exception handling around injected regions and propagate exceptions through enclosing regions to an outer handler. ASM updates the exception table according to where the method visitor notifies new try and catch region boundaries while retaining the regions determined by existing notifications. ASM provides mechanism for more complex cases. If you are rewriting existing bytecodes or exception regions then you can use the ASM visitor pattern to process and then renotify both line numbers and try catch boundaries as you visit the bytecode stream. Of course, the logic of how to do that can be as complex as (or more so than) the rewrite logic. n.b. Remapping exception regions at load time is tricky for two reasons. Firstly, you cannot afford to load exception classes to investigate the exception class hierarchy without losing the opportunity to transform the exception class's bytecode. So, you have to identify exception shadowing by parsing the bytecode as a resource to establish exception super relationships. Secondly, if you tinker with or inject extra try regions you need to a) ensure they are properly nested inside containing try regions b) make sure that new exception exit paths out of synchronized regions include monitorexits. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From aph at redhat.com Tue Aug 3 09:16:30 2021 From: aph at redhat.com (Andrew Haley) Date: Tue, 3 Aug 2021 10:16:30 +0100 Subject: Ad removing finalize eventually (Re: JEP 411 Headaches: Instrumenting private methods in the JDK for authorization checkpoints. In-Reply-To: References: <19858490-648a-d539-2429-b1999f597658@zeus.net.au> <8d6f394d-f0a8-fa41-24ec-f8437af99d4f@oracle.com> <8f9e9e58-d5bb-0a99-7f3e-937a33c9e2b8@zeus.net.au> <0ae93ef1-3416-9cc0-d6e3-2fe1ccb1df4f@oracle.com> <67886c79-aef1-bc41-0057-9acb943a0e0f@wu.ac.at> <7e0768d2-4afd-23be-8bb4-e66e6f1c3eed@redhat.com> Message-ID: On 8/2/21 7:39 PM, Rony G. Flatscher wrote: > If the Java ScriptEngine goes out of scope at the Java side its peer > ooRexx interpreter instance should be terminated, the same is true > for peer objects for either side (Java peer objects for Rexx > objects, i.e. Rexx objects being boxed in Java proxy objects, and > vice versa, ooRexx peer objects for Java objects such that one can > send messages to an ooRexx peer to the Java side where with > reflection the appropriate methods get invoked in the corresponding > Java object). Sure, but Java doesn't know when a Java ScriptEngine goes out of scope. Here's the scenario: we're running a generational garbage collector. Young-generation collections are keeping the heap well within our limits, so there's no need to do full collections. The ScriptEngine has been running for a while, so is in the old generation. There's no reason it will ever be collected. That's why some sort of scoped access, such as try with resources, is the right way to go if you really need cleanups to be done. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From peter.firmstone at zeus.net.au Tue Aug 3 09:44:07 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Tue, 3 Aug 2021 19:44:07 +1000 Subject: [External] : Re: JEP 411, removal of finalizers, a path forward. In-Reply-To: <47D86F98-369E-4B25-84BE-185931B99E53@oracle.com> References: <4257646b-6678-5419-13ae-5b470d4c510d@redhat.com> <000001d786e1$7885b0b0$69911210$@apache.org> <391deb02-68ba-4d67-7475-e13534dfd97d@redhat.com> <64671073-b67c-4a83-5949-7a97273349eb@zeus.net.au> <75A781C9-9A0D-4A3B-8E59-352CDCF088BE@oracle.com> <69e09a94-0717-0ac0-74c2-8b0fd78fbc78@zeus.net.au> <8416aaae-8d12-eb33-fb50-7e861d1c6cbd@zeus.net.au> <47D86F98-369E-4B25-84BE-185931B99E53@oracle.com> Message-ID: <8815f1ce-9ed4-1d60-ded4-b15f70b46dce@zeus.net.au> Thanks Ron, reply inline. On 3/08/2021 6:48 pm, Ron Pressler wrote: > >> On 3 Aug 2021, at 06:48, Peter Firmstone wrote: >> >> >> We can still use these without an SM, Policy or Permissions for authorization decisions, as mentioned previously I'd replace the inherited thread context with an unprivileged context, and also allow the stack walk to be disabled for people only using Subject. >> > I think what you mean is that you can envision using the same API points for a different, but reasonably similar > role to the one they have. But that would mean changing the behaviour of existing classes, possibly making some > final classes non-final, in non-trivial ways. I'd limit changes to: 1. Make the stack walk optional (via command line argument to disable it). 2. Remove Thread's inherited context, replace it with an unprivileged context. This would allow us to use the API for virtual threads, eg to obtain Subject credentials to authenticate TLS connections. It also means that for someone implementing guard checks, that these only need check the thread stack back to the last doPrivileged call, or the start of the thread, in the latter case it will have no privileges.? It fixes the viral permission check problem, usually doPrivileged calls are short and sweet. It may require the addition of doPrivileged calls where they're currently missing (and should have been used), where they've been responsible for viral permission checks. > >> Just performed a search for java.security.AccessController on GitHub, got 1,398,418 results for Java: >> > The plan is to degrade these into no-ops until such time as most of those usages disappear, not to imbue > those lines of code with new meaning. The actual removal of the API elements might be a long way off, > but, becoming no-ops before then, the JDK and libraries will be free to remove those usages. No new meanings, the same as they have now is sufficient, just we leave the granularity of the checks to the developers of guards and provide a means by which guards can be registered for common check points that developers request (perhaps via a poll), rather than all existing permission check points.? Keeping in mind that we are not trying to isolate code, but perform authorization access checks, as well as provide credentials for authentication. For example, if someone is only concerned with stopping the JVM from exiting, then they only implement a guard for that particular hook, the actual code that needs to call System::exit, then calls a doPrivileged method before doing so.? The guard need only check the domain on the stack is the one it expects, which could be based on Principal, CodeSource, Module or ClassLoader etc, they may also chose to implement something more complex. Someone else may only be concerned with network connections, so they only implement and register a guard for that. So basically we don't dictate how to implement guards or policy, we just leave enough in place, to ensure that a minimalist authorization access control api is common among all implementations on all Java versions. It is suitable, for Subject's only or code and Subject's. The doPrivileged call simply indicates the code is requesting to do something that might be privileged, or needs to provide credentials for authentication, as it does now, but it's the light version of the stack walk, if doPrivileged is not called, then the context will have an unprivileged domain on the stack (that initialized when Thread was created.). It's also possible to register guards that do fine grained permission checks, similar to the way Java does now. Then there's the use case, or registering no guards at all, and disabling the stack walk, and only using the api to obtain and preserve Subject credentials for authentication. You can trust me on this one, I'm experienced with the current API and have pushed it to all sorts of limits. Cheers, Peter. From peter.firmstone at zeus.net.au Tue Aug 3 09:47:32 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Tue, 3 Aug 2021 19:47:32 +1000 Subject: [External] : Re: JEP 411, removal of finalizers, a path forward. In-Reply-To: References: <4257646b-6678-5419-13ae-5b470d4c510d@redhat.com> <000001d786e1$7885b0b0$69911210$@apache.org> <391deb02-68ba-4d67-7475-e13534dfd97d@redhat.com> <64671073-b67c-4a83-5949-7a97273349eb@zeus.net.au> <75A781C9-9A0D-4A3B-8E59-352CDCF088BE@oracle.com> <69e09a94-0717-0ac0-74c2-8b0fd78fbc78@zeus.net.au> Message-ID: Wow, thanks Andrew, There's certainly some complexity there, I appreciate your guidance. Regards, Peter. On 3/08/2021 7:11 pm, Andrew Dinn wrote: > On 03/08/2021 02:30, Peter Firmstone wrote: >> Just curious, when using Agents, what are the recommendations for >> line numbers in code, for exceptions etc, how are these affected when >> instrumenting? > > For Byteman I use ASM to inject bytecode sequences into methods > without any (significant) modification to existing bytecodes. ASM > successfully adjusts line number info to allow for the injected code > without the need for my agent to take any action. > > I also add extra exception handling around injected regions and > propagate exceptions through enclosing regions to an outer handler. > ASM updates the exception table according to where the method visitor > notifies new try and catch region boundaries while retaining the > regions determined by existing notifications. > > ASM provides mechanism for more complex cases. If you are rewriting > existing bytecodes or exception regions then you can use the ASM > visitor pattern to process and then renotify both line numbers and try > catch boundaries as you visit the bytecode stream. Of course, the > logic of how to do that can be as complex as (or more so than) the > rewrite logic. > > n.b. Remapping exception regions at load time is tricky for two > reasons. Firstly, you cannot afford to load exception classes to > investigate the exception class hierarchy without losing the > opportunity to transform the exception class's bytecode. So, you have > to identify exception shadowing by parsing the bytecode as a resource > to establish exception super relationships. Secondly, if you tinker > with or inject extra try regions you need to a) ensure they are > properly nested inside containing try regions b) make sure that new? > exception exit paths out of synchronized regions include monitorexits. > > regards, > > > Andrew Dinn > ----------- > Red Hat Distinguished Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill > From ron.pressler at oracle.com Tue Aug 3 11:21:00 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Tue, 3 Aug 2021 11:21:00 +0000 Subject: [External] : Re: JEP 411, removal of finalizers, a path forward. In-Reply-To: <8815f1ce-9ed4-1d60-ded4-b15f70b46dce@zeus.net.au> References: <4257646b-6678-5419-13ae-5b470d4c510d@redhat.com> <000001d786e1$7885b0b0$69911210$@apache.org> <391deb02-68ba-4d67-7475-e13534dfd97d@redhat.com> <64671073-b67c-4a83-5949-7a97273349eb@zeus.net.au> <75A781C9-9A0D-4A3B-8E59-352CDCF088BE@oracle.com> <69e09a94-0717-0ac0-74c2-8b0fd78fbc78@zeus.net.au> <8416aaae-8d12-eb33-fb50-7e861d1c6cbd@zeus.net.au> <47D86F98-369E-4B25-84BE-185931B99E53@oracle.com> <8815f1ce-9ed4-1d60-ded4-b15f70b46dce@zeus.net.au> Message-ID: <6D038394-300A-42E0-AEA9-A075A132F553@oracle.com> What you are proposing is: 1. Add an SPI for deep permission checks in the JDK. 2. Do so by changing the behaviour of existing classes in a non-trivial way. 3. Keep access checks in the JDK. I do not speak for those who work on the security mechanisms, but I believe that none one of these, even in isolation, would be reasonable. For one, even without the principle against changing the behaviour of existing classes in drastic and non-trivial ways, without the use of doPrivileged in the JDK, AccessController would make a bad API. For another, the cost of SM isn?t in the lines of code that make up the AccessController implementation but in the fact that the JDK does access checks and privileged operations in the first place, as those impose a tax on everything, and also take resources away from what we believe is more robust and effective security. The starting point isn?t removing the policy file implementation, but removing all access checks and privileged operations from the JDK, and everything else follows from there (it will take a long time until API elements are actually removed, anyway). Even if someone might choose to contemplate adding callbacks to one or two I/O operations, it is not the intent for the JDK to participate in a general access checking mechanism deep in its guts in addition to strong encapsulation; quite the opposite. ? Ron > On 3 Aug 2021, at 10:44, Peter Firmstone wrote: > > Thanks Ron, reply inline. > > On 3/08/2021 6:48 pm, Ron Pressler wrote: >> >>> On 3 Aug 2021, at 06:48, Peter Firmstone >>> wrote: >>> >>> >>> We can still use these without an SM, Policy or Permissions for authorization decisions, as mentioned previously I'd replace the inherited thread context with an unprivileged context, and also allow the stack walk to be disabled for people only using Subject. >>> >>> >> I think what you mean is that you can envision using the same API points for a different, but reasonably similar >> role to the one they have. But that would mean changing the behaviour of existing classes, possibly making some >> final classes non-final, in non-trivial ways. >> > I'd limit changes to: > > ? Make the stack walk optional (via command line argument to disable it). > ? Remove Thread's inherited context, replace it with an unprivileged context. > This would allow us to use the API for virtual threads, eg to obtain Subject credentials to authenticate TLS connections. > > It also means that for someone implementing guard checks, that these only need check the thread stack back to the last doPrivileged call, or the start of the thread, in the latter case it will have no privileges. It fixes the viral permission check problem, usually doPrivileged calls are short and sweet. > > It may require the addition of doPrivileged calls where they're currently missing (and should have been used), where they've been responsible for viral permission checks. > >> >>> Just performed a search for java.security.AccessController on GitHub, got 1,398,418 results for Java: >>> >>> >> The plan is to degrade these into no-ops until such time as most of those usages disappear, not to imbue >> those lines of code with new meaning. The actual removal of the API elements might be a long way off, >> but, becoming no-ops before then, the JDK and libraries will be free to remove those usages. >> > No new meanings, the same as they have now is sufficient, just we leave the granularity of the checks to the developers of guards and provide a means by which guards can be registered for common check points that developers request (perhaps via a poll), rather than all existing permission check points. Keeping in mind that we are not trying to isolate code, but perform authorization access checks, as well as provide credentials for authentication. > > For example, if someone is only concerned with stopping the JVM from exiting, then they only implement a guard for that particular hook, the actual code that needs to call System::exit, then calls a doPrivileged method before doing so. The guard need only check the domain on the stack is the one it expects, which could be based on Principal, CodeSource, Module or ClassLoader etc, they may also chose to implement something more complex. > > Someone else may only be concerned with network connections, so they only implement and register a guard for that. > > So basically we don't dictate how to implement guards or policy, we just leave enough in place, to ensure that a minimalist authorization access control api is common among all implementations on all Java versions. > > It is suitable, for Subject's only or code and Subject's. > > The doPrivileged call simply indicates the code is requesting to do something that might be privileged, or needs to provide credentials for authentication, as it does now, but it's the light version of the stack walk, if doPrivileged is not called, then the context will have an unprivileged domain on the stack (that initialized when Thread was created.). > > It's also possible to register guards that do fine grained permission checks, similar to the way Java does now. > > Then there's the use case, or registering no guards at all, and disabling the stack walk, and only using the api to obtain and preserve Subject credentials for authentication. > > You can trust me on this one, I'm experienced with the current API and have pushed it to all sorts of limits. > > Cheers, > > Peter. > From peter.firmstone at zeus.net.au Tue Aug 3 11:50:34 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Tue, 3 Aug 2021 21:50:34 +1000 Subject: [External] : Re: JEP 411, removal of finalizers, a path forward. In-Reply-To: <6D038394-300A-42E0-AEA9-A075A132F553@oracle.com> References: <4257646b-6678-5419-13ae-5b470d4c510d@redhat.com> <000001d786e1$7885b0b0$69911210$@apache.org> <391deb02-68ba-4d67-7475-e13534dfd97d@redhat.com> <64671073-b67c-4a83-5949-7a97273349eb@zeus.net.au> <75A781C9-9A0D-4A3B-8E59-352CDCF088BE@oracle.com> <69e09a94-0717-0ac0-74c2-8b0fd78fbc78@zeus.net.au> <8416aaae-8d12-eb33-fb50-7e861d1c6cbd@zeus.net.au> <47D86F98-369E-4B25-84BE-185931B99E53@oracle.com> <8815f1ce-9ed4-1d60-ded4-b15f70b46dce@zeus.net.au> <6D038394-300A-42E0-AEA9-A075A132F553@oracle.com> Message-ID: <3bd68043-cd3a-16a8-f6a2-4273b2247de6@zeus.net.au> Can you think of any workable alternative compromises? On 3/08/2021 9:21 pm, Ron Pressler wrote: > What you are proposing is: > > 1. Add an SPI for deep permission checks in the JDK. > 2. Do so by changing the behaviour of existing classes in a non-trivial way. > 3. Keep access checks in the JDK. > > I do not speak for those who work on the security mechanisms, but I believe that none one of these, > even in isolation, would be reasonable. > > For one, even without the principle against changing the behaviour of existing classes in drastic > and non-trivial ways, without the use of doPrivileged in the JDK, AccessController would make > a bad API. That's true, it would better if those doPrivileged calls to remain. An alternative I thought about if they were removed, was to treat a thread as privileged if all domains on the thread stack were resolvable from the bootstrap ClassLoader. > > For another, the cost of SM isn?t in the lines of code that make up the AccessController implementation > but in the fact that the JDK does access checks and privileged operations in the first place, as those > impose a tax on everything, and also take resources away from what we believe is more robust and effective > security. Yes, I realise this, however I'm not looking to replace all permission checks, just the most common.? Perhaps then a static method added to a class, without implementation would be better, in cases where it's not practical to instrument the JVM.? Such that it does nothing by default and would be optimised away by hotspot. eg: static instrumentGuard(String [] args) throws SecurityException{} Thanks, Peter. > > The starting point isn?t removing the policy file implementation, but removing all access checks > and privileged operations from the JDK, and everything else follows from there (it will take a long > time until API elements are actually removed, anyway). Even if someone might choose to contemplate adding > callbacks to one or two I/O operations, it is not the intent for the JDK to participate in a general access > checking mechanism deep in its guts in addition to strong encapsulation; quite the opposite. > > > ? Ron > > >> On 3 Aug 2021, at 10:44, Peter Firmstone wrote: >> >> Thanks Ron, reply inline. >> >> On 3/08/2021 6:48 pm, Ron Pressler wrote: >>>> On 3 Aug 2021, at 06:48, Peter Firmstone >>>> wrote: >>>> >>>> >>>> We can still use these without an SM, Policy or Permissions for authorization decisions, as mentioned previously I'd replace the inherited thread context with an unprivileged context, and also allow the stack walk to be disabled for people only using Subject. >>>> >>>> >>> I think what you mean is that you can envision using the same API points for a different, but reasonably similar >>> role to the one they have. But that would mean changing the behaviour of existing classes, possibly making some >>> final classes non-final, in non-trivial ways. >>> >> I'd limit changes to: >> >> ? Make the stack walk optional (via command line argument to disable it). >> ? Remove Thread's inherited context, replace it with an unprivileged context. >> This would allow us to use the API for virtual threads, eg to obtain Subject credentials to authenticate TLS connections. >> >> It also means that for someone implementing guard checks, that these only need check the thread stack back to the last doPrivileged call, or the start of the thread, in the latter case it will have no privileges. It fixes the viral permission check problem, usually doPrivileged calls are short and sweet. >> >> It may require the addition of doPrivileged calls where they're currently missing (and should have been used), where they've been responsible for viral permission checks. >> >>>> Just performed a search for java.security.AccessController on GitHub, got 1,398,418 results for Java: >>>> >>>> >>> The plan is to degrade these into no-ops until such time as most of those usages disappear, not to imbue >>> those lines of code with new meaning. The actual removal of the API elements might be a long way off, >>> but, becoming no-ops before then, the JDK and libraries will be free to remove those usages. >>> >> No new meanings, the same as they have now is sufficient, just we leave the granularity of the checks to the developers of guards and provide a means by which guards can be registered for common check points that developers request (perhaps via a poll), rather than all existing permission check points. Keeping in mind that we are not trying to isolate code, but perform authorization access checks, as well as provide credentials for authentication. >> >> For example, if someone is only concerned with stopping the JVM from exiting, then they only implement a guard for that particular hook, the actual code that needs to call System::exit, then calls a doPrivileged method before doing so. The guard need only check the domain on the stack is the one it expects, which could be based on Principal, CodeSource, Module or ClassLoader etc, they may also chose to implement something more complex. >> >> Someone else may only be concerned with network connections, so they only implement and register a guard for that. >> >> So basically we don't dictate how to implement guards or policy, we just leave enough in place, to ensure that a minimalist authorization access control api is common among all implementations on all Java versions. >> >> It is suitable, for Subject's only or code and Subject's. >> >> The doPrivileged call simply indicates the code is requesting to do something that might be privileged, or needs to provide credentials for authentication, as it does now, but it's the light version of the stack walk, if doPrivileged is not called, then the context will have an unprivileged domain on the stack (that initialized when Thread was created.). >> >> It's also possible to register guards that do fine grained permission checks, similar to the way Java does now. >> >> Then there's the use case, or registering no guards at all, and disabling the stack walk, and only using the api to obtain and preserve Subject credentials for authentication. >> >> You can trust me on this one, I'm experienced with the current API and have pushed it to all sorts of limits. >> >> Cheers, >> >> Peter. >> From ron.pressler at oracle.com Tue Aug 3 12:15:07 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Tue, 3 Aug 2021 12:15:07 +0000 Subject: [External] : Re: JEP 411, removal of finalizers, a path forward. In-Reply-To: <3bd68043-cd3a-16a8-f6a2-4273b2247de6@zeus.net.au> References: <4257646b-6678-5419-13ae-5b470d4c510d@redhat.com> <000001d786e1$7885b0b0$69911210$@apache.org> <391deb02-68ba-4d67-7475-e13534dfd97d@redhat.com> <64671073-b67c-4a83-5949-7a97273349eb@zeus.net.au> <75A781C9-9A0D-4A3B-8E59-352CDCF088BE@oracle.com> <69e09a94-0717-0ac0-74c2-8b0fd78fbc78@zeus.net.au> <8416aaae-8d12-eb33-fb50-7e861d1c6cbd@zeus.net.au> <47D86F98-369E-4B25-84BE-185931B99E53@oracle.com> <8815f1ce-9ed4-1d60-ded4-b15f70b46dce@zeus.net.au> <6D038394-300A-42E0-AEA9-A075A132F553@oracle.com> <3bd68043-cd3a-16a8-f6a2-4273b2247de6@zeus.net.au> Message-ID: <5BE7D172-304A-4143-BD6B-B6426BEEC258@oracle.com> > On 3 Aug 2021, at 12:50, Peter Firmstone wrote: > > Can you think of any workable alternative compromises? If you mean a compromise between no access checks in the JDK and all access checks in the JDK, then yes, which is 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, as the value in such a mechanism might end up being worthy of that amount of effort. But I?m guessing that the more such hooks are requested, the less likely it is that the cost remains acceptable. ? Ron From Rony.Flatscher at wu.ac.at Tue Aug 3 13:08:01 2021 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Tue, 3 Aug 2021 15:08:01 +0200 Subject: Ad removing finalize eventually (Re: JEP 411 Headaches: Instrumenting private methods in the JDK for authorization checkpoints. In-Reply-To: References: <19858490-648a-d539-2429-b1999f597658@zeus.net.au> <8d6f394d-f0a8-fa41-24ec-f8437af99d4f@oracle.com> <8f9e9e58-d5bb-0a99-7f3e-937a33c9e2b8@zeus.net.au> <0ae93ef1-3416-9cc0-d6e3-2fe1ccb1df4f@oracle.com> <67886c79-aef1-bc41-0057-9acb943a0e0f@wu.ac.at> <7e0768d2-4afd-23be-8bb4-e66e6f1c3eed@redhat.com> Message-ID: On 03.08.2021 11:16, Andrew Haley wrote: > On 8/2/21 7:39 PM, Rony G. Flatscher wrote: > >> If the Java ScriptEngine goes out of scope at the Java side its peer >> ooRexx interpreter instance should be terminated, the same is true >> for peer objects for either side (Java peer objects for Rexx >> objects, i.e. Rexx objects being boxed in Java proxy objects, and >> vice versa, ooRexx peer objects for Java objects such that one can >> send messages to an ooRexx peer to the Java side where with >> reflection the appropriate methods get invoked in the corresponding >> Java object). > Sure, but Java doesn't know when a Java ScriptEngine goes out of scope. > > Here's the scenario: we're running a generational garbage collector. > Young-generation collections are keeping the heap well within our > limits, so there's no need to do full collections. The ScriptEngine > has been running for a while, so is in the old generation. There's no > reason it will ever be collected. That's why some sort of scoped > access, such as try with resources, is the right way to go if you > really need cleanups to be done. This approach depends on a try-with block, which is easy and straight forward if e.g. reading from a resource like a file, processing a SLQ statement etc. But "longevity service objects" are hard, if not impossible, to be put into a (single, central) try-with block. This is especially true for peer usages (e.g. in ooRexx an object created by one Rexx interpreter instance can be deployed on another Rexx interpreter instance, and if it is a peer object the peer Java object must stay alive as long as the ooRexx object is referenced). >From first, simple tests on Java 8 it seems however, that System.runFinalization() will invoke finalize() on those Java objects that have no references at the time runFinalization() runs. So it does not follow the general gc strategy you describe. Running System.gc() does not have that effect, i.e. running finalize() of the very same Java objects without references at gc() time. So currently PhantomReferences to these Java objects that have no references would not be put on the queue but at some undefined later time, possibly never as you describe. The question then would be whether it was possible to have runFinalization() also look out for PhantomReference'd Java objects without references and put them on the queue at that point in time. This of course assumes that runFinalization() not only is able to identify unreferenced Java objects with a finalize method, but also unreferenced Java objects for which a PhantomReference got created for. [If so, runFinalization() may remain helpful even after finalize() got eventually removed.] ---rony From hboehm at google.com Tue Aug 3 16:09:08 2021 From: hboehm at google.com (Hans Boehm) Date: Tue, 3 Aug 2021 09:09:08 -0700 Subject: Fate of {System|Runtime}.runFinalization (Re: Ad removing finalize eventually In-Reply-To: References: <19858490-648a-d539-2429-b1999f597658@zeus.net.au> <8d6f394d-f0a8-fa41-24ec-f8437af99d4f@oracle.com> <8f9e9e58-d5bb-0a99-7f3e-937a33c9e2b8@zeus.net.au> <0ae93ef1-3416-9cc0-d6e3-2fe1ccb1df4f@oracle.com> <67886c79-aef1-bc41-0057-9acb943a0e0f@wu.ac.at> <3b555f81-2cb5-73dd-90d4-e37d9549cb56@wu.ac.at> <39c357e2-dc51-32ae-71fa-c8aebde1aeb5@oracle.com> <19cc0c9c-1b93-8af9-28db-a07f2b9c71e5@wu.ac.at> Message-ID: On Mon, Aug 2, 2021 at 11:32 PM Alan Bateman wrote: > ... > > When using cleaners or references then the typical response to resource > exhaustion will be System.gc with back-off/retry in a loop until the > resource can be allocated. Privileged ops in the JDK can do a bit better > by polling the pending reference list to see if there is still work to > do. So all a bit primitive. I agree that this is a bit primitive. Perhaps more importantly, it seems like a regression from finalization, where I can be reasonably sure that System.gc(); System.runFinalization(); (with no locks held) will finalize all objects that can be finalized. (This ignores the case in which finalizers generate more Java garbage, but in most cases that's not a very significant effect.) AFAICT, the spec currently provides no promise that System.gc() will "expend effort" towards enqueueing References; it only talks about reclaiming memory in the positive, though oddly enough, it does make a negative statement about enqueueing references. The spec does not make it sound like System.gc() waits for the right condition before returning. So the back-off in the suggested retry loop seems critical, even if I can explicitly wait on the queue. That seems unfortunate to me. > > It's not clear to me that it's worth trying to do anything with > runFinalization now. Yes, it is deadlock prone. It might help if it were > changed from an untimed to a timed-wait when waiting for the secondary > finalizer thread but that may just move the problem for finalizers that > interact with locking. My problem with the current situation is that it's not clear how to write client code. If runFinalization() does not have the timeout, I need to be very careful where I call it, in ways that probably make it less effective. But I'm also not at all sure this is worth addressing now. If we want to move away from finalizers, I think it is important to make things easier in the new world with Cleaners. Currently there seem to be at least two things that make it significantly harder: 1) The lack of a default user-visible Cleaner seems to effectively tie up an additional thread per Cleaner-using-library. AFAICT, the decreased interference between Cleaners makes that desirable in some contexts, but the additional threads make it untenable in others. 2) The lack of a clean runFinalization alternative. I think this is actually an opportunity to improve things and motivate people to switch away from finalization. But currently it pushes in the wrong direction. Hans > > -Alan From sean.mullan at oracle.com Tue Aug 3 16:40:58 2021 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 3 Aug 2021 12:40:58 -0400 Subject: JEP 411, removal of finalizers, a path forward. In-Reply-To: References: <4257646b-6678-5419-13ae-5b470d4c510d@redhat.com> <000001d786e1$7885b0b0$69911210$@apache.org> <391deb02-68ba-4d67-7475-e13534dfd97d@redhat.com> <64671073-b67c-4a83-5949-7a97273349eb@zeus.net.au> Message-ID: <4287ede7-f145-7c87-fe23-baa22bd0347d@oracle.com> On 8/2/21 8:28 PM, Peter Firmstone wrote: > In JGDMS without SM, at least the following must be addressed to > maintain security: > > 1. TLS and Kerberos connections cannot be established.? (My software is > littered with doPrivileged calls that preserve the Subject, we don't > have anon TLS connections, we require client certificates). As mentioned several times, this use case will be preserved and is already covered in JEP 411: https://openjdk.java.net/jeps/411#subject-doas > 2. All remote connections are authorized to load classes. Not sure why you can't do something with a custom ClassLoader that only loads classes for authorized users. > 3. All remote connections are authorized to perform deserialization. Depending on serialization long-term seems somewhat dubious. > Having established that OpenJDK is not yet willing to compromise, I have > been attempting to create an authorization layer using Agents, so that I > can restore perimeter security following the removal of SM and support > future versions of Java.?? It is my hope that either I will be > successful in recreating an authorization layer, or that enough people > come forward and OpenJDK decides there are enough affected developers to > find a compromise that either makes migration practical, or less expensive. You may have some interesting ideas, but in my opinion you have not presented them in a clear and easily digestible manner, and your long emails are time consuming to read, repetitive and often diverge into rants. (Keep in mind there are many people on the jdk-dev alias, and a lot of them may not care about this topic). 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. --Sean From peter.firmstone at zeus.net.au Wed Aug 4 00:10:56 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Wed, 4 Aug 2021 10:10:56 +1000 Subject: JEP 411, removal of finalizers, a path forward. In-Reply-To: <4287ede7-f145-7c87-fe23-baa22bd0347d@oracle.com> References: <4257646b-6678-5419-13ae-5b470d4c510d@redhat.com> <000001d786e1$7885b0b0$69911210$@apache.org> <391deb02-68ba-4d67-7475-e13534dfd97d@redhat.com> <64671073-b67c-4a83-5949-7a97273349eb@zeus.net.au> <4287ede7-f145-7c87-fe23-baa22bd0347d@oracle.com> Message-ID: <7f967c5e-9674-9202-6895-bda490f72a74@zeus.net.au> On 4/08/2021 2:40 am, Sean Mullan wrote: > > > On 8/2/21 8:28 PM, Peter Firmstone wrote: >> In JGDMS without SM, at least the following must be addressed to >> maintain security: >> >> ? 1. TLS and Kerberos connections cannot be established.? (My >> software is >> ???? littered with doPrivileged calls that preserve the Subject, we >> don't >> ???? have anon TLS connections, we require client certificates). > > As mentioned several times, this use case will be preserved and is > already covered in JEP 411: > https://openjdk.java.net/jeps/411#subject-doas Yes, that's true, a secondary consideration is the amount of work that will be required to support different versions of Java, no doubt reflection will be helpful, to check for the existence of the new methods.?? Last time I checked, I have around 1,000 locations in the code that will require changes.?? My motivation for mentioning it was to highlight the benefit of reusing existing methods, which currently provide this functionality. > >> ? 2. All remote connections are authorized to load classes. > > Not sure why you can't do something with a custom ClassLoader that > only loads classes for authorized users. Interesting, what do you have in mind? We currently do have a hierarchy of custom ClassLoaders, however its concern is class resolution at client endpoints (Warning this isn't simple and may be confusing if you're not familiar with Jini and I may not be able to explain it sufficiently for it to be simply understood). We have solved some extremely difficult software design problems that Sun Microsystems left unresolved with Jini. https://dl.acm.org/doi/epdf/10.5555/1698139 Our software architecture is designed for separation of concerns.? Grafting authorization onto ClassLoader's doesn't sound like a good design decision, however I'm listening. Our current ClassLoader inheritance hierarchy: SecureClassLoader -> URLClassLoader -> RFC3986URLClassLoader -> PreferredClassLoader The reason I highlight SecureClassLoader is, we override SecureClassLoader methods to replace CodeSource, with a CodeSource that uses RFC3986 and RFC5952 normalization for identity in SecureClassLoader, to avoid DNS calls and to normalize IPv6 addresses where DNS isn't used and endpoints contact each other directly and their identity needs to be defined by their normalized address. However, PreferredClassLoader, modifies class resolution, allowing the authenticated service to resolve classes that it prefers, from it's own CodeSource, before they are loaded from the parent ClassLoader, that it lists as preferred, allowing the service to have a weak form of Isolation (we didn't design this, inherited from Sun). In our JERI (Jini Extensible Remote Invocation) Endpoints, ClassLoader's are assigned at both Client and Server Endpoint's, for class resolution (we designed this), and at the client endpoint, each ClassLoader is unique to the identity of the Service, the authenticated Subject of the Service, is part of the Service identity.? Only the Service can deserialize (not Java serialization) into this ClassLoader, but only after authenticating. Unlike Java RMI, we don't annotate codebases in the stream (a mistake that duplicates the ClassLoader class resolution mechanism), instead we assign ClassLoaders for class resolution at both endpoints when the streams are created, the ClassLoader is provisioned with the correct codebase for the service, after authentication. A user is assigned GrantPermission( Insert Java permission here) in policy files, users can dynamically grant permissions to a Service, after it has authenticated, the service, advises the client of Permissions it needs, the permissions granted are the intersection of the sets of what the client is willing and authorized to grant, and the permissions requested by the Service. This might highlight why the simplest option at this time is to re-implement an authorization layer. The resulting capability and power of these features are not widely understood or known.?? Think of a service, that can be advertised on any IPv6 network, anywhere in the world, and be discovered by a user on an IPv6 anywhere else in the world, without an intermediary.? Over secure sockets.? Provided the user and the service have common trust certificates, they could be from the same company, or part of a club or organization. For example multiple parties can participate in a transaction globally. > >> ? 3. All remote connections are authorized to perform deserialization. > > Depending on serialization long-term seems somewhat dubious. Agreed, in many of my previous emails I've added brackets after serialization that state (not Java serialization), perhaps I should just start calling it not Java serialization, this was written prior to the introduction of serialization filters, to address the shortcomings of Java Serialization, it's a subset of Java serialization re-implemented to use constructors and parameter type checking.?? We've had 10 years to prepare for Java Serialization's removal, which seems overdue now.? I was currently working on a public Serialization API that would allow JERI to have an extensible serialization layer, to allow the use of various protocols, however that is on hold, until (assuming) I can resolve JEP 411. https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/io/AtomicMarshalInputStream.java > >> Having established that OpenJDK is not yet willing to compromise, I have >> been attempting to create an authorization layer using Agents, so that I >> can restore perimeter security following the removal of SM and support >> future versions of Java.?? It is my hope that either I will be >> successful in recreating an authorization layer, or that enough people >> come forward and OpenJDK decides there are enough affected developers to >> find a compromise that either makes migration practical, or less >> expensive. > > You may have some interesting ideas, but in my opinion you have not > presented them in a clear and easily digestible manner, and your long > emails are time consuming to read, repetitive and often diverge into > rants. (Keep in mind there are many people on the jdk-dev alias, and a > lot of them may not care about this topic). 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. It's a two way street, I'm currently penetration testing OpenJDK dev's to discover their pain points with SM architecture, as they haven't documented them in JEP411.? When I am sure I have discovered your pain points, I plan to document a proposal. There's no point writing something up that address the wrong pain points. On that topic, I think for historical purposes, JEP 411's wording could more accurately reflect the experiences of developers who overcame the shortcomings that beginners experience with SM.?? JEP 411 does well to document beginners experiences when first attempting to use SM, however I think this unfairly penalizes the original authors, history should look more kindly on their achievements.? SM is a great achievement that stood the test of time for over 20 years, and no one else has succeeded at this task, it's not perfect, but it works well for those who are using it to it's full potential.? It's association with Applets and their use of ClassLoaders as a weak form of isolation, and the resulting permission sprawl that eventuated as band-aids to each vulnerability, is unfortunate. Some of these problems solved today, that JEP 411 is undoing, took years to solve the first time around.?? Don't expect it to be easy to understand. Thanks, Peter. From peter.firmstone at zeus.net.au Wed Aug 4 00:19:03 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Wed, 4 Aug 2021 10:19:03 +1000 Subject: [External] : Re: JEP 411, removal of finalizers, a path forward. In-Reply-To: <5BE7D172-304A-4143-BD6B-B6426BEEC258@oracle.com> References: <4257646b-6678-5419-13ae-5b470d4c510d@redhat.com> <000001d786e1$7885b0b0$69911210$@apache.org> <391deb02-68ba-4d67-7475-e13534dfd97d@redhat.com> <64671073-b67c-4a83-5949-7a97273349eb@zeus.net.au> <75A781C9-9A0D-4A3B-8E59-352CDCF088BE@oracle.com> <69e09a94-0717-0ac0-74c2-8b0fd78fbc78@zeus.net.au> <8416aaae-8d12-eb33-fb50-7e861d1c6cbd@zeus.net.au> <47D86F98-369E-4B25-84BE-185931B99E53@oracle.com> <8815f1ce-9ed4-1d60-ded4-b15f70b46dce@zeus.net.au> <6D038394-300A-42E0-AEA9-A075A132F553@oracle.com> <3bd68043-cd3a-16a8-f6a2-4273b2247de6@zeus.net.au> <5BE7D172-304A-4143-BD6B-B6426BEEC258@oracle.com> Message-ID: <6699b16f-e2be-f12a-646a-d060d4bd3588@zeus.net.au> Excellent, Ron, that's exactly what I'm after. I need to be able to implement an authorization layer on top of the JDK, but reach down into the JDK to use authorization to control access. Can we find out how many such checks that OpenJDK is prepared to support, then we will pick the most important? Don't worry about ClassLoader, I can instrument that (thank you Erik), and maybe I can instrument Properties, and System.exit. So basically things we can't easily instrument with agents, that everybody is most likely to want. * Network access * File System access * User Credentials Maybe we should have a mailing list dedicated to this where we can discuss and potentially collaborate? Regards, Peter. On 3/08/2021 10:15 pm, Ron Pressler wrote: > >> On 3 Aug 2021, at 12:50, Peter Firmstone wrote: >> >> Can you think of any workable alternative compromises? > If you mean a compromise between no access checks in the JDK and all access checks in the JDK, then yes, > which is 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, as the value in such a mechanism might end up being worthy of that amount of effort. But I?m > guessing that the more such hooks are requested, the less likely it is that the cost remains acceptable. > > ? Ron From peter.firmstone at zeus.net.au Wed Aug 4 01:23:47 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Wed, 4 Aug 2021 11:23:47 +1000 Subject: [External] : Re: JEP 411, removal of finalizers, a path forward. In-Reply-To: <6699b16f-e2be-f12a-646a-d060d4bd3588@zeus.net.au> References: <4257646b-6678-5419-13ae-5b470d4c510d@redhat.com> <000001d786e1$7885b0b0$69911210$@apache.org> <391deb02-68ba-4d67-7475-e13534dfd97d@redhat.com> <64671073-b67c-4a83-5949-7a97273349eb@zeus.net.au> <75A781C9-9A0D-4A3B-8E59-352CDCF088BE@oracle.com> <69e09a94-0717-0ac0-74c2-8b0fd78fbc78@zeus.net.au> <8416aaae-8d12-eb33-fb50-7e861d1c6cbd@zeus.net.au> <47D86F98-369E-4B25-84BE-185931B99E53@oracle.com> <8815f1ce-9ed4-1d60-ded4-b15f70b46dce@zeus.net.au> <6D038394-300A-42E0-AEA9-A075A132F553@oracle.com> <3bd68043-cd3a-16a8-f6a2-4273b2247de6@zeus.net.au> <5BE7D172-304A-4143-BD6B-B6426BEEC258@oracle.com> <6699b16f-e2be-f12a-646a-d060d4bd3588@zeus.net.au> Message-ID: <72a6a79d-2f49-f60c-9fe3-8e57b5948bb5@zeus.net.au> Maybe we need some criteria, that defines what's not easily instrumented? On 4/08/2021 10:19 am, Peter Firmstone wrote: > > Excellent, Ron, that's exactly what I'm after. > > I need to be able to implement an authorization layer on top of the > JDK, but reach down into the JDK to use authorization to control access. > > Can we find out how many such checks that OpenJDK is prepared to > support, then we will pick the most important? > > Don't worry about ClassLoader, I can instrument that (thank you Erik), > and maybe I can instrument Properties, and System.exit. So basically > things we can't easily instrument with agents, that everybody is most > likely to want. > > * Network access > * File System access > * User Credentials > > Maybe we should have a mailing list dedicated to this where we can > discuss and potentially collaborate? > > Regards, > > Peter. > > On 3/08/2021 10:15 pm, Ron Pressler wrote: >>> On 3 Aug 2021, at 12:50, Peter Firmstone wrote: >>> >>> Can you think of any workable alternative compromises? >> If you mean a compromise between no access checks in the JDK and all access checks in the JDK, then yes, >> which is 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, as the value in such a mechanism might end up being worthy of that amount of effort. But I?m >> guessing that the more such hooks are requested, the less likely it is that the cost remains acceptable. >> >> ? Ron -- Regards, Peter Firmstone 0498 286 363 Zeus Project Services Pty Ltd. From frederick888 at tsundere.moe Wed Aug 4 02:38:25 2021 From: frederick888 at tsundere.moe (Frederick Zhang) Date: Wed, 04 Aug 2021 12:38:25 +1000 Subject: Question about JDK-6925410 Message-ID: Hello everyone, I've got a question about JDK-6925410 [1] and I hope this is the right place to ask. I'm experiencing some slowness when handling XML request bodies in Spring. After digging into the code, it led me to [2] where it instantiates XMLReader upon every request. And the reason of the slowness here seems to be related to JDK-6925410, since after pre-assigning a parser via '-Dorg.xml.sax.driver=com.sun.org.apache.xerces.internal.parsers.SAXParser' the slowness was gone. Although I understand creating new XMLReader instances every time is an anti-pattern, JDK-6925410 mentioned that there was a fix put in place on jaxp's side so I'm wondering what the fix was? I tried downloading relevant sources from [3][4][5] for comparison but some links were broken. Then I checked out the latest JDK code [6] and it's still doing the class scanning but the method has been marked as deprecated. May I know if people are simply suggested to migrate to SAXParserFactory or there's another way of using XMLReaderFactory to avoid the scanning without pre-assigning any parser? [1] https://bugs.openjdk.java.net/browse/JDK-6925410 [2] https://github.com/spring-projects/spring-framework/blob/8242d02f9d47679610e4c6259dc7b87f195f2eaa/spring-web/src/main/java/org/springframework/http/converter/xml/Jaxb2RootElementHttpMessageConverter.java#L162 [3] https://download.java.net/openjdk/jdk6/promoted/b13/ [4] https://download.java.net/openjdk/jdk7/promoted/b112/ [5] https://download.java.net/openjdk/jdk7/ [6] https://github.com/openjdk/jdk/blob/c8add223a10030e40ccef42e081fd0d8f00e0593/src/java.xml/share/classes/org/xml/sax/helpers/XMLReaderFactory.java#L144-L148 -- Best regards, Frederick Zhang Email: frederick888 at tsundere.moe PGP: 8BFB EA5B 4C44 BFAC C8EC 5F93 1F92 8BE6 0D8B C11D From Alan.Bateman at oracle.com Wed Aug 4 07:53:27 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 4 Aug 2021 08:53:27 +0100 Subject: Question about JDK-6925410 In-Reply-To: References: Message-ID: <9e483539-0a03-3287-8520-42648fda84c9@oracle.com> On 04/08/2021 03:38, Frederick Zhang wrote: > Hello everyone, > > I've got a question about JDK-6925410 [1] and I hope this is the right > place to ask. > > I'm experiencing some slowness when handling XML request bodies in > Spring. After digging into the code, it led me to [2] where it > instantiates XMLReader upon every request. And the reason of the > slowness here seems to be related to JDK-6925410, since after > pre-assigning a parser via > '-Dorg.xml.sax.driver=com.sun.org.apache.xerces.internal.parsers.SAXParser' > > the slowness was gone. > > Although I understand creating new XMLReader instances every time is an > anti-pattern, JDK-6925410 mentioned that there was a fix put in place on > jaxp's side so I'm wondering what the fix was? > > I tried downloading relevant sources from [3][4][5] for comparison but > some links were broken. Then I checked out the latest JDK code [6] and > it's still doing the class scanning but the method has been marked as > deprecated. May I know if people are simply suggested to migrate to > SAXParserFactory or there's another way of using XMLReaderFactory to > avoid the scanning without pre-assigning any parser? Yes, this has ben deprecated for many releases. The scanning to locate an XMLReader implementation is specified so I don't think that can be dropped without a specification change and/or coordination with the defunct SAX project. jdk-dev isn't the right place to go into all this. Best to bring a test case to core-libs-dev for discussion. -Alan. From frederick888 at tsundere.moe Wed Aug 4 08:29:42 2021 From: frederick888 at tsundere.moe (Frederick Zhang) Date: Wed, 4 Aug 2021 18:29:42 +1000 Subject: Question about JDK-6925410 In-Reply-To: <9e483539-0a03-3287-8520-42648fda84c9@oracle.com> References: <9e483539-0a03-3287-8520-42648fda84c9@oracle.com> Message-ID: <70bcb0f7-b39e-c8c1-d54d-8fd9ff71aa31@tsundere.moe> Thanks a lot for the prompt response, Alan! If this is the case I think it's probably better to get the Spring folks involved. I've submitted a PR [1] to their project to see how they think about this. [1] https://github.com/spring-projects/spring-framework/pull/27239 On 4/8/21 5:53 pm, Alan Bateman wrote: > On 04/08/2021 03:38, Frederick Zhang wrote: >> Hello everyone, >> >> I've got a question about JDK-6925410 [1] and I hope this is the right >> place to ask. >> >> I'm experiencing some slowness when handling XML request bodies in >> Spring. After digging into the code, it led me to [2] where it >> instantiates XMLReader upon every request. And the reason of the >> slowness here seems to be related to JDK-6925410, since after >> pre-assigning a parser via >> '-Dorg.xml.sax.driver=com.sun.org.apache.xerces.internal.parsers.SAXParser' >> the slowness was gone. >> >> Although I understand creating new XMLReader instances every time is an >> anti-pattern, JDK-6925410 mentioned that there was a fix put in place on >> jaxp's side so I'm wondering what the fix was? >> >> I tried downloading relevant sources from [3][4][5] for comparison but >> some links were broken. Then I checked out the latest JDK code [6] and >> it's still doing the class scanning but the method has been marked as >> deprecated. May I know if people are simply suggested to migrate to >> SAXParserFactory or there's another way of using XMLReaderFactory to >> avoid the scanning without pre-assigning any parser? > Yes, this has ben deprecated for many releases. The scanning to locate an XMLReader implementation is specified so I don't think that can be dropped without a specification change and/or coordination with the defunct SAX project. jdk-dev isn't the right place to go into all this. Best to bring a test case to core-libs-dev for discussion. > > -Alan. -- Best regards, Frederick Zhang Email: frederick888 at tsundere.moe PGP: 8BFB EA5B 4C44 BFAC C8EC 5F93 1F92 8BE6 0D8B C11D From ron.pressler at oracle.com Wed Aug 4 10:29:08 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Wed, 4 Aug 2021 10:29:08 +0000 Subject: [External] : Re: JEP 411, removal of finalizers, a path forward. In-Reply-To: <6699b16f-e2be-f12a-646a-d060d4bd3588@zeus.net.au> References: <4257646b-6678-5419-13ae-5b470d4c510d@redhat.com> <000001d786e1$7885b0b0$69911210$@apache.org> <391deb02-68ba-4d67-7475-e13534dfd97d@redhat.com> <64671073-b67c-4a83-5949-7a97273349eb@zeus.net.au> <75A781C9-9A0D-4A3B-8E59-352CDCF088BE@oracle.com> <69e09a94-0717-0ac0-74c2-8b0fd78fbc78@zeus.net.au> <8416aaae-8d12-eb33-fb50-7e861d1c6cbd@zeus.net.au> <47D86F98-369E-4B25-84BE-185931B99E53@oracle.com> <8815f1ce-9ed4-1d60-ded4-b15f70b46dce@zeus.net.au> <6D038394-300A-42E0-AEA9-A075A132F553@oracle.com> <3bd68043-cd3a-16a8-f6a2-4273b2247de6@zeus.net.au> <5BE7D172-304A-4143-BD6B-B6426BEEC258@oracle.com> <6699b16f-e2be-f12a-646a-d060d4bd3588@zeus.net.au> Message-ID: <984CB06D-63E8-4CD1-AF04-285C83125BE6@oracle.com> > On 4 Aug 2021, at 01:19, Peter Firmstone wrote: > > Excellent, Ron, that's exactly what I'm after. > > I need to be able to implement an authorization layer on top of the JDK, but reach down into the JDK to use authorization to control access. > > Can we find out how many such checks that OpenJDK is prepared to support, then we will pick the most important? > > Pick any three you?d like. I?m joking. How many or few ? or whether this is the right approach at all ? depends, like everything, on value vs. cost. Maybe Sean or Alan can tell you where the best place to discuss this is ? there probably won?t be a separate mailing list, as it won?t be a big project ? but perhaps it?s best to let things sink in for a while and take time to think. The OpenJDK development process is such that the relevant stewards of the platform, people like Alan and Sean, make the decisions, the committers do the development, and relevant (and, preferably succinct) feedback from users is appreciated. It?s important to remember that while all feedback is taken seriously, not all of it is accepted, for the simple reason that it is ultimately the stewards? job to consider the interests of the entire ecosystem ? to the best of their abilities ? and not just that of those who give feedback. To see what ideas are currently being considered and which proposals are planned ? the stewards will present them to the OpenJDK community at the appropriate time ? see the Future Work section of the JEP: https://openjdk.java.net/jeps/411#Future-Work ? Ron From thomas.schatzl at oracle.com Wed Aug 4 10:33:40 2021 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 4 Aug 2021 12:33:40 +0200 Subject: CFV: New JDK Reviewer: Albert Mingkun Yang Message-ID: Hi all, I hereby nominate Albert Mingkun Yang (ayang[1]) to the role of JDK Project Reviewer. Albert is currently a JDK committer, member of the Garbage Collection team at Oracle for a few years now, and has, before joining Oracle, been working on garbage collection with ZGC during his PhD (e.g. [2], [3]). He has made substantial contributions [4] to the development of the mostly G1 and ZGC, in particular just recently an algorithm to dynamically adjust the number of concurrent threads for ZGC [5], and has in total made 60 individual contributions to the JDK project. Only current JDK Project Reviewers [6] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [7]. Votes are due by 12:00 UTC on 18th of August 2021. Thomas [1] https://openjdk.java.net/census#ayang [2] https://dl.acm.org/doi/abs/10.1145/3381898.3397213 [3] https://dl.acm.org/doi/abs/10.1145/3385412.3385977 [4] https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Albert+Yang%22&type=commits [5] https://bugs.openjdk.java.net/browse/JDK-8268372 [6] https://openjdk.java.net/census [7] https://openjdk.java.net/projects/#reviewer-vote From thomas.schatzl at oracle.com Wed Aug 4 10:34:13 2021 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 4 Aug 2021 12:34:13 +0200 Subject: CFV: New JDK Reviewer: Albert Mingkun Yang In-Reply-To: References: Message-ID: <988a91ff-3821-c971-8b40-229ad55754a6@oracle.com> Vote: yes On 04.08.21 12:33, Thomas Schatzl wrote: > Hi all, > > ? I hereby nominate Albert Mingkun Yang (ayang[1]) to the role of JDK > Project Reviewer. > > Albert is currently a JDK committer, member of the Garbage Collection > team at Oracle for a few years now, and has, before joining Oracle, been > working on garbage collection with ZGC during his PhD (e.g. [2], [3]). > > He has made substantial contributions [4] to the development of the > mostly G1 and ZGC, in particular just recently an algorithm to > dynamically adjust the number of concurrent threads for ZGC [5], and has > in total made 60 individual contributions to the JDK project. > > Only current JDK Project Reviewers [6] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > For Three-Vote Consensus voting instructions, see [7]. > > Votes are due by 12:00 UTC on 18th of August 2021. > > Thomas > > [1] https://openjdk.java.net/census#ayang > [2] https://dl.acm.org/doi/abs/10.1145/3381898.3397213 > [3] https://dl.acm.org/doi/abs/10.1145/3385412.3385977 > [4] > https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Albert+Yang%22&type=commits > > [5] https://bugs.openjdk.java.net/browse/JDK-8268372 > [6] https://openjdk.java.net/census > [7] https://openjdk.java.net/projects/#reviewer-vote From volker.simonis at gmail.com Wed Aug 4 10:36:28 2021 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 4 Aug 2021 12:36:28 +0200 Subject: CFV: New JDK Reviewer: Albert Mingkun Yang In-Reply-To: References: Message-ID: Vote: yes On Wed, Aug 4, 2021 at 12:34 PM Thomas Schatzl wrote: > > Hi all, > > I hereby nominate Albert Mingkun Yang (ayang[1]) to the role of JDK > Project Reviewer. > > Albert is currently a JDK committer, member of the Garbage Collection > team at Oracle for a few years now, and has, before joining Oracle, been > working on garbage collection with ZGC during his PhD (e.g. [2], [3]). > > He has made substantial contributions [4] to the development of the > mostly G1 and ZGC, in particular just recently an algorithm to > dynamically adjust the number of concurrent threads for ZGC [5], and has > in total made 60 individual contributions to the JDK project. > > Only current JDK Project Reviewers [6] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > For Three-Vote Consensus voting instructions, see [7]. > > Votes are due by 12:00 UTC on 18th of August 2021. > > Thomas > > [1] https://openjdk.java.net/census#ayang > [2] https://dl.acm.org/doi/abs/10.1145/3381898.3397213 > [3] https://dl.acm.org/doi/abs/10.1145/3385412.3385977 > [4] > https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Albert+Yang%22&type=commits > [5] https://bugs.openjdk.java.net/browse/JDK-8268372 > [6] https://openjdk.java.net/census > [7] https://openjdk.java.net/projects/#reviewer-vote From claes.redestad at oracle.com Wed Aug 4 11:06:28 2021 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 4 Aug 2021 13:06:28 +0200 Subject: CFV: New JDK Reviewer: Albert Mingkun Yang In-Reply-To: References: Message-ID: <953a4db2-0068-44e4-dcdb-84a571886a0f@oracle.com> Vote: yes /Claes On 2021-08-04 12:33, Thomas Schatzl wrote: > Hi all, > > ? I hereby nominate Albert Mingkun Yang (ayang[1]) to the role of JDK > Project Reviewer. > > Albert is currently a JDK committer, member of the Garbage Collection > team at Oracle for a few years now, and has, before joining Oracle, been > working on garbage collection with ZGC during his PhD (e.g. [2], [3]). > > He has made substantial contributions [4] to the development of the > mostly G1 and ZGC, in particular just recently an algorithm to > dynamically adjust the number of concurrent threads for ZGC [5], and has > in total made 60 individual contributions to the JDK project. > > Only current JDK Project Reviewers [6] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > For Three-Vote Consensus voting instructions, see [7]. > > Votes are due by 12:00 UTC on 18th of August 2021. > > Thomas > > [1] https://openjdk.java.net/census#ayang > [2] https://dl.acm.org/doi/abs/10.1145/3381898.3397213 > [3] https://dl.acm.org/doi/abs/10.1145/3385412.3385977 > [4] > https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Albert+Yang%22&type=commits > > [5] https://bugs.openjdk.java.net/browse/JDK-8268372 > [6] https://openjdk.java.net/census > [7] https://openjdk.java.net/projects/#reviewer-vote From Alan.Bateman at oracle.com Wed Aug 4 11:08:12 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 4 Aug 2021 12:08:12 +0100 Subject: Fate of {System|Runtime}.runFinalization (Re: Ad removing finalize eventually In-Reply-To: References: <19858490-648a-d539-2429-b1999f597658@zeus.net.au> <8d6f394d-f0a8-fa41-24ec-f8437af99d4f@oracle.com> <8f9e9e58-d5bb-0a99-7f3e-937a33c9e2b8@zeus.net.au> <0ae93ef1-3416-9cc0-d6e3-2fe1ccb1df4f@oracle.com> <67886c79-aef1-bc41-0057-9acb943a0e0f@wu.ac.at> <3b555f81-2cb5-73dd-90d4-e37d9549cb56@wu.ac.at> <39c357e2-dc51-32ae-71fa-c8aebde1aeb5@oracle.com> <19cc0c9c-1b93-8af9-28db-a07f2b9c71e5@wu.ac.at> Message-ID: <95a880e3-2f69-6b5a-e35a-075540e2e848@oracle.com> On 03/08/2021 17:09, Hans Boehm wrote: > : > > 2) The lack of a clean runFinalization alternative. I think this is > actually an opportunity > to improve things and motivate people to switch away from > finalization. But currently > it pushes in the wrong direction. > Maybe but at the same time I don't think runFinalization is widely used. A analysis of >100k artifacts from Maven central found only 275 usages and this reduces down to about 175 when only the latest version of libraries are analyzed. I don't have data to know how many of these have been maintained in the last 10 years but at least some of the usages are tests or benchmarks. So it might be that there is manageable set of examples that can be studied to see if there is big need for something to coordinate with reference processing. -Alan From kartikohri13 at gmail.com Wed Aug 4 11:26:41 2021 From: kartikohri13 at gmail.com (Kartik Ohri) Date: Wed, 4 Aug 2021 16:56:41 +0530 Subject: Plans to remove -source & -target option 7 in javac? Message-ID: Hi all! JDK-8173605 has not been updated for some time. Hence, out of curiosity, I ask if there are currently any plans to remove the -source & -target 7 options in javac in JDK 18? Regards, Kartik From jesper.wilhelmsson at oracle.com Wed Aug 4 11:37:39 2021 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 4 Aug 2021 11:37:39 +0000 Subject: CFV: New JDK Reviewer: Albert Mingkun Yang In-Reply-To: References: Message-ID: Vote: Yes /Jesper > 4 aug. 2021 kl. 12:33 skrev Thomas Schatzl : > > Hi all, > > I hereby nominate Albert Mingkun Yang (ayang[1]) to the role of JDK Project Reviewer. > > Albert is currently a JDK committer, member of the Garbage Collection team at Oracle for a few years now, and has, before joining Oracle, been working on garbage collection with ZGC during his PhD (e.g. [2], [3]). > > He has made substantial contributions [4] to the development of the mostly G1 and ZGC, in particular just recently an algorithm to dynamically adjust the number of concurrent threads for ZGC [5], and has in total made 60 individual contributions to the JDK project. > > Only current JDK Project Reviewers [6] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > For Three-Vote Consensus voting instructions, see [7]. > > Votes are due by 12:00 UTC on 18th of August 2021. > > Thomas > > [1] https://openjdk.java.net/census#ayang > [2] https://dl.acm.org/doi/abs/10.1145/3381898.3397213 > [3] https://dl.acm.org/doi/abs/10.1145/3385412.3385977 > [4] https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Albert+Yang%22&type=commits > [5] https://bugs.openjdk.java.net/browse/JDK-8268372 > [6] https://openjdk.java.net/census > [7] https://openjdk.java.net/projects/#reviewer-vote From erik.osterlund at oracle.com Wed Aug 4 11:39:48 2021 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Wed, 4 Aug 2021 11:39:48 +0000 Subject: CFV: New JDK Reviewer: Albert Mingkun Yang In-Reply-To: References: Message-ID: <253D7532-C31F-4287-8225-B7761E62E9B2@oracle.com> Vote: yes /Erik > On 4 Aug 2021, at 12:34, Thomas Schatzl wrote: > > ?Hi all, > > I hereby nominate Albert Mingkun Yang (ayang[1]) to the role of JDK Project Reviewer. > > Albert is currently a JDK committer, member of the Garbage Collection team at Oracle for a few years now, and has, before joining Oracle, been working on garbage collection with ZGC during his PhD (e.g. [2], [3]). > > He has made substantial contributions [4] to the development of the mostly G1 and ZGC, in particular just recently an algorithm to dynamically adjust the number of concurrent threads for ZGC [5], and has in total made 60 individual contributions to the JDK project. > > Only current JDK Project Reviewers [6] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > For Three-Vote Consensus voting instructions, see [7]. > > Votes are due by 12:00 UTC on 18th of August 2021. > > Thomas > > [1] https://openjdk.java.net/census#ayang > [2] https://dl.acm.org/doi/abs/10.1145/3381898.3397213 > [3] https://dl.acm.org/doi/abs/10.1145/3385412.3385977 > [4] https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Albert+Yang%22&type=commits > [5] https://bugs.openjdk.java.net/browse/JDK-8268372 > [6] https://openjdk.java.net/census > [7] https://openjdk.java.net/projects/#reviewer-vote From adinn at redhat.com Wed Aug 4 12:00:24 2021 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 4 Aug 2021 13:00:24 +0100 Subject: CFV: New JDK Reviewer: Albert Mingkun Yang In-Reply-To: References: Message-ID: Vote: yes On 04/08/2021 11:33, Thomas Schatzl wrote: > Hi all, > > ? I hereby nominate Albert Mingkun Yang (ayang[1]) to the role of JDK > Project Reviewer. > > Albert is currently a JDK committer, member of the Garbage Collection > team at Oracle for a few years now, and has, before joining Oracle, been > working on garbage collection with ZGC during his PhD (e.g. [2], [3]). > > He has made substantial contributions [4] to the development of the > mostly G1 and ZGC, in particular just recently an algorithm to > dynamically adjust the number of concurrent threads for ZGC [5], and has > in total made 60 individual contributions to the JDK project. > > Only current JDK Project Reviewers [6] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > For Three-Vote Consensus voting instructions, see [7]. > > Votes are due by 12:00 UTC on 18th of August 2021. > > Thomas > > [1] https://openjdk.java.net/census#ayang > [2] https://dl.acm.org/doi/abs/10.1145/3381898.3397213 > [3] https://dl.acm.org/doi/abs/10.1145/3385412.3385977 > [4] > https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Albert+Yang%22&type=commits > > [5] https://bugs.openjdk.java.net/browse/JDK-8268372 > [6] https://openjdk.java.net/census > [7] https://openjdk.java.net/projects/#reviewer-vote > -- regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From Alan.Bateman at oracle.com Wed Aug 4 12:04:50 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 4 Aug 2021 13:04:50 +0100 Subject: CFV: New JDK Reviewer: Albert Mingkun Yang In-Reply-To: References: Message-ID: Vote: yes From zgu at redhat.com Wed Aug 4 12:16:00 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 4 Aug 2021 08:16:00 -0400 Subject: CFV: New JDK Reviewer: Albert Mingkun Yang In-Reply-To: References: Message-ID: <3bece090-1114-4f22-2296-f54bfc5487f1@redhat.com> Vote: yes -Zhengyu On 8/4/21 6:33 AM, Thomas Schatzl wrote: > Hi all, > > ? I hereby nominate Albert Mingkun Yang (ayang[1]) to the role of JDK > Project Reviewer. > > Albert is currently a JDK committer, member of the Garbage Collection > team at Oracle for a few years now, and has, before joining Oracle, been > working on garbage collection with ZGC during his PhD (e.g. [2], [3]). > > He has made substantial contributions [4] to the development of the > mostly G1 and ZGC, in particular just recently an algorithm to > dynamically adjust the number of concurrent threads for ZGC [5], and has > in total made 60 individual contributions to the JDK project. > > Only current JDK Project Reviewers [6] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > For Three-Vote Consensus voting instructions, see [7]. > > Votes are due by 12:00 UTC on 18th of August 2021. > > Thomas > > [1] https://openjdk.java.net/census#ayang > [2] https://dl.acm.org/doi/abs/10.1145/3381898.3397213 > [3] https://dl.acm.org/doi/abs/10.1145/3385412.3385977 > [4] > https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Albert+Yang%22&type=commits > > [5] https://bugs.openjdk.java.net/browse/JDK-8268372 > [6] https://openjdk.java.net/census > [7] https://openjdk.java.net/projects/#reviewer-vote > From david.holmes at oracle.com Wed Aug 4 12:38:06 2021 From: david.holmes at oracle.com (David Holmes) Date: Wed, 4 Aug 2021 22:38:06 +1000 Subject: CFV: New JDK Reviewer: Albert Mingkun Yang In-Reply-To: References: Message-ID: <795d864c-13ec-9ffb-c52c-2f93f261ef3b@oracle.com> Vote: yes David On 4/08/2021 8:33 pm, Thomas Schatzl wrote: > Hi all, > > ? I hereby nominate Albert Mingkun Yang (ayang[1]) to the role of JDK > Project Reviewer. > > Albert is currently a JDK committer, member of the Garbage Collection > team at Oracle for a few years now, and has, before joining Oracle, been > working on garbage collection with ZGC during his PhD (e.g. [2], [3]). > > He has made substantial contributions [4] to the development of the > mostly G1 and ZGC, in particular just recently an algorithm to > dynamically adjust the number of concurrent threads for ZGC [5], and has > in total made 60 individual contributions to the JDK project. > > Only current JDK Project Reviewers [6] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > For Three-Vote Consensus voting instructions, see [7]. > > Votes are due by 12:00 UTC on 18th of August 2021. > > Thomas > > [1] https://openjdk.java.net/census#ayang > [2] https://dl.acm.org/doi/abs/10.1145/3381898.3397213 > [3] https://dl.acm.org/doi/abs/10.1145/3385412.3385977 > [4] > https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Albert+Yang%22&type=commits > > [5] https://bugs.openjdk.java.net/browse/JDK-8268372 > [6] https://openjdk.java.net/census > [7] https://openjdk.java.net/projects/#reviewer-vote From harold.seigel at oracle.com Wed Aug 4 12:38:58 2021 From: harold.seigel at oracle.com (Harold Seigel) Date: Wed, 4 Aug 2021 08:38:58 -0400 Subject: CFV: New JDK Reviewer: Albert Mingkun Yang In-Reply-To: References: Message-ID: Vote: Yes Harold On 8/4/2021 6:33 AM, Thomas Schatzl wrote: > Hi all, > > ? I hereby nominate Albert Mingkun Yang (ayang[1]) to the role of JDK > Project Reviewer. > > Albert is currently a JDK committer, member of the Garbage Collection > team at Oracle for a few years now, and has, before joining Oracle, > been working on garbage collection with ZGC during his PhD (e.g. [2], > [3]). > > He has made substantial contributions [4] to the development of the > mostly G1 and ZGC, in particular just recently an algorithm to > dynamically adjust the number of concurrent threads for ZGC [5], and > has in total made 60 individual contributions to the JDK project. > > Only current JDK Project Reviewers [6] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > For Three-Vote Consensus voting instructions, see [7]. > > Votes are due by 12:00 UTC on 18th of August 2021. > > Thomas > > [1] https://openjdk.java.net/census#ayang > [2] https://dl.acm.org/doi/abs/10.1145/3381898.3397213 > [3] https://dl.acm.org/doi/abs/10.1145/3385412.3385977 > [4] > https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Albert+Yang%22&type=commits > [5] https://bugs.openjdk.java.net/browse/JDK-8268372 > [6] https://openjdk.java.net/census > [7] https://openjdk.java.net/projects/#reviewer-vote From kim.barrett at oracle.com Wed Aug 4 13:27:19 2021 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 4 Aug 2021 13:27:19 +0000 Subject: CFV: New JDK Reviewer: Albert Mingkun Yang In-Reply-To: References: Message-ID: vote: yes > On Aug 4, 2021, at 6:33 AM, Thomas Schatzl wrote: > > Hi all, > > I hereby nominate Albert Mingkun Yang (ayang[1]) to the role of JDK Project Reviewer. > > Albert is currently a JDK committer, member of the Garbage Collection team at Oracle for a few years now, and has, before joining Oracle, been working on garbage collection with ZGC during his PhD (e.g. [2], [3]). > > He has made substantial contributions [4] to the development of the mostly G1 and ZGC, in particular just recently an algorithm to dynamically adjust the number of concurrent threads for ZGC [5], and has in total made 60 individual contributions to the JDK project. > > Only current JDK Project Reviewers [6] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > For Three-Vote Consensus voting instructions, see [7]. > > Votes are due by 12:00 UTC on 18th of August 2021. > > Thomas > > [1] https://openjdk.java.net/census#ayang > [2] https://dl.acm.org/doi/abs/10.1145/3381898.3397213 > [3] https://dl.acm.org/doi/abs/10.1145/3385412.3385977 > [4] https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Albert+Yang%22&type=commits > [5] https://bugs.openjdk.java.net/browse/JDK-8268372 > [6] https://openjdk.java.net/census > [7] https://openjdk.java.net/projects/#reviewer-vote From per.liden at oracle.com Wed Aug 4 13:40:38 2021 From: per.liden at oracle.com (Per Liden) Date: Wed, 4 Aug 2021 15:40:38 +0200 Subject: CFV: New JDK Reviewer: Albert Mingkun Yang In-Reply-To: References: Message-ID: Vote: yes /Per On 8/4/21 12:33 PM, Thomas Schatzl wrote: > Hi all, > > ? I hereby nominate Albert Mingkun Yang (ayang[1]) to the role of JDK > Project Reviewer. > > Albert is currently a JDK committer, member of the Garbage Collection > team at Oracle for a few years now, and has, before joining Oracle, been > working on garbage collection with ZGC during his PhD (e.g. [2], [3]). > > He has made substantial contributions [4] to the development of the > mostly G1 and ZGC, in particular just recently an algorithm to > dynamically adjust the number of concurrent threads for ZGC [5], and has > in total made 60 individual contributions to the JDK project. > > Only current JDK Project Reviewers [6] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > For Three-Vote Consensus voting instructions, see [7]. > > Votes are due by 12:00 UTC on 18th of August 2021. > > Thomas > > [1] https://openjdk.java.net/census#ayang > [2] https://dl.acm.org/doi/abs/10.1145/3381898.3397213 > [3] https://dl.acm.org/doi/abs/10.1145/3385412.3385977 > [4] > https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Albert+Yang%22&type=commits > > [5] https://bugs.openjdk.java.net/browse/JDK-8268372 > [6] https://openjdk.java.net/census > [7] https://openjdk.java.net/projects/#reviewer-vote From leo.korinth at oracle.com Wed Aug 4 13:46:41 2021 From: leo.korinth at oracle.com (Leo Korinth) Date: Wed, 4 Aug 2021 15:46:41 +0200 Subject: CFV: New JDK Reviewer: Albert Mingkun Yang In-Reply-To: References: Message-ID: Vote: yes /Leo On 04/08/2021 12:33, Thomas Schatzl wrote: > Hi all, > > ? I hereby nominate Albert Mingkun Yang (ayang[1]) to the role of JDK > Project Reviewer. > > Albert is currently a JDK committer, member of the Garbage Collection > team at Oracle for a few years now, and has, before joining Oracle, been > working on garbage collection with ZGC during his PhD (e.g. [2], [3]). > > He has made substantial contributions [4] to the development of the > mostly G1 and ZGC, in particular just recently an algorithm to > dynamically adjust the number of concurrent threads for ZGC [5], and has > in total made 60 individual contributions to the JDK project. > > Only current JDK Project Reviewers [6] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > For Three-Vote Consensus voting instructions, see [7]. > > Votes are due by 12:00 UTC on 18th of August 2021. > > Thomas > > [1] https://openjdk.java.net/census#ayang > [2] https://dl.acm.org/doi/abs/10.1145/3381898.3397213 > [3] https://dl.acm.org/doi/abs/10.1145/3385412.3385977 > [4] > https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Albert+Yang%22&type=commits > > [5] https://bugs.openjdk.java.net/browse/JDK-8268372 > [6] https://openjdk.java.net/census > [7] https://openjdk.java.net/projects/#reviewer-vote From joe.darcy at oracle.com Wed Aug 4 14:09:58 2021 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 4 Aug 2021 07:09:58 -0700 Subject: Plans to remove -source & -target option 7 in javac? In-Reply-To: References: Message-ID: <2ab1479d-9b41-0f2c-5f9e-568a7a66f052@oracle.com> Hello Kartik, Updating JEP 182: "Policy for Retiring javac -source and -target Options" (http://openjdk.java.net/jeps/182) for the six-month release process is a known item to be done. That updated policy would in turn guide when -source/-target 7 and now also --release 7 would be dropped. Cheers, -Joe On 8/4/2021 4:26 AM, Kartik Ohri wrote: > Hi all! > > JDK-8173605 has not been > updated for some time. Hence, out of curiosity, I ask if there are > currently any plans to remove the -source & -target 7 options in javac in > JDK 18? > > Regards, > Kartik From lois.foltan at oracle.com Wed Aug 4 14:11:09 2021 From: lois.foltan at oracle.com (Lois Foltan) Date: Wed, 4 Aug 2021 10:11:09 -0400 Subject: CFV: New JDK Reviewer: Albert Mingkun Yang In-Reply-To: References: Message-ID: Vote: yes Lois On 8/4/2021 6:33 AM, Thomas Schatzl wrote: > Hi all, > > ? I hereby nominate Albert Mingkun Yang (ayang[1]) to the role of JDK > Project Reviewer. > > Albert is currently a JDK committer, member of the Garbage Collection > team at Oracle for a few years now, and has, before joining Oracle, > been working on garbage collection with ZGC during his PhD (e.g. [2], > [3]). > > He has made substantial contributions [4] to the development of the > mostly G1 and ZGC, in particular just recently an algorithm to > dynamically adjust the number of concurrent threads for ZGC [5], and > has in total made 60 individual contributions to the JDK project. > > Only current JDK Project Reviewers [6] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > For Three-Vote Consensus voting instructions, see [7]. > > Votes are due by 12:00 UTC on 18th of August 2021. > > Thomas > > [1] https://openjdk.java.net/census#ayang > [2] https://dl.acm.org/doi/abs/10.1145/3381898.3397213 > [3] https://dl.acm.org/doi/abs/10.1145/3385412.3385977 > [4] > https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Albert+Yang%22&type=commits > [5] https://bugs.openjdk.java.net/browse/JDK-8268372 > [6] https://openjdk.java.net/census > [7] https://openjdk.java.net/projects/#reviewer-vote From kartikohri13 at gmail.com Wed Aug 4 14:14:50 2021 From: kartikohri13 at gmail.com (Kartik Ohri) Date: Wed, 4 Aug 2021 19:44:50 +0530 Subject: Plans to remove -source & -target option 7 in javac? In-Reply-To: <2ab1479d-9b41-0f2c-5f9e-568a7a66f052@oracle.com> References: <2ab1479d-9b41-0f2c-5f9e-568a7a66f052@oracle.com> Message-ID: Hi, That makes sense. Thanks for the response, Joe. Cheers, Kartik On Wed, Aug 4, 2021 at 7:41 PM Joe Darcy wrote: > Hello Kartik, > > Updating JEP 182: "Policy for Retiring javac -source and -target > Options" (http://openjdk.java.net/jeps/182) for the six-month release > process is a known item to be done. That updated policy would in turn > guide when -source/-target 7 and now also --release 7 would be dropped. > > Cheers, > > -Joe > > On 8/4/2021 4:26 AM, Kartik Ohri wrote: > > Hi all! > > > > JDK-8173605 has not > been > > updated for some time. Hence, out of curiosity, I ask if there are > > currently any plans to remove the -source & -target 7 options in javac in > > JDK 18? > > > > Regards, > > Kartik > From Rony.Flatscher at wu.ac.at Wed Aug 4 14:35:10 2021 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Wed, 4 Aug 2021 16:35:10 +0200 Subject: Ad removing finalize eventually (Re: JEP 411 Headaches: Instrumenting private methods in the JDK for authorization checkpoints. In-Reply-To: References: <19858490-648a-d539-2429-b1999f597658@zeus.net.au> <8d6f394d-f0a8-fa41-24ec-f8437af99d4f@oracle.com> <8f9e9e58-d5bb-0a99-7f3e-937a33c9e2b8@zeus.net.au> <0ae93ef1-3416-9cc0-d6e3-2fe1ccb1df4f@oracle.com> <67886c79-aef1-bc41-0057-9acb943a0e0f@wu.ac.at> <7e0768d2-4afd-23be-8bb4-e66e6f1c3eed@redhat.com> Message-ID: <3f619862-9a30-d50a-1662-1665520e7326@wu.ac.at> On 03.08.2021 15:08, Rony G. Flatscher wrote: > On 03.08.2021 11:16, Andrew Haley wrote: >> On 8/2/21 7:39 PM, Rony G. Flatscher wrote: >> >>> If the Java ScriptEngine goes out of scope at the Java side its peer >>> ooRexx interpreter instance should be terminated, the same is true >>> for peer objects for either side (Java peer objects for Rexx >>> objects, i.e. Rexx objects being boxed in Java proxy objects, and >>> vice versa, ooRexx peer objects for Java objects such that one can >>> send messages to an ooRexx peer to the Java side where with >>> reflection the appropriate methods get invoked in the corresponding >>> Java object). >> Sure, but Java doesn't know when a Java ScriptEngine goes out of scope. >> >> Here's the scenario: we're running a generational garbage collector. >> Young-generation collections are keeping the heap well within our >> limits, so there's no need to do full collections. The ScriptEngine >> has been running for a while, so is in the old generation. There's no >> reason it will ever be collected. That's why some sort of scoped >> access, such as try with resources, is the right way to go if you >> really need cleanups to be done. > This approach depends on a try-with block, which is easy and straight forward if e.g. reading from a > resource like a file, processing a SLQ statement etc. But "longevity service objects" are hard, if > not impossible, to be put into a (single, central) try-with block. This is especially true for peer > usages (e.g. in ooRexx an object created by one Rexx interpreter instance can be deployed on another > Rexx interpreter instance, and if it is a peer object the peer Java object must stay alive as long > as the ooRexx object is referenced). > > From first, simple tests on Java 8 it seems however, that System.runFinalization() will invoke > finalize() on those Java objects that have no references at the time runFinalization() runs. So it > does not follow the general gc strategy you describe. Running System.gc() does not have that effect, > i.e. running finalize() of the very same Java objects without references at gc() time. So currently > PhantomReferences to these Java objects that have no references would not be put on the queue but at > some undefined later time, possibly never as you describe. > > The question then would be whether it was possible to have runFinalization() also look out for > PhantomReference'd Java objects without references and put them on the queue at that point in time. > This of course assumes that runFinalization() not only is able to identify unreferenced Java objects > with a finalize method, but also unreferenced Java objects for which a PhantomReference got created > for. [If so, runFinalization() may remain helpful even after finalize() got eventually removed.] Just for the record: the observed behavior (finalize() of all unreferenced objects runs at runFinalization() time, PhantomReferences are not put on the queue at that time) is the same for Java 6, 8, 11 and 16. ---rony From forax at univ-mlv.fr Wed Aug 4 14:41:04 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 4 Aug 2021 16:41:04 +0200 (CEST) Subject: Plans to remove -source & -target option 7 in javac? In-Reply-To: <2ab1479d-9b41-0f2c-5f9e-568a7a66f052@oracle.com> References: <2ab1479d-9b41-0f2c-5f9e-568a7a66f052@oracle.com> Message-ID: <1969768008.798595.1628088064640.JavaMail.zimbra@u-pem.fr> To complement what Joe said, this is the discussion where we have decided to remove -source/-target 6 in Java 12 https://mail.openjdk.java.net/pipermail/jdk-dev/2018-May/001190.html So as Kartik suggests, removing the support of -source/-target 7 for Java 18 seems the logical consequence. R?mi ----- Original Message ----- > From: "joe darcy" > To: "jdk-dev" > Sent: Mercredi 4 Ao?t 2021 16:09:58 > Subject: Re: Plans to remove -source & -target option 7 in javac? > Hello Kartik, > > Updating JEP 182: "Policy for Retiring javac -source and -target > Options" (http://openjdk.java.net/jeps/182) for the six-month release > process is a known item to be done. That updated policy would in turn > guide when -source/-target 7 and now also --release 7 would be dropped. > > Cheers, > > -Joe > > On 8/4/2021 4:26 AM, Kartik Ohri wrote: >> Hi all! >> >> JDK-8173605 has not been >> updated for some time. Hence, out of curiosity, I ask if there are >> currently any plans to remove the -source & -target 7 options in javac in >> JDK 18? >> >> Regards, > > Kartik From daniel.daugherty at oracle.com Wed Aug 4 15:28:14 2021 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Wed, 4 Aug 2021 11:28:14 -0400 Subject: CFV: New JDK Reviewer: Albert Mingkun Yang In-Reply-To: References: Message-ID: Vote: yes Dan On 8/4/21 6:33 AM, Thomas Schatzl wrote: > Hi all, > > ? I hereby nominate Albert Mingkun Yang (ayang[1]) to the role of JDK > Project Reviewer. > > Albert is currently a JDK committer, member of the Garbage Collection > team at Oracle for a few years now, and has, before joining Oracle, > been working on garbage collection with ZGC during his PhD (e.g. [2], > [3]). > > He has made substantial contributions [4] to the development of the > mostly G1 and ZGC, in particular just recently an algorithm to > dynamically adjust the number of concurrent threads for ZGC [5], and > has in total made 60 individual contributions to the JDK project. > > Only current JDK Project Reviewers [6] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > For Three-Vote Consensus voting instructions, see [7]. > > Votes are due by 12:00 UTC on 18th of August 2021. > > Thomas > > [1] https://openjdk.java.net/census#ayang > [2] https://dl.acm.org/doi/abs/10.1145/3381898.3397213 > [3] https://dl.acm.org/doi/abs/10.1145/3385412.3385977 > [4] > https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Albert+Yang%22&type=commits > [5] https://bugs.openjdk.java.net/browse/JDK-8268372 > [6] https://openjdk.java.net/census > [7] https://openjdk.java.net/projects/#reviewer-vote From calvin.cheung at oracle.com Wed Aug 4 15:46:57 2021 From: calvin.cheung at oracle.com (calvin.cheung at oracle.com) Date: Wed, 4 Aug 2021 08:46:57 -0700 Subject: CFV: New JDK Reviewer: Albert Mingkun Yang In-Reply-To: References: Message-ID: Vote: yes On 8/4/21 3:33 AM, Thomas Schatzl wrote: > Hi all, > > ? I hereby nominate Albert Mingkun Yang (ayang[1]) to the role of JDK > Project Reviewer. > > Albert is currently a JDK committer, member of the Garbage Collection > team at Oracle for a few years now, and has, before joining Oracle, > been working on garbage collection with ZGC during his PhD (e.g. [2], > [3]). > > He has made substantial contributions [4] to the development of the > mostly G1 and ZGC, in particular just recently an algorithm to > dynamically adjust the number of concurrent threads for ZGC [5], and > has in total made 60 individual contributions to the JDK project. > > Only current JDK Project Reviewers [6] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > For Three-Vote Consensus voting instructions, see [7]. > > Votes are due by 12:00 UTC on 18th of August 2021. > > Thomas > > [1] https://openjdk.java.net/census#ayang > [2] https://dl.acm.org/doi/abs/10.1145/3381898.3397213 > [3] https://dl.acm.org/doi/abs/10.1145/3385412.3385977 > [4] > https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Albert+Yang%22&type=commits > [5] https://bugs.openjdk.java.net/browse/JDK-8268372 > [6] https://openjdk.java.net/census > [7] https://openjdk.java.net/projects/#reviewer-vote From dalibor.topic at oracle.com Wed Aug 4 17:11:53 2021 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 4 Aug 2021 19:11:53 +0200 Subject: JEP 411, removal of finalizers, a path forward. In-Reply-To: References: <4257646b-6678-5419-13ae-5b470d4c510d@redhat.com> <000001d786e1$7885b0b0$69911210$@apache.org> <391deb02-68ba-4d67-7475-e13534dfd97d@redhat.com> <64671073-b67c-4a83-5949-7a97273349eb@zeus.net.au> Message-ID: Hi Peter, On 03.08.2021 02:28, Peter Firmstone wrote: > I have previously offered to donate code to OpenJDK, but I was unable to > get clarification on whether I could include AL2.0 licensed code from > other authors, as my code is not my sole works, two of whom have since > passed away (only one at the time). I'm sorry to hear that. Unfortunately, all parties that want to contribute a work to OpenJDK should have a respective agreement in place to be able to do so. cheers, dalibor topic -- Dalibor Topic Consulting Product Manager Phone: +494089091214 , Mobile: +491737185961 , Video: dalibor.topic at oracle.com Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRB 246209 Gesch?ftsf?hrer: Ralf Herrmann From mark.reinhold at oracle.com Wed Aug 4 17:14:10 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 04 Aug 2021 10:14:10 -0700 Subject: JEP 411, removal of finalizers, a path forward. In-Reply-To: <4287ede7-f145-7c87-fe23-baa22bd0347d@oracle.com> References: <4257646b-6678-5419-13ae-5b470d4c510d@redhat.com> <000001d786e1$7885b0b0$69911210$@apache.org> <391deb02-68ba-4d67-7475-e13534dfd97d@redhat.com> <64671073-b67c-4a83-5949-7a97273349eb@zeus.net.au> <4287ede7-f145-7c87-fe23-baa22bd0347d@oracle.com> Message-ID: <20210804101410.269382562@eggemoggin.niobe.net> 2021/8/3 9:40:58 -0700, sean.mullan at oracle.com: > On 8/2/21 8:28 PM, Peter Firmstone wrote: >> ... >> >> Having established that OpenJDK is not yet willing to compromise, I have >> been attempting to create an authorization layer using Agents, so that I >> can restore perimeter security following the removal of SM and support >> future versions of Java. It is my hope that either I will be >> successful in recreating an authorization layer, or that enough people >> come forward and OpenJDK decides there are enough affected developers to >> find a compromise that either makes migration practical, or less expensive. > > You may have some interesting ideas, but in my opinion you have not > presented them in a clear and easily digestible manner, and your long > emails are time consuming to read, repetitive and often diverge into > rants. (Keep in mind there are many people on the jdk-dev alias, and a > lot of them may not care about this topic). Agreed. Over a thousand people are subscribed to the jdk-dev list, which is meant for discussion of topics of the broadest interest. I suspect that many people would appreciate it if future discussions of this topic were confined to the security-dev list. > 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. A fine suggestion. - Mark From Rony.Flatscher at wu.ac.at Wed Aug 4 18:54:19 2021 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Wed, 4 Aug 2021 20:54:19 +0200 Subject: finalize() *much* better than PhantomReferences (Re: Ad removing finalize eventually (Re: JEP 411 Headaches: Instrumenting private methods in the JDK for authorization checkpoints. In-Reply-To: <3f619862-9a30-d50a-1662-1665520e7326@wu.ac.at> References: <19858490-648a-d539-2429-b1999f597658@zeus.net.au> <8d6f394d-f0a8-fa41-24ec-f8437af99d4f@oracle.com> <8f9e9e58-d5bb-0a99-7f3e-937a33c9e2b8@zeus.net.au> <0ae93ef1-3416-9cc0-d6e3-2fe1ccb1df4f@oracle.com> <67886c79-aef1-bc41-0057-9acb943a0e0f@wu.ac.at> <7e0768d2-4afd-23be-8bb4-e66e6f1c3eed@redhat.com> <3f619862-9a30-d50a-1662-1665520e7326@wu.ac.at> Message-ID: On 04.08.2021 16:35, Rony G. Flatscher wrote: > On 03.08.2021 15:08, Rony G. Flatscher wrote: >> On 03.08.2021 11:16, Andrew Haley wrote: >>> On 8/2/21 7:39 PM, Rony G. Flatscher wrote: >>> >>>> If the Java ScriptEngine goes out of scope at the Java side its peer >>>> ooRexx interpreter instance should be terminated, the same is true >>>> for peer objects for either side (Java peer objects for Rexx >>>> objects, i.e. Rexx objects being boxed in Java proxy objects, and >>>> vice versa, ooRexx peer objects for Java objects such that one can >>>> send messages to an ooRexx peer to the Java side where with >>>> reflection the appropriate methods get invoked in the corresponding >>>> Java object). >>> Sure, but Java doesn't know when a Java ScriptEngine goes out of scope. >>> >>> Here's the scenario: we're running a generational garbage collector. >>> Young-generation collections are keeping the heap well within our >>> limits, so there's no need to do full collections. The ScriptEngine >>> has been running for a while, so is in the old generation. There's no >>> reason it will ever be collected. That's why some sort of scoped >>> access, such as try with resources, is the right way to go if you >>> really need cleanups to be done. >> This approach depends on a try-with block, which is easy and straight forward if e.g. reading from a >> resource like a file, processing a SLQ statement etc. But "longevity service objects" are hard, if >> not impossible, to be put into a (single, central) try-with block. This is especially true for peer >> usages (e.g. in ooRexx an object created by one Rexx interpreter instance can be deployed on another >> Rexx interpreter instance, and if it is a peer object the peer Java object must stay alive as long >> as the ooRexx object is referenced). >> >> From first, simple tests on Java 8 it seems however, that System.runFinalization() will invoke >> finalize() on those Java objects that have no references at the time runFinalization() runs. So it >> does not follow the general gc strategy you describe. Running System.gc() does not have that effect, >> i.e. running finalize() of the very same Java objects without references at gc() time. So currently >> PhantomReferences to these Java objects that have no references would not be put on the queue but at >> some undefined later time, possibly never as you describe. >> >> The question then would be whether it was possible to have runFinalization() also look out for >> PhantomReference'd Java objects without references and put them on the queue at that point in time. >> This of course assumes that runFinalization() not only is able to identify unreferenced Java objects >> with a finalize method, but also unreferenced Java objects for which a PhantomReference got created >> for. [If so, runFinalization() may remain helpful even after finalize() got eventually removed.] > Just for the record: the observed behavior (finalize() of all unreferenced objects runs at > runFinalization() time, PhantomReferences are not put on the queue at that time) is the same for > Java 6, 8, 11 and 16. O.K. now having implemented PhantomReferences to replace the usage of finalize() in the bridge it turns out that finalize() gets invoked "magnitudes" of times (100 and more finazable objects in different gc runs within a total run of five seconds) more often than their PhantomReferences are being put on the reference queue (not a single one!) to allow to carry out the necessary finalizations! This is without employing runFinalization(), just the normal garbage collection that takes place in a running system. (These tests were run against unit tests of the ooRexx-Java bridge to make sure that the tests work the same as before the code changes.) --- Another test with JavaFX (the quite famous JavaFX address book example implemented in ooRexx) is even interactively demonstrative: there were about ten, twelve finalize() runs while operating it compared to not a single (!) reference being put on the reference queue in the same time frame! Observing this one would wonder whether PhantomReferences would work at all (the implementation works, it got tested separately). [To be able to compare the behavior I left finalize() in place but only output a debug message with a string-id while for the same objects PhantomReferences got created and any such reference removed from the reference queue would create a debug message there with the string-id as well and run the cleanup method, however this has never happened.] --- So seriously, please consider to have PhantomReferences being serviced by the gc like finalizable() objects, such that gc runs put PhantomReferences on the reference queue as early as possible. ---rony P.S.: For the time being I will probably be employing finalize() as long as the Object.finalize() method exists and switch over to PhantomReferences thereafter, hoping that by then the timings of PhantomReferences being put on the reference queue by gc will be close or comparable to the current timings a finalizable object gets its finalize() cleanup method invoked. From rkennke at redhat.com Wed Aug 4 19:13:19 2021 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 4 Aug 2021 21:13:19 +0200 Subject: finalize() *much* better than PhantomReferences (Re: Ad removing finalize eventually (Re: JEP 411 Headaches: Instrumenting private methods in the JDK for authorization checkpoints. In-Reply-To: References: <19858490-648a-d539-2429-b1999f597658@zeus.net.au> <8d6f394d-f0a8-fa41-24ec-f8437af99d4f@oracle.com> <8f9e9e58-d5bb-0a99-7f3e-937a33c9e2b8@zeus.net.au> <0ae93ef1-3416-9cc0-d6e3-2fe1ccb1df4f@oracle.com> <67886c79-aef1-bc41-0057-9acb943a0e0f@wu.ac.at> <7e0768d2-4afd-23be-8bb4-e66e6f1c3eed@redhat.com> <3f619862-9a30-d50a-1662-1665520e7326@wu.ac.at> Message-ID: > O.K. now having implemented PhantomReferences to replace the usage of finalize() in the bridge it > turns out that finalize() gets invoked "magnitudes" of times (100 and more finazable objects in > different gc runs within a total run of five seconds) more often than their PhantomReferences are > being put on the reference queue (not a single one!) to allow to carry out the necessary finalizations! I'd suggest that you verify if you've done it correctly. PhantomReferences and Finalizers are handled during the same pass during GC. If no PhantomRefs show up, then it's probably still reachable? A twist may be when the referent has a finalize() method, then it will not get enqueued until finalize() has been called (and object remains unreachable). finalize() is *not* much better than PhantomReference. Roman From kim.barrett at oracle.com Thu Aug 5 00:30:29 2021 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 5 Aug 2021 00:30:29 +0000 Subject: Ad removing finalize eventually (Re: JEP 411 Headaches: Instrumenting private methods in the JDK for authorization checkpoints. In-Reply-To: References: <19858490-648a-d539-2429-b1999f597658@zeus.net.au> <8d6f394d-f0a8-fa41-24ec-f8437af99d4f@oracle.com> <8f9e9e58-d5bb-0a99-7f3e-937a33c9e2b8@zeus.net.au> <0ae93ef1-3416-9cc0-d6e3-2fe1ccb1df4f@oracle.com> <67886c79-aef1-bc41-0057-9acb943a0e0f@wu.ac.at> <7e0768d2-4afd-23be-8bb4-e66e6f1c3eed@redhat.com> Message-ID: <0E80BD26-C094-4BD4-8780-AF117E88A7E5@oracle.com> > On Aug 3, 2021, at 9:08 AM, Rony G. Flatscher wrote: > From first, simple tests on Java 8 it seems however, that System.runFinalization() will invoke > finalize() on those Java objects that have no references at the time runFinalization() runs. So it > does not follow the general gc strategy you describe. Running System.gc() does not have that effect, > i.e. running finalize() of the very same Java objects without references at gc() time. So currently > PhantomReferences to these Java objects that have no references would not be put on the queue but at > some undefined later time, possibly never as you describe. > > The question then would be whether it was possible to have runFinalization() also look out for > PhantomReference'd Java objects without references and put them on the queue at that point in time. > This of course assumes that runFinalization() not only is able to identify unreferenced Java objects > with a finalize method, but also unreferenced Java objects for which a PhantomReference got created > for. [If so, runFinalization() may remain helpful even after finalize() got eventually removed.] runFinalization spawns a thread that loops on getting the next enqueued finalization and running it, exiting when there aren't any more in the queue. There's a known race condition in this - see JDK-6306116. The GC adds j.l.r.References and objects for finalization to the pending list, and the in-Java reference processing thread takes those and adds them to their associated queues. In the sequence "System.gc(); runFinalization();", the new finalization thread can start, check the finalization queue and find it still empty, and immediately exit because the reference processing thread hasn't gotten around to transferring anything to that queue from the pending list. runFinalization doesn't recognize unreferenced objects at all. It just deals with what the GC and the reference processing thread conspire to give it (in cooperation with the default finalization processing thread). That's been true "forever" (JDK-6306116 was filed against JDK 6). That is, runFinalization just adds a temporary thread to run in parallel with the existing built-in finalization processing thread. And the way this all works is no different from how the specified j.l.r.References are added to their respective queues. So I think there's something wrong with that test or the interpretation of its behavior. From kim.barrett at oracle.com Thu Aug 5 00:45:51 2021 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 5 Aug 2021 00:45:51 +0000 Subject: Fate of {System|Runtime}.runFinalization (Re: Ad removing finalize eventually In-Reply-To: References: <19858490-648a-d539-2429-b1999f597658@zeus.net.au> <8d6f394d-f0a8-fa41-24ec-f8437af99d4f@oracle.com> <8f9e9e58-d5bb-0a99-7f3e-937a33c9e2b8@zeus.net.au> <0ae93ef1-3416-9cc0-d6e3-2fe1ccb1df4f@oracle.com> <67886c79-aef1-bc41-0057-9acb943a0e0f@wu.ac.at> <3b555f81-2cb5-73dd-90d4-e37d9549cb56@wu.ac.at> <39c357e2-dc51-32ae-71fa-c8aebde1aeb5@oracle.com> <19cc0c9c-1b93-8af9-28db-a07f2b9c71e5@wu.ac.at> Message-ID: > On Aug 3, 2021, at 12:09 PM, Hans Boehm wrote: > > On Mon, Aug 2, 2021 at 11:32 PM Alan Bateman > wrote: >> > ... >> >> When using cleaners or references then the typical response to resource >> exhaustion will be System.gc with back-off/retry in a loop until the >> resource can be allocated. Privileged ops in the JDK can do a bit better >> by polling the pending reference list to see if there is still work to >> do. So all a bit primitive. > > I agree that this is a bit primitive. Perhaps more importantly, > it seems like a regression from finalization, where > I can be reasonably sure that System.gc(); System.runFinalization(); > (with no locks held) will finalize all objects that can be finalized. > (This ignores the case in which finalizers generate more Java garbage, > but in most cases that's not a very significant effect.) That privileged operation is Reference.waitForReferenceProcessing. (If there are references that haven't been enqueued, wait for some progress on enqueuing and return true, else return false.) I don't think there's a good reason for it being privileged or private. I added it as part of JDK-8156500. I made it private and accessible as a privileged operation because at the time only java.nio.Bits needed it, and was previously using a privileged access to Reference.tryHandlePendingReference (which was rightly privileged, and removed by that change). So I had a model to follow (on occasion I pretend to be a Java programmer), and I was too lazy to go through the process of making waitForReferenceProcessing or some similar functionality public. Later I noticed that function might be useful for runFinalization, and maybe other things as well, such as being discussed here. See, for example, JDK-6306116. Of course, if runFinalization were the only use-case, the wait function still wouldn't need to be made public. And there's a different problem, which is that System.gc may be disabled entirely via -XX:+DisableExplicitGC. > But I'm also not at all sure this is worth addressing now. If we want to > move away > from finalizers, I think it is important to make things easier in the new > world > with Cleaners. Currently there seem to be at least two things that make it > significantly > harder: > > 1) The lack of a default user-visible Cleaner seems to effectively tie up > an additional > thread per Cleaner-using-library. AFAICT, the decreased interference > between Cleaners makes > that desirable in some contexts, but the additional threads make it > untenable in others. > > 2) The lack of a clean runFinalization alternative. I think this is > actually an opportunity > to improve things and motivate people to switch away from finalization. But > currently > it pushes in the wrong direction. It was intentional that there's no "default" Cleaner. That would have all the same problems as finalization wrto a cleanup that stalls and blocks everything behind it. As for the additional threads, an application is free to provide a widely known Cleaner, and libraries that use the Cleaner API could provide a mechanism for being told which Cleaner to use. runFinalization provides a workaround for the stalled cleanup situation; something similar could be added to Cleaner. But PhantomReference-based cleanups are, I think, less prone to such problems because they aren't using operations on the original object but are instead dealing just the the dedicated PRef object. Exposing waitForReferenceProcessing or something similar might help. From kim.barrett at oracle.com Thu Aug 5 00:58:51 2021 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 5 Aug 2021 00:58:51 +0000 Subject: finalize() *much* better than PhantomReferences (Re: Ad removing finalize eventually (Re: JEP 411 Headaches: Instrumenting private methods in the JDK for authorization checkpoints. In-Reply-To: References: <19858490-648a-d539-2429-b1999f597658@zeus.net.au> <8d6f394d-f0a8-fa41-24ec-f8437af99d4f@oracle.com> <8f9e9e58-d5bb-0a99-7f3e-937a33c9e2b8@zeus.net.au> <0ae93ef1-3416-9cc0-d6e3-2fe1ccb1df4f@oracle.com> <67886c79-aef1-bc41-0057-9acb943a0e0f@wu.ac.at> <7e0768d2-4afd-23be-8bb4-e66e6f1c3eed@redhat.com> <3f619862-9a30-d50a-1662-1665520e7326@wu.ac.at> Message-ID: > On Aug 4, 2021, at 2:54 PM, Rony G. Flatscher wrote: > > On 04.08.2021 16:35, Rony G. Flatscher wrote: >> Just for the record: the observed behavior (finalize() of all unreferenced objects runs at >> runFinalization() time, PhantomReferences are not put on the queue at that time) is the same for >> Java 6, 8, 11 and 16. > > O.K. now having implemented PhantomReferences to replace the usage of finalize() in the bridge it > turns out that finalize() gets invoked "magnitudes" of times (100 and more finazable objects in > different gc runs within a total run of five seconds) more often than their PhantomReferences are > being put on the reference queue (not a single one!) to allow to carry out the necessary finalizations! > > This is without employing runFinalization(), just the normal garbage collection that takes place in > a running system. (These tests were run against unit tests of the ooRexx-Java bridge to make sure > that the tests work the same as before the code changes.) > > --- > > Another test with JavaFX (the quite famous JavaFX address book example implemented in ooRexx) is > even interactively demonstrative: there were about ten, twelve finalize() runs while operating it > compared to not a single (!) reference being put on the reference queue in the same time frame! > Observing this one would wonder whether PhantomReferences would work at all (the implementation > works, it got tested separately). > > [To be able to compare the behavior I left finalize() in place but only output a debug message with > a string-id while for the same objects PhantomReferences got created and any such reference removed > from the reference queue would create a debug message there with the string-id as well and run the > cleanup method, however this has never happened.] > > --- > > So seriously, please consider to have PhantomReferences being serviced by the gc like finalizable() > objects, such that gc runs put PhantomReferences on the reference queue as early as possible. Finalization and PhantomReferences are implemented *identically* as far as detection and enqueuing, other than the criteria the GC uses for detection. It's almost all shared code, and that's been true for a long time (possibly forever, but I don't have easy access to really old versions of the code). So I think there is a bug in the testing. My guess would be that the referents of the PhantomReferences aren?t actually phantom reachable. Not having any knowledge of the code involved, I can?t even speculate on why that might be. But I have no other explanation to offer. From hboehm at google.com Thu Aug 5 01:11:54 2021 From: hboehm at google.com (Hans Boehm) Date: Wed, 4 Aug 2021 18:11:54 -0700 Subject: finalize() *much* better than PhantomReferences (Re: Ad removing finalize eventually (Re: JEP 411 Headaches: Instrumenting private methods in the JDK for authorization checkpoints. In-Reply-To: References: <19858490-648a-d539-2429-b1999f597658@zeus.net.au> <8d6f394d-f0a8-fa41-24ec-f8437af99d4f@oracle.com> <8f9e9e58-d5bb-0a99-7f3e-937a33c9e2b8@zeus.net.au> <0ae93ef1-3416-9cc0-d6e3-2fe1ccb1df4f@oracle.com> <67886c79-aef1-bc41-0057-9acb943a0e0f@wu.ac.at> <7e0768d2-4afd-23be-8bb4-e66e6f1c3eed@redhat.com> <3f619862-9a30-d50a-1662-1665520e7326@wu.ac.at> Message-ID: One complication with bare PhantomReferences (as opposed to e.g. Cleaners) is that you need to make sure that the Reference itself is kept reachable, by putting it in some reachable data structure. As the spec says: "If a registered reference becomes unreachable itself, then it will never be enqueued." Normally the ReferenceQueue processing code will need to remove it from that data structure. There's typically a fair amount of boilerplate involved in correct use. I think this can be unexpected for users. Could that be causing the problem here? Hans On Wed, Aug 4, 2021 at 5:59 PM Kim Barrett wrote: > > On Aug 4, 2021, at 2:54 PM, Rony G. Flatscher > wrote: > > > > On 04.08.2021 16:35, Rony G. Flatscher wrote: > >> Just for the record: the observed behavior (finalize() of all > unreferenced objects runs at > >> runFinalization() time, PhantomReferences are not put on the queue at > that time) is the same for > >> Java 6, 8, 11 and 16. > > > > O.K. now having implemented PhantomReferences to replace the usage of > finalize() in the bridge it > > turns out that finalize() gets invoked "magnitudes" of times (100 and > more finazable objects in > > different gc runs within a total run of five seconds) more often than > their PhantomReferences are > > being put on the reference queue (not a single one!) to allow to carry > out the necessary finalizations! > > > > This is without employing runFinalization(), just the normal garbage > collection that takes place in > > a running system. (These tests were run against unit tests of the > ooRexx-Java bridge to make sure > > that the tests work the same as before the code changes.) > > > > --- > > > > Another test with JavaFX (the quite famous JavaFX address book example > implemented in ooRexx) is > > even interactively demonstrative: there were about ten, twelve > finalize() runs while operating it > > compared to not a single (!) reference being put on the reference queue > in the same time frame! > > Observing this one would wonder whether PhantomReferences would work at > all (the implementation > > works, it got tested separately). > > > > [To be able to compare the behavior I left finalize() in place but only > output a debug message with > > a string-id while for the same objects PhantomReferences got created and > any such reference removed > > from the reference queue would create a debug message there with the > string-id as well and run the > > cleanup method, however this has never happened.] > > > > --- > > > > So seriously, please consider to have PhantomReferences being serviced > by the gc like finalizable() > > objects, such that gc runs put PhantomReferences on the reference queue > as early as possible. > > Finalization and PhantomReferences are implemented *identically* as far as > detection and enqueuing, other than the criteria the GC uses for detection. > It's almost all shared code, and that's been true for a long time (possibly > forever, but I don't have easy access to really old versions of the code). > So I think there is a bug in the testing. My guess would be that the > referents of the PhantomReferences aren?t actually phantom reachable. Not > having any knowledge of the code involved, I can?t even speculate on why > that might be. But I have no other explanation to offer. > > > From kim.barrett at oracle.com Thu Aug 5 01:21:37 2021 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 5 Aug 2021 01:21:37 +0000 Subject: finalize() *much* better than PhantomReferences (Re: Ad removing finalize eventually (Re: JEP 411 Headaches: Instrumenting private methods in the JDK for authorization checkpoints. In-Reply-To: References: <19858490-648a-d539-2429-b1999f597658@zeus.net.au> <8d6f394d-f0a8-fa41-24ec-f8437af99d4f@oracle.com> <8f9e9e58-d5bb-0a99-7f3e-937a33c9e2b8@zeus.net.au> <0ae93ef1-3416-9cc0-d6e3-2fe1ccb1df4f@oracle.com> <67886c79-aef1-bc41-0057-9acb943a0e0f@wu.ac.at> <7e0768d2-4afd-23be-8bb4-e66e6f1c3eed@redhat.com> <3f619862-9a30-d50a-1662-1665520e7326@wu.ac.at> Message-ID: > On Aug 4, 2021, at 9:11 PM, Hans Boehm wrote: > > One complication with bare PhantomReferences (as opposed to e.g. Cleaners) is that you need to make sure that the Reference itself is kept reachable, by putting it in some reachable data structure. As the spec says: "If a registered reference becomes unreachable itself, then it will never be enqueued." Normally the ReferenceQueue processing code will need to remove it from that data structure. There's typically a fair amount of boilerplate involved in correct use. > > I think this can be unexpected for users. Could that be causing the problem here? That sounds like a good guess. From christoph.langer at sap.com Thu Aug 5 06:47:17 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 5 Aug 2021 06:47:17 +0000 Subject: CFV: New JDK Reviewer: Albert Mingkun Yang In-Reply-To: References: Message-ID: Vote: yes /Christoph > -----Original Message----- > From: jdk-dev On Behalf Of Thomas > Schatzl > Sent: Mittwoch, 4. August 2021 12:34 > To: jdk-dev at openjdk.java.net > Subject: CFV: New JDK Reviewer: Albert Mingkun Yang > > Hi all, > > I hereby nominate Albert Mingkun Yang (ayang[1]) to the role of JDK > Project Reviewer. > > Albert is currently a JDK committer, member of the Garbage Collection > team at Oracle for a few years now, and has, before joining Oracle, been > working on garbage collection with ZGC during his PhD (e.g. [2], [3]). > > He has made substantial contributions [4] to the development of the > mostly G1 and ZGC, in particular just recently an algorithm to > dynamically adjust the number of concurrent threads for ZGC [5], and has > in total made 60 individual contributions to the JDK project. > > Only current JDK Project Reviewers [6] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > For Three-Vote Consensus voting instructions, see [7]. > > Votes are due by 12:00 UTC on 18th of August 2021. > > Thomas > > [1] https://openjdk.java.net/census#ayang > [2] https://dl.acm.org/doi/abs/10.1145/3381898.3397213 > [3] https://dl.acm.org/doi/abs/10.1145/3385412.3385977 > [4] > https://github.com/openjdk/jdk/search?p=1&q=author- > name%3A%22Albert+Yang%22&type=commits > [5] https://bugs.openjdk.java.net/browse/JDK-8268372 > [6] https://openjdk.java.net/census > [7] https://openjdk.java.net/projects/#reviewer-vote From richard.reingruber at sap.com Thu Aug 5 07:28:44 2021 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Thu, 5 Aug 2021 07:28:44 +0000 Subject: CFV: New JDK Reviewer: Albert Mingkun Yang In-Reply-To: References: Message-ID: Vote: yes Richard. -----Original Message----- From: jdk-dev On Behalf Of Thomas Schatzl Sent: Mittwoch, 4. August 2021 12:34 To: jdk-dev at openjdk.java.net Subject: CFV: New JDK Reviewer: Albert Mingkun Yang Hi all, I hereby nominate Albert Mingkun Yang (ayang[1]) to the role of JDK Project Reviewer. Albert is currently a JDK committer, member of the Garbage Collection team at Oracle for a few years now, and has, before joining Oracle, been working on garbage collection with ZGC during his PhD (e.g. [2], [3]). He has made substantial contributions [4] to the development of the mostly G1 and ZGC, in particular just recently an algorithm to dynamically adjust the number of concurrent threads for ZGC [5], and has in total made 60 individual contributions to the JDK project. Only current JDK Project Reviewers [6] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [7]. Votes are due by 12:00 UTC on 18th of August 2021. Thomas [1] https://openjdk.java.net/census#ayang [2] https://dl.acm.org/doi/abs/10.1145/3381898.3397213 [3] https://dl.acm.org/doi/abs/10.1145/3385412.3385977 [4] https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Albert+Yang%22&type=commits [5] https://bugs.openjdk.java.net/browse/JDK-8268372 [6] https://openjdk.java.net/census [7] https://openjdk.java.net/projects/#reviewer-vote From lihuaming3 at huawei.com Thu Aug 5 12:41:27 2021 From: lihuaming3 at huawei.com (lihuaming (A)) Date: Thu, 5 Aug 2021 12:41:27 +0000 Subject: New JDK Reviewer: Albert Mingkun Yang Message-ID: <00febd2ef3844c938fd3e4d8962b57b0@huawei.com> Vote: yes -Hamlin From Rony.Flatscher at wu.ac.at Thu Aug 5 15:45:37 2021 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Thu, 5 Aug 2021 17:45:37 +0200 Subject: finalize() *not* much better than PhantomReferences (Re: Ad removing finalize eventually (Re: JEP 411 Headaches: Instrumenting private methods in the JDK for authorization checkpoints. In-Reply-To: References: <19858490-648a-d539-2429-b1999f597658@zeus.net.au> <8d6f394d-f0a8-fa41-24ec-f8437af99d4f@oracle.com> <8f9e9e58-d5bb-0a99-7f3e-937a33c9e2b8@zeus.net.au> <0ae93ef1-3416-9cc0-d6e3-2fe1ccb1df4f@oracle.com> <67886c79-aef1-bc41-0057-9acb943a0e0f@wu.ac.at> <7e0768d2-4afd-23be-8bb4-e66e6f1c3eed@redhat.com> <3f619862-9a30-d50a-1662-1665520e7326@wu.ac.at> Message-ID: <4f19ba12-3d1c-bec2-17f6-a2d74d0e9be8@wu.ac.at> Dear Hans, dear Kim, On 05.08.2021 03:21, Kim Barrett wrote: >> On Aug 4, 2021, at 9:11 PM, Hans Boehm wrote: >> >> One complication with bare PhantomReferences (as opposed to e.g. Cleaners) is that you need to make sure that the Reference itself is kept reachable, by putting it in some reachable data structure. As the spec says: "If a registered reference becomes unreachable itself, then it will never be enqueued." Normally the ReferenceQueue processing code will need to remove it from that data structure. There's typically a fair amount of boilerplate involved in correct use. >> >> I think this can be unexpected for users. Could that be causing the problem here? > That sounds like a good guess. thank you very much for this information! Indeed that was the reason. Adding the PhantomReferences to an IdentityHashMap at creation time causes them to be placed on the reference queue in a comparable timely manner as compared to the usage of the finalize() method! (And removing the reference from the IdentityHashMap once it got removed from the reference queue.) Going back to the documentation of PhantomReference (Java 6 and 11) this is something I would not have concluded (but then, I am not a native English speaker). It might help to give a nutshell example in the documentation that demonstrates how to properly use this important feature or otherwise stress this important "detail" in the documentation text with a brief sentence! Sorry therefore to have claimed a false information on the subject line, which I try to make good by changing it to what the right information is with this message! Again, thank you very much for pointing this out, you have saved me a lot of time! ---rony From mark.reinhold at oracle.com Thu Aug 5 17:59:02 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 5 Aug 2021 10:59:02 -0700 (PDT) Subject: New candidate JEP: 416: Reimplement Core Reflection with Method Handles Message-ID: <20210805175902.A4E823EE0CD@eggemoggin.niobe.net> https://openjdk.java.net/jeps/416 Summary: Reimplement java.lang.reflect.Method, Constructor, and Field on top of java.lang.invoke method handles. Making method handles the underlying mechanism for reflection will reduce the maintenance and development cost of both the java.lang.reflect and java.lang.invoke APIs. - Mark From mark.reinhold at oracle.com Thu Aug 5 20:18:33 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 05 Aug 2021 13:18:33 -0700 Subject: JDK 17 is now in the Release Candidate Phase Message-ID: <20210805131833.314205853@eggemoggin.niobe.net> Per the JDK 17 schedule [1], we are now in the Release Candidate phase. The stabilization repository [2] is open for P1 bug fixes per the JDK Release Process (JEP 3) [3]. All changes require approval via the Fix-Request Process [4]. If you?re responsible for any of the bugs on the RC candidate-bug list [5] then please see JEP 3 for guidance on how to handle them. We?ll tag the first Release Candidate build shortly. - Mark [1] https://openjdk.java.net/projects/jdk/17/#Schedule [2] https://github.com/openjdk/jdk17 [3] https://openjdk.java.net/jeps/3 [4] https://openjdk.java.net/jeps/3#Fix-Request-Process [5] https://j.mp/jdk-rc From stefan.karlsson at oracle.com Fri Aug 6 08:08:50 2021 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 6 Aug 2021 10:08:50 +0200 Subject: CFV: New JDK Reviewer: Albert Mingkun Yang In-Reply-To: References: Message-ID: <0372c00e-86c2-d74e-f16a-e13dc1f3cb6f@oracle.com> Vote: yes StefanK On 2021-08-04 12:33, Thomas Schatzl wrote: > Hi all, > > ? I hereby nominate Albert Mingkun Yang (ayang[1]) to the role of JDK > Project Reviewer. > > Albert is currently a JDK committer, member of the Garbage Collection > team at Oracle for a few years now, and has, before joining Oracle, > been working on garbage collection with ZGC during his PhD (e.g. [2], > [3]). > > He has made substantial contributions [4] to the development of the > mostly G1 and ZGC, in particular just recently an algorithm to > dynamically adjust the number of concurrent threads for ZGC [5], and > has in total made 60 individual contributions to the JDK project. > > Only current JDK Project Reviewers [6] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > For Three-Vote Consensus voting instructions, see [7]. > > Votes are due by 12:00 UTC on 18th of August 2021. > > Thomas > > [1] https://openjdk.java.net/census#ayang > [2] https://dl.acm.org/doi/abs/10.1145/3381898.3397213 > [3] https://dl.acm.org/doi/abs/10.1145/3385412.3385977 > [4] > https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Albert+Yang%22&type=commits > [5] https://bugs.openjdk.java.net/browse/JDK-8268372 > [6] https://openjdk.java.net/census > [7] https://openjdk.java.net/projects/#reviewer-vote From markus.gronlund at oracle.com Fri Aug 6 11:15:33 2021 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Fri, 6 Aug 2021 11:15:33 +0000 Subject: CFV: New JDK Committer: Denghui Dong Message-ID: I hereby nominate Denghui Dong (ddong) [0] to JDK Committer. Denghui is working in the Alibaba JVM Team and is a Committer in the JDK 8 updates project. He has made over a dozen contributions to the JDK project [3]. Votes are due by 14h00 CET on Friday, the 20th of August, 2021. Only current JDK Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Thank you Markus [0] https://openjdk.java.net/census#ddong [1] https://openjdk.java.net/census#jdk [2] http://openjdk.java.net/projects/#committer-vote [3] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3AD-D-H+is%3Aclosed [3 inlined, including co-authored PRs] 8261441: JFR: Filename expansion 8271726: JFR: should use equal() to check event fields in tests 8268298: jdk/jfr/api/consumer/log/TestVerbosity.java fails: unexpected log message 8269225: JFR.stop misses the written info when the filename is only specified by JFR.start 8268857: Merge VM_PrintJNI and VM_PrintThreads and remove the unused field 'is_deadlock' of DeadlockCycle 8268780: Use 'print_cr' instead of 'print' for the message 'eliminated ' 8267800: Remove the '_dirty' set in BCEscapeAnalyzer 8265129: Add intrinsic support for JVM.getClassId 8266642: improve ResolvedMethodTable hash function 8264633: Add missing logging to PlatformRecording#stop 8259956: jdk.jfr.internal.ChunkInputStream#available should return the sum of remaining available bytes 8259808: Add JFR event to detect GC locker stall 8242792: interval < flushInterval is always false in jdk.jfr.internal.RequestEngine#setFlushInterval 8240360: NativeLibraryEvent has wrong library name on Linux 8242844: JFR: Clean up typos and log format 8242485: Null _file checking in fileStream::flush() 8238665: Add JFR event for direct memory statistics 8237499: JFR: Include stack trace in the ThreadStart event 8234060: Potential memory reordering problem in JfrBuffer flush mechanism (co-author with Markus) 8260589: Crash in JfrTraceIdLoadBarrier::load(_jclass*) (co-author with Markus) From markus.gronlund at oracle.com Fri Aug 6 11:18:33 2021 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Fri, 6 Aug 2021 11:18:33 +0000 Subject: CFV: New JDK Reviewer: Albert Mingkun Yang In-Reply-To: References: Message-ID: Vote: yes Markus -----Original Message----- From: jdk-dev On Behalf Of Thomas Schatzl Sent: den 4 augusti 2021 12:34 To: jdk-dev at openjdk.java.net Subject: CFV: New JDK Reviewer: Albert Mingkun Yang Hi all, I hereby nominate Albert Mingkun Yang (ayang[1]) to the role of JDK Project Reviewer. Albert is currently a JDK committer, member of the Garbage Collection team at Oracle for a few years now, and has, before joining Oracle, been working on garbage collection with ZGC during his PhD (e.g. [2], [3]). He has made substantial contributions [4] to the development of the mostly G1 and ZGC, in particular just recently an algorithm to dynamically adjust the number of concurrent threads for ZGC [5], and has in total made 60 individual contributions to the JDK project. Only current JDK Project Reviewers [6] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [7]. Votes are due by 12:00 UTC on 18th of August 2021. Thomas [1] https://openjdk.java.net/census#ayang [2] https://dl.acm.org/doi/abs/10.1145/3381898.3397213 [3] https://dl.acm.org/doi/abs/10.1145/3385412.3385977 [4] https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Albert+Yang%22&type=commits [5] https://bugs.openjdk.java.net/browse/JDK-8268372 [6] https://openjdk.java.net/census [7] https://openjdk.java.net/projects/#reviewer-vote From jiefu at tencent.com Fri Aug 6 11:22:27 2021 From: jiefu at tencent.com (=?utf-8?B?amllZnUo5YKF5p2wKQ==?=) Date: Fri, 6 Aug 2021 11:22:27 +0000 Subject: [Internet]CFV: New JDK Committer: Denghui Dong Message-ID: <867A7757-56E6-4D85-8C9F-CFE5D8BD17BB@tencent.com> Vote: yes. Best regards, Jie ?On 2021/8/6, 7:16 PM, "jdk-dev on behalf of Markus Gronlund" wrote: I hereby nominate Denghui Dong (ddong) [0] to JDK Committer. Denghui is working in the Alibaba JVM Team and is a Committer in the JDK 8 updates project. He has made over a dozen contributions to the JDK project [3]. Votes are due by 14h00 CET on Friday, the 20th of August, 2021. Only current JDK Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Thank you Markus [0] https://openjdk.java.net/census#ddong [1] https://openjdk.java.net/census#jdk [2] http://openjdk.java.net/projects/#committer-vote [3] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3AD-D-H+is%3Aclosed [3 inlined, including co-authored PRs] 8261441: JFR: Filename expansion 8271726: JFR: should use equal() to check event fields in tests 8268298: jdk/jfr/api/consumer/log/TestVerbosity.java fails: unexpected log message 8269225: JFR.stop misses the written info when the filename is only specified by JFR.start 8268857: Merge VM_PrintJNI and VM_PrintThreads and remove the unused field 'is_deadlock' of DeadlockCycle 8268780: Use 'print_cr' instead of 'print' for the message 'eliminated ' 8267800: Remove the '_dirty' set in BCEscapeAnalyzer 8265129: Add intrinsic support for JVM.getClassId 8266642: improve ResolvedMethodTable hash function 8264633: Add missing logging to PlatformRecording#stop 8259956: jdk.jfr.internal.ChunkInputStream#available should return the sum of remaining available bytes 8259808: Add JFR event to detect GC locker stall 8242792: interval < flushInterval is always false in jdk.jfr.internal.RequestEngine#setFlushInterval 8240360: NativeLibraryEvent has wrong library name on Linux 8242844: JFR: Clean up typos and log format 8242485: Null _file checking in fileStream::flush() 8238665: Add JFR event for direct memory statistics 8237499: JFR: Include stack trace in the ThreadStart event 8234060: Potential memory reordering problem in JfrBuffer flush mechanism (co-author with Markus) 8260589: Crash in JfrTraceIdLoadBarrier::load(_jclass*) (co-author with Markus) From harold.seigel at oracle.com Fri Aug 6 12:08:52 2021 From: harold.seigel at oracle.com (Harold Seigel) Date: Fri, 6 Aug 2021 08:08:52 -0400 Subject: CFV: New JDK Committer: Denghui Dong In-Reply-To: References: Message-ID: <122fa23f-3446-809a-8199-4aa162b9041e@oracle.com> Vote: Yes Harold On 8/6/2021 7:15 AM, Markus Gronlund wrote: > I hereby nominate Denghui Dong (ddong) [0] to JDK Committer. > > Denghui is working in the Alibaba JVM Team and is a Committer in the JDK 8 updates project. > > He has made over a dozen contributions to the JDK project [3]. > > Votes are due by 14h00 CET on Friday, the 20th of August, 2021. > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thank you > Markus > > [0] https://openjdk.java.net/census#ddong > [1] https://openjdk.java.net/census#jdk > [2] http://openjdk.java.net/projects/#committer-vote > [3] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3AD-D-H+is%3Aclosed > [3 inlined, including co-authored PRs] > 8261441: JFR: Filename expansion > 8271726: JFR: should use equal() to check event fields in tests > 8268298: jdk/jfr/api/consumer/log/TestVerbosity.java fails: unexpected log message > 8269225: JFR.stop misses the written info when the filename is only specified by JFR.start > 8268857: Merge VM_PrintJNI and VM_PrintThreads and remove the unused field 'is_deadlock' of DeadlockCycle > 8268780: Use 'print_cr' instead of 'print' for the message 'eliminated ' > 8267800: Remove the '_dirty' set in BCEscapeAnalyzer > 8265129: Add intrinsic support for JVM.getClassId > 8266642: improve ResolvedMethodTable hash function > 8264633: Add missing logging to PlatformRecording#stop > 8259956: jdk.jfr.internal.ChunkInputStream#available should return the sum of remaining available bytes > 8259808: Add JFR event to detect GC locker stall > 8242792: interval < flushInterval is always false in jdk.jfr.internal.RequestEngine#setFlushInterval > 8240360: NativeLibraryEvent has wrong library name on Linux > 8242844: JFR: Clean up typos and log format > 8242485: Null _file checking in fileStream::flush() > 8238665: Add JFR event for direct memory statistics > 8237499: JFR: Include stack trace in the ThreadStart event > 8234060: Potential memory reordering problem in JfrBuffer flush mechanism (co-author with Markus) > 8260589: Crash in JfrTraceIdLoadBarrier::load(_jclass*) (co-author with Markus) From sgehwolf at redhat.com Fri Aug 6 12:21:10 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 06 Aug 2021 14:21:10 +0200 Subject: CFV: New JDK Committer: Denghui Dong In-Reply-To: References: Message-ID: <319783169fbf24e9a72850a6d9472aa653c39958.camel@redhat.com> Vote: yes. On Fri, 2021-08-06 at 11:15 +0000, Markus Gronlund wrote: > I hereby nominate Denghui Dong (ddong) [0] to JDK Committer. > > Denghui is working in the Alibaba JVM Team and is a Committer in the > JDK 8 updates project. > > He has made over a dozen contributions to the JDK project [3]. > > Votes are due by 14h00 CET on Friday, the 20th of August, 2021. > > Only current JDK Committers [1] are eligible to vote on this > nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thank you > Markus > > [0] https://openjdk.java.net/census#ddong > [1] https://openjdk.java.net/census#jdk? > [2] http://openjdk.java.net/projects/#committer-vote? > [3] > https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3AD-D-H+is%3Aclosed > [3? inlined, including co-authored PRs] > 8261441: JFR: Filename expansion > 8271726: JFR: should use equal() to check event fields in tests > 8268298: jdk/jfr/api/consumer/log/TestVerbosity.java fails: > unexpected log message > 8269225: JFR.stop misses the written info when the filename is only > specified by JFR.start > 8268857: Merge VM_PrintJNI and VM_PrintThreads and remove the unused > field 'is_deadlock' of DeadlockCycle > 8268780: Use 'print_cr' instead of 'print' for the message > 'eliminated ' > 8267800: Remove the '_dirty' set in BCEscapeAnalyzer > 8265129: Add intrinsic support for JVM.getClassId > 8266642: improve ResolvedMethodTable hash function > 8264633: Add missing logging to PlatformRecording#stop > 8259956: jdk.jfr.internal.ChunkInputStream#available should return > the sum of remaining available bytes > 8259808: Add JFR event to detect GC locker stall > 8242792: interval < flushInterval is always false in > jdk.jfr.internal.RequestEngine#setFlushInterval > 8240360: NativeLibraryEvent has wrong library name on Linux > 8242844: JFR: Clean up typos and log format > 8242485: Null _file checking in fileStream::flush() > 8238665: Add JFR event for direct memory statistics > 8237499: JFR: Include stack trace in the ThreadStart event > 8234060: Potential memory reordering problem in JfrBuffer flush > mechanism (co-author with Markus) > 8260589: Crash in JfrTraceIdLoadBarrier::load(_jclass*) (co-author > with Markus) > From neugens at redhat.com Fri Aug 6 13:10:21 2021 From: neugens at redhat.com (Mario Torre) Date: Fri, 6 Aug 2021 15:10:21 +0200 Subject: CFV: New JDK Committer: Denghui Dong In-Reply-To: References: Message-ID: Vote: Yes, Cheers, Mario On Fri, Aug 6, 2021 at 1:16 PM Markus Gronlund wrote: > > I hereby nominate Denghui Dong (ddong) [0] to JDK Committer. > > Denghui is working in the Alibaba JVM Team and is a Committer in the JDK 8 updates project. > > He has made over a dozen contributions to the JDK project [3]. > > Votes are due by 14h00 CET on Friday, the 20th of August, 2021. > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thank you > Markus > > [0] https://openjdk.java.net/census#ddong > [1] https://openjdk.java.net/census#jdk > [2] http://openjdk.java.net/projects/#committer-vote > [3] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3AD-D-H+is%3Aclosed > [3 inlined, including co-authored PRs] > 8261441: JFR: Filename expansion > 8271726: JFR: should use equal() to check event fields in tests > 8268298: jdk/jfr/api/consumer/log/TestVerbosity.java fails: unexpected log message > 8269225: JFR.stop misses the written info when the filename is only specified by JFR.start > 8268857: Merge VM_PrintJNI and VM_PrintThreads and remove the unused field 'is_deadlock' of DeadlockCycle > 8268780: Use 'print_cr' instead of 'print' for the message 'eliminated ' > 8267800: Remove the '_dirty' set in BCEscapeAnalyzer > 8265129: Add intrinsic support for JVM.getClassId > 8266642: improve ResolvedMethodTable hash function > 8264633: Add missing logging to PlatformRecording#stop > 8259956: jdk.jfr.internal.ChunkInputStream#available should return the sum of remaining available bytes > 8259808: Add JFR event to detect GC locker stall > 8242792: interval < flushInterval is always false in jdk.jfr.internal.RequestEngine#setFlushInterval > 8240360: NativeLibraryEvent has wrong library name on Linux > 8242844: JFR: Clean up typos and log format > 8242485: Null _file checking in fileStream::flush() > 8238665: Add JFR event for direct memory statistics > 8237499: JFR: Include stack trace in the ThreadStart event > 8234060: Potential memory reordering problem in JfrBuffer flush mechanism (co-author with Markus) > 8260589: Crash in JfrTraceIdLoadBarrier::load(_jclass*) (co-author with Markus) > -- Mario Torre Manager, Software Engineering, core OpenJDK Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From zgu at redhat.com Fri Aug 6 13:19:25 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 6 Aug 2021 09:19:25 -0400 Subject: CFV: New JDK Committer: Denghui Dong In-Reply-To: References: Message-ID: <70e42f61-b93b-8490-c20c-cbbd62c1c6da@redhat.com> Vote: yes -Zhengyu On 8/6/21 7:15 AM, Markus Gronlund wrote: > I hereby nominate Denghui Dong (ddong) [0] to JDK Committer. > > Denghui is working in the Alibaba JVM Team and is a Committer in the JDK 8 updates project. > > He has made over a dozen contributions to the JDK project [3]. > > Votes are due by 14h00 CET on Friday, the 20th of August, 2021. > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thank you > Markus > > [0] https://openjdk.java.net/census#ddong > [1] https://openjdk.java.net/census#jdk > [2] http://openjdk.java.net/projects/#committer-vote > [3] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3AD-D-H+is%3Aclosed > [3 inlined, including co-authored PRs] > 8261441: JFR: Filename expansion > 8271726: JFR: should use equal() to check event fields in tests > 8268298: jdk/jfr/api/consumer/log/TestVerbosity.java fails: unexpected log message > 8269225: JFR.stop misses the written info when the filename is only specified by JFR.start > 8268857: Merge VM_PrintJNI and VM_PrintThreads and remove the unused field 'is_deadlock' of DeadlockCycle > 8268780: Use 'print_cr' instead of 'print' for the message 'eliminated ' > 8267800: Remove the '_dirty' set in BCEscapeAnalyzer > 8265129: Add intrinsic support for JVM.getClassId > 8266642: improve ResolvedMethodTable hash function > 8264633: Add missing logging to PlatformRecording#stop > 8259956: jdk.jfr.internal.ChunkInputStream#available should return the sum of remaining available bytes > 8259808: Add JFR event to detect GC locker stall > 8242792: interval < flushInterval is always false in jdk.jfr.internal.RequestEngine#setFlushInterval > 8240360: NativeLibraryEvent has wrong library name on Linux > 8242844: JFR: Clean up typos and log format > 8242485: Null _file checking in fileStream::flush() > 8238665: Add JFR event for direct memory statistics > 8237499: JFR: Include stack trace in the ThreadStart event > 8234060: Potential memory reordering problem in JfrBuffer flush mechanism (co-author with Markus) > 8260589: Crash in JfrTraceIdLoadBarrier::load(_jclass*) (co-author with Markus) > From eric.caspole at oracle.com Fri Aug 6 13:30:48 2021 From: eric.caspole at oracle.com (eric.caspole at oracle.com) Date: Fri, 6 Aug 2021 09:30:48 -0400 Subject: CFV: New JDK Committer: Denghui Dong In-Reply-To: References: Message-ID: <61d8e5a4-43c1-3d16-0022-a763d21ffc2a@oracle.com> Vote: yes Eric On 8/6/21 7:15 AM, Markus Gronlund wrote: > I hereby nominate Denghui Dong (ddong) [0] to JDK Committer. > > Denghui is working in the Alibaba JVM Team and is a Committer in the JDK 8 updates project. > > He has made over a dozen contributions to the JDK project [3]. > > Votes are due by 14h00 CET on Friday, the 20th of August, 2021. > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thank you > Markus > > [0] https://openjdk.java.net/census#ddong > [1] https://openjdk.java.net/census#jdk > [2] http://openjdk.java.net/projects/#committer-vote > [3] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3AD-D-H+is%3Aclosed > [3 inlined, including co-authored PRs] > 8261441: JFR: Filename expansion > 8271726: JFR: should use equal() to check event fields in tests > 8268298: jdk/jfr/api/consumer/log/TestVerbosity.java fails: unexpected log message > 8269225: JFR.stop misses the written info when the filename is only specified by JFR.start > 8268857: Merge VM_PrintJNI and VM_PrintThreads and remove the unused field 'is_deadlock' of DeadlockCycle > 8268780: Use 'print_cr' instead of 'print' for the message 'eliminated ' > 8267800: Remove the '_dirty' set in BCEscapeAnalyzer > 8265129: Add intrinsic support for JVM.getClassId > 8266642: improve ResolvedMethodTable hash function > 8264633: Add missing logging to PlatformRecording#stop > 8259956: jdk.jfr.internal.ChunkInputStream#available should return the sum of remaining available bytes > 8259808: Add JFR event to detect GC locker stall > 8242792: interval < flushInterval is always false in jdk.jfr.internal.RequestEngine#setFlushInterval > 8240360: NativeLibraryEvent has wrong library name on Linux > 8242844: JFR: Clean up typos and log format > 8242485: Null _file checking in fileStream::flush() > 8238665: Add JFR event for direct memory statistics > 8237499: JFR: Include stack trace in the ThreadStart event > 8234060: Potential memory reordering problem in JfrBuffer flush mechanism (co-author with Markus) > 8260589: Crash in JfrTraceIdLoadBarrier::load(_jclass*) (co-author with Markus) From raffaello.giulietti at gmail.com Fri Aug 6 13:57:28 2021 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Fri, 6 Aug 2021 15:57:28 +0200 Subject: Is the JMM spec progressing? Message-ID: <27a1640c-830f-d0f8-eb2c-5c6753ce43c0@gmail.com> Hello, "JEP 188: Java Memory Model Update" [1], the JMM wiki [2] and the jmm-dev mailing list [3] seem quite inactive. (The latter point explains why I'm posting to this list instead.) The introduction of j.l.i.VarHandle [4] brought more access modes to Java, but in a narrative and informal way. A paper by Bender & Palsberg [5], addressing the formalization of the concurrent access modes, has been published in 2019 but I'm not sure if it caught the attention of the OpenJDK community. So what is the current thinking for progressing the JMM spec? Greetings Raffaello ---- [1] https://openjdk.java.net/jeps/188 [2] https://wiki.openjdk.java.net/display/jmm/Main [3] https://mail.openjdk.java.net/pipermail/jmm-dev/ [4] https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/lang/invoke/VarHandle.html [5] https://dl.acm.org/doi/10.1145/3360568 From erik.gahlin at oracle.com Fri Aug 6 15:02:45 2021 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Fri, 6 Aug 2021 15:02:45 +0000 Subject: New JDK Committer: Denghui Dong Message-ID: Vote: yes Erik ?On 2021-08-06, 13:15, "jdk-dev on behalf of Markus Gronlund" wrote: I hereby nominate Denghui Dong (ddong) [0] to JDK Committer. Denghui is working in the Alibaba JVM Team and is a Committer in the JDK 8 updates project. He has made over a dozen contributions to the JDK project [3]. Votes are due by 14h00 CET on Friday, the 20th of August, 2021. Only current JDK Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Thank you Markus [0] https://openjdk.java.net/census#ddong [1] https://openjdk.java.net/census#jdk [2] http://openjdk.java.net/projects/#committer-vote [3] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3AD-D-H+is%3Aclosed [3 inlined, including co-authored PRs] 8261441: JFR: Filename expansion 8271726: JFR: should use equal() to check event fields in tests 8268298: jdk/jfr/api/consumer/log/TestVerbosity.java fails: unexpected log message 8269225: JFR.stop misses the written info when the filename is only specified by JFR.start 8268857: Merge VM_PrintJNI and VM_PrintThreads and remove the unused field 'is_deadlock' of DeadlockCycle 8268780: Use 'print_cr' instead of 'print' for the message 'eliminated ' 8267800: Remove the '_dirty' set in BCEscapeAnalyzer 8265129: Add intrinsic support for JVM.getClassId 8266642: improve ResolvedMethodTable hash function 8264633: Add missing logging to PlatformRecording#stop 8259956: jdk.jfr.internal.ChunkInputStream#available should return the sum of remaining available bytes 8259808: Add JFR event to detect GC locker stall 8242792: interval < flushInterval is always false in jdk.jfr.internal.RequestEngine#setFlushInterval 8240360: NativeLibraryEvent has wrong library name on Linux 8242844: JFR: Clean up typos and log format 8242485: Null _file checking in fileStream::flush() 8238665: Add JFR event for direct memory statistics 8237499: JFR: Include stack trace in the ThreadStart event 8234060: Potential memory reordering problem in JfrBuffer flush mechanism (co-author with Markus) 8260589: Crash in JfrTraceIdLoadBarrier::load(_jclass*) (co-author with Markus) From mark.reinhold at oracle.com Fri Aug 6 17:09:00 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 06 Aug 2021 10:09:00 -0700 Subject: JDK 17: First Release Candidate Message-ID: <20210806100900.252926147@eggemoggin.niobe.net> There are no unresolved P1 bugs in build 35, so that is our first JDK 17 Release Candidate. Binaries available here, as usual: https://jdk.java.net/17 - Mark From xxinliu at amazon.com Fri Aug 6 17:20:40 2021 From: xxinliu at amazon.com (Liu, Xin) Date: Fri, 6 Aug 2021 10:20:40 -0700 Subject: [UNVERIFIED SENDER] CFV: New JDK Committer: Denghui Dong In-Reply-To: References: Message-ID: Vote: yes. --lx On 8/6/21 4:15 AM, Markus Gronlund wrote: > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > I hereby nominate Denghui Dong (ddong) [0] to JDK Committer. > > Denghui is working in the Alibaba JVM Team and is a Committer in the JDK 8 updates project. > > He has made over a dozen contributions to the JDK project [3]. > > Votes are due by 14h00 CET on Friday, the 20th of August, 2021. > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thank you > Markus > > [0] https://openjdk.java.net/census#ddong > [1] https://openjdk.java.net/census#jdk > [2] http://openjdk.java.net/projects/#committer-vote > [3] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3AD-D-H+is%3Aclosed > [3 inlined, including co-authored PRs] > 8261441: JFR: Filename expansion > 8271726: JFR: should use equal() to check event fields in tests > 8268298: jdk/jfr/api/consumer/log/TestVerbosity.java fails: unexpected log message > 8269225: JFR.stop misses the written info when the filename is only specified by JFR.start > 8268857: Merge VM_PrintJNI and VM_PrintThreads and remove the unused field 'is_deadlock' of DeadlockCycle > 8268780: Use 'print_cr' instead of 'print' for the message 'eliminated ' > 8267800: Remove the '_dirty' set in BCEscapeAnalyzer > 8265129: Add intrinsic support for JVM.getClassId > 8266642: improve ResolvedMethodTable hash function > 8264633: Add missing logging to PlatformRecording#stop > 8259956: jdk.jfr.internal.ChunkInputStream#available should return the sum of remaining available bytes > 8259808: Add JFR event to detect GC locker stall > 8242792: interval < flushInterval is always false in jdk.jfr.internal.RequestEngine#setFlushInterval > 8240360: NativeLibraryEvent has wrong library name on Linux > 8242844: JFR: Clean up typos and log format > 8242485: Null _file checking in fileStream::flush() > 8238665: Add JFR event for direct memory statistics > 8237499: JFR: Include stack trace in the ThreadStart event > 8234060: Potential memory reordering problem in JfrBuffer flush mechanism (co-author with Markus) > 8260589: Crash in JfrTraceIdLoadBarrier::load(_jclass*) (co-author with Markus) > From christoph.langer at sap.com Fri Aug 6 21:43:23 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 6 Aug 2021 21:43:23 +0000 Subject: CFV: New JDK Committer: Denghui Dong In-Reply-To: References: Message-ID: Vote: yes /christoph > -----Original Message----- > From: jdk-dev On Behalf Of Markus > Gronlund > Sent: Freitag, 6. August 2021 13:16 > To: jdk-dev at openjdk.java.net > Subject: CFV: New JDK Committer: Denghui Dong > > I hereby nominate Denghui Dong (ddong) [0] to JDK Committer. > > Denghui is working in the Alibaba JVM Team and is a Committer in the JDK 8 > updates project. > > He has made over a dozen contributions to the JDK project [3]. > > Votes are due by 14h00 CET on Friday, the 20th of August, 2021. > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thank you > Markus > > [0] https://openjdk.java.net/census#ddong > [1] https://openjdk.java.net/census#jdk > [2] http://openjdk.java.net/projects/#committer-vote > [3] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3AD-D- > H+is%3Aclosed > [3 inlined, including co-authored PRs] > 8261441: JFR: Filename expansion > 8271726: JFR: should use equal() to check event fields in tests > 8268298: jdk/jfr/api/consumer/log/TestVerbosity.java fails: unexpected log > message > 8269225: JFR.stop misses the written info when the filename is only specified > by JFR.start > 8268857: Merge VM_PrintJNI and VM_PrintThreads and remove the unused > field 'is_deadlock' of DeadlockCycle > 8268780: Use 'print_cr' instead of 'print' for the message 'eliminated is scalar replaced>' > 8267800: Remove the '_dirty' set in BCEscapeAnalyzer > 8265129: Add intrinsic support for JVM.getClassId > 8266642: improve ResolvedMethodTable hash function > 8264633: Add missing logging to PlatformRecording#stop > 8259956: jdk.jfr.internal.ChunkInputStream#available should return the sum > of remaining available bytes > 8259808: Add JFR event to detect GC locker stall > 8242792: interval < flushInterval is always false in > jdk.jfr.internal.RequestEngine#setFlushInterval > 8240360: NativeLibraryEvent has wrong library name on Linux > 8242844: JFR: Clean up typos and log format > 8242485: Null _file checking in fileStream::flush() > 8238665: Add JFR event for direct memory statistics > 8237499: JFR: Include stack trace in the ThreadStart event > 8234060: Potential memory reordering problem in JfrBuffer flush mechanism > (co-author with Markus) > 8260589: Crash in JfrTraceIdLoadBarrier::load(_jclass*) (co-author with > Markus) From hboehm at google.com Fri Aug 6 22:32:18 2021 From: hboehm at google.com (Hans Boehm) Date: Fri, 6 Aug 2021 15:32:18 -0700 Subject: Is the JMM spec progressing? In-Reply-To: <27a1640c-830f-d0f8-eb2c-5c6753ce43c0@gmail.com> References: <27a1640c-830f-d0f8-eb2c-5c6753ce43c0@gmail.com> Message-ID: I think it's safe to say that it has been slow going, not just for Java, but for other languages as well. In my view, the core problem, shared by pretty much all of them, is that we don't have an established way to give well-defined semantics to potentially racing unordered accesses, like ordinary variable accesses in Java, or memory_order_relaxed accesses in C and C++. That's particularly essential with the traditional Java language-based-security model, since we can't just give up on racing accesses to ordinary variables. I'm aware of a number of proposed solutions. But I don't think we currently have enough confidence that they a) Are correct, and don't have issues similar to the older models, a) Don't have unintended consequences, particularly for compilation, and b) Are sufficiently comprehensible by programmers to actually be useful. (a) is hard because the models have gotten complex enough that reviewers are scarce. (A problem that I gather you're familiar with.) The authors are commonly experts at formally analyzing the models, but it's hard to analyze whether the model conflicts with some well-known, but perhaps not well-written-down compilation technique. Probably even more controversially, I think we've realized that existing compiler technology can compile such racing code in ways that some of us are not 100% sure should really be allowed. Demonstrably unexecuted code can affect the semantics in ways that strike me as scary. (See wg21.link/p1217 for a down-to-assembly C++ version; IIUC, Lochbihler and others earlier came up with some closely related observations for Java.) It might be possible to do what we've involuntarily done for C++: Punt the hard cases for now, and define what the model is for programs without racing ordinary accesses. On Fri, Aug 6, 2021 at 6:57 AM Raffaello Giulietti < raffaello.giulietti at gmail.com> wrote: > Hello, > > "JEP 188: Java Memory Model Update" [1], the JMM wiki [2] and the > jmm-dev mailing list [3] seem quite inactive. (The latter point explains > why I'm posting to this list instead.) > > The introduction of j.l.i.VarHandle [4] brought more access modes to > Java, but in a narrative and informal way. A paper by Bender & Palsberg > [5], addressing the formalization of the concurrent access modes, has > been published in 2019 but I'm not sure if it caught the attention of > the OpenJDK community. > > So what is the current thinking for progressing the JMM spec? > > > Greetings > Raffaello > > ---- > > [1] https://openjdk.java.net/jeps/188 > [2] https://wiki.openjdk.java.net/display/jmm/Main > [3] https://mail.openjdk.java.net/pipermail/jmm-dev/ > [4] > > https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/lang/invoke/VarHandle.html > [5] https://dl.acm.org/doi/10.1145/3360568 > From lgxbslgx at gmail.com Sat Aug 7 04:27:51 2021 From: lgxbslgx at gmail.com (Guoxiong Li) Date: Sat, 7 Aug 2021 12:27:51 +0800 Subject: CFV: New JDK Committer: Denghui Dong In-Reply-To: References: Message-ID: Vote: yes -- Guoxiong From aph-open at littlepinkcloud.com Sat Aug 7 09:18:18 2021 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Sat, 7 Aug 2021 10:18:18 +0100 Subject: Is the JMM spec progressing? In-Reply-To: References: <27a1640c-830f-d0f8-eb2c-5c6753ce43c0@gmail.com> Message-ID: <3a326f91-7684-084b-8c1b-233c067d3f8f@littlepinkcloud.com> On 8/6/21 11:32 PM, Hans Boehm wrote: > Probably even more controversially, I think we've realized that > existing compiler technology can compile such racing code in ways > that some of us are not 100% sure should really be allowed. This implies, does it not, that the problem is not formalization as such, but that we don't really understand what the language is supposed to mean? That's always been my problem with OOTA: I'm unsure whether the problem is due to the inadequacy of formal models, in which case the formalists can fix their own problem, or something we all have to pay attention to. > Demonstrably unexecuted code can affect the semantics in ways that > strike me as scary. (See wg21.link/p1217 for a down-to-assembly C++ > version; IIUC, Lochbihler and others earlier came up with some > closely related observations for Java.) Looking again at p1217, it seems to me that enforcing load-store ordering would have severe effects on compilers, at least without new optimization techniques. We hoist loads before loops and sink stores after them. When it all works out, there are no memory accesses in the loop. A load-store barrier in a loop would have the effect of forcing succeeding stores out to memory, and forcing preceding loads to reload from memory. It's not hard to imagine that this would cause an order-of-margnitude performance reduction in common cases. I suppose one could argue that such optimizations would continue to be valid, so only those stores which would have been emitted anyway would be affected. But that's not how compilers work, as far as I know. In our IR for C2, memory accesses are not pinned in any way, so the only way to make unrelated accesses execute in any particular order is to add a dependency between all loads and stores. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph-open at littlepinkcloud.com Sat Aug 7 09:27:29 2021 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Sat, 7 Aug 2021 10:27:29 +0100 Subject: Is the JMM spec progressing? In-Reply-To: References: <27a1640c-830f-d0f8-eb2c-5c6753ce43c0@gmail.com> Message-ID: On 8/6/21 11:32 PM, Hans Boehm wrote: > Probably even more controversially, I think we've realized that > existing compiler technology can compile such racing code in ways > that some of us are not 100% sure should really be allowed. This implies, does it not, that the problem is not formalization as such, but that we don't really understand what the language is supposed to mean? That's always been my problem with OOTA: I'm unsure whether the problem is due to the inadequacy of formal models, in which case the formalists can fix their own problem, or something we all have to pay attention to. > Demonstrably unexecuted code can affect the semantics in ways that > strike me as scary. (See wg21.link/p1217 for a down-to-assembly C++ > version; IIUC, Lochbihler and others earlier came up with some > closely related observations for Java.) Looking again at p1217, it seems to me that enforcing load-store ordering would have severe effects on compilers, at least without new optimization techniques. We hoist loads before loops and sink stores after them. When it all works out, there are no memory accesses in the loop. A load-store barrier in a loop would have the effect of forcing succeeding stores out to memory, and forcing preceding loads to reload from memory. It's not hard to imagine that this would cause an order-of-margnitude performance reduction in common cases. I suppose one could argue that such optimizations would continue to be valid, so only those stores which would have been emitted anyway would be affected. But that's not how compilers work, as far as I know. In our IR for C2, memory accesses are not pinned in any way, so the only way to make unrelated accesses execute in any particular order is to add a dependency between all loads and stores. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dl at cs.oswego.edu Sat Aug 7 11:43:52 2021 From: dl at cs.oswego.edu (Doug Lea) Date: Sat, 7 Aug 2021 07:43:52 -0400 Subject: [jmm-dev] Is the JMM spec progressing? In-Reply-To: References: <27a1640c-830f-d0f8-eb2c-5c6753ce43c0@gmail.com> Message-ID: (Henceforth, let's drop jdk-dev and move this to jmm-dev.) On 8/7/21 5:27 AM, Andrew Haley wrote: > On 8/6/21 11:32 PM, Hans Boehm wrote: > >> Probably even more controversially, I think we've realized that >> existing compiler technology can compile such racing code in ways >> that some of us are not 100% sure should really be allowed. > This implies, does it not, that the problem is not formalization as > such, but that we don't really understand what the language is > supposed to mean? That's always been my problem with OOTA: I'm unsure > whether the problem is due to the inadequacy of formal models, in > which case the formalists can fix their own problem, or something we > all have to pay attention to. Yes. My stance in the less formal account (http://gee.cs.oswego.edu/dl/html/j9mm.html) as well as Shuyang Liu et al's ongoing formalization (see links from http://compilers.cs.ucla.edu/people/) is that the most you want to say about racy Java programs is that they are typesafe. As in: you can't see a String when expecting an int. Even this looser constraint is challenging to specify, prove, and extend. But it is a path for Java that might not apply to languages like C that are not guaranteed typesafe anyway, and so enter Undefined Behavior territory (as opposed to possibly-unexpected but still typesafe behavior). -Doug > >> Demonstrably unexecuted code can affect the semantics in ways that >> strike me as scary. (See wg21.link/p1217 for a down-to-assembly C++ >> version; IIUC, Lochbihler and others earlier came up with some >> closely related observations for Java.) > Looking again at p1217, it seems to me that enforcing load-store > ordering would have severe effects on compilers, at least without new > optimization techniques. We hoist loads before loops and sink stores > after them. When it all works out, there are no memory accesses in the > loop. A load-store barrier in a loop would have the effect of forcing > succeeding stores out to memory, and forcing preceding loads to reload > from memory. It's not hard to imagine that this would cause an > order-of-margnitude performance reduction in common cases. > > I suppose one could argue that such optimizations would continue to be > valid, so only those stores which would have been emitted anyway would > be affected. But that's not how compilers work, as far as I know. In > our IR for C2, memory accesses are not pinned in any way, so the only > way to make unrelated accesses execute in any particular order is to > add a dependency between all loads and stores. > From hohensee at amazon.com Sat Aug 7 17:09:07 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Sat, 7 Aug 2021 17:09:07 +0000 Subject: CFV: New JDK Committer: Denghui Dong Message-ID: Vote: yes ?-----Original Message----- From: jdk-dev on behalf of Markus Gronlund Date: Friday, August 6, 2021 at 4:16 AM To: "jdk-dev at openjdk.java.net" Subject: CFV: New JDK Committer: Denghui Dong I hereby nominate Denghui Dong (ddong) [0] to JDK Committer. Denghui is working in the Alibaba JVM Team and is a Committer in the JDK 8 updates project. He has made over a dozen contributions to the JDK project [3]. Votes are due by 14h00 CET on Friday, the 20th of August, 2021. Only current JDK Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Thank you Markus [0] https://openjdk.java.net/census#ddong [1] https://openjdk.java.net/census#jdk [2] http://openjdk.java.net/projects/#committer-vote [3] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3AD-D-H+is%3Aclosed [3 inlined, including co-authored PRs] 8261441: JFR: Filename expansion 8271726: JFR: should use equal() to check event fields in tests 8268298: jdk/jfr/api/consumer/log/TestVerbosity.java fails: unexpected log message 8269225: JFR.stop misses the written info when the filename is only specified by JFR.start 8268857: Merge VM_PrintJNI and VM_PrintThreads and remove the unused field 'is_deadlock' of DeadlockCycle 8268780: Use 'print_cr' instead of 'print' for the message 'eliminated ' 8267800: Remove the '_dirty' set in BCEscapeAnalyzer 8265129: Add intrinsic support for JVM.getClassId 8266642: improve ResolvedMethodTable hash function 8264633: Add missing logging to PlatformRecording#stop 8259956: jdk.jfr.internal.ChunkInputStream#available should return the sum of remaining available bytes 8259808: Add JFR event to detect GC locker stall 8242792: interval < flushInterval is always false in jdk.jfr.internal.RequestEngine#setFlushInterval 8240360: NativeLibraryEvent has wrong library name on Linux 8242844: JFR: Clean up typos and log format 8242485: Null _file checking in fileStream::flush() 8238665: Add JFR event for direct memory statistics 8237499: JFR: Include stack trace in the ThreadStart event 8234060: Potential memory reordering problem in JfrBuffer flush mechanism (co-author with Markus) 8260589: Crash in JfrTraceIdLoadBarrier::load(_jclass*) (co-author with Markus) From hboehm at google.com Sat Aug 7 22:13:25 2021 From: hboehm at google.com (Hans Boehm) Date: Sat, 7 Aug 2021 15:13:25 -0700 Subject: Is the JMM spec progressing? In-Reply-To: References: <27a1640c-830f-d0f8-eb2c-5c6753ce43c0@gmail.com> Message-ID: On Sat, Aug 7, 2021 at 2:28 AM Andrew Haley wrote: > On 8/6/21 11:32 PM, Hans Boehm wrote: > > > Probably even more controversially, I think we've realized that > > existing compiler technology can compile such racing code in ways > > that some of us are not 100% sure should really be allowed. > > This implies, does it not, that the problem is not formalization as > such, but that we don't really understand what the language is > supposed to mean? That's always been my problem with OOTA: I'm unsure > whether the problem is due to the inadequacy of formal models, in > which case the formalists can fix their own problem, or something we > all have to pay attention to. > In some sense, I'm not sure either. The p1217 examples bother me in that they seem to violate some global programming rules ("if x is only ever null or refers to an object properly constructed by the same thread, then x should never appear to refer to an incompletely constructed object"). And there seems to be disagreement about whether the currently allowed behavior is "correct". On the other hand, in practice the weirdness doesn't seem to break things. If you ask people advocating the current behavior, the answer will be that it doesn't matter because nobody writes code that way. If you ask people trying to analyzer or verify code, they'll probably be unhappy. And I haven't been able to convince myself that you cannot get yourself into these situations just by linking components together, each of which does something perfectly reasonable. And there are very common code patterns (like the standard implementation of reentrant locks used by all Java implementations) that break if you allow general OOTA behavior. Which at least means that you can't currently formally verify such code. The theorem you'd be trying to prove is false with respect to the part of the language spec we know how to formalize. It's a mess. > > Demonstrably unexecuted code can affect the semantics in ways that > > strike me as scary. (See wg21.link/p1217 for a down-to-assembly C++ > > version; IIUC, Lochbihler and others earlier came up with some > > closely related observations for Java.) > > Looking again at p1217, it seems to me that enforcing load-store > ordering would have severe effects on compilers, at least without new > optimization techniques. We hoist loads before loops and sink stores > after them. When it all works out, there are no memory accesses in the > loop. A load-store barrier in a loop would have the effect of forcing > succeeding stores out to memory, and forcing preceding loads to reload > from memory. It's not hard to imagine that this would cause an > order-of-margnitude performance reduction in common cases. > I think it would be a fairly pervasive change to optimizers. It has also become clear in WG21, the C++ committee, that there is not enough support for requiring this. In that case, Ou and Demsky have a paper saying that the overhead is likely to be on the order of 1% or less. For Java if it were applied everywhere, it would probably be appreciably higher. On the other hand, it's a bit harder than that to come up with examples where the generated x86 code has to be worse. Moving loads earlier in the code, or delaying stores, as you suggest, would still be fine. The only issue is with delaying loads past stores, which seems less common, though it can certainly be beneficial for reducing live ranges, probably some vectorization etc. But it seems unlikely that such a restriction will be applied even to C++ memory_order_relaxed, much less Java ordinary variables. Hans > > I suppose one could argue that such optimizations would continue to be > valid, so only those stores which would have been emitted anyway would > be affected. But that's not how compilers work, as far as I know. In > our IR for C2, memory accesses are not pinned in any way, so the only > way to make unrelated accesses execute in any particular order is to > add a dependency between all loads and stores. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From felix.yang at huawei.com Mon Aug 9 02:27:21 2021 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Mon, 9 Aug 2021 02:27:21 +0000 Subject: New JDK Committer: Denghui Dong In-Reply-To: References: Message-ID: <388b79a61a4649b5acad11dd1b41b0ce@huawei.com> Vote: Yes Thanks, Felix > -----Original Message----- > From: jdk-dev [mailto:jdk-dev-retn at openjdk.java.net] On Behalf Of Markus > Gronlund > Sent: Friday, August 6, 2021 7:16 PM > To: jdk-dev at openjdk.java.net > Subject: CFV: New JDK Committer: Denghui Dong > > I hereby nominate Denghui Dong (ddong) [0] to JDK Committer. From qingfeng.yy at alibaba-inc.com Mon Aug 9 02:29:32 2021 From: qingfeng.yy at alibaba-inc.com (Yi Yang) Date: Mon, 09 Aug 2021 10:29:32 +0800 Subject: =?UTF-8?B?UmU6IENGVjogTmV3IEpESyBDb21taXR0ZXI6IERlbmdodWkgRG9uZw==?= In-Reply-To: References: Message-ID: Vote: Yes Best regards, Yi Yang ------------------------------------------------------------------ From:Markus Gronlund Send Time:2021 Aug. 6 (Fri.) 19:16 To:jdk-dev at openjdk.java.net Subject:CFV: New JDK Committer: Denghui Dong I hereby nominate Denghui Dong (ddong) [0] to JDK Committer. Denghui is working in the Alibaba JVM Team and is a Committer in the JDK 8 updates project. He has made over a dozen contributions to the JDK project [3]. Votes are due by 14h00 CET on Friday, the 20th of August, 2021. Only current JDK Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Thank you Markus [0] https://openjdk.java.net/census#ddong [1] https://openjdk.java.net/census#jdk [2] http://openjdk.java.net/projects/#committer-vote [3] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3AD-D-H+is%3Aclosed [3 inlined, including co-authored PRs] 8261441: JFR: Filename expansion 8271726: JFR: should use equal() to check event fields in tests 8268298: jdk/jfr/api/consumer/log/TestVerbosity.java fails: unexpected log message 8269225: JFR.stop misses the written info when the filename is only specified by JFR.start 8268857: Merge VM_PrintJNI and VM_PrintThreads and remove the unused field 'is_deadlock' of DeadlockCycle 8268780: Use 'print_cr' instead of 'print' for the message 'eliminated ' 8267800: Remove the '_dirty' set in BCEscapeAnalyzer 8265129: Add intrinsic support for JVM.getClassId 8266642: improve ResolvedMethodTable hash function 8264633: Add missing logging to PlatformRecording#stop 8259956: jdk.jfr.internal.ChunkInputStream#available should return the sum of remaining available bytes 8259808: Add JFR event to detect GC locker stall 8242792: interval < flushInterval is always false in jdk.jfr.internal.RequestEngine#setFlushInterval 8240360: NativeLibraryEvent has wrong library name on Linux 8242844: JFR: Clean up typos and log format 8242485: Null _file checking in fileStream::flush() 8238665: Add JFR event for direct memory statistics 8237499: JFR: Include stack trace in the ThreadStart event 8234060: Potential memory reordering problem in JfrBuffer flush mechanism (co-author with Markus) 8260589: Crash in JfrTraceIdLoadBarrier::load(_jclass*) (co-author with Markus) From adinn at redhat.com Mon Aug 9 08:55:20 2021 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 9 Aug 2021 09:55:20 +0100 Subject: CFV: New JDK Committer: Denghui Dong In-Reply-To: References: Message-ID: <6f7c79dc-2b31-5271-8543-21e640e10cf3@redhat.com> Vote: yes On 06/08/2021 12:15, Markus Gronlund wrote: > 8268780: Use 'print_cr' instead of 'print' for the message 'eliminated ' > 8267800: Remove the '_dirty' set in BCEscapeAnalyzer > 8265129: Add intrinsic support for JVM.getClassId > 8266642: improve ResolvedMethodTable hash function > 8264633: Add missing logging to PlatformRecording#stop > 8259956: jdk.jfr.internal.ChunkInputStream#available should return the sum of remaining available bytes > 8259808: Add JFR event to detect GC locker stall > 8242792: interval < flushInterval is always false in jdk.jfr.internal.RequestEngine#setFlushInterval > 8240360: NativeLibraryEvent has wrong library name on Linux > 8242844: JFR: Clean up typos and log format > 8242485: Null _file checking in fileStream::flush() > 8238665: Add JFR event for direct memory statistics > 8237499: JFR: Include stack trace in the ThreadStart event > 8234060: Potential memory reordering problem in JfrBuffer flush mechanism (co-author with Markus) -- regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From lois.foltan at oracle.com Mon Aug 9 14:21:24 2021 From: lois.foltan at oracle.com (Lois Foltan) Date: Mon, 9 Aug 2021 10:21:24 -0400 Subject: CFV: New JDK Committer: Denghui Dong In-Reply-To: References: Message-ID: <0cd8278a-3ee7-9fc5-2bcd-93489696832d@oracle.com> Vote: yes Lois On 8/6/2021 7:15 AM, Markus Gronlund wrote: > I hereby nominate Denghui Dong (ddong) [0] to JDK Committer. > > Denghui is working in the Alibaba JVM Team and is a Committer in the JDK 8 updates project. > > He has made over a dozen contributions to the JDK project [3]. > > Votes are due by 14h00 CET on Friday, the 20th of August, 2021. > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thank you > Markus > > [0] https://openjdk.java.net/census#ddong > [1] https://openjdk.java.net/census#jdk > [2] http://openjdk.java.net/projects/#committer-vote > [3] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3AD-D-H+is%3Aclosed > [3 inlined, including co-authored PRs] > 8261441: JFR: Filename expansion > 8271726: JFR: should use equal() to check event fields in tests > 8268298: jdk/jfr/api/consumer/log/TestVerbosity.java fails: unexpected log message > 8269225: JFR.stop misses the written info when the filename is only specified by JFR.start > 8268857: Merge VM_PrintJNI and VM_PrintThreads and remove the unused field 'is_deadlock' of DeadlockCycle > 8268780: Use 'print_cr' instead of 'print' for the message 'eliminated ' > 8267800: Remove the '_dirty' set in BCEscapeAnalyzer > 8265129: Add intrinsic support for JVM.getClassId > 8266642: improve ResolvedMethodTable hash function > 8264633: Add missing logging to PlatformRecording#stop > 8259956: jdk.jfr.internal.ChunkInputStream#available should return the sum of remaining available bytes > 8259808: Add JFR event to detect GC locker stall > 8242792: interval < flushInterval is always false in jdk.jfr.internal.RequestEngine#setFlushInterval > 8240360: NativeLibraryEvent has wrong library name on Linux > 8242844: JFR: Clean up typos and log format > 8242485: Null _file checking in fileStream::flush() > 8238665: Add JFR event for direct memory statistics > 8237499: JFR: Include stack trace in the ThreadStart event > 8234060: Potential memory reordering problem in JfrBuffer flush mechanism (co-author with Markus) > 8260589: Crash in JfrTraceIdLoadBarrier::load(_jclass*) (co-author with Markus) From mikhailo.seledtsov at oracle.com Mon Aug 9 21:10:22 2021 From: mikhailo.seledtsov at oracle.com (mikhailo.seledtsov at oracle.com) Date: Mon, 9 Aug 2021 14:10:22 -0700 Subject: CFV: New JDK Committer: Denghui Dong In-Reply-To: References: Message-ID: Vote: yes On 8/6/21 4:15 AM, Markus Gronlund wrote: > I hereby nominate Denghui Dong (ddong) [0] to JDK Committer. > > Denghui is working in the Alibaba JVM Team and is a Committer in the JDK 8 updates project. > > He has made over a dozen contributions to the JDK project [3]. > > Votes are due by 14h00 CET on Friday, the 20th of August, 2021. > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thank you > Markus > > [0] https://openjdk.java.net/census#ddong > [1] https://openjdk.java.net/census#jdk > [2] http://openjdk.java.net/projects/#committer-vote > [3] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3AD-D-H+is%3Aclosed > [3 inlined, including co-authored PRs] > 8261441: JFR: Filename expansion > 8271726: JFR: should use equal() to check event fields in tests > 8268298: jdk/jfr/api/consumer/log/TestVerbosity.java fails: unexpected log message > 8269225: JFR.stop misses the written info when the filename is only specified by JFR.start > 8268857: Merge VM_PrintJNI and VM_PrintThreads and remove the unused field 'is_deadlock' of DeadlockCycle > 8268780: Use 'print_cr' instead of 'print' for the message 'eliminated ' > 8267800: Remove the '_dirty' set in BCEscapeAnalyzer > 8265129: Add intrinsic support for JVM.getClassId > 8266642: improve ResolvedMethodTable hash function > 8264633: Add missing logging to PlatformRecording#stop > 8259956: jdk.jfr.internal.ChunkInputStream#available should return the sum of remaining available bytes > 8259808: Add JFR event to detect GC locker stall > 8242792: interval < flushInterval is always false in jdk.jfr.internal.RequestEngine#setFlushInterval > 8240360: NativeLibraryEvent has wrong library name on Linux > 8242844: JFR: Clean up typos and log format > 8242485: Null _file checking in fileStream::flush() > 8238665: Add JFR event for direct memory statistics > 8237499: JFR: Include stack trace in the ThreadStart event > 8234060: Potential memory reordering problem in JfrBuffer flush mechanism (co-author with Markus) > 8260589: Crash in JfrTraceIdLoadBarrier::load(_jclass*) (co-author with Markus) From thomas.stuefe at sap.com Tue Aug 10 06:09:03 2021 From: thomas.stuefe at sap.com (Stuefe, Thomas) Date: Tue, 10 Aug 2021 06:09:03 +0000 Subject: CFV: New JDK Committer: Denghui Dong In-Reply-To: References: Message-ID: Vote: yes > -----Original Message----- > From: jdk-dev On Behalf Of Markus Gronlund > Sent: Freitag, 6. August 2021 13:16 > To: jdk-dev at openjdk.java.net > Subject: CFV: New JDK Committer: Denghui Dong > > I hereby nominate Denghui Dong (ddong) [0] to JDK Committer. > > Denghui is working in the Alibaba JVM Team and is a Committer in the JDK 8 > updates project. > > He has made over a dozen contributions to the JDK project [3]. > > Votes are due by 14h00 CET on Friday, the 20th of August, 2021. > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thank you > Markus > > [0] https://openjdk.java.net/census#ddong > [1] https://openjdk.java.net/census#jdk > [2] http://openjdk.java.net/projects/#committer-vote > [3] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3AD-D- > H+is%3Aclosed > [3 inlined, including co-authored PRs] > 8261441: JFR: Filename expansion > 8271726: JFR: should use equal() to check event fields in tests > 8268298: jdk/jfr/api/consumer/log/TestVerbosity.java fails: unexpected log > message > 8269225: JFR.stop misses the written info when the filename is only specified by > JFR.start > 8268857: Merge VM_PrintJNI and VM_PrintThreads and remove the unused field > 'is_deadlock' of DeadlockCycle > 8268780: Use 'print_cr' instead of 'print' for the message 'eliminated scalar replaced>' > 8267800: Remove the '_dirty' set in BCEscapeAnalyzer > 8265129: Add intrinsic support for JVM.getClassId > 8266642: improve ResolvedMethodTable hash function > 8264633: Add missing logging to PlatformRecording#stop > 8259956: jdk.jfr.internal.ChunkInputStream#available should return the sum of > remaining available bytes > 8259808: Add JFR event to detect GC locker stall > 8242792: interval < flushInterval is always false in > jdk.jfr.internal.RequestEngine#setFlushInterval > 8240360: NativeLibraryEvent has wrong library name on Linux > 8242844: JFR: Clean up typos and log format > 8242485: Null _file checking in fileStream::flush() > 8238665: Add JFR event for direct memory statistics > 8237499: JFR: Include stack trace in the ThreadStart event > 8234060: Potential memory reordering problem in JfrBuffer flush mechanism > (co-author with Markus) > 8260589: Crash in JfrTraceIdLoadBarrier::load(_jclass*) (co-author with Markus) From kevin.rushforth at oracle.com Tue Aug 10 18:51:21 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 10 Aug 2021 11:51:21 -0700 Subject: [External] : Re: GitHub/Mailing list communication defunct? In-Reply-To: References: <095fc050-dbb1-107d-eac9-89c974ba42b8@oracle.com> <59dd2185-104f-3235-6d8a-5f581f6d99be@gmail.com> Message-ID: <35752964-122b-a857-9002-ea8d6e38ae27@oracle.com> [Moving jdk-dev to Bcc] Shah deployed a tentative fix for this about an hour ago. We hope this will resolve the problem. -- Kevin On 7/27/2021 10:44 AM, tim.bell at oracle.com wrote: > Hello > >> if someone comments/replies directly to the mailing list thread (like >> Bernd and I did, during this past hour[2]), those comments aren't >> being registered in that github PR. This used to work previously and >> seems to be broken right now. > > We are aware of this problem and still investigating.? We don't have a > root cause or an ETA for this. > > Tim > > > On 7/22/21 09:21, Jaikiran Pai wrote: >> FWIW, it looks like this isn't fully back to normal. From what I can >> see in one of the PR's[1] I'm involved in, if I comment directly on >> the PR through the github UI, a mail is now getting delivered to the >> relevant mailing lists. So this part is back to normal now. >> >> However, if someone comments/replies directly to the mailing list >> thread (like Bernd and I did, during this past hour[2]), those >> comments aren't being registered in that github PR. This used to work >> previously and seems to be broken right now. >> >> [1] >> https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/4607__;!!ACWV5N9M2RV99hQ!eNjD04SNNH9INHTt0cyyed12lRNw9aZfSspNKh0ILIUQCIcvka-_vJ8XHXipGIQ$ >> >> [2] >> https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-July/079994.html >> >> >> -Jaikiran >> >> On 22/07/21 3:03 am, tim.bell at oracle.com wrote: >>>> just recognized that all of a sudden the traffic on the OpenJDK >>>> mailing lists dropped >>> >>> About an hour ago we corrected a problem on the Skara server >>> processing external (EG: github) messages.? Message traffic should >>> be flowing again. >>> >>> Messages for events during the outage are lost.? We will be holding >>> a port-mortem to investigate why this outage was not noticed sooner, >>> and why there was a data loss. >>> >>> Tim >>> >>> >>> On 7/21/21 14:29, David Holmes wrote: >>>> Hi Christoph, >>>> >>>> On 22/07/2021 1:07 am, Langer, Christoph wrote: >>>>> Hi, >>>>> >>>>> there's still no traffic on the mailing lists... >>>>> >>>>> It would be much appreciated if you could share an update on the >>>>> status. >>>> >>>> There was no update to share I'm afraid but it has now been resolved. >>>> >>>> It seems likely that the missing mail is gone forever unfortunately. >>>> >>>> Cheers, >>>> David >>>> >>>>> Thanks >>>>> Christoph >>>>> >>>>> From: Langer, Christoph >>>>> Sent: Dienstag, 20. Juli 2021 08:23 >>>>> To: ops at openjdk.java.net; skara-dev at openjdk.java.net; >>>>> jdk-dev at openjdk.java.net >>>>> Subject: GitHub/Mailing list communication defunct? >>>>> >>>>> Hi, >>>>> >>>>> I just recognized that all of a sudden the traffic on the OpenJDK >>>>> mailing lists dropped... First I thought it's an issue with my >>>>> account but looking at the pipermail archives, I don't find any >>>>> mails after e.g. some time yesterday. And I guess there's still >>>>> the usual activity on GitHub... >>>>> >>>>> Are you aware of an issue? >>>>> >>>>> Thanks & Best regards >>>>> Christoph >>>>> >>> >> > From peter.firmstone at zeus.net.au Wed Aug 11 08:13:23 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Wed, 11 Aug 2021 18:13:23 +1000 Subject: JDK17 - Possible TLS issue. Message-ID: <973c1457-c24d-6a9e-8979-9cabba0a164e@zeus.net.au> I'm testing on JDK17, having some issues communicating using TLS between processes. With TLS disabled, the test passes on JDK17. The test passes using TLS on JDK 16 and earlier JDK versions. I've enabled TLS handshake debug on the output 1. https://github.com/pfirmstone/JGDMS/blob/trunk/qa/LookupNegMatches-jdk16-tls-handshake-debug.txt 2. https://github.com/pfirmstone/JGDMS/blob/trunk/qa/LookupNegMatches-jdk16.txt 3. https://github.com/pfirmstone/JGDMS/blob/trunk/qa/LookupNegMatches-jdk17-TLS-disabled.txt 4. https://github.com/pfirmstone/JGDMS/blob/trunk/qa/LookupNegMatches-jdk17-tls-handshake-debug.txt 5. https://github.com/pfirmstone/JGDMS/blob/trunk/qa/LookupNegMatches-jdk17-TLS-handshake-debug2.txt There are 5 JVM instances created during this integration test and these JVM's are communicating using network connections.? I have checked that all JVM processes are running, it seems to be a communication issue. Using diff to compare files 1 and 5 above, it appears to be related to a close notify in JDK17, on the (JSK) connection . Any suggestions? Thanks, Peter. [java] ActSys-err: javax.net.ssl|DEBUG|D2|(JSK) mux reader|2021-08-11 14:56:20.606 AEST|SSLSocketImpl.java:1775|close the SSL connection (passive) [java] ActSys-err: javax.net.ssl|DEBUG|C2|(JSK) mux writer|2021-08-11 14:56:20.606 AEST|SSLSocketImpl.java:572|duplex close of SSLSocket [java] ActSys-err: javax.net.ssl|ALL|D2|(JSK) mux reader|2021-08-11 14:56:20.606 AEST|SSLSocketImpl.java:1129|Closing input stream [java] ActSys-err: javax.net.ssl|WARNING|B2|(JSK) mux reader|2021-08-11 14:56:20.607 AEST|SSLSocketImpl.java:1666|handling exception ( [java] ActSys-err: "throwable" : { [java] ActSys-err: java.net.SocketException: Socket closed [java] ActSys-err: at java.base/sun.nio.ch.NioSocketImpl.endRead(NioSocketImpl.java:248) [java] ActSys-err: at java.base/sun.nio.ch.NioSocketImpl.implRead(NioSocketImpl.java:327) [java] ActSys-err: at java.base/sun.nio.ch.NioSocketImpl.read(NioSocketImpl.java:350) [java] ActSys-err: at java.base/sun.nio.ch.NioSocketImpl$1.read(NioSocketImpl.java:803) [java] ActSys-err: at java.base/java.net.Socket$SocketInputStream.read(Socket.java:966) [java] ActSys-err: at java.base/sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:478) [java] ActSys-err: at java.base/sun.security.ssl.SSLSocketInputRecord.readHeader(SSLSocketInputRecord.java:472) [java] ActSys-err: at java.base/sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(SSLSocketInputRecord.java:70) [java] ActSys-err: at java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1455) [java] ActSys-err: at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:1059) [java] ActSys-err: at org.apache.river.jeri.internal.mux.StreamConnectionIO$1.read(StreamConnectionIO.java:372) [java] ActSys-err: at org.apache.river.jeri.internal.mux.StreamConnectionIO$Reader.run(StreamConnectionIO.java:277) [java] ActSys-err: at org.apache.river.thread.ThreadPool$Task.run(ThreadPool.java:172) [java] ActSys-err: at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) [java] ActSys-err: at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) [java] ActSys-err: at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) [java] ActSys-err: at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [java] ActSys-err: at java.base/java.lang.Thread.run(Thread.java:833)} [java] ActSys-err: [java] ActSys-err: ) [java] ActSys-err: javax.net.ssl|ERROR|B2|(JSK) mux reader|2021-08-11 14:56:20.607 AEST|TransportContext.java:363|Fatal (UNEXPECTED_MESSAGE): Socket closed ( [java] ActSys-err: "throwable" : { [java] ActSys-err: java.net.SocketException: Socket closed [java] ActSys-err: at java.base/sun.nio.ch.NioSocketImpl.endRead(NioSocketImpl.java:248) [java] ActSys-err: at java.base/sun.nio.ch.NioSocketImpl.implRead(NioSocketImpl.java:327) [java] ActSys-err: at java.base/sun.nio.ch.NioSocketImpl.read(NioSocketImpl.java:350) [java] ActSys-err: at java.base/sun.nio.ch.NioSocketImpl$1.read(NioSocketImpl.java:803) [java] ActSys-err: at java.base/java.net.Socket$SocketInputStream.read(Socket.java:966) [java] ActSys-err: at java.base/sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:478) [java] ActSys-err: at java.base/sun.security.ssl.SSLSocketInputRecord.readHeader(SSLSocketInputRecord.java:472) [java] ActSys-err: at java.base/sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(SSLSocketInputRecord.java:70) [java] ActSys-err: at java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1455) [java] ActSys-err: at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:1059) [java] ActSys-err: at org.apache.river.jeri.internal.mux.StreamConnectionIO$1.read(StreamConnectionIO.java:372) [java] ActSys-err: at org.apache.river.jeri.internal.mux.StreamConnectionIO$Reader.run(StreamConnectionIO.java:277) [java] ActSys-err: at org.apache.river.thread.ThreadPool$Task.run(ThreadPool.java:172) [java] ActSys-err: at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) [java] ActSys-err: at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) [java] ActSys-err: at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) [java] ActSys-err: at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [java] ActSys-err: at java.base/java.lang.Thread.run(Thread.java:833)} [java] ActSys-err: [java] ActSys-err: ) [java] ActSys-err: javax.net.ssl|ALL|B2|(JSK) mux reader|2021-08-11 14:56:20.609 AEST|SSLSocketImpl.java:1129|Closing input stream [java] ActSys-err: 11 Aug 2021 2:57:02 pm:Group-0:err:WARNING: A terminally deprecated method in java.lang.System has been called [java] ActSys-err: WARNING: System::setSecurityManager has been called by org.apache.river.phoenix.init.ActivationGroupInit (file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/phoenix-init-3.1.1-SNAPSHOT.jar) [java] ActSys-err: WARNING: Please consider reporting this to the maintainers of org.apache.river.phoenix.init.ActivationGroupInit [java] ActSys-err: WARNING: System::setSecurityManager will be removed in a future release [java] ActSys-err: [java] ActSys-err: Aug 11, 2021 2:57:02 PM org.apache.river.phoenix.Activation$GroupEntry getInstantiator [java] ActSys-err: FINE: Group-1 exec [C:\Program Files\Zulu\jdk-17\bin\java, -ea, -esa, -server, -Dorg.apache.river.qa.harness.harnessJar=C:\Users\peter\Documents\NetBeansProjects\JGDMS\qa\lib\jiniharness.jar, -Djsk.iiop.jar=jgdms-iiop-3.1.1-SNAPSHOT.jar, -Doutrigger-snaplogstore.jar=outrigger-snaplogstore-3.1.1-SNAPSHOT.jar, -Dorg.apache.river.jsk.port=9080, -Dcollections.jar=jgdms-collections-3.1.1-SNAPSHOT.jar, -Dsharedvm.jar=service-starter-3.1.1-SNAPSHOT.jar, -Djgdms-rmi-tls.jar=jgdms-rmi-tls-3.1.1-SNAPSHOT.jar, -Djava.protocol.handler.pkgs=net.jini.url, -Dphoenix.jar=phoenix-3.1.1-SNAPSHOT.jar, -Dplatform.jar=jgdms-platform-3.1.1-SNAPSHOT.jar, -Dnorm-dl.jar=norm-dl-3.1.1-SNAPSHOT.jar, -Dorg.apache.river.qa.harness.testJar=C:\Users\peter\Documents\NetBeansProjects\JGDMS\qa\lib\jinitests.jar, -Djava.util.logging.config.file=C:\Users\peter\Documents\NetBeansProjects\JGDMS\qa\src\org\apache\river\test\resources\qa1.logging, -Djsk.pref.jar=jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar, -Dstart.jar=service-starter-3.1.1-SNAPSHOT.jar, -Dphoenix-common.jar=phoenix-common-3.1.1-SNAPSHOT.jar, -Djava.security.properties=file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/harness/trust/dynamic-policy.properties, -Dmercury-dl.jar=mercury-dl-3.1.1-SNAPSHOT.jar, -Dreggie-dl.jar=reggie-dl-3.1.1-SNAPSHOT.jar, -Dloader.jar=jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar, -Dclassserver.jar=classserver-3.1.1-SNAPSHOT.jar, -Djsk-dl.jar=jgdms-lib-dl-3.1.1-SNAPSHOT.jar, -Dorg.apache.river.test.home=C:\Users\peter\Documents\NetBeansProjects\JGDMS\qa, -Dreggie.jar=reggie-service-3.1.1-SNAPSHOT.jar, -Djdk.io.permissionsUseCanonicalPath=true, -Dphoenix-dl.jar=phoenix-dl-3.1.1-SNAPSHOT.jar, -Djsk.home=C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT, -Djeri.jar=jgdms-jeri-3.1.1-SNAPSHOT.jar, -Dhigh-scale-lib.jar=high-scale-lib-1.0.6.jar, -Djava.net.preferIPv6Addresses=true, -DHOST=DESKTOP-R0ORPA2, -Dorg.apache.river.qa.harness.testhosts=, -Dmahalo.jar=mahalo-service-3.1.1-SNAPSHOT.jar, -Djavax.net.ssl.trustStore=harness\trust\truststore, -Dbouncy-jce.jar=bcprov-jdk15on-1.59.jar, -Dorg.apache.river.discovery.x500.trustStore=file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/harness/trust/truststore, -Doutrigger-dl.jar=outrigger-dl-3.1.1-SNAPSHOT.jar, -Ddisco.jar=jgdms-discovery-providers-3.1.1-SNAPSHOT.jar, -Djgdms.version=3.1.1-SNAPSHOT, -Dgroup.jar=group-service-3.1.1-SNAPSHOT.jar, -Djava.security.policy=file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/harness/policy/defaultsecuresharedvm.policy, -Dorg.apache.river.qa.harness.runjiniserver=true, -Dactivation-param.jar=jgdms-activation-parameters-3.1.1-SNAPSHOT.jar, -Dactivation.jar=jgdms-activation-3.1.1-SNAPSHOT.jar, -Dorg.apache.river.qa.harness.policies=file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/src/org/apache/river/test/resources/jinitest.policy, -Dsun.net.maxDatagramSockets=1024, -Dnorm.jar=norm-service-3.1.1-SNAPSHOT.jar, -Dmercury.jar=mercury-service-3.1.1-SNAPSHOT.jar, -Djsk.url.jar=jgdms-url-integrity-3.1.1-SNAPSHOT.jar, -Djsk-lib.jar=jgdms-lib-3.1.1-SNAPSHOT.jar, -Dfiddler.jar=fiddler-service-3.1.1-SNAPSHOT.jar, -Dbouncy-jsse.jar=bctls-jdk15on-1.59.jar, -Dnet.jini.core.lookup.ServiceRegistrar.portAbitraryIfInUse=true, -Djavax.net.debug=ssl:handshake, -Dorg.apache.river.discovery.x500.trustStorePassword=trustpw, -Dphoenix-group.jar=phoenix-group-3.1.1-SNAPSHOT.jar, -Dnet.jini.security.allowInsecureConnections=true, -Dorg.apache.river.test.port=9082, -Dorg.apache.river.qa.harness.runkitserver=true, -Djava.security.auth.login.config=file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/harness/trust/jsselogins, -Dfiddler-dl.jar=fiddler-dl-3.1.1-SNAPSHOT.jar, -Dmahalo-dl.jar=mahalo-dl-3.1.1-SNAPSHOT.jar, -Dorg.apache.river.qa.port=9081, -Dphoenix-init.jar=phoenix-init-3.1.1-SNAPSHOT.jar, -Doutrigger.jar=outrigger-service-3.1.1-SNAPSHOT.jar, -Djavax.net.ssl.trustStorePassword=trustpw, -Ddestroy.jar=jgdms-destroy-3.1.1-SNAPSHOT.jar, -Dqa.home=C:\Users\peter\Documents\NetBeansProjects\JGDMS\qa, -cp, C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\service-starter-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-collections-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\high-scale-lib-1.0.6.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\phoenix-init-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-platform-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib-dl\jgdms-lib-dl-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-lib-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-discovery-providers-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-jeri-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\phoenix-group-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib-dl\phoenix-dl-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\phoenix-common-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-activation-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-activation-parameters-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-url-integrity-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\bcprov-jdk15on-1.59.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\bctls-jdk15on-1.59.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\security-policy-debug-3.1.1-SNAPSHOT.jar, org.apache.river.phoenix.init.ActivationGroupInit] [java] ActSys-err: javax.net.ssl|WARNING|F1|(JSK) mux request dispatch|2021-08-11 14:57:03.067 AEST|ServerNameExtension.java:266|Unable to indicate server name [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request dispatch|2021-08-11 14:57:03.067 AEST|SSLExtensions.java:272|Ignore, context unavailable extension: server_name [java] ActSys-err: javax.net.ssl|INFO|F1|(JSK) mux request dispatch|2021-08-11 14:57:03.068 AEST|AlpnExtension.java:182|No available application protocols [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request dispatch|2021-08-11 14:57:03.068 AEST|SSLExtensions.java:272|Ignore, context unavailable extension: application_layer_protocol_negotiation [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request dispatch|2021-08-11 14:57:03.068 AEST|SessionTicketExtension.java:408|Stateless resumption supported [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request dispatch|2021-08-11 14:57:03.070 AEST|SSLExtensions.java:272|Ignore, context unavailable extension: cookie [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request dispatch|2021-08-11 14:57:03.075 AEST|PreSharedKeyExtension.java:662|No session to resume. [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request dispatch|2021-08-11 14:57:03.075 AEST|SSLExtensions.java:272|Ignore, context unavailable extension: pre_shared_key [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request dispatch|2021-08-11 14:57:03.077 AEST|ClientHello From johnsjiang at tencent.com Wed Aug 11 09:22:40 2021 From: johnsjiang at tencent.com (=?iso-2022-jp?B?am9obnNqaWFuZygbJEI5Pmg1GyhCKQ==?=) Date: Wed, 11 Aug 2021 09:22:40 +0000 Subject: JDK17 - Possible TLS issue. References: <973c1457-c24d-6a9e-8979-9cabba0a164e@zeus.net.au> Message-ID: <9c8b95163e9b486886dcd8ca04a62e78@tencent.com> + security-dev Hi Peter, It looks both of file 1 and 5 contain that close_notify warning alert. This point may be related to JDK-8208526: TLS 1.3 half-close and synchronization issues [1]. [1] https://bugs.openjdk.java.net/browse/JDK-8208526 Best regards, John Jiang At 2021/8/11 PM 4:14, Peter Firmstone wrote: > I'm testing on JDK17, having some issues communicating using TLS between > processes. > > With TLS disabled, the test passes on JDK17. > > The test passes using TLS on JDK 16 and earlier JDK versions. > > I've enabled TLS handshake debug on the output > > 1. https://github.com/pfirmstone/JGDMS/blob/trunk/qa/LookupNegMatches-jdk16-tls-handshake-debug.txt > 2. https://github.com/pfirmstone/JGDMS/blob/trunk/qa/LookupNegMatches-jdk16.txt > 3. https://github.com/pfirmstone/JGDMS/blob/trunk/qa/LookupNegMatches-jdk17-TLS-disabled.txt > 4. https://github.com/pfirmstone/JGDMS/blob/trunk/qa/LookupNegMatches-jdk17-tls-handshake-debug.txt > 5. https://github.com/pfirmstone/JGDMS/blob/trunk/qa/LookupNegMatches-jdk17-TLS-handshake-debug2.txt > > There are 5 JVM instances created during this integration test and these > JVM's are communicating using network connections. I have checked that > all JVM processes are running, it seems to be a communication issue. > > Using diff to compare files 1 and 5 above, it appears to be related to a > close notify in JDK17, on the (JSK) connection . > > Any suggestions? > > Thanks, > > Peter. > > [java] ActSys-err: javax.net.ssl|DEBUG|D2|(JSK) mux reader|2021-08-11 14:56:20.606 AEST|SSLSocketImpl.java:1775|close the SSL connection (passive) > [java] ActSys-err: javax.net.ssl|DEBUG|C2|(JSK) mux writer|2021-08-11 14:56:20.606 AEST|SSLSocketImpl.java:572|duplex close of SSLSocket > [java] ActSys-err: javax.net.ssl|ALL|D2|(JSK) mux reader|2021-08-11 14:56:20.606 AEST|SSLSocketImpl.java:1129|Closing input stream > [java] ActSys-err: javax.net.ssl|WARNING|B2|(JSK) mux reader|2021-08-11 14:56:20.607 AEST|SSLSocketImpl.java:1666|handling exception ( > [java] ActSys-err: "throwable" : { > [java] ActSys-err: java.net.SocketException: Socket closed > [java] ActSys-err: at java.base/sun.nio.ch.NioSocketImpl.endRead(NioSocketImpl.java:248) > [java] ActSys-err: at java.base/sun.nio.ch.NioSocketImpl.implRead(NioSocketImpl.java:327) > [java] ActSys-err: at java.base/sun.nio.ch.NioSocketImpl.read(NioSocketImpl.java:350) > [java] ActSys-err: at java.base/sun.nio.ch.NioSocketImpl$1.read(NioSocketImpl.java:803) > [java] ActSys-err: at java.base/java.net.Socket$SocketInputStream.read(Socket.java:966) > [java] ActSys-err: at java.base/sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:478) > [java] ActSys-err: at java.base/sun.security.ssl.SSLSocketInputRecord.readHeader(SSLSocketInputRecord.java:472) > [java] ActSys-err: at java.base/sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(SSLSocketInputRecord.java:70) > [java] ActSys-err: at java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1455) > [java] ActSys-err: at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:1059) > [java] ActSys-err: at org.apache.river.jeri.internal.mux.StreamConnectionIO$1.read(StreamConnectionIO.java:372) > [java] ActSys-err: at org.apache.river.jeri.internal.mux.StreamConnectionIO$Reader.run(StreamConnectionIO.java:277) > [java] ActSys-err: at org.apache.river.thread.ThreadPool$Task.run(ThreadPool.java:172) > [java] ActSys-err: at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) > [java] ActSys-err: at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > [java] ActSys-err: at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) > [java] ActSys-err: at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) > [java] ActSys-err: at java.base/java.lang.Thread.run(Thread.java:833)} > [java] ActSys-err: > [java] ActSys-err: ) > [java] ActSys-err: javax.net.ssl|ERROR|B2|(JSK) mux reader|2021-08-11 14:56:20.607 AEST|TransportContext.java:363|Fatal (UNEXPECTED_MESSAGE): Socket closed ( > [java] ActSys-err: "throwable" : { > [java] ActSys-err: java.net.SocketException: Socket closed > [java] ActSys-err: at java.base/sun.nio.ch.NioSocketImpl.endRead(NioSocketImpl.java:248) > [java] ActSys-err: at java.base/sun.nio.ch.NioSocketImpl.implRead(NioSocketImpl.java:327) > [java] ActSys-err: at java.base/sun.nio.ch.NioSocketImpl.read(NioSocketImpl.java:350) > [java] ActSys-err: at java.base/sun.nio.ch.NioSocketImpl$1.read(NioSocketImpl.java:803) > [java] ActSys-err: at java.base/java.net.Socket$SocketInputStream.read(Socket.java:966) > [java] ActSys-err: at java.base/sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:478) > [java] ActSys-err: at java.base/sun.security.ssl.SSLSocketInputRecord.readHeader(SSLSocketInputRecord.java:472) > [java] ActSys-err: at java.base/sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(SSLSocketInputRecord.java:70) > [java] ActSys-err: at java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1455) > [java] ActSys-err: at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:1059) > [java] ActSys-err: at org.apache.river.jeri.internal.mux.StreamConnectionIO$1.read(StreamConnectionIO.java:372) > [java] ActSys-err: at org.apache.river.jeri.internal.mux.StreamConnectionIO$Reader.run(StreamConnectionIO.java:277) > [java] ActSys-err: at org.apache.river.thread.ThreadPool$Task.run(ThreadPool.java:172) > [java] ActSys-err: at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) > [java] ActSys-err: at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > [java] ActSys-err: at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) > [java] ActSys-err: at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) > [java] ActSys-err: at java.base/java.lang.Thread.run(Thread.java:833)} > [java] ActSys-err: > [java] ActSys-err: ) > [java] ActSys-err: javax.net.ssl|ALL|B2|(JSK) mux reader|2021-08-11 14:56:20.609 AEST|SSLSocketImpl.java:1129|Closing input stream > [java] ActSys-err: 11 Aug 2021 2:57:02 pm:Group-0:err:WARNING: A terminally deprecated method in java.lang.System has been called > [java] ActSys-err: WARNING: System::setSecurityManager has been called by org.apache.river.phoenix.init.ActivationGroupInit (file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/phoenix-init-3.1.1-SNAPSHOT.jar) > [java] ActSys-err: WARNING: Please consider reporting this to the maintainers of org.apache.river.phoenix.init.ActivationGroupInit > [java] ActSys-err: WARNING: System::setSecurityManager will be removed in a future release > [java] ActSys-err: > [java] ActSys-err: Aug 11, 2021 2:57:02 PM org.apache.river.phoenix.Activation$GroupEntry getInstantiator > [java] ActSys-err: FINE: Group-1 exec [C:\Program Files\Zulu\jdk-17\bin\java, -ea, -esa, -server, -Dorg.apache.river.qa.harness.harnessJar=C:\Users\peter\Documents\NetBeansProjects\JGDMS\qa\lib\jiniharness.jar, -Djsk.iiop.jar=jgdms-iiop-3.1.1-SNAPSHOT.jar, -Doutrigger-snaplogstore.jar=outrigger-snaplogstore-3.1.1-SNAPSHOT.jar, -Dorg.apache.river.jsk.port=9080, -Dcollections.jar=jgdms-collections-3.1.1-SNAPSHOT.jar, -Dsharedvm.jar=service-starter-3.1.1-SNAPSHOT.jar, -Djgdms-rmi-tls.jar=jgdms-rmi-tls-3.1.1-SNAPSHOT.jar, -Djava.protocol.handler.pkgs=net.jini.url, -Dphoenix.jar=phoenix-3.1.1-SNAPSHOT.jar, -Dplatform.jar=jgdms-platform-3.1.1-SNAPSHOT.jar, -Dnorm-dl.jar=norm-dl-3.1.1-SNAPSHOT.jar, -Dorg.apache.river.qa.harness.testJar=C:\Users\peter\Documents\NetBeansProjects\JGDMS\qa\lib\jinitests.jar, -Djava.util.logging.config.file=C:\Users\peter\Documents\NetBeansProjects\JGDMS\qa\src\org\apache\river\test\resources\qa1.logging, -Djsk.pref.jar=jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar, -Dstart.jar=service-starter-3.1.1-SNAPSHOT.jar, -Dphoenix-common.jar=phoenix-common-3.1.1-SNAPSHOT.jar, -Djava.security.properties=file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/harness/trust/dynamic-policy.properties, -Dmercury-dl.jar=mercury-dl-3.1.1-SNAPSHOT.jar, -Dreggie-dl.jar=reggie-dl-3.1.1-SNAPSHOT.jar, -Dloader.jar=jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar, -Dclassserver.jar=classserver-3.1.1-SNAPSHOT.jar, -Djsk-dl.jar=jgdms-lib-dl-3.1.1-SNAPSHOT.jar, -Dorg.apache.river.test.home=C:\Users\peter\Documents\NetBeansProjects\JGDMS\qa, -Dreggie.jar=reggie-service-3.1.1-SNAPSHOT.jar, -Djdk.io.permissionsUseCanonicalPath=true, -Dphoenix-dl.jar=phoenix-dl-3.1.1-SNAPSHOT.jar, -Djsk.home=C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT, -Djeri.jar=jgdms-jeri-3.1.1-SNAPSHOT.jar, -Dhigh-scale-lib.jar=high-scale-lib-1.0.6.jar, -Djava.net.preferIPv6Addresses=true, -DHOST=DESKTOP-R0ORPA2, -Dorg.apache.river.qa.harness.testhosts=, -Dmahalo.jar=mahalo-service-3.1.1-SNAPSHOT.jar, -Djavax.net.ssl.trustStore=harness\trust\truststore, -Dbouncy-jce.jar=bcprov-jdk15on-1.59.jar, -Dorg.apache.river.discovery.x500.trustStore=file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/harness/trust/truststore, -Doutrigger-dl.jar=outrigger-dl-3.1.1-SNAPSHOT.jar, -Ddisco.jar=jgdms-discovery-providers-3.1.1-SNAPSHOT.jar, -Djgdms.version=3.1.1-SNAPSHOT, -Dgroup.jar=group-service-3.1.1-SNAPSHOT.jar, -Djava.security.policy=file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/harness/policy/defaultsecuresharedvm.policy, -Dorg.apache.river.qa.harness.runjiniserver=true, -Dactivation-param.jar=jgdms-activation-parameters-3.1.1-SNAPSHOT.jar, -Dactivation.jar=jgdms-activation-3.1.1-SNAPSHOT.jar, -Dorg.apache.river.qa.harness.policies=file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/src/org/apache/river/test/resources/jinitest.policy, -Dsun.net.maxDatagramSockets=1024, -Dnorm.jar=norm-service-3.1.1-SNAPSHOT.jar, -Dmercury.jar=mercury-service-3.1.1-SNAPSHOT.jar, -Djsk.url.jar=jgdms-url-integrity-3.1.1-SNAPSHOT.jar, -Djsk-lib.jar=jgdms-lib-3.1.1-SNAPSHOT.jar, -Dfiddler.jar=fiddler-service-3.1.1-SNAPSHOT.jar, -Dbouncy-jsse.jar=bctls-jdk15on-1.59.jar, -Dnet.jini.core.lookup.ServiceRegistrar.portAbitraryIfInUse=true, -Djavax.net.debug=ssl:handshake, -Dorg.apache.river.discovery.x500.trustStorePassword=trustpw, -Dphoenix-group.jar=phoenix-group-3.1.1-SNAPSHOT.jar, -Dnet.jini.security.allowInsecureConnections=true, -Dorg.apache.river.test.port=9082, -Dorg.apache.river.qa.harness.runkitserver=true, -Djava.security.auth.login.config=file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/harness/trust/jsselogins, -Dfiddler-dl.jar=fiddler-dl-3.1.1-SNAPSHOT.jar, -Dmahalo-dl.jar=mahalo-dl-3.1.1-SNAPSHOT.jar, -Dorg.apache.river.qa.port=9081, -Dphoenix-init.jar=phoenix-init-3.1.1-SNAPSHOT.jar, -Doutrigger.jar=outrigger-service-3.1.1-SNAPSHOT.jar, -Djavax.net.ssl.trustStorePassword=trustpw, -Ddestroy.jar=jgdms-destroy-3.1.1-SNAPSHOT.jar, -Dqa.home=C:\Users\peter\Documents\NetBeansProjects\JGDMS\qa, -cp, C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\service-starter-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-collections-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\high-scale-lib-1.0.6.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\phoenix-init-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-platform-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib-dl\jgdms-lib-dl-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-lib-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-discovery-providers-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-jeri-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\phoenix-group-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib-dl\phoenix-dl-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\phoenix-common-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-activation-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-activation-parameters-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-url-integrity-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\bcprov-jdk15on-1.59.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\bctls-jdk15on-1.59.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\security-policy-debug-3.1.1-SNAPSHOT.jar, org.apache.river.phoenix.init.ActivationGroupInit] > [java] ActSys-err: javax.net.ssl|WARNING|F1|(JSK) mux request dispatch|2021-08-11 14:57:03.067 AEST|ServerNameExtension.java:266|Unable to indicate server name > [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request dispatch|2021-08-11 14:57:03.067 AEST|SSLExtensions.java:272|Ignore, context unavailable extension: server_name > [java] ActSys-err: javax.net.ssl|INFO|F1|(JSK) mux request dispatch|2021-08-11 14:57:03.068 AEST|AlpnExtension.java:182|No available application protocols > [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request dispatch|2021-08-11 14:57:03.068 AEST|SSLExtensions.java:272|Ignore, context unavailable extension: application_layer_protocol_negotiation > [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request dispatch|2021-08-11 14:57:03.068 AEST|SessionTicketExtension.java:408|Stateless resumption supported > [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request dispatch|2021-08-11 14:57:03.070 AEST|SSLExtensions.java:272|Ignore, context unavailable extension: cookie > [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request dispatch|2021-08-11 14:57:03.075 AEST|PreSharedKeyExtension.java:662|No session to resume. > [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request dispatch|2021-08-11 14:57:03.075 AEST|SSLExtensions.java:272|Ignore, context unavailable extension: pre_shared_key > [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request dispatch|2021-08-11 14:57:03.077 AEST|ClientHello > > > From peter.firmstone at zeus.net.au Wed Aug 11 10:12:54 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Wed, 11 Aug 2021 20:12:54 +1000 Subject: JDK17 - Possible TLS issue. In-Reply-To: <9c8b95163e9b486886dcd8ca04a62e78@tencent.com> References: <973c1457-c24d-6a9e-8979-9cabba0a164e@zeus.net.au> <9c8b95163e9b486886dcd8ca04a62e78@tencent.com> Message-ID: ??johnsjiang(??)? I set the property: -Djdk.tls.acknowledgeCloseNotify=true. Unfortunately the test is still failing on JDK17, although the output has changed and acknowledges the duplex close, so it appears something else is causing the connection to close early. Interestingly, there is a WARNING that the socket didn't close, followed by an ERROR, then FATAL(UNEXPECTED MESSAGE). ???????Peter. https://github.com/pfirmstone/JGDMS/blob/trunk/qa/LookupNegMatches-jdk17-TLS-handshake-debug-ack-close-notify-true.txt ???? [java] ActSys-err: javax.net.ssl|DEBUG|92|(JSK) ConnectionManager.Reaper|2021-08-11 19:41:49.598 AEST|SSLSocketImpl.java:572|duplex close of SSLSocket ???? [java] ActSys-err: javax.net.ssl|DEBUG|D2|(JSK) mux reader|2021-08-11 19:41:49.599 AEST|Alert.java:238|Received alert message ( ???? [java] ActSys-err: "Alert": { ???? [java] ActSys-err:?? "level"????? : "warning", ???? [java] ActSys-err:?? "description": "user_canceled" ???? [java] ActSys-err: } ???? [java] ActSys-err: ) ???? [java] ActSys-err: javax.net.ssl|DEBUG|92|(JSK) ConnectionManager.Reaper|2021-08-11 19:41:49.599 AEST|SSLSocketImpl.java:1775|close the SSL connection (passive) ???? [java] ActSys-err: javax.net.ssl|DEBUG|D2|(JSK) mux reader|2021-08-11 19:41:49.599 AEST|Alert.java:238|Received alert message ( ???? [java] ActSys-err: "Alert": { ???? [java] ActSys-err:?? "level"????? : "warning", ???? [java] ActSys-err:?? "description": "close_notify" ???? [java] ActSys-err: } ???? [java] ActSys-err: ) ???? [java] ActSys-err: javax.net.ssl|ALL|A2|(JSK) mux writer|2021-08-11 19:41:49.599 AEST|SSLSocketImpl.java:1324|Closing output stream ???? [java] ActSys-err: javax.net.ssl|DEBUG|D2|(JSK) mux reader|2021-08-11 19:41:49.600 AEST|SSLSocketImpl.java:572|duplex close of SSLSocket ???? [java] ActSys-err: javax.net.ssl|ALL|C2|(JSK) mux writer|2021-08-11 19:41:49.600 AEST|SSLSocketImpl.java:1324|Closing output stream ???? [java] ActSys-err: javax.net.ssl|DEBUG|D2|(JSK) mux reader|2021-08-11 19:41:49.600 AEST|SSLSocketImpl.java:1775|close the SSL connection (passive) ???? [java] ActSys-err: javax.net.ssl|DEBUG|C2|(JSK) mux writer|2021-08-11 19:41:49.600 AEST|SSLSocketImpl.java:572|duplex close of SSLSocket ???? [java] ActSys-err: javax.net.ssl|DEBUG|C2|(JSK) mux writer|2021-08-11 19:41:49.600 AEST|SSLSocketImpl.java:1775|close the SSL connection (passive) ???? [java] ActSys-err: javax.net.ssl|ALL|D2|(JSK) mux reader|2021-08-11 19:41:49.600 AEST|SSLSocketImpl.java:1129|Closing input stream ???? [java] ActSys-err: javax.net.ssl|WARNING|C2|(JSK) mux writer|2021-08-11 19:41:49.602 AEST|SSLSocketImpl.java:600|SSLSocket close failed. Debug info only. Exception details: ( ???? [java] ActSys-err: "throwable" : { ???? [java] ActSys-err:?? java.net.SocketException: Socket closed ???? [java] ActSys-err:?? ??? at java.base/sun.nio.ch.NioSocketImpl.ensureOpenAndConnected(NioSocketImpl.java:165) ???? [java] ActSys-err:?? ??? at java.base/sun.nio.ch.NioSocketImpl.available(NioSocketImpl.java:838) ???? [java] ActSys-err:?? ??? at java.base/sun.nio.ch.NioSocketImpl$1.available(NioSocketImpl.java:807) ???? [java] ActSys-err:?? ??? at java.base/java.net.Socket$SocketInputStream.available(Socket.java:970) ???? [java] ActSys-err:?? ??? at java.base/sun.security.ssl.SSLSocketInputRecord.deplete(SSLSocketInputRecord.java:495) ???? [java] ActSys-err:?? ??? at java.base/sun.security.ssl.SSLSocketImpl.closeSocket(SSLSocketImpl.java:1785) ???? [java] ActSys-err:?? ??? at java.base/sun.security.ssl.SSLSocketImpl.close(SSLSocketImpl.java:596) ???? [java] ActSys-err:?? ??? at java.base/sun.security.ssl.SSLSocketImpl$AppOutputStream.close(SSLSocketImpl.java:1328) ???? [java] ActSys-err:?? ??? at org.apache.river.jeri.internal.mux.StreamConnectionIO$2.close(StreamConnectionIO.java:427) ???? [java] ActSys-err:?? ??? at org.apache.river.jeri.internal.mux.StreamConnectionIO$Writer.run(StreamConnectionIO.java:250) ???? [java] ActSys-err:?? ??? at org.apache.river.thread.ThreadPool$Task.run(ThreadPool.java:172) ???? [java] ActSys-err:?? ??? at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) ???? [java] ActSys-err:?? ??? at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) ???? [java] ActSys-err:?? ??? at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) ???? [java] ActSys-err:?? ??? at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ???? [java] ActSys-err:?? ??? at java.base/java.lang.Thread.run(Thread.java:833)} ???? [java] ActSys-err: ???? [java] ActSys-err: ) ???? [java] ActSys-err: javax.net.ssl|WARNING|B2|(JSK) mux reader|2021-08-11 19:41:49.602 AEST|SSLSocketImpl.java:1666|handling exception ( ???? [java] ActSys-err: "throwable" : { ???? [java] ActSys-err:?? java.net.SocketException: Socket closed ???? [java] ActSys-err:?? ??? at java.base/sun.nio.ch.NioSocketImpl.endRead(NioSocketImpl.java:248) ???? [java] ActSys-err:?? ??? at java.base/sun.nio.ch.NioSocketImpl.implRead(NioSocketImpl.java:327) ???? [java] ActSys-err:?? ??? at java.base/sun.nio.ch.NioSocketImpl.read(NioSocketImpl.java:350) ???? [java] ActSys-err:?? ??? at java.base/sun.nio.ch.NioSocketImpl$1.read(NioSocketImpl.java:803) ???? [java] ActSys-err:?? ??? at java.base/java.net.Socket$SocketInputStream.read(Socket.java:966) ???? [java] ActSys-err:?? ??? at java.base/sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:478) ???? [java] ActSys-err:?? ??? at java.base/sun.security.ssl.SSLSocketInputRecord.readHeader(SSLSocketInputRecord.java:472) ???? [java] ActSys-err:?? ??? at java.base/sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(SSLSocketInputRecord.java:70) ???? [java] ActSys-err:?? ??? at java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1455) ???? [java] ActSys-err:?? ??? at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:1059) ???? [java] ActSys-err:?? ??? at org.apache.river.jeri.internal.mux.StreamConnectionIO$1.read(StreamConnectionIO.java:372) ???? [java] ActSys-err:?? ??? at org.apache.river.jeri.internal.mux.StreamConnectionIO$Reader.run(StreamConnectionIO.java:277) ???? [java] ActSys-err:?? ??? at org.apache.river.thread.ThreadPool$Task.run(ThreadPool.java:172) ???? [java] ActSys-err:?? ??? at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) ???? [java] ActSys-err:?? ??? at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) ???? [java] ActSys-err:?? ??? at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) ???? [java] ActSys-err:?? ??? at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ???? [java] ActSys-err:?? ??? at java.base/java.lang.Thread.run(Thread.java:833)} ???? [java] ActSys-err: ???? [java] ActSys-err: ) ???? [java] ActSys-err: javax.net.ssl|ERROR|B2|(JSK) mux reader|2021-08-11 19:41:49.602 AEST|TransportContext.java:363|Fatal (UNEXPECTED_MESSAGE): Socket closed ( ???? [java] ActSys-err: "throwable" : { ???? [java] ActSys-err:?? java.net.SocketException: Socket closed ???? [java] ActSys-err:?? ??? at java.base/sun.nio.ch.NioSocketImpl.endRead(NioSocketImpl.java:248) ???? [java] ActSys-err:?? ??? at java.base/sun.nio.ch.NioSocketImpl.implRead(NioSocketImpl.java:327) ???? [java] ActSys-err:?? ??? at java.base/sun.nio.ch.NioSocketImpl.read(NioSocketImpl.java:350) ???? [java] ActSys-err:?? ??? at java.base/sun.nio.ch.NioSocketImpl$1.read(NioSocketImpl.java:803) ???? [java] ActSys-err:?? ??? at java.base/java.net.Socket$SocketInputStream.read(Socket.java:966) ???? [java] ActSys-err:?? ??? at java.base/sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:478) ???? [java] ActSys-err:?? ??? at java.base/sun.security.ssl.SSLSocketInputRecord.readHeader(SSLSocketInputRecord.java:472) ???? [java] ActSys-err:?? ??? at java.base/sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(SSLSocketInputRecord.java:70) ???? [java] ActSys-err:?? ??? at java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1455) ???? [java] ActSys-err:?? ??? at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:1059) ???? [java] ActSys-err:?? ??? at org.apache.river.jeri.internal.mux.StreamConnectionIO$1.read(StreamConnectionIO.java:372) ???? [java] ActSys-err:?? ??? at org.apache.river.jeri.internal.mux.StreamConnectionIO$Reader.run(StreamConnectionIO.java:277) ???? [java] ActSys-err:?? ??? at org.apache.river.thread.ThreadPool$Task.run(ThreadPool.java:172) ???? [java] ActSys-err:?? ??? at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) ???? [java] ActSys-err:?? ??? at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) ???? [java] ActSys-err:?? ??? at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) ???? [java] ActSys-err:?? ??? at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ???? [java] ActSys-err:?? ??? at java.base/java.lang.Thread.run(Thread.java:833)} ???? [java] ActSys-err: ???? [java] ActSys-err: ) ???? [java] ActSys-err: javax.net.ssl|ALL|B2|(JSK) mux reader|2021-08-11 19:41:49.603 AEST|SSLSocketImpl.java:1129|Closing input stream ???? [java] ActSys-err: 11 Aug 2021 7:42:31 pm:Group-0:err:WARNING: A terminally deprecated method in java.lang.System has been called ???? [java] ActSys-err: WARNING: System::setSecurityManager has been called by org.apache.river.phoenix.init.ActivationGroupInit (file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/phoenix-init-3.1.1-SNAPSHOT.jar) ???? [java] ActSys-err: WARNING: Please consider reporting this to the maintainers of org.apache.river.phoenix.init.ActivationGroupInit ???? [java] ActSys-err: WARNING: System::setSecurityManager will be removed in a future release ???? [java] ActSys-err: ???? [java] ActSys-err: Aug 11, 2021 7:42:31 PM org.apache.river.phoenix.Activation$GroupEntry getInstantiator ???? [java] ActSys-err: FINE: Group-1 exec [C:\Program Files\Zulu\jdk-17\bin\java, -ea, -esa, -server, -Dorg.apache.river.qa.harness.harnessJar=C:\Users\peter\Documents\NetBeansProjects\JGDMS\qa\lib\jiniharness.jar, -Djsk.iiop.jar=jgdms-iiop-3.1.1-SNAPSHOT.jar, -Doutrigger-snaplogstore.jar=outrigger-snaplogstore-3.1.1-SNAPSHOT.jar, -Dorg.apache.river.jsk.port=9080, -Dcollections.jar=jgdms-collections-3.1.1-SNAPSHOT.jar, -Dsharedvm.jar=service-starter-3.1.1-SNAPSHOT.jar, -Djgdms-rmi-tls.jar=jgdms-rmi-tls-3.1.1-SNAPSHOT.jar, -Djdk.tls.acknowledgeCloseNotify=true, -Djava.protocol.handler.pkgs=net.jini.url, -Dphoenix.jar=phoenix-3.1.1-SNAPSHOT.jar, -Dplatform.jar=jgdms-platform-3.1.1-SNAPSHOT.jar, -Dnorm-dl.jar=norm-dl-3.1.1-SNAPSHOT.jar, -Dorg.apache.river.qa.harness.testJar=C:\Users\peter\Documents\NetBeansProjects\JGDMS\qa\lib\jinitests.jar, -Djava.util.logging.config.file=C:\Users\peter\Documents\NetBeansProjects\JGDMS\qa\src\org\apache\river\test\resources\qa1.logging, -Djsk.pref.jar=jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar, -Dstart.jar=service-starter-3.1.1-SNAPSHOT.jar, -Dphoenix-common.jar=phoenix-common-3.1.1-SNAPSHOT.jar, -Djava.security.properties=file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/harness/trust/dynamic-policy.properties, -Dmercury-dl.jar=mercury-dl-3.1.1-SNAPSHOT.jar, -Dreggie-dl.jar=reggie-dl-3.1.1-SNAPSHOT.jar, -Dloader.jar=jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar, -Dclassserver.jar=classserver-3.1.1-SNAPSHOT.jar, -Djsk-dl.jar=jgdms-lib-dl-3.1.1-SNAPSHOT.jar, -Dorg.apache.river.test.home=C:\Users\peter\Documents\NetBeansProjects\JGDMS\qa, -Dreggie.jar=reggie-service-3.1.1-SNAPSHOT.jar, -Djdk.io.permissionsUseCanonicalPath=true, -Dphoenix-dl.jar=phoenix-dl-3.1.1-SNAPSHOT.jar, -Djsk.home=C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT, -Djeri.jar=jgdms-jeri-3.1.1-SNAPSHOT.jar, -Dhigh-scale-lib.jar=high-scale-lib-1.0.6.jar, -Djava.net.preferIPv6Addresses=true, -DHOST=DESKTOP-R0ORPA2, -Dorg.apache.river.qa.harness.testhosts=, -Dmahalo.jar=mahalo-service-3.1.1-SNAPSHOT.jar, -Djavax.net.ssl.trustStore=harness\trust\truststore, -Dbouncy-jce.jar=bcprov-jdk15on-1.59.jar, -Dorg.apache.river.discovery.x500.trustStore=file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/harness/trust/truststore, -Doutrigger-dl.jar=outrigger-dl-3.1.1-SNAPSHOT.jar, -Ddisco.jar=jgdms-discovery-providers-3.1.1-SNAPSHOT.jar, -Djgdms.version=3.1.1-SNAPSHOT, -Dgroup.jar=group-service-3.1.1-SNAPSHOT.jar, -Djava.security.policy=file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/harness/policy/defaultsecuresharedvm.policy, -Dorg.apache.river.qa.harness.runjiniserver=true, -Dactivation-param.jar=jgdms-activation-parameters-3.1.1-SNAPSHOT.jar, -Dactivation.jar=jgdms-activation-3.1.1-SNAPSHOT.jar, -Dorg.apache.river.qa.harness.policies=file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/src/org/apache/river/test/resources/jinitest.policy, -Dsun.net.maxDatagramSockets=1024, -Dnorm.jar=norm-service-3.1.1-SNAPSHOT.jar, -Dmercury.jar=mercury-service-3.1.1-SNAPSHOT.jar, -Djsk.url.jar=jgdms-url-integrity-3.1.1-SNAPSHOT.jar, -Djsk-lib.jar=jgdms-lib-3.1.1-SNAPSHOT.jar, -Dfiddler.jar=fiddler-service-3.1.1-SNAPSHOT.jar, -Dbouncy-jsse.jar=bctls-jdk15on-1.59.jar, -Dnet.jini.core.lookup.ServiceRegistrar.portAbitraryIfInUse=true, -Djavax.net.debug=ssl:handshake, -Dorg.apache.river.discovery.x500.trustStorePassword=trustpw, -Dphoenix-group.jar=phoenix-group-3.1.1-SNAPSHOT.jar, -Dnet.jini.security.allowInsecureConnections=true, -Dorg.apache.river.test.port=9082, -Dorg.apache.river.qa.harness.runkitserver=true, -Djava.security.auth.login.config=file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/harness/trust/jsselogins, -Dfiddler-dl.jar=fiddler-dl-3.1.1-SNAPSHOT.jar, -Dmahalo-dl.jar=mahalo-dl-3.1.1-SNAPSHOT.jar, -Dorg.apache.river.qa.port=9081, -Dphoenix-init.jar=phoenix-init-3.1.1-SNAPSHOT.jar, -Doutrigger.jar=outrigger-service-3.1.1-SNAPSHOT.jar, -Djavax.net.ssl.trustStorePassword=trustpw, -Ddestroy.jar=jgdms-destroy-3.1.1-SNAPSHOT.jar, -Dqa.home=C:\Users\peter\Documents\NetBeansProjects\JGDMS\qa, -cp, C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\service-starter-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-collections-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\high-scale-lib-1.0.6.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\phoenix-init-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-platform-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib-dl\jgdms-lib-dl-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-lib-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-discovery-providers-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-jeri-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\phoenix-group-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib-dl\phoenix-dl-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\phoenix-common-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-activation-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-activation-parameters-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-url-integrity-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\bcprov-jdk15on-1.59.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\bctls-jdk15on-1.59.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\security-policy-debug-3.1.1-SNAPSHOT.jar, org.apache.river.phoenix.init.ActivationGroupInit] ???? [java] ActSys-err: javax.net.ssl|WARNING|F1|(JSK) mux request dispatch|2021-08-11 19:42:32.033 AEST|ServerNameExtension.java:266|Unable to indicate server name ???? [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request dispatch|2021-08-11 19:42:32.033 AEST|SSLExtensions.java:272|Ignore, context unavailable extension: server_name ???? [java] ActSys-err: javax.net.ssl|INFO|F1|(JSK) mux request dispatch|2021-08-11 19:42:32.034 AEST|AlpnExtension.java:182|No available application protocols ???? [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request dispatch|2021-08-11 19:42:32.034 AEST|SSLExtensions.java:272|Ignore, context unavailable extension: application_layer_protocol_negotiation ???? [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request dispatch|2021-08-11 19:42:32.034 AEST|SessionTicketExtension.java:408|Stateless resumption supported ???? [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request dispatch|2021-08-11 19:42:32.035 AEST|SSLExtensions.java:272|Ignore, context unavailable extension: cookie ???? [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request dispatch|2021-08-11 19:42:32.041 AEST|PreSharedKeyExtension.java:662|No session to resume. ???? [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request dispatch|2021-08-11 19:42:32.041 AEST|SSLExtensions.java:272|Ignore, context unavailable extension: pre_shared_key ???? [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request dispatch|2021-08-11 19:42:32.044 AEST|ClientHello.java:652|Produced ClientHello handsha On 11/08/2021 7:22 pm, johnsjiang(??) wrote: > + security-dev > > Hi Peter, > It looks both of file 1 and 5 contain that close_notify warning alert. > This point may be related to JDK-8208526: TLS 1.3 half-close and synchronization issues [1]. > > [1] https://bugs.openjdk.java.net/browse/JDK-8208526 > > Best regards, > John Jiang > > At 2021/8/11 PM 4:14, Peter Firmstone wrote: >> I'm testing on JDK17, having some issues communicating using TLS between >> processes. >> >> With TLS disabled, the test passes on JDK17. >> >> The test passes using TLS on JDK 16 and earlier JDK versions. >> >> I've enabled TLS handshake debug on the output >> >> 1. https://github.com/pfirmstone/JGDMS/blob/trunk/qa/LookupNegMatches-jdk16-tls-handshake-debug.txt >> 2. https://github.com/pfirmstone/JGDMS/blob/trunk/qa/LookupNegMatches-jdk16.txt >> 3. https://github.com/pfirmstone/JGDMS/blob/trunk/qa/LookupNegMatches-jdk17-TLS-disabled.txt >> 4. https://github.com/pfirmstone/JGDMS/blob/trunk/qa/LookupNegMatches-jdk17-tls-handshake-debug.txt >> 5. https://github.com/pfirmstone/JGDMS/blob/trunk/qa/LookupNegMatches-jdk17-TLS-handshake-debug2.txt >> >> There are 5 JVM instances created during this integration test and these >> JVM's are communicating using network connections. I have checked that >> all JVM processes are running, it seems to be a communication issue. >> >> Using diff to compare files 1 and 5 above, it appears to be related to a >> close notify in JDK17, on the (JSK) connection . >> >> Any suggestions? >> >> Thanks, >> >> Peter. >> >> [java] ActSys-err: javax.net.ssl|DEBUG|D2|(JSK) mux reader|2021-08-11 14:56:20.606 AEST|SSLSocketImpl.java:1775|close the SSL connection (passive) >> [java] ActSys-err: javax.net.ssl|DEBUG|C2|(JSK) mux writer|2021-08-11 14:56:20.606 AEST|SSLSocketImpl.java:572|duplex close of SSLSocket >> [java] ActSys-err: javax.net.ssl|ALL|D2|(JSK) mux reader|2021-08-11 14:56:20.606 AEST|SSLSocketImpl.java:1129|Closing input stream >> [java] ActSys-err: javax.net.ssl|WARNING|B2|(JSK) mux reader|2021-08-11 14:56:20.607 AEST|SSLSocketImpl.java:1666|handling exception ( >> [java] ActSys-err: "throwable" : { >> [java] ActSys-err: java.net.SocketException: Socket closed >> [java] ActSys-err: at java.base/sun.nio.ch.NioSocketImpl.endRead(NioSocketImpl.java:248) >> [java] ActSys-err: at java.base/sun.nio.ch.NioSocketImpl.implRead(NioSocketImpl.java:327) >> [java] ActSys-err: at java.base/sun.nio.ch.NioSocketImpl.read(NioSocketImpl.java:350) >> [java] ActSys-err: at java.base/sun.nio.ch.NioSocketImpl$1.read(NioSocketImpl.java:803) >> [java] ActSys-err: at java.base/java.net.Socket$SocketInputStream.read(Socket.java:966) >> [java] ActSys-err: at java.base/sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:478) >> [java] ActSys-err: at java.base/sun.security.ssl.SSLSocketInputRecord.readHeader(SSLSocketInputRecord.java:472) >> [java] ActSys-err: at java.base/sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(SSLSocketInputRecord.java:70) >> [java] ActSys-err: at java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1455) >> [java] ActSys-err: at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:1059) >> [java] ActSys-err: at org.apache.river.jeri.internal.mux.StreamConnectionIO$1.read(StreamConnectionIO.java:372) >> [java] ActSys-err: at org.apache.river.jeri.internal.mux.StreamConnectionIO$Reader.run(StreamConnectionIO.java:277) >> [java] ActSys-err: at org.apache.river.thread.ThreadPool$Task.run(ThreadPool.java:172) >> [java] ActSys-err: at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) >> [java] ActSys-err: at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) >> [java] ActSys-err: at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) >> [java] ActSys-err: at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) >> [java] ActSys-err: at java.base/java.lang.Thread.run(Thread.java:833)} >> [java] ActSys-err: >> [java] ActSys-err: ) >> [java] ActSys-err: javax.net.ssl|ERROR|B2|(JSK) mux reader|2021-08-11 14:56:20.607 AEST|TransportContext.java:363|Fatal (UNEXPECTED_MESSAGE): Socket closed ( >> [java] ActSys-err: "throwable" : { >> [java] ActSys-err: java.net.SocketException: Socket closed >> [java] ActSys-err: at java.base/sun.nio.ch.NioSocketImpl.endRead(NioSocketImpl.java:248) >> [java] ActSys-err: at java.base/sun.nio.ch.NioSocketImpl.implRead(NioSocketImpl.java:327) >> [java] ActSys-err: at java.base/sun.nio.ch.NioSocketImpl.read(NioSocketImpl.java:350) >> [java] ActSys-err: at java.base/sun.nio.ch.NioSocketImpl$1.read(NioSocketImpl.java:803) >> [java] ActSys-err: at java.base/java.net.Socket$SocketInputStream.read(Socket.java:966) >> [java] ActSys-err: at java.base/sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:478) >> [java] ActSys-err: at java.base/sun.security.ssl.SSLSocketInputRecord.readHeader(SSLSocketInputRecord.java:472) >> [java] ActSys-err: at java.base/sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(SSLSocketInputRecord.java:70) >> [java] ActSys-err: at java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1455) >> [java] ActSys-err: at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:1059) >> [java] ActSys-err: at org.apache.river.jeri.internal.mux.StreamConnectionIO$1.read(StreamConnectionIO.java:372) >> [java] ActSys-err: at org.apache.river.jeri.internal.mux.StreamConnectionIO$Reader.run(StreamConnectionIO.java:277) >> [java] ActSys-err: at org.apache.river.thread.ThreadPool$Task.run(ThreadPool.java:172) >> [java] ActSys-err: at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) >> [java] ActSys-err: at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) >> [java] ActSys-err: at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) >> [java] ActSys-err: at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) >> [java] ActSys-err: at java.base/java.lang.Thread.run(Thread.java:833)} >> [java] ActSys-err: >> [java] ActSys-err: ) >> [java] ActSys-err: javax.net.ssl|ALL|B2|(JSK) mux reader|2021-08-11 14:56:20.609 AEST|SSLSocketImpl.java:1129|Closing input stream >> [java] ActSys-err: 11 Aug 2021 2:57:02 pm:Group-0:err:WARNING: A terminally deprecated method in java.lang.System has been called >> [java] ActSys-err: WARNING: System::setSecurityManager has been called by org.apache.river.phoenix.init.ActivationGroupInit (file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/phoenix-init-3.1.1-SNAPSHOT.jar) >> [java] ActSys-err: WARNING: Please consider reporting this to the maintainers of org.apache.river.phoenix.init.ActivationGroupInit >> [java] ActSys-err: WARNING: System::setSecurityManager will be removed in a future release >> [java] ActSys-err: >> [java] ActSys-err: Aug 11, 2021 2:57:02 PM org.apache.river.phoenix.Activation$GroupEntry getInstantiator >> [java] ActSys-err: FINE: Group-1 exec [C:\Program Files\Zulu\jdk-17\bin\java, -ea, -esa, -server, -Dorg.apache.river.qa.harness.harnessJar=C:\Users\peter\Documents\NetBeansProjects\JGDMS\qa\lib\jiniharness.jar, -Djsk.iiop.jar=jgdms-iiop-3.1.1-SNAPSHOT.jar, -Doutrigger-snaplogstore.jar=outrigger-snaplogstore-3.1.1-SNAPSHOT.jar, -Dorg.apache.river.jsk.port=9080, -Dcollections.jar=jgdms-collections-3.1.1-SNAPSHOT.jar, -Dsharedvm.jar=service-starter-3.1.1-SNAPSHOT.jar, -Djgdms-rmi-tls.jar=jgdms-rmi-tls-3.1.1-SNAPSHOT.jar, -Djava.protocol.handler.pkgs=net.jini.url, -Dphoenix.jar=phoenix-3.1.1-SNAPSHOT.jar, -Dplatform.jar=jgdms-platform-3.1.1-SNAPSHOT.jar, -Dnorm-dl.jar=norm-dl-3.1.1-SNAPSHOT.jar, -Dorg.apache.river.qa.harness.testJar=C:\Users\peter\Documents\NetBeansProjects\JGDMS\qa\lib\jinitests.jar, -Djava.util.logging.config.file=C:\Users\peter\Documents\NetBeansProjects\JGDMS\qa\src\org\apache\river\test\resources\qa1.logging, -Djsk.pref.jar=jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar, -Dstart.jar=service-starter-3.1.1-SNAPSHOT.jar, -Dphoenix-common.jar=phoenix-common-3.1.1-SNAPSHOT.jar, -Djava.security.properties=file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/harness/trust/dynamic-policy.properties, -Dmercury-dl.jar=mercury-dl-3.1.1-SNAPSHOT.jar, -Dreggie-dl.jar=reggie-dl-3.1.1-SNAPSHOT.jar, -Dloader.jar=jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar, -Dclassserver.jar=classserver-3.1.1-SNAPSHOT.jar, -Djsk-dl.jar=jgdms-lib-dl-3.1.1-SNAPSHOT.jar, -Dorg.apache.river.test.home=C:\Users\peter\Documents\NetBeansProjects\JGDMS\qa, -Dreggie.jar=reggie-service-3.1.1-SNAPSHOT.jar, -Djdk.io.permissionsUseCanonicalPath=true, -Dphoenix-dl.jar=phoenix-dl-3.1.1-SNAPSHOT.jar, -Djsk.home=C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT, -Djeri.jar=jgdms-jeri-3.1.1-SNAPSHOT.jar, -Dhigh-scale-lib.jar=high-scale-lib-1.0.6.jar, -Djava.net.preferIPv6Addresses=true, -DHOST=DESKTOP-R0ORPA2, -Dorg.apache.river.qa.harness.testhosts=, -Dmahalo.jar=mahalo-service-3.1.1-SNAPSHOT.jar, -Djavax.net.ssl.trustStore=harness\trust\truststore, -Dbouncy-jce.jar=bcprov-jdk15on-1.59.jar, -Dorg.apache.river.discovery.x500.trustStore=file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/harness/trust/truststore, -Doutrigger-dl.jar=outrigger-dl-3.1.1-SNAPSHOT.jar, -Ddisco.jar=jgdms-discovery-providers-3.1.1-SNAPSHOT.jar, -Djgdms.version=3.1.1-SNAPSHOT, -Dgroup.jar=group-service-3.1.1-SNAPSHOT.jar, -Djava.security.policy=file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/harness/policy/defaultsecuresharedvm.policy, -Dorg.apache.river.qa.harness.runjiniserver=true, -Dactivation-param.jar=jgdms-activation-parameters-3.1.1-SNAPSHOT.jar, -Dactivation.jar=jgdms-activation-3.1.1-SNAPSHOT.jar, -Dorg.apache.river.qa.harness.policies=file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/src/org/apache/river/test/resources/jinitest.policy, -Dsun.net.maxDatagramSockets=1024, -Dnorm.jar=norm-service-3.1.1-SNAPSHOT.jar, -Dmercury.jar=mercury-service-3.1.1-SNAPSHOT.jar, -Djsk.url.jar=jgdms-url-integrity-3.1.1-SNAPSHOT.jar, -Djsk-lib.jar=jgdms-lib-3.1.1-SNAPSHOT.jar, -Dfiddler.jar=fiddler-service-3.1.1-SNAPSHOT.jar, -Dbouncy-jsse.jar=bctls-jdk15on-1.59.jar, -Dnet.jini.core.lookup.ServiceRegistrar.portAbitraryIfInUse=true, -Djavax.net.debug=ssl:handshake, -Dorg.apache.river.discovery.x500.trustStorePassword=trustpw, -Dphoenix-group.jar=phoenix-group-3.1.1-SNAPSHOT.jar, -Dnet.jini.security.allowInsecureConnections=true, -Dorg.apache.river.test.port=9082, -Dorg.apache.river.qa.harness.runkitserver=true, -Djava.security.auth.login.config=file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/harness/trust/jsselogins, -Dfiddler-dl.jar=fiddler-dl-3.1.1-SNAPSHOT.jar, -Dmahalo-dl.jar=mahalo-dl-3.1.1-SNAPSHOT.jar, -Dorg.apache.river.qa.port=9081, -Dphoenix-init.jar=phoenix-init-3.1.1-SNAPSHOT.jar, -Doutrigger.jar=outrigger-service-3.1.1-SNAPSHOT.jar, -Djavax.net.ssl.trustStorePassword=trustpw, -Ddestroy.jar=jgdms-destroy-3.1.1-SNAPSHOT.jar, -Dqa.home=C:\Users\peter\Documents\NetBeansProjects\JGDMS\qa, -cp, C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\service-starter-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-collections-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\high-scale-lib-1.0.6.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\phoenix-init-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-platform-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib-dl\jgdms-lib-dl-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-lib-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-discovery-providers-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-jeri-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\phoenix-group-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib-dl\phoenix-dl-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\phoenix-common-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-activation-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-activation-parameters-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-url-integrity-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\bcprov-jdk15on-1.59.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\bctls-jdk15on-1.59.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\security-policy-debug-3.1.1-SNAPSHOT.jar, org.apache.river.phoenix.init.ActivationGroupInit] >> [java] ActSys-err: javax.net.ssl|WARNING|F1|(JSK) mux request dispatch|2021-08-11 14:57:03.067 AEST|ServerNameExtension.java:266|Unable to indicate server name >> [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request dispatch|2021-08-11 14:57:03.067 AEST|SSLExtensions.java:272|Ignore, context unavailable extension: server_name >> [java] ActSys-err: javax.net.ssl|INFO|F1|(JSK) mux request dispatch|2021-08-11 14:57:03.068 AEST|AlpnExtension.java:182|No available application protocols >> [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request dispatch|2021-08-11 14:57:03.068 AEST|SSLExtensions.java:272|Ignore, context unavailable extension: application_layer_protocol_negotiation >> [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request dispatch|2021-08-11 14:57:03.068 AEST|SessionTicketExtension.java:408|Stateless resumption supported >> [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request dispatch|2021-08-11 14:57:03.070 AEST|SSLExtensions.java:272|Ignore, context unavailable extension: cookie >> [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request dispatch|2021-08-11 14:57:03.075 AEST|PreSharedKeyExtension.java:662|No session to resume. >> [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request dispatch|2021-08-11 14:57:03.075 AEST|SSLExtensions.java:272|Ignore, context unavailable extension: pre_shared_key >> [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request dispatch|2021-08-11 14:57:03.077 AEST|ClientHello >> >> >> -- Regards, Peter Firmstone 0498 286 363 Zeus Project Services Pty Ltd. From mgridinas at gmail.com Wed Aug 11 16:54:56 2021 From: mgridinas at gmail.com (Mantas Gridinas) Date: Wed, 11 Aug 2021 16:54:56 +0000 Subject: java.nio.file.FileSystem TCK Message-ID: Hi! I would like to implement my own filesystem driver for network based file systems (think Amazon S3, Azure Storage, Google Drive, etc.) Reading through JDK source code I found the following tests: https://github.com/openjdk/jdk/tree/master/test/jdk/java/nio/file. Would these suffice to cover expectations required by general use case when depending on FileSystem API? Are there any more? Cheers! -- // Mantas From Alan.Bateman at oracle.com Wed Aug 11 17:12:50 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 11 Aug 2021 18:12:50 +0100 Subject: java.nio.file.FileSystem TCK In-Reply-To: References: Message-ID: On 11/08/2021 17:54, Mantas Gridinas wrote: > Hi! > > I would like to implement my own filesystem driver for network based > file systems (think Amazon S3, Azure Storage, Google Drive, etc.) > Reading through JDK source code I found the following tests: > https://github.com/openjdk/jdk/tree/master/test/jdk/java/nio/file. > Would these suffice to cover expectations required by general use case > when depending on FileSystem API? Are there any more? There isn't the equivalent of a TCK for service provider implementations but there are tests in the repo for the default provider, the zipfs provider, and jrtfs provider as these are the 3 implementations in the JDK. They may give you some ideas on the types of tests that you will need for your provider. It's probably best to follow on nio-dev if you have questions rather than here. AFAIK the Google folks have a NIO file system provider for Google cloud storage already ("gs" URI scheme). Also Microsoft folks seem to have something for Azure blob storage ("azb" URI scheme). So it's possible there are file system providers out there for what you want. -Alan. From jamil.j.nimeh at oracle.com Wed Aug 11 19:32:59 2021 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Wed, 11 Aug 2021 12:32:59 -0700 Subject: JDK17 - Possible TLS issue. In-Reply-To: References: <973c1457-c24d-6a9e-8979-9cabba0a164e@zeus.net.au> <9c8b95163e9b486886dcd8ca04a62e78@tencent.com> Message-ID: Hi Peter, I've captured the issue in https://bugs.openjdk.java.net/browse/JDK-8272340.? The synopsis is a bit vague right now as I'm going through the logs.? I'll revise it once I have a little more info.? I was also looking at the JGDMS project just to see how easy it would be for me to replicate the specific tests that exhibit the failure.? I may contact you directly for a bit more info.? The instructions on the JGDMS page look pretty straightforward, so hopefully that won't take long to replicate. Thanks, --Jamil On 8/11/2021 3:12 AM, Peter Firmstone wrote: > ??johnsjiang(??)? > > I set the property: > > -Djdk.tls.acknowledgeCloseNotify=true. > > Unfortunately the test is still failing on JDK17, although the output > has changed and acknowledges the duplex close, so it appears something > else is causing the connection to close early. Interestingly, there is > a WARNING that the socket didn't close, followed by an ERROR, then > FATAL(UNEXPECTED MESSAGE). > > ???????Peter. > > https://github.com/pfirmstone/JGDMS/blob/trunk/qa/LookupNegMatches-jdk17-TLS-handshake-debug-ack-close-notify-true.txt > > > ???? [java] ActSys-err: javax.net.ssl|DEBUG|92|(JSK) > ConnectionManager.Reaper|2021-08-11 19:41:49.598 > AEST|SSLSocketImpl.java:572|duplex close of SSLSocket > ???? [java] ActSys-err: javax.net.ssl|DEBUG|D2|(JSK) mux > reader|2021-08-11 19:41:49.599 AEST|Alert.java:238|Received alert > message ( > ???? [java] ActSys-err: "Alert": { > ???? [java] ActSys-err:?? "level"????? : "warning", > ???? [java] ActSys-err:?? "description": "user_canceled" > ???? [java] ActSys-err: } > ???? [java] ActSys-err: ) > ???? [java] ActSys-err: javax.net.ssl|DEBUG|92|(JSK) > ConnectionManager.Reaper|2021-08-11 19:41:49.599 > AEST|SSLSocketImpl.java:1775|close the SSL connection (passive) > ???? [java] ActSys-err: javax.net.ssl|DEBUG|D2|(JSK) mux > reader|2021-08-11 19:41:49.599 AEST|Alert.java:238|Received alert > message ( > ???? [java] ActSys-err: "Alert": { > ???? [java] ActSys-err:?? "level"????? : "warning", > ???? [java] ActSys-err:?? "description": "close_notify" > ???? [java] ActSys-err: } > ???? [java] ActSys-err: ) > ???? [java] ActSys-err: javax.net.ssl|ALL|A2|(JSK) mux > writer|2021-08-11 19:41:49.599 AEST|SSLSocketImpl.java:1324|Closing > output stream > ???? [java] ActSys-err: javax.net.ssl|DEBUG|D2|(JSK) mux > reader|2021-08-11 19:41:49.600 AEST|SSLSocketImpl.java:572|duplex > close of SSLSocket > ???? [java] ActSys-err: javax.net.ssl|ALL|C2|(JSK) mux > writer|2021-08-11 19:41:49.600 AEST|SSLSocketImpl.java:1324|Closing > output stream > ???? [java] ActSys-err: javax.net.ssl|DEBUG|D2|(JSK) mux > reader|2021-08-11 19:41:49.600 AEST|SSLSocketImpl.java:1775|close the > SSL connection (passive) > ???? [java] ActSys-err: javax.net.ssl|DEBUG|C2|(JSK) mux > writer|2021-08-11 19:41:49.600 AEST|SSLSocketImpl.java:572|duplex > close of SSLSocket > ???? [java] ActSys-err: javax.net.ssl|DEBUG|C2|(JSK) mux > writer|2021-08-11 19:41:49.600 AEST|SSLSocketImpl.java:1775|close the > SSL connection (passive) > ???? [java] ActSys-err: javax.net.ssl|ALL|D2|(JSK) mux > reader|2021-08-11 19:41:49.600 AEST|SSLSocketImpl.java:1129|Closing > input stream > ???? [java] ActSys-err: javax.net.ssl|WARNING|C2|(JSK) mux > writer|2021-08-11 19:41:49.602 AEST|SSLSocketImpl.java:600|SSLSocket > close failed. Debug info only. Exception details: ( > ???? [java] ActSys-err: "throwable" : { > ???? [java] ActSys-err:?? java.net.SocketException: Socket closed > ???? [java] ActSys-err:?? ??? at > java.base/sun.nio.ch.NioSocketImpl.ensureOpenAndConnected(NioSocketImpl.java:165) > ???? [java] ActSys-err:?? ??? at > java.base/sun.nio.ch.NioSocketImpl.available(NioSocketImpl.java:838) > ???? [java] ActSys-err:?? ??? at > java.base/sun.nio.ch.NioSocketImpl$1.available(NioSocketImpl.java:807) > ???? [java] ActSys-err:?? ??? at > java.base/java.net.Socket$SocketInputStream.available(Socket.java:970) > ???? [java] ActSys-err:?? ??? at > java.base/sun.security.ssl.SSLSocketInputRecord.deplete(SSLSocketInputRecord.java:495) > ???? [java] ActSys-err:?? ??? at > java.base/sun.security.ssl.SSLSocketImpl.closeSocket(SSLSocketImpl.java:1785) > ???? [java] ActSys-err:?? ??? at > java.base/sun.security.ssl.SSLSocketImpl.close(SSLSocketImpl.java:596) > ???? [java] ActSys-err:?? ??? at > java.base/sun.security.ssl.SSLSocketImpl$AppOutputStream.close(SSLSocketImpl.java:1328) > ???? [java] ActSys-err:?? ??? at > org.apache.river.jeri.internal.mux.StreamConnectionIO$2.close(StreamConnectionIO.java:427) > ???? [java] ActSys-err:?? ??? at > org.apache.river.jeri.internal.mux.StreamConnectionIO$Writer.run(StreamConnectionIO.java:250) > ???? [java] ActSys-err:?? ??? at > org.apache.river.thread.ThreadPool$Task.run(ThreadPool.java:172) > ???? [java] ActSys-err:?? ??? at > java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) > ???? [java] ActSys-err:?? ??? at > java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > ???? [java] ActSys-err:?? ??? at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) > ???? [java] ActSys-err:?? ??? at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) > ???? [java] ActSys-err:?? ??? at > java.base/java.lang.Thread.run(Thread.java:833)} > ???? [java] ActSys-err: > ???? [java] ActSys-err: ) > ???? [java] ActSys-err: javax.net.ssl|WARNING|B2|(JSK) mux > reader|2021-08-11 19:41:49.602 AEST|SSLSocketImpl.java:1666|handling > exception ( > ???? [java] ActSys-err: "throwable" : { > ???? [java] ActSys-err:?? java.net.SocketException: Socket closed > ???? [java] ActSys-err:?? ??? at > java.base/sun.nio.ch.NioSocketImpl.endRead(NioSocketImpl.java:248) > ???? [java] ActSys-err:?? ??? at > java.base/sun.nio.ch.NioSocketImpl.implRead(NioSocketImpl.java:327) > ???? [java] ActSys-err:?? ??? at > java.base/sun.nio.ch.NioSocketImpl.read(NioSocketImpl.java:350) > ???? [java] ActSys-err:?? ??? at > java.base/sun.nio.ch.NioSocketImpl$1.read(NioSocketImpl.java:803) > ???? [java] ActSys-err:?? ??? at > java.base/java.net.Socket$SocketInputStream.read(Socket.java:966) > ???? [java] ActSys-err:?? ??? at > java.base/sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:478) > ???? [java] ActSys-err:?? ??? at > java.base/sun.security.ssl.SSLSocketInputRecord.readHeader(SSLSocketInputRecord.java:472) > ???? [java] ActSys-err:?? ??? at > java.base/sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(SSLSocketInputRecord.java:70) > ???? [java] ActSys-err:?? ??? at > java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1455) > ???? [java] ActSys-err:?? ??? at > java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:1059) > ???? [java] ActSys-err:?? ??? at > org.apache.river.jeri.internal.mux.StreamConnectionIO$1.read(StreamConnectionIO.java:372) > ???? [java] ActSys-err:?? ??? at > org.apache.river.jeri.internal.mux.StreamConnectionIO$Reader.run(StreamConnectionIO.java:277) > ???? [java] ActSys-err:?? ??? at > org.apache.river.thread.ThreadPool$Task.run(ThreadPool.java:172) > ???? [java] ActSys-err:?? ??? at > java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) > ???? [java] ActSys-err:?? ??? at > java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > ???? [java] ActSys-err:?? ??? at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) > ???? [java] ActSys-err:?? ??? at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) > ???? [java] ActSys-err:?? ??? at > java.base/java.lang.Thread.run(Thread.java:833)} > ???? [java] ActSys-err: > ???? [java] ActSys-err: ) > ???? [java] ActSys-err: javax.net.ssl|ERROR|B2|(JSK) mux > reader|2021-08-11 19:41:49.602 AEST|TransportContext.java:363|Fatal > (UNEXPECTED_MESSAGE): Socket closed ( > ???? [java] ActSys-err: "throwable" : { > ???? [java] ActSys-err:?? java.net.SocketException: Socket closed > ???? [java] ActSys-err:?? ??? at > java.base/sun.nio.ch.NioSocketImpl.endRead(NioSocketImpl.java:248) > ???? [java] ActSys-err:?? ??? at > java.base/sun.nio.ch.NioSocketImpl.implRead(NioSocketImpl.java:327) > ???? [java] ActSys-err:?? ??? at > java.base/sun.nio.ch.NioSocketImpl.read(NioSocketImpl.java:350) > ???? [java] ActSys-err:?? ??? at > java.base/sun.nio.ch.NioSocketImpl$1.read(NioSocketImpl.java:803) > ???? [java] ActSys-err:?? ??? at > java.base/java.net.Socket$SocketInputStream.read(Socket.java:966) > ???? [java] ActSys-err:?? ??? at > java.base/sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:478) > ???? [java] ActSys-err:?? ??? at > java.base/sun.security.ssl.SSLSocketInputRecord.readHeader(SSLSocketInputRecord.java:472) > ???? [java] ActSys-err:?? ??? at > java.base/sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(SSLSocketInputRecord.java:70) > ???? [java] ActSys-err:?? ??? at > java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1455) > ???? [java] ActSys-err:?? ??? at > java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:1059) > ???? [java] ActSys-err:?? ??? at > org.apache.river.jeri.internal.mux.StreamConnectionIO$1.read(StreamConnectionIO.java:372) > ???? [java] ActSys-err:?? ??? at > org.apache.river.jeri.internal.mux.StreamConnectionIO$Reader.run(StreamConnectionIO.java:277) > ???? [java] ActSys-err:?? ??? at > org.apache.river.thread.ThreadPool$Task.run(ThreadPool.java:172) > ???? [java] ActSys-err:?? ??? at > java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) > ???? [java] ActSys-err:?? ??? at > java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > ???? [java] ActSys-err:?? ??? at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) > ???? [java] ActSys-err:?? ??? at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) > ???? [java] ActSys-err:?? ??? at > java.base/java.lang.Thread.run(Thread.java:833)} > ???? [java] ActSys-err: > ???? [java] ActSys-err: ) > ???? [java] ActSys-err: javax.net.ssl|ALL|B2|(JSK) mux > reader|2021-08-11 19:41:49.603 AEST|SSLSocketImpl.java:1129|Closing > input stream > ???? [java] ActSys-err: 11 Aug 2021 7:42:31 pm:Group-0:err:WARNING: A > terminally deprecated method in java.lang.System has been called > ???? [java] ActSys-err: WARNING: System::setSecurityManager has been > called by org.apache.river.phoenix.init.ActivationGroupInit > (file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/phoenix-init-3.1.1-SNAPSHOT.jar) > ???? [java] ActSys-err: WARNING: Please consider reporting this to the > maintainers of org.apache.river.phoenix.init.ActivationGroupInit > ???? [java] ActSys-err: WARNING: System::setSecurityManager will be > removed in a future release > ???? [java] ActSys-err: > ???? [java] ActSys-err: Aug 11, 2021 7:42:31 PM > org.apache.river.phoenix.Activation$GroupEntry getInstantiator > ???? [java] ActSys-err: FINE: Group-1 exec [C:\Program > Files\Zulu\jdk-17\bin\java, -ea, -esa, -server, > -Dorg.apache.river.qa.harness.harnessJar=C:\Users\peter\Documents\NetBeansProjects\JGDMS\qa\lib\jiniharness.jar, > -Djsk.iiop.jar=jgdms-iiop-3.1.1-SNAPSHOT.jar, > -Doutrigger-snaplogstore.jar=outrigger-snaplogstore-3.1.1-SNAPSHOT.jar, > -Dorg.apache.river.jsk.port=9080, > -Dcollections.jar=jgdms-collections-3.1.1-SNAPSHOT.jar, > -Dsharedvm.jar=service-starter-3.1.1-SNAPSHOT.jar, > -Djgdms-rmi-tls.jar=jgdms-rmi-tls-3.1.1-SNAPSHOT.jar, > -Djdk.tls.acknowledgeCloseNotify=true, > -Djava.protocol.handler.pkgs=net.jini.url, > -Dphoenix.jar=phoenix-3.1.1-SNAPSHOT.jar, > -Dplatform.jar=jgdms-platform-3.1.1-SNAPSHOT.jar, > -Dnorm-dl.jar=norm-dl-3.1.1-SNAPSHOT.jar, > -Dorg.apache.river.qa.harness.testJar=C:\Users\peter\Documents\NetBeansProjects\JGDMS\qa\lib\jinitests.jar, > -Djava.util.logging.config.file=C:\Users\peter\Documents\NetBeansProjects\JGDMS\qa\src\org\apache\river\test\resources\qa1.logging, > -Djsk.pref.jar=jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar, > -Dstart.jar=service-starter-3.1.1-SNAPSHOT.jar, > -Dphoenix-common.jar=phoenix-common-3.1.1-SNAPSHOT.jar, > -Djava.security.properties=file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/harness/trust/dynamic-policy.properties, > -Dmercury-dl.jar=mercury-dl-3.1.1-SNAPSHOT.jar, > -Dreggie-dl.jar=reggie-dl-3.1.1-SNAPSHOT.jar, > -Dloader.jar=jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar, > -Dclassserver.jar=classserver-3.1.1-SNAPSHOT.jar, > -Djsk-dl.jar=jgdms-lib-dl-3.1.1-SNAPSHOT.jar, > -Dorg.apache.river.test.home=C:\Users\peter\Documents\NetBeansProjects\JGDMS\qa, > -Dreggie.jar=reggie-service-3.1.1-SNAPSHOT.jar, > -Djdk.io.permissionsUseCanonicalPath=true, > -Dphoenix-dl.jar=phoenix-dl-3.1.1-SNAPSHOT.jar, > -Djsk.home=C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT, > -Djeri.jar=jgdms-jeri-3.1.1-SNAPSHOT.jar, > -Dhigh-scale-lib.jar=high-scale-lib-1.0.6.jar, > -Djava.net.preferIPv6Addresses=true, -DHOST=DESKTOP-R0ORPA2, > -Dorg.apache.river.qa.harness.testhosts=, > -Dmahalo.jar=mahalo-service-3.1.1-SNAPSHOT.jar, > -Djavax.net.ssl.trustStore=harness\trust\truststore, > -Dbouncy-jce.jar=bcprov-jdk15on-1.59.jar, > -Dorg.apache.river.discovery.x500.trustStore=file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/harness/trust/truststore, > -Doutrigger-dl.jar=outrigger-dl-3.1.1-SNAPSHOT.jar, > -Ddisco.jar=jgdms-discovery-providers-3.1.1-SNAPSHOT.jar, > -Djgdms.version=3.1.1-SNAPSHOT, > -Dgroup.jar=group-service-3.1.1-SNAPSHOT.jar, > -Djava.security.policy=file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/harness/policy/defaultsecuresharedvm.policy, > -Dorg.apache.river.qa.harness.runjiniserver=true, > -Dactivation-param.jar=jgdms-activation-parameters-3.1.1-SNAPSHOT.jar, > -Dactivation.jar=jgdms-activation-3.1.1-SNAPSHOT.jar, > -Dorg.apache.river.qa.harness.policies=file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/src/org/apache/river/test/resources/jinitest.policy, > -Dsun.net.maxDatagramSockets=1024, > -Dnorm.jar=norm-service-3.1.1-SNAPSHOT.jar, > -Dmercury.jar=mercury-service-3.1.1-SNAPSHOT.jar, > -Djsk.url.jar=jgdms-url-integrity-3.1.1-SNAPSHOT.jar, > -Djsk-lib.jar=jgdms-lib-3.1.1-SNAPSHOT.jar, > -Dfiddler.jar=fiddler-service-3.1.1-SNAPSHOT.jar, > -Dbouncy-jsse.jar=bctls-jdk15on-1.59.jar, > -Dnet.jini.core.lookup.ServiceRegistrar.portAbitraryIfInUse=true, > -Djavax.net.debug=ssl:handshake, > -Dorg.apache.river.discovery.x500.trustStorePassword=trustpw, > -Dphoenix-group.jar=phoenix-group-3.1.1-SNAPSHOT.jar, > -Dnet.jini.security.allowInsecureConnections=true, > -Dorg.apache.river.test.port=9082, > -Dorg.apache.river.qa.harness.runkitserver=true, > -Djava.security.auth.login.config=file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/harness/trust/jsselogins, > -Dfiddler-dl.jar=fiddler-dl-3.1.1-SNAPSHOT.jar, > -Dmahalo-dl.jar=mahalo-dl-3.1.1-SNAPSHOT.jar, > -Dorg.apache.river.qa.port=9081, > -Dphoenix-init.jar=phoenix-init-3.1.1-SNAPSHOT.jar, > -Doutrigger.jar=outrigger-service-3.1.1-SNAPSHOT.jar, > -Djavax.net.ssl.trustStorePassword=trustpw, > -Ddestroy.jar=jgdms-destroy-3.1.1-SNAPSHOT.jar, > -Dqa.home=C:\Users\peter\Documents\NetBeansProjects\JGDMS\qa, -cp, > C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\service-starter-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-collections-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\high-scale-lib-1.0.6.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\phoenix-init-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-platform-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib-dl\jgdms-lib-dl-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-lib-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-discovery-providers-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-jeri-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\phoenix-group-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib-dl\phoenix-dl-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\phoenix-common-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-activation-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-activation-parameters-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-url-integrity-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\bcprov-jdk15on-1.59.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\bctls-jdk15on-1.59.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\security-policy-debug-3.1.1-SNAPSHOT.jar, > org.apache.river.phoenix.init.ActivationGroupInit] > ???? [java] ActSys-err: javax.net.ssl|WARNING|F1|(JSK) mux request > dispatch|2021-08-11 19:42:32.033 > AEST|ServerNameExtension.java:266|Unable to indicate server name > ???? [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request > dispatch|2021-08-11 19:42:32.033 AEST|SSLExtensions.java:272|Ignore, > context unavailable extension: server_name > ???? [java] ActSys-err: javax.net.ssl|INFO|F1|(JSK) mux request > dispatch|2021-08-11 19:42:32.034 AEST|AlpnExtension.java:182|No > available application protocols > ???? [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request > dispatch|2021-08-11 19:42:32.034 AEST|SSLExtensions.java:272|Ignore, > context unavailable extension: application_layer_protocol_negotiation > ???? [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request > dispatch|2021-08-11 19:42:32.034 > AEST|SessionTicketExtension.java:408|Stateless resumption supported > ???? [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request > dispatch|2021-08-11 19:42:32.035 AEST|SSLExtensions.java:272|Ignore, > context unavailable extension: cookie > ???? [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request > dispatch|2021-08-11 19:42:32.041 > AEST|PreSharedKeyExtension.java:662|No session to resume. > ???? [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request > dispatch|2021-08-11 19:42:32.041 AEST|SSLExtensions.java:272|Ignore, > context unavailable extension: pre_shared_key > ???? [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request > dispatch|2021-08-11 19:42:32.044 AEST|ClientHello.java:652|Produced > ClientHello handsha > > > > On 11/08/2021 7:22 pm, johnsjiang(??) wrote: >> + security-dev >> >> Hi Peter, >> It looks both of file 1 and 5 contain that close_notify warning alert. >> This point may be related to JDK-8208526: TLS 1.3 half-close and >> synchronization issues [1]. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8208526 >> >> Best regards, >> John Jiang >> >> At 2021/8/11 PM 4:14, Peter Firmstone wrote: >>> I'm testing on JDK17, having some issues communicating using TLS >>> between >>> processes. >>> >>> With TLS disabled, the test passes on JDK17. >>> >>> The test passes using TLS on JDK 16 and earlier JDK versions. >>> >>> I've enabled TLS handshake debug on the output >>> >>> ? 1. >>> https://github.com/pfirmstone/JGDMS/blob/trunk/qa/LookupNegMatches-jdk16-tls-handshake-debug.txt >>> ? 2. >>> https://github.com/pfirmstone/JGDMS/blob/trunk/qa/LookupNegMatches-jdk16.txt >>> ? 3. >>> https://github.com/pfirmstone/JGDMS/blob/trunk/qa/LookupNegMatches-jdk17-TLS-disabled.txt >>> ? 4. >>> https://github.com/pfirmstone/JGDMS/blob/trunk/qa/LookupNegMatches-jdk17-tls-handshake-debug.txt >>> ? 5. >>> https://github.com/pfirmstone/JGDMS/blob/trunk/qa/LookupNegMatches-jdk17-TLS-handshake-debug2.txt >>> >>> There are 5 JVM instances created during this integration test and >>> these >>> JVM's are communicating using network connections.? I have checked that >>> all JVM processes are running, it seems to be a communication issue. >>> >>> Using diff to compare files 1 and 5 above, it appears to be related >>> to a >>> close notify in JDK17, on the (JSK) connection . >>> >>> Any suggestions? >>> >>> Thanks, >>> >>> Peter. >>> >>> ?????? [java] ActSys-err: javax.net.ssl|DEBUG|D2|(JSK) mux >>> reader|2021-08-11 14:56:20.606 AEST|SSLSocketImpl.java:1775|close >>> the SSL connection (passive) >>> ?????? [java] ActSys-err: javax.net.ssl|DEBUG|C2|(JSK) mux >>> writer|2021-08-11 14:56:20.606 AEST|SSLSocketImpl.java:572|duplex >>> close of SSLSocket >>> ?????? [java] ActSys-err: javax.net.ssl|ALL|D2|(JSK) mux >>> reader|2021-08-11 14:56:20.606 AEST|SSLSocketImpl.java:1129|Closing >>> input stream >>> ?????? [java] ActSys-err: javax.net.ssl|WARNING|B2|(JSK) mux >>> reader|2021-08-11 14:56:20.607 AEST|SSLSocketImpl.java:1666|handling >>> exception ( >>> ?????? [java] ActSys-err: "throwable" : { >>> ?????? [java] ActSys-err:?? java.net.SocketException: Socket closed >>> ?????? [java] ActSys-err:?????? at >>> java.base/sun.nio.ch.NioSocketImpl.endRead(NioSocketImpl.java:248) >>> ?????? [java] ActSys-err:?????? at >>> java.base/sun.nio.ch.NioSocketImpl.implRead(NioSocketImpl.java:327) >>> ?????? [java] ActSys-err:?????? at >>> java.base/sun.nio.ch.NioSocketImpl.read(NioSocketImpl.java:350) >>> ?????? [java] ActSys-err:?????? at >>> java.base/sun.nio.ch.NioSocketImpl$1.read(NioSocketImpl.java:803) >>> ?????? [java] ActSys-err:?????? at >>> java.base/java.net.Socket$SocketInputStream.read(Socket.java:966) >>> ?????? [java] ActSys-err:?????? at >>> java.base/sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:478) >>> ?????? [java] ActSys-err:?????? at >>> java.base/sun.security.ssl.SSLSocketInputRecord.readHeader(SSLSocketInputRecord.java:472) >>> ?????? [java] ActSys-err:?????? at >>> java.base/sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(SSLSocketInputRecord.java:70) >>> ?????? [java] ActSys-err:?????? at >>> java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1455) >>> ?????? [java] ActSys-err:?????? at >>> java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:1059) >>> ?????? [java] ActSys-err:?????? at >>> org.apache.river.jeri.internal.mux.StreamConnectionIO$1.read(StreamConnectionIO.java:372) >>> ?????? [java] ActSys-err:?????? at >>> org.apache.river.jeri.internal.mux.StreamConnectionIO$Reader.run(StreamConnectionIO.java:277) >>> ?????? [java] ActSys-err:?????? at >>> org.apache.river.thread.ThreadPool$Task.run(ThreadPool.java:172) >>> ?????? [java] ActSys-err:?????? at >>> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) >>> ?????? [java] ActSys-err:?????? at >>> java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) >>> ?????? [java] ActSys-err:?????? at >>> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) >>> ?????? [java] ActSys-err:?????? at >>> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) >>> ?????? [java] ActSys-err:?????? at >>> java.base/java.lang.Thread.run(Thread.java:833)} >>> ?????? [java] ActSys-err: >>> ?????? [java] ActSys-err: ) >>> ?????? [java] ActSys-err: javax.net.ssl|ERROR|B2|(JSK) mux >>> reader|2021-08-11 14:56:20.607 AEST|TransportContext.java:363|Fatal >>> (UNEXPECTED_MESSAGE): Socket closed ( >>> ?????? [java] ActSys-err: "throwable" : { >>> ?????? [java] ActSys-err:?? java.net.SocketException: Socket closed >>> ?????? [java] ActSys-err:?????? at >>> java.base/sun.nio.ch.NioSocketImpl.endRead(NioSocketImpl.java:248) >>> ?????? [java] ActSys-err:?????? at >>> java.base/sun.nio.ch.NioSocketImpl.implRead(NioSocketImpl.java:327) >>> ?????? [java] ActSys-err:?????? at >>> java.base/sun.nio.ch.NioSocketImpl.read(NioSocketImpl.java:350) >>> ?????? [java] ActSys-err:?????? at >>> java.base/sun.nio.ch.NioSocketImpl$1.read(NioSocketImpl.java:803) >>> ?????? [java] ActSys-err:?????? at >>> java.base/java.net.Socket$SocketInputStream.read(Socket.java:966) >>> ?????? [java] ActSys-err:?????? at >>> java.base/sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:478) >>> ?????? [java] ActSys-err:?????? at >>> java.base/sun.security.ssl.SSLSocketInputRecord.readHeader(SSLSocketInputRecord.java:472) >>> ?????? [java] ActSys-err:?????? at >>> java.base/sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(SSLSocketInputRecord.java:70) >>> ?????? [java] ActSys-err:?????? at >>> java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1455) >>> ?????? [java] ActSys-err:?????? at >>> java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:1059) >>> ?????? [java] ActSys-err:?????? at >>> org.apache.river.jeri.internal.mux.StreamConnectionIO$1.read(StreamConnectionIO.java:372) >>> ?????? [java] ActSys-err:?????? at >>> org.apache.river.jeri.internal.mux.StreamConnectionIO$Reader.run(StreamConnectionIO.java:277) >>> ?????? [java] ActSys-err:?????? at >>> org.apache.river.thread.ThreadPool$Task.run(ThreadPool.java:172) >>> ?????? [java] ActSys-err:?????? at >>> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) >>> ?????? [java] ActSys-err:?????? at >>> java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) >>> ?????? [java] ActSys-err:?????? at >>> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) >>> ?????? [java] ActSys-err:?????? at >>> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) >>> ?????? [java] ActSys-err:?????? at >>> java.base/java.lang.Thread.run(Thread.java:833)} >>> ?????? [java] ActSys-err: >>> ?????? [java] ActSys-err: ) >>> ?????? [java] ActSys-err: javax.net.ssl|ALL|B2|(JSK) mux >>> reader|2021-08-11 14:56:20.609 AEST|SSLSocketImpl.java:1129|Closing >>> input stream >>> ?????? [java] ActSys-err: 11 Aug 2021 2:57:02 >>> pm:Group-0:err:WARNING: A terminally deprecated method in >>> java.lang.System has been called >>> ?????? [java] ActSys-err: WARNING: System::setSecurityManager has >>> been called by org.apache.river.phoenix.init.ActivationGroupInit >>> (file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/phoenix-init-3.1.1-SNAPSHOT.jar) >>> ?????? [java] ActSys-err: WARNING: Please consider reporting this to >>> the maintainers of org.apache.river.phoenix.init.ActivationGroupInit >>> ?????? [java] ActSys-err: WARNING: System::setSecurityManager will >>> be removed in a future release >>> ?????? [java] ActSys-err: >>> ?????? [java] ActSys-err: Aug 11, 2021 2:57:02 PM >>> org.apache.river.phoenix.Activation$GroupEntry getInstantiator >>> ?????? [java] ActSys-err: FINE: Group-1 exec [C:\Program >>> Files\Zulu\jdk-17\bin\java, -ea, -esa, -server, >>> -Dorg.apache.river.qa.harness.harnessJar=C:\Users\peter\Documents\NetBeansProjects\JGDMS\qa\lib\jiniharness.jar, >>> -Djsk.iiop.jar=jgdms-iiop-3.1.1-SNAPSHOT.jar, >>> -Doutrigger-snaplogstore.jar=outrigger-snaplogstore-3.1.1-SNAPSHOT.jar, >>> -Dorg.apache.river.jsk.port=9080, >>> -Dcollections.jar=jgdms-collections-3.1.1-SNAPSHOT.jar, >>> -Dsharedvm.jar=service-starter-3.1.1-SNAPSHOT.jar, >>> -Djgdms-rmi-tls.jar=jgdms-rmi-tls-3.1.1-SNAPSHOT.jar, >>> -Djava.protocol.handler.pkgs=net.jini.url, >>> -Dphoenix.jar=phoenix-3.1.1-SNAPSHOT.jar, >>> -Dplatform.jar=jgdms-platform-3.1.1-SNAPSHOT.jar, >>> -Dnorm-dl.jar=norm-dl-3.1.1-SNAPSHOT.jar, >>> -Dorg.apache.river.qa.harness.testJar=C:\Users\peter\Documents\NetBeansProjects\JGDMS\qa\lib\jinitests.jar, >>> -Djava.util.logging.config.file=C:\Users\peter\Documents\NetBeansProjects\JGDMS\qa\src\org\apache\river\test\resources\qa1.logging, >>> -Djsk.pref.jar=jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar, >>> -Dstart.jar=service-starter-3.1.1-SNAPSHOT.jar, >>> -Dphoenix-common.jar=phoenix-common-3.1.1-SNAPSHOT.jar, >>> -Djava.security.properties=file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/harness/trust/dynamic-policy.properties, >>> -Dmercury-dl.jar=mercury-dl-3.1.1-SNAPSHOT.jar, >>> -Dreggie-dl.jar=reggie-dl-3.1.1-SNAPSHOT.jar, >>> -Dloader.jar=jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar, >>> -Dclassserver.jar=classserver-3.1.1-SNAPSHOT.jar, >>> -Djsk-dl.jar=jgdms-lib-dl-3.1.1-SNAPSHOT.jar, >>> -Dorg.apache.river.test.home=C:\Users\peter\Documents\NetBeansProjects\JGDMS\qa, >>> -Dreggie.jar=reggie-service-3.1.1-SNAPSHOT.jar, >>> -Djdk.io.permissionsUseCanonicalPath=true, >>> -Dphoenix-dl.jar=phoenix-dl-3.1.1-SNAPSHOT.jar, >>> -Djsk.home=C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT, >>> -Djeri.jar=jgdms-jeri-3.1.1-SNAPSHOT.jar, >>> -Dhigh-scale-lib.jar=high-scale-lib-1.0.6.jar, >>> -Djava.net.preferIPv6Addresses=true, -DHOST=DESKTOP-R0ORPA2, >>> -Dorg.apache.river.qa.harness.testhosts=, >>> -Dmahalo.jar=mahalo-service-3.1.1-SNAPSHOT.jar, >>> -Djavax.net.ssl.trustStore=harness\trust\truststore, >>> -Dbouncy-jce.jar=bcprov-jdk15on-1.59.jar, >>> -Dorg.apache.river.discovery.x500.trustStore=file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/harness/trust/truststore, >>> -Doutrigger-dl.jar=outrigger-dl-3.1.1-SNAPSHOT.jar, >>> -Ddisco.jar=jgdms-discovery-providers-3.1.1-SNAPSHOT.jar, >>> -Djgdms.version=3.1.1-SNAPSHOT, >>> -Dgroup.jar=group-service-3.1.1-SNAPSHOT.jar, >>> -Djava.security.policy=file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/harness/policy/defaultsecuresharedvm.policy, >>> -Dorg.apache.river.qa.harness.runjiniserver=true, >>> -Dactivation-param.jar=jgdms-activation-parameters-3.1.1-SNAPSHOT.jar, >>> -Dactivation.jar=jgdms-activation-3.1.1-SNAPSHOT.jar, >>> -Dorg.apache.river.qa.harness.policies=file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/src/org/apache/river/test/resources/jinitest.policy, >>> -Dsun.net.maxDatagramSockets=1024, >>> -Dnorm.jar=norm-service-3.1.1-SNAPSHOT.jar, >>> -Dmercury.jar=mercury-service-3.1.1-SNAPSHOT.jar, >>> -Djsk.url.jar=jgdms-url-integrity-3.1.1-SNAPSHOT.jar, >>> -Djsk-lib.jar=jgdms-lib-3.1.1-SNAPSHOT.jar, >>> -Dfiddler.jar=fiddler-service-3.1.1-SNAPSHOT.jar, >>> -Dbouncy-jsse.jar=bctls-jdk15on-1.59.jar, >>> -Dnet.jini.core.lookup.ServiceRegistrar.portAbitraryIfInUse=true, >>> -Djavax.net.debug=ssl:handshake, >>> -Dorg.apache.river.discovery.x500.trustStorePassword=trustpw, >>> -Dphoenix-group.jar=phoenix-group-3.1.1-SNAPSHOT.jar, >>> -Dnet.jini.security.allowInsecureConnections=true, >>> -Dorg.apache.river.test.port=9082, >>> -Dorg.apache.river.qa.harness.runkitserver=true, >>> -Djava.security.auth.login.config=file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/harness/trust/jsselogins, >>> -Dfiddler-dl.jar=fiddler-dl-3.1.1-SNAPSHOT.jar, >>> -Dmahalo-dl.jar=mahalo-dl-3.1.1-SNAPSHOT.jar, >>> -Dorg.apache.river.qa.port=9081, >>> -Dphoenix-init.jar=phoenix-init-3.1.1-SNAPSHOT.jar, >>> -Doutrigger.jar=outrigger-service-3.1.1-SNAPSHOT.jar, >>> -Djavax.net.ssl.trustStorePassword=trustpw, >>> -Ddestroy.jar=jgdms-destroy-3.1.1-SNAPSHOT.jar, >>> -Dqa.home=C:\Users\peter\Documents\NetBeansProjects\JGDMS\qa, -cp, >>> C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\service-starter-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-collections-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\high-scale-lib-1.0.6.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\phoenix-init-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-platform-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib-dl\jgdms-lib-dl-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-lib-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-discovery-providers-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-jeri-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\phoenix-group-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib-dl\phoenix-dl-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\phoenix-common-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-activation-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-activation-parameters-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\jgdms-url-integrity-3.1.1-SNAPSHOT.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\bcprov-jdk15on-1.59.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\bctls-jdk15on-1.59.jar;C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT\lib\security-policy-debug-3.1.1-SNAPSHOT.jar, >>> org.apache.river.phoenix.init.ActivationGroupInit] >>> ?????? [java] ActSys-err: javax.net.ssl|WARNING|F1|(JSK) mux request >>> dispatch|2021-08-11 14:57:03.067 >>> AEST|ServerNameExtension.java:266|Unable to indicate server name >>> ?????? [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request >>> dispatch|2021-08-11 14:57:03.067 AEST|SSLExtensions.java:272|Ignore, >>> context unavailable extension: server_name >>> ?????? [java] ActSys-err: javax.net.ssl|INFO|F1|(JSK) mux request >>> dispatch|2021-08-11 14:57:03.068 AEST|AlpnExtension.java:182|No >>> available application protocols >>> ?????? [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request >>> dispatch|2021-08-11 14:57:03.068 AEST|SSLExtensions.java:272|Ignore, >>> context unavailable extension: application_layer_protocol_negotiation >>> ?????? [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request >>> dispatch|2021-08-11 14:57:03.068 >>> AEST|SessionTicketExtension.java:408|Stateless resumption supported >>> ?????? [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request >>> dispatch|2021-08-11 14:57:03.070 AEST|SSLExtensions.java:272|Ignore, >>> context unavailable extension: cookie >>> ?????? [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request >>> dispatch|2021-08-11 14:57:03.075 >>> AEST|PreSharedKeyExtension.java:662|No session to resume. >>> ?????? [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request >>> dispatch|2021-08-11 14:57:03.075 AEST|SSLExtensions.java:272|Ignore, >>> context unavailable extension: pre_shared_key >>> ?????? [java] ActSys-err: javax.net.ssl|DEBUG|F1|(JSK) mux request >>> dispatch|2021-08-11 14:57:03.077 AEST|ClientHello >>> >>> >>> From david.holmes at oracle.com Thu Aug 12 00:03:49 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 12 Aug 2021 10:03:49 +1000 Subject: [External] : Re: GitHub/Mailing list communication defunct? In-Reply-To: References: <095fc050-dbb1-107d-eac9-89c974ba42b8@oracle.com> <59dd2185-104f-3235-6d8a-5f581f6d99be@gmail.com> Message-ID: Just FYI the problem is still under investigation and still seems to persist for some ML's but not all. David On 28/07/2021 3:44 am, tim.bell at oracle.com wrote: > Hello > >> if someone comments/replies directly to the mailing list thread (like >> Bernd and I did, during this past hour[2]), those comments aren't >> being registered in that github PR. This used to work previously and >> seems to be broken right now. > > We are aware of this problem and still investigating.? We don't have a > root cause or an ETA for this. > > Tim > > > On 7/22/21 09:21, Jaikiran Pai wrote: >> FWIW, it looks like this isn't fully back to normal. From what I can >> see in one of the PR's[1] I'm involved in, if I comment directly on >> the PR through the github UI, a mail is now getting delivered to the >> relevant mailing lists. So this part is back to normal now. >> >> However, if someone comments/replies directly to the mailing list >> thread (like Bernd and I did, during this past hour[2]), those >> comments aren't being registered in that github PR. This used to work >> previously and seems to be broken right now. >> >> [1] >> https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/4607__;!!ACWV5N9M2RV99hQ!eNjD04SNNH9INHTt0cyyed12lRNw9aZfSspNKh0ILIUQCIcvka-_vJ8XHXipGIQ$ >> >> [2] >> https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-July/079994.html >> >> >> -Jaikiran >> >> On 22/07/21 3:03 am, tim.bell at oracle.com wrote: >>>> just recognized that all of a sudden the traffic on the OpenJDK >>>> mailing lists dropped >>> >>> About an hour ago we corrected a problem on the Skara server >>> processing external (EG: github) messages.? Message traffic should be >>> flowing again. >>> >>> Messages for events during the outage are lost.? We will be holding a >>> port-mortem to investigate why this outage was not noticed sooner, >>> and why there was a data loss. >>> >>> Tim >>> >>> >>> On 7/21/21 14:29, David Holmes wrote: >>>> Hi Christoph, >>>> >>>> On 22/07/2021 1:07 am, Langer, Christoph wrote: >>>>> Hi, >>>>> >>>>> there's still no traffic on the mailing lists... >>>>> >>>>> It would be much appreciated if you could share an update on the >>>>> status. >>>> >>>> There was no update to share I'm afraid but it has now been resolved. >>>> >>>> It seems likely that the missing mail is gone forever unfortunately. >>>> >>>> Cheers, >>>> David >>>> >>>>> Thanks >>>>> Christoph >>>>> >>>>> From: Langer, Christoph >>>>> Sent: Dienstag, 20. Juli 2021 08:23 >>>>> To: ops at openjdk.java.net; skara-dev at openjdk.java.net; >>>>> jdk-dev at openjdk.java.net >>>>> Subject: GitHub/Mailing list communication defunct? >>>>> >>>>> Hi, >>>>> >>>>> I just recognized that all of a sudden the traffic on the OpenJDK >>>>> mailing lists dropped... First I thought it's an issue with my >>>>> account but looking at the pipermail archives, I don't find any >>>>> mails after e.g. some time yesterday. And I guess there's still the >>>>> usual activity on GitHub... >>>>> >>>>> Are you aware of an issue? >>>>> >>>>> Thanks & Best regards >>>>> Christoph >>>>> >>> >> > From mark.reinhold at oracle.com Thu Aug 12 21:45:38 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 12 Aug 2021 14:45:38 -0700 (PDT) Subject: New candidate JEP: 417: Vector API (Third Incubator) Message-ID: <20210812214538.EA2C93EEAA5@eggemoggin.niobe.net> https://openjdk.java.net/jeps/417 Summary: Introduce an API to express vector computations that reliably compile at runtime to optimal vector instructions on supported CPU architectures, thus achieving performance superior to equivalent scalar computations. - Mark From doko at ubuntu.com Fri Aug 13 16:00:47 2021 From: doko at ubuntu.com (Matthias Klose) Date: Fri, 13 Aug 2021 18:00:47 +0200 Subject: JDK 17: First Release Candidate In-Reply-To: <20210806100900.252926147@eggemoggin.niobe.net> References: <20210806100900.252926147@eggemoggin.niobe.net> Message-ID: <90d989fb-123f-f7e7-8f3f-3dc95a0de098@ubuntu.com> On 8/6/21 7:09 PM, mark.reinhold at oracle.com wrote: > There are no unresolved P1 bugs in build 35, so that is our > first JDK 17 Release Candidate. > > Binaries available here, as usual: https://jdk.java.net/17 this fails to build with glibc 2.34, i.e. on recent Fedora and Ubuntu development versions: /<>/test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c: In function 'set_signal_handler': /<>/test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c:72:15: error: storage size of 'altstack' isn't constant 72 | static char altstack[SIGSTKSZ]; | ^~~~~~~~ gmake[4]: *** [test/JtregNativeHotspot.gmk:1525: /<>/build/support/test/hotspot/jtreg/native/support/exeinvoke/exeinvoke.o] Error 1 From david.holmes at oracle.com Sat Aug 14 00:58:04 2021 From: david.holmes at oracle.com (David Holmes) Date: Sat, 14 Aug 2021 10:58:04 +1000 Subject: JDK 17: First Release Candidate In-Reply-To: <90d989fb-123f-f7e7-8f3f-3dc95a0de098@ubuntu.com> References: <20210806100900.252926147@eggemoggin.niobe.net> <90d989fb-123f-f7e7-8f3f-3dc95a0de098@ubuntu.com> Message-ID: <4fd853b8-1ca8-7bb5-8a88-7ea9938905af@oracle.com> Hi Matthias, On 14/08/2021 2:00 am, Matthias Klose wrote: > On 8/6/21 7:09 PM, mark.reinhold at oracle.com wrote: >> There are no unresolved P1 bugs in build 35, so that is our >> first JDK 17 Release Candidate. >> >> Binaries available here, as usual: https://jdk.java.net/17 > > this fails to build with glibc 2.34, i.e. on recent Fedora and Ubuntu > development versions: > > /<>/test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c: In > function 'set_signal_handler': > /<>/test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c:72:15: > error: storage size of 'altstack' isn't constant > 72 | static char altstack[SIGSTKSZ]; > | ^~~~~~~~ > gmake[4]: *** [test/JtregNativeHotspot.gmk:1525: > /<>/build/support/test/hotspot/jtreg/native/support/exeinvoke/exeinvoke.o] > Error 1 That seems like a glibc bug to me as SIGSTKSZ is supposed to be a constant. David From doko at ubuntu.com Sat Aug 14 08:06:59 2021 From: doko at ubuntu.com (Matthias Klose) Date: Sat, 14 Aug 2021 10:06:59 +0200 Subject: JDK 17: First Release Candidate In-Reply-To: <4fd853b8-1ca8-7bb5-8a88-7ea9938905af@oracle.com> References: <20210806100900.252926147@eggemoggin.niobe.net> <90d989fb-123f-f7e7-8f3f-3dc95a0de098@ubuntu.com> <4fd853b8-1ca8-7bb5-8a88-7ea9938905af@oracle.com> Message-ID: On 8/14/21 2:58 AM, David Holmes wrote: > Hi Matthias, > > On 14/08/2021 2:00 am, Matthias Klose wrote: >> On 8/6/21 7:09 PM, mark.reinhold at oracle.com wrote: >>> There are no unresolved P1 bugs in build 35, so that is our >>> first JDK 17 Release Candidate. >>> >>> Binaries available here, as usual: https://jdk.java.net/17 >> >> this fails to build with glibc 2.34, i.e. on recent Fedora and Ubuntu >> development versions: >> >> /<>/test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c: In >> function 'set_signal_handler': >> /<>/test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c:72:15: >> error: storage size of 'altstack' isn't constant >> ??? 72 |?? static char altstack[SIGSTKSZ]; >> ?????? |?????????????? ^~~~~~~~ >> gmake[4]: *** [test/JtregNativeHotspot.gmk:1525: >> /<>/build/support/test/hotspot/jtreg/native/support/exeinvoke/exeinvoke.o] >> >> Error 1 > > That seems like a glibc bug to me as SIGSTKSZ is supposed to be a constant. No, this change is intentional according to the glibc 2.34 release notes: * Add _SC_MINSIGSTKSZ and _SC_SIGSTKSZ. When _DYNAMIC_STACK_SIZE_SOURCE or _GNU_SOURCE are defined, MINSIGSTKSZ and SIGSTKSZ are no longer constant on Linux. MINSIGSTKSZ is redefined to sysconf(_SC_MINSIGSTKSZ) and SIGSTKSZ is redefined to sysconf (_SC_SIGSTKSZ). This supports dynamic sized register sets for modern architectural features like Arm SVE. Matthias From david.holmes at oracle.com Sat Aug 14 09:21:05 2021 From: david.holmes at oracle.com (David Holmes) Date: Sat, 14 Aug 2021 19:21:05 +1000 Subject: JDK 17: First Release Candidate In-Reply-To: References: <20210806100900.252926147@eggemoggin.niobe.net> <90d989fb-123f-f7e7-8f3f-3dc95a0de098@ubuntu.com> <4fd853b8-1ca8-7bb5-8a88-7ea9938905af@oracle.com> Message-ID: On 14/08/2021 6:06 pm, Matthias Klose wrote: > On 8/14/21 2:58 AM, David Holmes wrote: >> Hi Matthias, >> >> On 14/08/2021 2:00 am, Matthias Klose wrote: >>> On 8/6/21 7:09 PM, mark.reinhold at oracle.com wrote: >>>> There are no unresolved P1 bugs in build 35, so that is our >>>> first JDK 17 Release Candidate. >>>> >>>> Binaries available here, as usual: https://jdk.java.net/17 >>> >>> this fails to build with glibc 2.34, i.e. on recent Fedora and Ubuntu >>> development versions: >>> >>> /<>/test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c: In >>> function 'set_signal_handler': >>> /<>/test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c:72:15: >>> error: storage size of 'altstack' isn't constant >>> ??? 72 |?? static char altstack[SIGSTKSZ]; >>> ?????? |?????????????? ^~~~~~~~ >>> gmake[4]: *** [test/JtregNativeHotspot.gmk:1525: >>> /<>/build/support/test/hotspot/jtreg/native/support/exeinvoke/exeinvoke.o] >>> >>> Error 1 >> >> That seems like a glibc bug to me as SIGSTKSZ is supposed to be a constant. > > No, this change is intentional according to the glibc 2.34 release notes: > * Add _SC_MINSIGSTKSZ and _SC_SIGSTKSZ. When _DYNAMIC_STACK_SIZE_SOURCE > or _GNU_SOURCE are defined, MINSIGSTKSZ and SIGSTKSZ are no longer > constant on Linux. MINSIGSTKSZ is redefined to sysconf(_SC_MINSIGSTKSZ) > and SIGSTKSZ is redefined to sysconf (_SC_SIGSTKSZ). This supports > dynamic sized register sets for modern architectural features like > Arm SVE. Well that is annoying ... I wonder if we can stop building with _GNU_SOURCE so that we maintain Posix compatibility? We can look at working around this somehow, but not being able to build is not, I believe, a showstopper in terms of the JDK 17 release. Can you file a bug? Otherwise I will. Thanks, David > Matthias > From fweimer at redhat.com Sat Aug 14 09:23:27 2021 From: fweimer at redhat.com (Florian Weimer) Date: Sat, 14 Aug 2021 11:23:27 +0200 Subject: JDK 17: First Release Candidate In-Reply-To: <4fd853b8-1ca8-7bb5-8a88-7ea9938905af@oracle.com> (David Holmes's message of "Sat, 14 Aug 2021 10:58:04 +1000") References: <20210806100900.252926147@eggemoggin.niobe.net> <90d989fb-123f-f7e7-8f3f-3dc95a0de098@ubuntu.com> <4fd853b8-1ca8-7bb5-8a88-7ea9938905af@oracle.com> Message-ID: <87v948crcg.fsf@oldenburg.str.redhat.com> * David Holmes: > Hi Matthias, > > On 14/08/2021 2:00 am, Matthias Klose wrote: >> On 8/6/21 7:09 PM, mark.reinhold at oracle.com wrote: >>> There are no unresolved P1 bugs in build 35, so that is our >>> first JDK 17 Release Candidate. >>> >>> Binaries available here, as usual: https://jdk.java.net/17 >> this fails to build with glibc 2.34, i.e. on recent Fedora and >> Ubuntu >> development versions: >> /<>/test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c: >> In >> function 'set_signal_handler': >> /<>/test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c:72:15: >> error: storage size of 'altstack' isn't constant >> 72 | static char altstack[SIGSTKSZ]; >> | ^~~~~~~~ >> gmake[4]: *** [test/JtregNativeHotspot.gmk:1525: >> /<>/build/support/test/hotspot/jtreg/native/support/exeinvoke/exeinvoke.o] >> Error 1 > > That seems like a glibc bug to me as SIGSTKSZ is supposed to be a constant. It is still a constant in glibc's POSIX mode, but OpenJDK does not use POSIX mode (with good reason). 8192 bytes is really tight on AVX-512 capability CPUs, so the code could still be buggy if it compiled. Thanks, Florian From doko at ubuntu.com Sat Aug 14 09:53:46 2021 From: doko at ubuntu.com (Matthias Klose) Date: Sat, 14 Aug 2021 11:53:46 +0200 Subject: JDK 17: First Release Candidate In-Reply-To: References: <20210806100900.252926147@eggemoggin.niobe.net> <90d989fb-123f-f7e7-8f3f-3dc95a0de098@ubuntu.com> <4fd853b8-1ca8-7bb5-8a88-7ea9938905af@oracle.com> Message-ID: On 8/14/21 11:21 AM, David Holmes wrote: > On 14/08/2021 6:06 pm, Matthias Klose wrote: >> On 8/14/21 2:58 AM, David Holmes wrote: >>> Hi Matthias, >>> >>> On 14/08/2021 2:00 am, Matthias Klose wrote: >>>> On 8/6/21 7:09 PM, mark.reinhold at oracle.com wrote: >>>>> There are no unresolved P1 bugs in build 35, so that is our >>>>> first JDK 17 Release Candidate. >>>>> >>>>> Binaries available here, as usual: https://jdk.java.net/17 >>>> >>>> this fails to build with glibc 2.34, i.e. on recent Fedora and Ubuntu >>>> development versions: >>>> >>>> /<>/test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c: In >>>> function 'set_signal_handler': >>>> /<>/test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c:72:15: >>>> error: storage size of 'altstack' isn't constant >>>> ???? 72 |?? static char altstack[SIGSTKSZ]; >>>> ??????? |?????????????? ^~~~~~~~ >>>> gmake[4]: *** [test/JtregNativeHotspot.gmk:1525: >>>> /<>/build/support/test/hotspot/jtreg/native/support/exeinvoke/exeinvoke.o] >>>> >>>> >>>> Error 1 >>> >>> That seems like a glibc bug to me as SIGSTKSZ is supposed to be a constant. >> >> No, this change is intentional according to the glibc 2.34 release notes: >> * Add _SC_MINSIGSTKSZ and _SC_SIGSTKSZ.? When _DYNAMIC_STACK_SIZE_SOURCE >> ?? or _GNU_SOURCE are defined, MINSIGSTKSZ and SIGSTKSZ are no longer >> ?? constant on Linux.? MINSIGSTKSZ is redefined to sysconf(_SC_MINSIGSTKSZ) >> ?? and SIGSTKSZ is redefined to sysconf (_SC_SIGSTKSZ).? This supports >> ?? dynamic sized register sets for modern architectural features like >> ?? Arm SVE. > > Well that is annoying ... I wonder if we can stop building with _GNU_SOURCE so > that we maintain Posix compatibility? > > We can look at working around this somehow, but not being able to build is not, > I believe, a showstopper in terms of the JDK 17 release. Can you file a bug? > Otherwise I will. this is now JDK-8272472. Matthias From mik3hall at gmail.com Sat Aug 14 15:22:30 2021 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 14 Aug 2021 10:22:30 -0500 Subject: Building jdk on OS/X Message-ID: Seeing the recent comments on build problems I was curious enough to try building on OS/X. I followed the directions here? https://hg.openjdk.java.net/jdk-updates/jdk9u/raw-file/tip/common/doc/building.html I get errors like? === Output from failing command(s) repeated here === * For target buildtools_buildtools_hotspot_tools_classes__the.BUILD_TOOLS_HOTSPOT_batch: warning: [path] bad path element "/Library/Frameworks/BSF4ooRexx.framework/Classes/bsf4ooRexx-v641-20190830-bin.jar": no such file or directory warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program/classes/ridl.jar": no such file or directory warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program/classes/jurt.jar": no such file or directory warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program/classes/juh.jar": no such file or directory warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program/classes/unoil.jar": no such file or directory warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program": no such file or directory warning: [path] bad path element "/Library/Frameworks/BSF4ooRexx.framework/Classes/bsf4ooRexx-v641-20191126-bin.jar": no such file or directory error: warnings found and -Werror specified 1 error 7 warnings First try I moved the concerned application (OpenOffice.app) and framework (BSF4ooRexx.framework) out of the way. The error persisted. Seeing that make clean removed make but not config files I removed the jdk directory and cloned the repository again and the error persisted. After spending some time trying to determine how to change compile options to eliminate the 'warnings as error' it occurred to me that these are not compile errors and no compiler option change will probably be a fix. My questions are? Where is these files having been present persisted? Why does building the jdk have anything to do with them? From mik3hall at gmail.com Sun Aug 15 11:25:47 2021 From: mik3hall at gmail.com (Michael Hall) Date: Sun, 15 Aug 2021 06:25:47 -0500 Subject: Building jdk on OS/X In-Reply-To: References: Message-ID: <01C2122F-AAD5-4712-8F62-F2E40E55A792@gmail.com> > On Aug 14, 2021, at 10:22 AM, Michael Hall wrote: > > Seeing the recent comments on build problems I was curious enough to try building on OS/X. > I followed the directions here? > https://hg.openjdk.java.net/jdk-updates/jdk9u/raw-file/tip/common/doc/building.html > I get errors like? > > === Output from failing command(s) repeated here === > * For target buildtools_buildtools_hotspot_tools_classes__the.BUILD_TOOLS_HOTSPOT_batch: > warning: [path] bad path element "/Library/Frameworks/BSF4ooRexx.framework/Classes/bsf4ooRexx-v641-20190830-bin.jar": no such file or directory > warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program/classes/ridl.jar": no such file or directory > warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program/classes/jurt.jar": no such file or directory > warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program/classes/juh.jar": no such file or directory > warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program/classes/unoil.jar": no such file or directory > warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program": no such file or directory > warning: [path] bad path element "/Library/Frameworks/BSF4ooRexx.framework/Classes/bsf4ooRexx-v641-20191126-bin.jar": no such file or directory > error: warnings found and -Werror specified > 1 error > 7 warnings I ended up doing a search and started to eliminate -Werror occurrences. It indicated something in the configuration had changed and had me do make reconfigure The above warnings occurred many times but didn?t fail the build which worked build/macosx-x86_64-server-release/jdk/bin/java -version openjdk version "18-internal" 2022-03-15 OpenJDK Runtime Environment (build 18-internal+0-adhoc.mjh.jdk) OpenJDK 64-Bit Server VM (build 18-internal+0-adhoc.mjh.jdk, mixed mode) If this is a known issue feel free to ignore. If I should ask about it on another list please let me know. Thanks. From david.holmes at oracle.com Sun Aug 15 12:17:13 2021 From: david.holmes at oracle.com (David Holmes) Date: Sun, 15 Aug 2021 22:17:13 +1000 Subject: JDK 17: First Release Candidate In-Reply-To: <87v948crcg.fsf@oldenburg.str.redhat.com> References: <20210806100900.252926147@eggemoggin.niobe.net> <90d989fb-123f-f7e7-8f3f-3dc95a0de098@ubuntu.com> <4fd853b8-1ca8-7bb5-8a88-7ea9938905af@oracle.com> <87v948crcg.fsf@oldenburg.str.redhat.com> Message-ID: On 14/08/2021 7:23 pm, Florian Weimer wrote: > * David Holmes: > >> Hi Matthias, >> >> On 14/08/2021 2:00 am, Matthias Klose wrote: >>> On 8/6/21 7:09 PM, mark.reinhold at oracle.com wrote: >>>> There are no unresolved P1 bugs in build 35, so that is our >>>> first JDK 17 Release Candidate. >>>> >>>> Binaries available here, as usual: https://jdk.java.net/17 >>> this fails to build with glibc 2.34, i.e. on recent Fedora and >>> Ubuntu >>> development versions: >>> /<>/test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c: >>> In >>> function 'set_signal_handler': >>> /<>/test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c:72:15: >>> error: storage size of 'altstack' isn't constant >>> 72 | static char altstack[SIGSTKSZ]; >>> | ^~~~~~~~ >>> gmake[4]: *** [test/JtregNativeHotspot.gmk:1525: >>> /<>/build/support/test/hotspot/jtreg/native/support/exeinvoke/exeinvoke.o] >>> Error 1 >> >> That seems like a glibc bug to me as SIGSTKSZ is supposed to be a constant. > > It is still a constant in glibc's POSIX mode, but OpenJDK does not use > POSIX mode (with good reason). 8192 bytes is really tight on AVX-512 > capability CPUs, so the code could still be buggy if it compiled. Please note this only relates to building a test file not the product, so we should be able to change the way the test is built with no issue. Cheers, David > Thanks, > Florian > From david.holmes at oracle.com Sun Aug 15 12:25:47 2021 From: david.holmes at oracle.com (David Holmes) Date: Sun, 15 Aug 2021 22:25:47 +1000 Subject: JDK 17: First Release Candidate In-Reply-To: <87v948crcg.fsf@oldenburg.str.redhat.com> References: <20210806100900.252926147@eggemoggin.niobe.net> <90d989fb-123f-f7e7-8f3f-3dc95a0de098@ubuntu.com> <4fd853b8-1ca8-7bb5-8a88-7ea9938905af@oracle.com> <87v948crcg.fsf@oldenburg.str.redhat.com> Message-ID: <0da42ec2-a548-33d3-d865-2c6cc65fec3f@oracle.com> Hi Florian, Just to follow up on a different point ... On 14/08/2021 7:23 pm, Florian Weimer wrote: > * David Holmes: > >> Hi Matthias, >> >> On 14/08/2021 2:00 am, Matthias Klose wrote: >>> On 8/6/21 7:09 PM, mark.reinhold at oracle.com wrote: >>>> There are no unresolved P1 bugs in build 35, so that is our >>>> first JDK 17 Release Candidate. >>>> >>>> Binaries available here, as usual: https://jdk.java.net/17 >>> this fails to build with glibc 2.34, i.e. on recent Fedora and >>> Ubuntu >>> development versions: >>> /<>/test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c: >>> In >>> function 'set_signal_handler': >>> /<>/test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c:72:15: >>> error: storage size of 'altstack' isn't constant >>> 72 | static char altstack[SIGSTKSZ]; >>> | ^~~~~~~~ >>> gmake[4]: *** [test/JtregNativeHotspot.gmk:1525: >>> /<>/build/support/test/hotspot/jtreg/native/support/exeinvoke/exeinvoke.o] >>> Error 1 >> >> That seems like a glibc bug to me as SIGSTKSZ is supposed to be a constant. > > It is still a constant in glibc's POSIX mode, but OpenJDK does not use > POSIX mode (with good reason). Can you elaborate on what that good reason is please? If this is something critical then it really needs to be documented somewhere. It makes me uncomfortable that we have spent a lot of time cleaning up hotspot runtime code to provide shared "posix" implementations, if we may not even be getting Posix semantics. Thanks, David > 8192 bytes is really tight on AVX-512 > capability CPUs, so the code could still be buggy if it compiled. > > Thanks, > Florian > From Rony.Flatscher at wu.ac.at Sun Aug 15 12:50:47 2021 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Sun, 15 Aug 2021 14:50:47 +0200 Subject: Building jdk on OS/X In-Reply-To: References: Message-ID: On 14.08.2021 17:22, Michael Hall wrote: > Seeing the recent comments on build problems I was curious enough to try building on OS/X. > I followed the directions here? > https://hg.openjdk.java.net/jdk-updates/jdk9u/raw-file/tip/common/doc/building.html > I get errors like? > > === Output from failing command(s) repeated here === > * For target buildtools_buildtools_hotspot_tools_classes__the.BUILD_TOOLS_HOTSPOT_batch: > warning: [path] bad path element "/Library/Frameworks/BSF4ooRexx.framework/Classes/bsf4ooRexx-v641-20190830-bin.jar": no such file or directory > warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program/classes/ridl.jar": no such file or directory > warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program/classes/jurt.jar": no such file or directory > warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program/classes/juh.jar": no such file or directory > warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program/classes/unoil.jar": no such file or directory > warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program": no such file or directory > warning: [path] bad path element "/Library/Frameworks/BSF4ooRexx.framework/Classes/bsf4ooRexx-v641-20191126-bin.jar": no such file or directory > error: warnings found and -Werror specified > 1 error > 7 warnings > > First try I moved the concerned application (OpenOffice.app) and framework (BSF4ooRexx.framework) out of the way. The error persisted. Seeing that make clean removed make but not config files I removed the jdk directory and cloned the repository again and the error persisted. > After spending some time trying to determine how to change compile options to eliminate the 'warnings as error' it occurred to me that these are not compile errors and no compiler option change will probably be a fix. > > My questions are? > > Where is these files having been present persisted? > > Why does building the jdk have anything to do with them? If the errors/warnings occurred while BSF4ooRexx and OpenOffice were available, I would not know why that would be. After you removed them I would assume that CLASSPATH gets still set because of /etc/profile containing its definitions pointing at the BSF4ooRexx and OpenOffice/LibreOffice jar files. Just delete them manually (these statements usually appear at the end and carry a needle comment to ease spotting them and using "grep -v" to remove them; newer versions for MacOS wil also add the same CLASSPATH statements to ~/.zshenv (as newer versions of MacOS default to zsh). ---rony P.S.: You will find newer versions of BSF4ooRexx at , currently the MacOS support gets extended to universal libraries, also the installation scripts get changed in the process. New install packages are imminent and will carry "20210815" or later in their name. From mik3hall at gmail.com Sun Aug 15 14:03:20 2021 From: mik3hall at gmail.com (Michael Hall) Date: Sun, 15 Aug 2021 09:03:20 -0500 Subject: Building jdk on OS/X In-Reply-To: References: Message-ID: > On Aug 15, 2021, at 7:50 AM, Rony G. Flatscher wrote: > > On 14.08.2021 17:22, Michael Hall wrote: >> Seeing the recent comments on build problems I was curious enough to try building on OS/X. >> I followed the directions here? >> https://hg.openjdk.java.net/jdk-updates/jdk9u/raw-file/tip/common/doc/building.html > >> I get errors like? >> >> === Output from failing command(s) repeated here === >> * For target buildtools_buildtools_hotspot_tools_classes__the.BUILD_TOOLS_HOTSPOT_batch: >> warning: [path] bad path element "/Library/Frameworks/BSF4ooRexx.framework/Classes/bsf4ooRexx-v641-20190830-bin.jar": no such file or directory >> warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program/classes/ridl.jar": no such file or directory >> warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program/classes/jurt.jar": no such file or directory >> warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program/classes/juh.jar": no such file or directory >> warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program/classes/unoil.jar": no such file or directory >> warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program": no such file or directory >> warning: [path] bad path element "/Library/Frameworks/BSF4ooRexx.framework/Classes/bsf4ooRexx-v641-20191126-bin.jar": no such file or directory >> error: warnings found and -Werror specified >> 1 error >> 7 warnings >> >> > > If the errors/warnings occurred while BSF4ooRexx and OpenOffice were available, I would not know why > that would be. In searching for related I think I did find one StackOverflow that suggested something like this could occur if jar file manifests contained class path information that was invalid. I didn?t follow up in checking on this. But yes it was strange getting not found errors when they were there. > > After you removed them I would assume that CLASSPATH gets still set because of /etc/profile > containing its definitions pointing at the BSF4ooRexx and OpenOffice/LibreOffice jar files. Just > delete them manually (these statements usually appear at the end and carry a needle comment to ease > spotting them and using "grep -v" to remove them; newer versions for MacOS wil also add the same > CLASSPATH statements to ~/.zshenv (as newer versions of MacOS default to zsh). export CLASSPATH=$CLASSPATH:/Library/Frameworks/BSF4ooRexx.framework/Classes/bsf4ooRexx-v641-20190830-bin.jar # BSF4ooRexxNeedle Correct. I will remove them. I will check to see if these are older and no longer match the jar files actually present. That might explain the not founds even though the application and framework were there. > > ---rony > > P.S.: You will find newer versions of BSF4ooRexx at > >, currently the MacOS support gets > extended to universal libraries, also the installation scripts get changed in the process. New > install packages are imminent and will carry "20210815" or later in their name. I didn?t do too much with Rexx. I had hoped to embed it into another application and if I remember correctly I had some difficulty with that. Mainframe Rexx helped pay my bills for a number of years and I would be happy to include some support. I will look at it again if I get a chance. Thanks for the reply. From mik3hall at gmail.com Sun Aug 15 15:45:29 2021 From: mik3hall at gmail.com (Michael Hall) Date: Sun, 15 Aug 2021 10:45:29 -0500 Subject: Building jdk on OS/X In-Reply-To: References: Message-ID: > On Aug 15, 2021, at 9:03 AM, Michael Hall wrote: > >> >> After you removed them I would assume that CLASSPATH gets still set because of /etc/profile >> containing its definitions pointing at the BSF4ooRexx and OpenOffice/LibreOffice jar files. Just >> delete them manually (these statements usually appear at the end and carry a needle comment to ease >> spotting them and using "grep -v" to remove them; newer versions for MacOS wil also add the same >> CLASSPATH statements to ~/.zshenv (as newer versions of MacOS default to zsh). > > export CLASSPATH=$CLASSPATH:/Library/Frameworks/BSF4ooRexx.framework/Classes/bsf4ooRexx-v641-20190830-bin.jar # BSF4ooRexxNeedle > > Correct. I will remove them. I will check to see if these are older and no longer match the jar files actually present. That might explain the not founds even though the application and framework were there. Path mismatches to older entries in /etc/profile does not seem correct - they do seem to match up to active current entries. If I had to make a guess at this point it would be that the build process has problems with class path entries from /etc/profile that involve Mac alias?s. For OpenOffice there is /Applications/OpenOffice.app/Contents/program Which finder indicates is an alias with the actual contents being in /Applications/OpenOffice.app/Contents/MacOS I tried to find something decent command line to demonstrate this but they seem to fail to show it. SO suggests something like? mdls -raw -name kMDItemContentType /Applications/OpenOffice.app/Contents/program public.folder Which doesn?t show it as an alias? For your BSF4ooRexx /Library/Frameworks/BSF4ooRexx.framework/Classes is an alias as Finder get info shows to Versions/A Again mdls doesn?t show it as an alias and I would ?guess? at this point that somehow the build process doesn?t correctly resolve the alias to the actual file either but indicates one off of the alias path is missing. From david.holmes at oracle.com Mon Aug 16 00:31:43 2021 From: david.holmes at oracle.com (David Holmes) Date: Mon, 16 Aug 2021 10:31:43 +1000 Subject: Building jdk on OS/X In-Reply-To: References: Message-ID: <171353ad-ad66-2ce8-a924-d888b01ebf46@oracle.com> Redirecting to the build-dev alias. On 15/08/2021 1:22 am, Michael Hall wrote: > Seeing the recent comments on build problems I was curious enough to try building on OS/X. > I followed the directions here? > https://hg.openjdk.java.net/jdk-updates/jdk9u/raw-file/tip/common/doc/building.html > I get errors like? > > === Output from failing command(s) repeated here === > * For target buildtools_buildtools_hotspot_tools_classes__the.BUILD_TOOLS_HOTSPOT_batch: > warning: [path] bad path element "/Library/Frameworks/BSF4ooRexx.framework/Classes/bsf4ooRexx-v641-20190830-bin.jar": no such file or directory > warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program/classes/ridl.jar": no such file or directory > warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program/classes/jurt.jar": no such file or directory > warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program/classes/juh.jar": no such file or directory > warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program/classes/unoil.jar": no such file or directory > warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program": no such file or directory > warning: [path] bad path element "/Library/Frameworks/BSF4ooRexx.framework/Classes/bsf4ooRexx-v641-20191126-bin.jar": no such file or directory > error: warnings found and -Werror specified > 1 error > 7 warnings I would not expect any of the Java based build tools to be picking up any default classpath elements from the environment. But I suppose this could be a problem if your boot JDK actually refers to wrapper scripts that do set such a classpath. I would need to see more details from the build log as to what was actually being executed. Cheers, David > First try I moved the concerned application (OpenOffice.app) and framework (BSF4ooRexx.framework) out of the way. The error persisted. Seeing that make clean removed make but not config files I removed the jdk directory and cloned the repository again and the error persisted. > After spending some time trying to determine how to change compile options to eliminate the 'warnings as error' it occurred to me that these are not compile errors and no compiler option change will probably be a fix. > > My questions are? > > Where is these files having been present persisted? > > Why does building the jdk have anything to do with them? > From mik3hall at gmail.com Mon Aug 16 01:05:34 2021 From: mik3hall at gmail.com (Michael Hall) Date: Sun, 15 Aug 2021 20:05:34 -0500 Subject: Building jdk on OS/X In-Reply-To: <171353ad-ad66-2ce8-a924-d888b01ebf46@oracle.com> References: <171353ad-ad66-2ce8-a924-d888b01ebf46@oracle.com> Message-ID: <149F8F2A-83F9-4CCA-B47A-ACD167849877@gmail.com> > On Aug 15, 2021, at 7:31 PM, David Holmes wrote: > > Redirecting to the build-dev alias. > > On 15/08/2021 1:22 am, Michael Hall wrote: >> Seeing the recent comments on build problems I was curious enough to try building on OS/X. >> I followed the directions here? >> https://hg.openjdk.java.net/jdk-updates/jdk9u/raw-file/tip/common/doc/building.html > >> I get errors like? >> === Output from failing command(s) repeated here === >> * For target buildtools_buildtools_hotspot_tools_classes__the.BUILD_TOOLS_HOTSPOT_batch: >> warning: [path] bad path element "/Library/Frameworks/BSF4ooRexx.framework/Classes/bsf4ooRexx-v641-20190830-bin.jar": no such file or directory >> warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program/classes/ridl.jar": no such file or directory >> warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program/classes/jurt.jar": no such file or directory >> warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program/classes/juh.jar": no such file or directory >> warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program/classes/unoil.jar": no such file or directory >> warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program": no such file or directory >> warning: [path] bad path element "/Library/Frameworks/BSF4ooRexx.framework/Classes/bsf4ooRexx-v641-20191126-bin.jar": no such file or directory >> error: warnings found and -Werror specified >> 1 error >> 7 warnings > > I would not expect any of the Java based build tools to be picking up any default classpath elements from the environment. But I suppose this could be a problem if your boot JDK actually refers to wrapper scripts that do set such a classpath. I would need to see more details from the build log as to what was actually being executed. It appears to be the OS/X Terminal application that picks it up and adds it to the environment and the installation process picks it up from the environment there. I had deleted the /etc/profile entries that Rony had indicated. Make still picked up a couple of the errors above. I rebooted and then got a clean build. Just quitting and restarting Terminal probably would have also worked. I had just installed the newer BSF4ooRexx version mentioned by Rony. It also had the export CLASSPATH entries for both BSF4ooRexx and OpenOffice so it appears that the BSF4ooRexx install is the source for both of those. I removed them and had been able to build the JDK. Right after that I got your email. So I uninstalled BSF4ooRexx and reinstalled to get the /etc/profile export CLASSPATH?s again. The jdk build was still working. oops. I quit and restarted Terminal. It failed as before. If you are interested in the build.log it is pretty much as above. Building target 'images' in configuration 'macosx-x86_64-server-release' Compiling 1 files for BUILD_TOOLS_HOTSPOT Compiling 8 files for BUILD_TOOLS_LANGTOOLS warning: [path] bad path element "/Applications/OpenOffice.app/Contents/lib": no such file or directory warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program/bin": no such file or directory error: warnings found and -Werror specified 1 error 2 warnings make[3]: *** [/Users/mjh/jdk/build/macosx-x86_64-server-release/buildtools/buildtools/hotspot_tools_classes/_the.BUILD_TOOLS_HOTSPOT_batch] Error 1 make[2]: *** [buildtools-hotspot] Error 2 make[2]: *** Waiting for unfinished jobs.... warning: [path] bad path element "/Applications/OpenOffice.app/Contents/lib": no such file or directory warning: [path] bad path element "/Applications/OpenOffice.app/Contents/program/bin": no such file or directory error: warnings found and -Werror specified 1 error 2 warnings make[3]: *** [/Users/mjh/jdk/build/macosx-x86_64-server-release/buildtools/langtools_tools_classes/_the.BUILD_TOOLS_LANGTOOLS_batch] Error 1 make[2]: *** [buildtools-langtools] Error 2 ERROR: Build failed for target 'images' in configuration 'macosx-x86_64-server-release' (exit code 2) If you are considering supporting this and not setting to ignore the environment I think you might get the not found type errors because the paths involved include Mac alias?s. You might need to look and see if they are getting resolved correctly. Normally this might not be a concern for your builds either. From fweimer at redhat.com Mon Aug 16 09:50:59 2021 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 16 Aug 2021 11:50:59 +0200 Subject: JDK 17: First Release Candidate In-Reply-To: <0da42ec2-a548-33d3-d865-2c6cc65fec3f@oracle.com> (David Holmes's message of "Sun, 15 Aug 2021 22:25:47 +1000") References: <20210806100900.252926147@eggemoggin.niobe.net> <90d989fb-123f-f7e7-8f3f-3dc95a0de098@ubuntu.com> <4fd853b8-1ca8-7bb5-8a88-7ea9938905af@oracle.com> <87v948crcg.fsf@oldenburg.str.redhat.com> <0da42ec2-a548-33d3-d865-2c6cc65fec3f@oracle.com> Message-ID: <87pmudbtvg.fsf@oldenburg.str.redhat.com> * David Holmes: >>> That seems like a glibc bug to me as SIGSTKSZ is supposed to be a constant. >> It is still a constant in glibc's POSIX mode, but OpenJDK does not >> use POSIX mode (with good reason). > > Can you elaborate on what that good reason is please? If this is > something critical then it really needs to be documented somewhere. It > makes me uncomfortable that we have spent a lot of time cleaning up > hotspot runtime code to provide shared "posix" implementations, if we > may not even be getting Posix semantics. glibc's POSIX mode removes all declarations and definitions from its header files which are not part of the requested POSIX version (at least in theory; there are of course bugs). This is based on what is in the actual standard, not on what typical implementations support. For example, the functions lseek64 and ftruncate64 are used in src/hotspot/os/posix/os_posix.cpp but are not part of any POSIX version. gethostbyname is no longer part of POSIX, either. Thanks, Florian From david.holmes at oracle.com Mon Aug 16 12:24:58 2021 From: david.holmes at oracle.com (David Holmes) Date: Mon, 16 Aug 2021 22:24:58 +1000 Subject: JDK 17: First Release Candidate In-Reply-To: <87pmudbtvg.fsf@oldenburg.str.redhat.com> References: <20210806100900.252926147@eggemoggin.niobe.net> <90d989fb-123f-f7e7-8f3f-3dc95a0de098@ubuntu.com> <4fd853b8-1ca8-7bb5-8a88-7ea9938905af@oracle.com> <87v948crcg.fsf@oldenburg.str.redhat.com> <0da42ec2-a548-33d3-d865-2c6cc65fec3f@oracle.com> <87pmudbtvg.fsf@oldenburg.str.redhat.com> Message-ID: <14dad2e6-99f3-acc2-d89c-24b5b860a04f@oracle.com> On 16/08/2021 7:50 pm, Florian Weimer wrote: > * David Holmes: > >>>> That seems like a glibc bug to me as SIGSTKSZ is supposed to be a constant. > >>> It is still a constant in glibc's POSIX mode, but OpenJDK does not >>> use POSIX mode (with good reason). >> >> Can you elaborate on what that good reason is please? If this is >> something critical then it really needs to be documented somewhere. It >> makes me uncomfortable that we have spent a lot of time cleaning up >> hotspot runtime code to provide shared "posix" implementations, if we >> may not even be getting Posix semantics. > > glibc's POSIX mode removes all declarations and definitions from its > header files which are not part of the requested POSIX version (at least > in theory; there are of course bugs). This is based on what is in the > actual standard, not on what typical implementations support. > > For example, the functions lseek64 and ftruncate64 are used in > src/hotspot/os/posix/os_posix.cpp but are not part of any POSIX version. > gethostbyname is no longer part of POSIX, either. Ah I see - thanks for the explanation Florian! I'll see where we can/should document this. David > Thanks, > Florian > From mark.yagnatinsky at barclays.com Mon Aug 16 18:22:17 2021 From: mark.yagnatinsky at barclays.com (mark.yagnatinsky at barclays.com) Date: Mon, 16 Aug 2021 18:22:17 +0000 Subject: since method references can be as debug-friendly as lambda expressions, perhaps they should be? Message-ID: I recently saw a cool blog post by Tagir Valeev about how to make method references as debug-friendly as lambda expressions: https://habr.com/en/post/569414/ If something like this were adopted, then Java developers could choose lambda expressions vs method references purely based on what makes the code easier to read, instead of having to make annoying trade-offs such as "a method reference is more readable in this case, but a lambda expression will give me better stack traces if something goes wrong". Thoughts? _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ ?This message is for information purposes only, it is not a recommendation, advice, offer or solicitation to buy or sell a product or service nor an official confirmation of any transaction. It is directed at persons who are professionals and is not intended for retail customer use. Intended for recipient only. This message is subject to the terms at: www.barclays.com/emaildisclaimer. For important disclosures, please see: www.barclays.com/salesandtradingdisclaimer regarding market commentary from Barclays Sales and/or Trading, who are active market participants; https://www.investmentbank.barclays.com/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for the Investment Bank of Barclays where we trade with you in principal-to-principal wholesale markets transactions; and in respect of Barclays Research, including disclosures relating to specific issuers, please see http://publicresearch.barclays.com.? _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ If you are incorporated or operating in Australia, please see https://www.home.barclays/disclosures/importantapacdisclosures.html for important disclosure. _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ How we use personal information see our privacy notice https://www.investmentbank.barclays.com/disclosures/personalinformationuse.html _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ From forax at univ-mlv.fr Mon Aug 16 21:22:34 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 16 Aug 2021 23:22:34 +0200 (CEST) Subject: since method references can be as debug-friendly as lambda expressions, perhaps they should be? In-Reply-To: References: Message-ID: <254154189.268912.1629148954255.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "mark yagnatinsky" > To: "jdk-dev" > Sent: Lundi 16 Ao?t 2021 20:22:17 > Subject: since method references can be as debug-friendly as lambda expressions, perhaps they should be? > I recently saw a cool blog post by Tagir Valeev about how to make method > references as debug-friendly as lambda expressions: > https://habr.com/en/post/569414/ > If something like this were adopted, then Java developers could choose lambda > expressions vs method references purely based on what makes the code easier to > read, instead of having to make annoying trade-offs such as "a method reference > is more readable in this case, but a lambda expression will give me better > stack traces if something goes wrong". > > Thoughts? It's a fun hack, and i don't think anyone want such horror in the real implementation. There is also an issue if in the future we want to use a ldc constant dynamic instead of invokedynamic in the generated code because in that case, the lambda proxy will be shared in between two method references Consumer c1 = Objects::requireNonNull; Consumer c2 = Objects::requireNonNull; regards, R?mi From mark.yagnatinsky at barclays.com Mon Aug 16 21:41:12 2021 From: mark.yagnatinsky at barclays.com (mark.yagnatinsky at barclays.com) Date: Mon, 16 Aug 2021 21:41:12 +0000 Subject: since method references can be as debug-friendly as lambda expressions, perhaps they should be? In-Reply-To: <254154189.268912.1629148954255.JavaMail.zimbra@u-pem.fr> References: <254154189.268912.1629148954255.JavaMail.zimbra@u-pem.fr> Message-ID: > It's a fun hack, and i don't think anyone want such horror in the real implementation. Is it fixable, or is there likely no non-hacky way to do this? > There is also an issue if in the future we want to use a ldc constant dynamic instead of invokedynamic in the generated code because in that case, the lambda proxy will be shared in between two method references That sounds like an argument to just not do that then, just as we don't optimize tail calls today for partly the same reason: to keep stack traces more readable. Or not so simple? _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ ?This message is for information purposes only, it is not a recommendation, advice, offer or solicitation to buy or sell a product or service nor an official confirmation of any transaction. It is directed at persons who are professionals and is not intended for retail customer use. Intended for recipient only. This message is subject to the terms at: www.barclays.com/emaildisclaimer. For important disclosures, please see: www.barclays.com/salesandtradingdisclaimer regarding market commentary from Barclays Sales and/or Trading, who are active market participants; https://www.investmentbank.barclays.com/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for the Investment Bank of Barclays where we trade with you in principal-to-principal wholesale markets transactions; and in respect of Barclays Research, including disclosures relating to specific issuers, please see http://publicresearch.barclays.com.? _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ If you are incorporated or operating in Australia, please see https://www.home.barclays/disclosures/importantapacdisclosures.html for important disclosure. _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ How we use personal information see our privacy notice https://www.investmentbank.barclays.com/disclosures/personalinformationuse.html _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ From stefan.johansson at oracle.com Wed Aug 18 09:05:04 2021 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Wed, 18 Aug 2021 11:05:04 +0200 Subject: CFV: New JDK Reviewer: Albert Mingkun Yang In-Reply-To: References: Message-ID: <93da31f4-3f3f-33b3-3e69-d8bf6ffe12c2@oracle.com> Vote: yes On 2021-08-04 12:33, Thomas Schatzl wrote: > Hi all, > > ? I hereby nominate Albert Mingkun Yang (ayang[1]) to the role of JDK > Project Reviewer. > > Albert is currently a JDK committer, member of the Garbage Collection > team at Oracle for a few years now, and has, before joining Oracle, been > working on garbage collection with ZGC during his PhD (e.g. [2], [3]). > > He has made substantial contributions [4] to the development of the > mostly G1 and ZGC, in particular just recently an algorithm to > dynamically adjust the number of concurrent threads for ZGC [5], and has > in total made 60 individual contributions to the JDK project. > > Only current JDK Project Reviewers [6] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > For Three-Vote Consensus voting instructions, see [7]. > > Votes are due by 12:00 UTC on 18th of August 2021. > > Thomas > > [1] https://openjdk.java.net/census#ayang > [2] https://dl.acm.org/doi/abs/10.1145/3381898.3397213 > [3] https://dl.acm.org/doi/abs/10.1145/3385412.3385977 > [4] > https://github.com/openjdk/jdk/search?p=1&q=author-name%3A%22Albert+Yang%22&type=commits > > [5] https://bugs.openjdk.java.net/browse/JDK-8268372 > [6] https://openjdk.java.net/census > [7] https://openjdk.java.net/projects/#reviewer-vote From coderodd3 at gmail.com Wed Aug 18 12:34:38 2021 From: coderodd3 at gmail.com (Rodion Efremov) Date: Wed, 18 Aug 2021 15:34:38 +0300 Subject: [(Much) faster java.util.LinkedList] Message-ID: Hello, I have implemented a heuristic, indexed doubly-linked list data structure [1][2] implementing java.util.List and java.util.Deque interfaces that has superior performance compared to java.util.LinkedList and java.util.ArrayList. I would like to propose it into the upcoming versions of OpenJDK, but, first, I need to know what do you think about it? Best regards, rodde [1] https://github.com/coderodde/LinkedList [2] http://coderodde.github.io/weblog/#eill From mark.reinhold at oracle.com Wed Aug 18 16:20:00 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 18 Aug 2021 09:20:00 -0700 (PDT) Subject: JEP proposed to target JDK 18: 400: UTF-8 by Default Message-ID: <20210818162000.B24DD3EF250@eggemoggin.niobe.net> The following JEP is proposed to target JDK 18: 400: UTF-8 by Default https://openjdk.java.net/jeps/400 Summary: Specify UTF-8 as the default charset of the standard Java APIs. With this change, APIs that depend upon the default charset will behave consistently across all implementations, operating systems, locales, and configurations. Feedback on this proposal from JDK Project Committers and Reviewers [1] is more than welcome, as are reasoned objections. If no such objections are raised by 23:59 UTC on Wednesday, 25 August, or if they?re raised and then satisfactorily answered, then per the JEP 2.0 process proposal [2] I?ll target this JEP to JDK 18. - Mark [1] https://openjdk.java.net/census#jdk [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From forax at univ-mlv.fr Wed Aug 18 17:03:10 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 18 Aug 2021 19:03:10 +0200 (CEST) Subject: JEP proposed to target JDK 18: 400: UTF-8 by Default In-Reply-To: <20210818162000.B24DD3EF250@eggemoggin.niobe.net> References: <20210818162000.B24DD3EF250@eggemoggin.niobe.net> Message-ID: <495293099.720409.1629306190011.JavaMail.zimbra@u-pem.fr> A minor comment, there is a sentence in the JEP that is weird. "However, having to pass an argument prevents these methods from being used via method references (::) in stream pipelines." You can not use these methods in a Stream anyway because they are declared with "throws IOException", so this argument does not hold. I think this sentence should be removed. The real argument is later in the same section, currently old APIs use the default charset and new APIs use UTF8, so we are asking developers to know the javadoc of these methods by heart. regards, R?mi ----- Original Message ----- > From: "mark reinhold" > To: "jdk-dev" > Sent: Mercredi 18 Ao?t 2021 18:20:00 > Subject: JEP proposed to target JDK 18: 400: UTF-8 by Default > The following JEP is proposed to target JDK 18: > > 400: UTF-8 by Default > https://openjdk.java.net/jeps/400 > > Summary: Specify UTF-8 as the default charset of the standard Java > APIs. With this change, APIs that depend upon the default charset > will behave consistently across all implementations, operating systems, > locales, and configurations. > > Feedback on this proposal from JDK Project Committers and Reviewers [1] > is more than welcome, as are reasoned objections. If no such objections > are raised by 23:59 UTC on Wednesday, 25 August, or if they?re raised > and then satisfactorily answered, then per the JEP 2.0 process proposal > [2] I?ll target this JEP to JDK 18. > > - Mark > > > [1] https://openjdk.java.net/census#jdk > [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From szegedia at gmail.com Wed Aug 18 18:11:30 2021 From: szegedia at gmail.com (Attila Szegedi) Date: Wed, 18 Aug 2021 20:11:30 +0200 Subject: since method references can be as debug-friendly as lambda expressions, perhaps they should be? In-Reply-To: <254154189.268912.1629148954255.JavaMail.zimbra@u-pem.fr> References: <254154189.268912.1629148954255.JavaMail.zimbra@u-pem.fr> Message-ID: <1101F84B-A808-403A-A58C-FDBB4B5E407C@gmail.com> > On 2021. Aug 16., at 23:22, Remi Forax wrote: >> > It's a fun hack, and i don't think anyone want such horror in the real implementation. Oh, it can be made less horrorific :-) JDK already has few places where specifically to avoid circular initialization dependencies, it skips some functionality. So it could use StackWalker if the streams are initialized, otherwise it could do nothing, so those few lambdas created during bootstrapping the runtime would not have this information, oh well? FWIW, I had a similar need in not so recent past where I had a trampolining evaluator that was using something akin to chained flatmaps of futures (it was a different monad, but that?s not relevant.) There it would?ve been great if I could?ve interrogated the "Test$$Lambda$14/0x0000000800c02508? object for where it was defined so I could construct an artificial stack traces of trampolined stuff. Basically, it?d be great to have an interface similar to a supplier of a StackWalker.StackFrame: interface LambdaSource { StackWalker.StackFrame getLambdaSource(); } and have lambda implementation classes optionally implement this interface too when they can, so lambda objects can be programmatically interrogated for their provenance. > > There is also an issue if in the future we want to use a ldc constant dynamic instead of invokedynamic in the generated code because in that case, > the lambda proxy will be shared in between two method references > Consumer c1 = Objects::requireNonNull; > Consumer c2 = Objects::requireNonNull; Obviously such canonicalization is desirable, but yeah, it?d make any of the above impossible :-) Attila. > > regards, > R?mi From raffaello.giulietti at gmail.com Wed Aug 18 18:48:01 2021 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Wed, 18 Aug 2021 20:48:01 +0200 Subject: [(Much) faster java.util.LinkedList] In-Reply-To: References: Message-ID: <7297da51-6490-055c-d850-365dcd7f817b@gmail.com> Hi, the first link results in a 404 error :-( I'd like to suggest you to show some JMH [1] figures to support your performance claims. Without them, it's hard to convince the community to have a look at your work. A more focused place to discuss core libs related issues and proposals is the core-libs-dev mailing list [2]. Greetings Raffaello ---- [1] https://github.com/openjdk/jmh [2] https://mail.openjdk.java.net/mailman/listinfo/core-libs-dev On 2021-08-18 14:34, Rodion Efremov wrote: > Hello, > > I have implemented a heuristic, indexed doubly-linked list data structure > [1][2] implementing java.util.List and java.util.Deque interfaces that has > superior performance compared to java.util.LinkedList and > java.util.ArrayList. > > I would like to propose it into the upcoming versions of OpenJDK, but, > first, I need to know what do you think about it? > > Best regards, > rodde > > [1] https://github.com/coderodde/LinkedList > [2] http://coderodde.github.io/weblog/#eill > From simon at cjnash.com Wed Aug 18 19:01:48 2021 From: simon at cjnash.com (Simon Nash) Date: Wed, 18 Aug 2021 20:01:48 +0100 Subject: JEP proposed to target JDK 18: 400: UTF-8 by Default In-Reply-To: <20210818162000.B24DD3EF250@eggemoggin.niobe.net> References: <20210818162000.B24DD3EF250@eggemoggin.niobe.net> Message-ID: <3821d480-78e9-47d6-b99a-5fc6df175291@cjnash.com> How should someone who is not a JDK Project Committer or Reviewer provide input to this proposal? The principle is good but I am concerned about the compatibility implications. Simon On 18/08/2021 17:20, mark.reinhold at oracle.com wrote: > The following JEP is proposed to target JDK 18: > > 400: UTF-8 by Default > https://openjdk.java.net/jeps/400 > > Summary: Specify UTF-8 as the default charset of the standard Java > APIs. With this change, APIs that depend upon the default charset > will behave consistently across all implementations, operating systems, > locales, and configurations. > > Feedback on this proposal from JDK Project Committers and Reviewers [1] > is more than welcome, as are reasoned objections. If no such objections > are raised by 23:59 UTC on Wednesday, 25 August, or if they?re raised > and then satisfactorily answered, then per the JEP 2.0 process proposal > [2] I?ll target this JEP to JDK 18. > > - Mark > > > [1] https://openjdk.java.net/census#jdk > [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html > From naoto.sato at oracle.com Wed Aug 18 19:48:07 2021 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 18 Aug 2021 12:48:07 -0700 Subject: JEP proposed to target JDK 18: 400: UTF-8 by Default In-Reply-To: <495293099.720409.1629306190011.JavaMail.zimbra@u-pem.fr> References: <20210818162000.B24DD3EF250@eggemoggin.niobe.net> <495293099.720409.1629306190011.JavaMail.zimbra@u-pem.fr> Message-ID: <93a3c337-2a0c-57fc-bd16-e6a967d21b29@oracle.com> Hi R?mi, On 8/18/21 10:03 AM, Remi Forax wrote: > A minor comment, there is a sentence in the JEP that is weird. > > "However, having to pass an argument prevents these methods from being used via method references (::) in stream pipelines." > > You can not use these methods in a Stream anyway because they are declared with "throws IOException", so this argument does not hold. > I think this sentence should be removed. Thanks. Removed the sentence. > > The real argument is later in the same section, currently old APIs use the default charset and new APIs use UTF8, so we are asking developers to know the javadoc of these methods by heart. That is correct. Reaching out to developers is the key of this JEP. In fact, that is one of the objectives of making this as a JEP. Naoto > > regards, > R?mi > > ----- Original Message ----- >> From: "mark reinhold" >> To: "jdk-dev" >> Sent: Mercredi 18 Ao?t 2021 18:20:00 >> Subject: JEP proposed to target JDK 18: 400: UTF-8 by Default > >> The following JEP is proposed to target JDK 18: >> >> 400: UTF-8 by Default >> https://openjdk.java.net/jeps/400 >> >> Summary: Specify UTF-8 as the default charset of the standard Java >> APIs. With this change, APIs that depend upon the default charset >> will behave consistently across all implementations, operating systems, >> locales, and configurations. >> >> Feedback on this proposal from JDK Project Committers and Reviewers [1] >> is more than welcome, as are reasoned objections. If no such objections >> are raised by 23:59 UTC on Wednesday, 25 August, or if they?re raised >> and then satisfactorily answered, then per the JEP 2.0 process proposal >> [2] I?ll target this JEP to JDK 18. >> >> - Mark >> >> >> [1] https://openjdk.java.net/census#jdk >> [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From raffaello.giulietti at gmail.com Wed Aug 18 19:48:59 2021 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Wed, 18 Aug 2021 21:48:59 +0200 Subject: JEP proposed to target JDK 18: 400: UTF-8 by Default In-Reply-To: <3821d480-78e9-47d6-b99a-5fc6df175291@cjnash.com> References: <20210818162000.B24DD3EF250@eggemoggin.niobe.net> <3821d480-78e9-47d6-b99a-5fc6df175291@cjnash.com> Message-ID: Hello, this JEP and its implementation have been discussed in March [1] and in July [2], resp., on the core-libs-dev mailing list (subscribing to that list is open to anybody). Greetings Raffaello ---- [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075111.html [2] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-July/079795.html On 2021-08-18 21:01, Simon Nash wrote: > How should someone who is not a JDK Project Committer or Reviewer > provide input to this proposal? The principle is good but I am concerned > about the compatibility implications. > > Simon > > On 18/08/2021 17:20, mark.reinhold at oracle.com wrote: >> The following JEP is proposed to target JDK 18: >> >> ?? 400: UTF-8 by Default >> ??????? https://openjdk.java.net/jeps/400 >> >> ?? Summary: Specify UTF-8 as the default charset of the standard Java >> ?? APIs.? With this change, APIs that depend upon the default charset >> ?? will behave consistently across all implementations, operating >> systems, >> ?? locales, and configurations. >> >> Feedback on this proposal from JDK Project Committers and Reviewers [1] >> is more than welcome, as are reasoned objections.? If no such objections >> are raised by 23:59 UTC on Wednesday, 25 August, or if they?re raised >> and then satisfactorily answered, then per the JEP 2.0 process proposal >> [2] I?ll target this JEP to JDK 18. >> >> - Mark >> >> >> [1] https://openjdk.java.net/census#jdk >> [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html >> > From naoto.sato at oracle.com Wed Aug 18 19:49:33 2021 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 18 Aug 2021 12:49:33 -0700 Subject: JEP proposed to target JDK 18: 400: UTF-8 by Default In-Reply-To: <3821d480-78e9-47d6-b99a-5fc6df175291@cjnash.com> References: <20210818162000.B24DD3EF250@eggemoggin.niobe.net> <3821d480-78e9-47d6-b99a-5fc6df175291@cjnash.com> Message-ID: <13adfe64-930d-a6cb-22a7-23678f7f09d5@oracle.com> Hi Simon, Please post your comments at core-libs-dev mailing list, where the discussion should take place. Naoto On 8/18/21 12:01 PM, Simon Nash wrote: > How should someone who is not a JDK Project Committer or Reviewer > provide input to this proposal? The principle is good but I am concerned > about the compatibility implications. > > Simon > > On 18/08/2021 17:20, mark.reinhold at oracle.com wrote: >> The following JEP is proposed to target JDK 18: >> >> ?? 400: UTF-8 by Default >> ??????? https://openjdk.java.net/jeps/400 >> >> ?? Summary: Specify UTF-8 as the default charset of the standard Java >> ?? APIs.? With this change, APIs that depend upon the default charset >> ?? will behave consistently across all implementations, operating >> systems, >> ?? locales, and configurations. >> >> Feedback on this proposal from JDK Project Committers and Reviewers [1] >> is more than welcome, as are reasoned objections.? If no such objections >> are raised by 23:59 UTC on Wednesday, 25 August, or if they?re raised >> and then satisfactorily answered, then per the JEP 2.0 process proposal >> [2] I?ll target this JEP to JDK 18. >> >> - Mark >> >> >> [1] https://openjdk.java.net/census#jdk >> [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html >> > From alex.buckley at oracle.com Wed Aug 18 20:47:53 2021 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 18 Aug 2021 13:47:53 -0700 Subject: JEP proposed to target JDK 18: 400: UTF-8 by Default In-Reply-To: <93a3c337-2a0c-57fc-bd16-e6a967d21b29@oracle.com> References: <20210818162000.B24DD3EF250@eggemoggin.niobe.net> <495293099.720409.1629306190011.JavaMail.zimbra@u-pem.fr> <93a3c337-2a0c-57fc-bd16-e6a967d21b29@oracle.com> Message-ID: On 8/18/2021 12:48 PM, Naoto Sato wrote: > On 8/18/21 10:03 AM, Remi Forax wrote: >> A minor comment, there is a sentence in the JEP that is weird. >> >> "However, having to pass an argument prevents these methods from being >> used via method references (::) in stream pipelines." >> >> You can not use these methods in a Stream anyway because they are >> declared with "throws IOException", so this argument does not hold. >> I think this sentence should be removed. > > Thanks. Removed the sentence. There is now a dangling paragraph -- "Developers familiar with such hazards can use methods that take a charset argument explicitly." -- whose words undermine the case for having a default charset at all. I recommend preserving the complaint about having to pass an argument, but rephrasing it to be less connected to the specific FileWriter/FileReader APIs in the prior paragraph (after all, there are ctors in Formatter and Scanner which use the default charset and don't throw IOException) : ----- Developers familiar with such hazards can use methods and constructors that take a charset argument explicitly. However, having to pass an argument prevents methods and constructors from being used via method references (::) in stream pipelines. [Swapped first two words, to continue the Developer theme] Developers sometimes attempt to set the default charset via ... ----- Alex From naoto.sato at oracle.com Wed Aug 18 21:21:04 2021 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 18 Aug 2021 14:21:04 -0700 Subject: JEP proposed to target JDK 18: 400: UTF-8 by Default In-Reply-To: References: <20210818162000.B24DD3EF250@eggemoggin.niobe.net> <495293099.720409.1629306190011.JavaMail.zimbra@u-pem.fr> <93a3c337-2a0c-57fc-bd16-e6a967d21b29@oracle.com> Message-ID: <005eb7e1-0479-beea-1d13-345f72c0be35@oracle.com> Thanks, Alex. Yes, distancing from FileReader/Writer would make the removed sentence stand. And the next sentence reads better with the developer focus. Modified as suggested. Naoto On 8/18/21 1:47 PM, Alex Buckley wrote: > On 8/18/2021 12:48 PM, Naoto Sato wrote: >> On 8/18/21 10:03 AM, Remi Forax wrote: >>> A minor comment, there is a sentence in the JEP that is weird. >>> >>> "However, having to pass an argument prevents these methods from >>> being used via method references (::) in stream pipelines." >>> >>> You can not use these methods in a Stream anyway because they are >>> declared with "throws IOException", so this argument does not hold. >>> I think this sentence should be removed. >> >> Thanks. Removed the sentence. > > There is now a dangling paragraph -- "Developers familiar with such > hazards can use methods that take a charset argument explicitly." -- > whose words undermine the case for having a default charset at all. > > I recommend preserving the complaint about having to pass an argument, > but rephrasing it to be less connected to the specific > FileWriter/FileReader APIs in the prior paragraph (after all, there are > ctors in Formatter and Scanner which use the default charset and don't > throw IOException) : > > ----- > Developers familiar with such hazards can use methods and constructors > that take a charset argument explicitly. However, having to pass an > argument prevents methods and constructors from being used via method > references (::) in stream pipelines. > > [Swapped first two words, to continue the Developer theme] Developers > sometimes attempt to set the default charset via ... > ----- > > Alex From alex.buckley at oracle.com Thu Aug 19 04:27:58 2021 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 18 Aug 2021 21:27:58 -0700 Subject: JEP proposed to target JDK 18: 400: UTF-8 by Default In-Reply-To: <005eb7e1-0479-beea-1d13-345f72c0be35@oracle.com> References: <20210818162000.B24DD3EF250@eggemoggin.niobe.net> <495293099.720409.1629306190011.JavaMail.zimbra@u-pem.fr> <93a3c337-2a0c-57fc-bd16-e6a967d21b29@oracle.com> <005eb7e1-0479-beea-1d13-345f72c0be35@oracle.com> Message-ID: <2ba4ebc5-3613-4c60-d50e-c5db27420d76@oracle.com> Some nits: - "especially [a word is missing here] the property is set after" - Re: "... change the specification of Charset.defaultCharset() to say that the default charset is UTF-8 ***unless configured otherwise by an implementation-specific means***" -- is the starred text alluding to this: "we will revise the treatment of the file.encoding property so that _setting it on the command line is a supported means of configuring the default charset_" ? If there's a connection, please acknowledge it via something like "... an implementation-specific means. (The JDK supports configuring the default charset once, at startup, by setting a system property on the command line; see below.)" - If `native.encoding` is new in 17, then it's a surprise to see the following text which suggests `native.encoding` is something that people have long relied upon: "native.encoding is public and ***there is no change in its behavior***" Also, "is public" should be "is standard". - Re: "This is, essentialy [spelling error], equivalent to file.encoding unless it is overridden on the command line." -- what is "it" ? A reader can easily think "it" means native.encoding. (Such a reader will be confused because System::getProperties apparently prohibits "overriding" native.encoding via "Setting this system property has no effect.") I believe the message here is that native.encoding is equivalent to file.encoding unless file.encoding is (new!) set on the command line. I think you would be better off unpicking native.encoding from the story: drop its bullet; don't mention "i.e., to the value of native.encoding" in the file.encoding=COMPAT bullet; and say after the final file.encoding bullet that "We introduce native.encoding as a standard way to detect the charset chosen by the JDK's algorithm, regardless of whether the default charset is actually configured to be that charset. If file.encoding is set to COMPAT on the command line, then the run-time value of file.encoding will be the same as the run-time value of native.encoding; if file.encoding is set to UTF-8 on the command line, then the run-time of file.encoding may differ from the run-time value of native.encoding." Alex On 8/18/2021 2:21 PM, Naoto Sato wrote: > Thanks, Alex. > > Yes, distancing from FileReader/Writer would make the removed sentence > stand. And the next sentence reads better with the developer focus. > Modified as suggested. > > Naoto > > On 8/18/21 1:47 PM, Alex Buckley wrote: >> On 8/18/2021 12:48 PM, Naoto Sato wrote: >>> On 8/18/21 10:03 AM, Remi Forax wrote: >>>> A minor comment, there is a sentence in the JEP that is weird. >>>> >>>> "However, having to pass an argument prevents these methods from >>>> being used via method references (::) in stream pipelines." >>>> >>>> You can not use these methods in a Stream anyway because they are >>>> declared with "throws IOException", so this argument does not hold. >>>> I think this sentence should be removed. >>> >>> Thanks. Removed the sentence. >> >> There is now a dangling paragraph -- "Developers familiar with such >> hazards can use methods that take a charset argument explicitly." -- >> whose words undermine the case for having a default charset at all. >> >> I recommend preserving the complaint about having to pass an argument, >> but rephrasing it to be less connected to the specific >> FileWriter/FileReader APIs in the prior paragraph (after all, there >> are ctors in Formatter and Scanner which use the default charset and >> don't throw IOException) : >> >> ----- >> Developers familiar with such hazards can use methods and constructors >> that take a charset argument explicitly. However, having to pass an >> argument prevents methods and constructors from being used via method >> references (::) in stream pipelines. >> >> [Swapped first two words, to continue the Developer theme] Developers >> sometimes attempt to set the default charset via ... >> ----- >> >> Alex From Alan.Bateman at oracle.com Thu Aug 19 10:46:36 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 19 Aug 2021 11:46:36 +0100 Subject: JEP proposed to target JDK 18: 400: UTF-8 by Default In-Reply-To: <2ba4ebc5-3613-4c60-d50e-c5db27420d76@oracle.com> References: <20210818162000.B24DD3EF250@eggemoggin.niobe.net> <495293099.720409.1629306190011.JavaMail.zimbra@u-pem.fr> <93a3c337-2a0c-57fc-bd16-e6a967d21b29@oracle.com> <005eb7e1-0479-beea-1d13-345f72c0be35@oracle.com> <2ba4ebc5-3613-4c60-d50e-c5db27420d76@oracle.com> Message-ID: On 19/08/2021 05:27, Alex Buckley wrote: > : > > - Re: "This is, essentialy [spelling error], equivalent to > file.encoding unless it is overridden on the command line." -- what is > "it" ? A reader can easily think "it" means native.encoding. (Such a > reader will be confused because System::getProperties apparently > prohibits "overriding" native.encoding via "Setting this system > property has no effect.") I believe the message here is that > native.encoding is equivalent to file.encoding unless file.encoding is > (new!) set on the command line. I think you would be better off > unpicking native.encoding from the story: drop its bullet; don't > mention "i.e., to the value of native.encoding" in the > file.encoding=COMPAT bullet; and say after the final file.encoding > bullet that "We introduce native.encoding as a standard way to detect > the charset chosen by the JDK's algorithm, regardless of whether the > default charset is actually configured to be that charset. If > file.encoding is set to COMPAT on the command line, then the run-time > value of file.encoding will be the same as the run-time value of > native.encoding; if file.encoding is set to UTF-8 on the command line, > then the run-time of file.encoding may differ from the run-time value > of native.encoding." native.encoding is an important part of the story for applications that do interop with native applications. It can also plays a key role for applications that want to target a very wide range of JDK releases. So I think the JEP does need to describe it. The sentence "That is, essentially, ..." can be dropped. The paragraph that follows the list of properties can focus on file.encoding. We can introduce a new paragraph to show native.encoding can be used. -Alan From thomas.schatzl at oracle.com Fri Aug 20 10:16:30 2021 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 20 Aug 2021 12:16:30 +0200 Subject: New OpenJDK Reviewer: Albert Mingkun Yang Message-ID: Voting for Albert Mingkun Yang [1] is now closed. Yes: 21 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. Thomas Schatzl [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2021-August/005857.html From markus.gronlund at oracle.com Sun Aug 22 12:14:40 2021 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Sun, 22 Aug 2021 12:14:40 +0000 Subject: Result: New JDK Committer: Denghui Dong Message-ID: Voting for Denghui Dong (ddong) [0] is now closed. Yes: 17 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Thank you Markus [0] https://mail.openjdk.java.net/pipermail/jdk-dev/2021-August/005896.html From chris.plummer at oracle.com Sun Aug 22 19:13:48 2021 From: chris.plummer at oracle.com (Chris Plummer) Date: Sun, 22 Aug 2021 12:13:48 -0700 Subject: CFV: New JDK Committer: Lin Zang Message-ID: <193c33fa-4059-0def-57f8-11b50d2a999e@oracle.com> I hereby nominate Lin Zang (lzang) to JDK Committer. Lin has contributed 21 patches [3] to hotspot, mostly in the serviceability area. Some of the more complex contributions include: 8215622: Add dump to file support for jmap ?histo 8215624: Add parallel heap iteration for jmap ?histo 8252103: Parallel heap inspection for ParallelScavengeHeap 8252104: parallel heap inspection for ShenandoahHeap 8257234: Add gz option to SA jmap to write a gzipped heap dump 8241638: launcher time metrics always report 1 on Linux when _JAVA_LAUNCHER_DEBUG is set 8252105: Parallel heap inspection for ZcollectedHeap 8256450: Add gz option to jmap to write a gzipped heap dump Lin is also currently working on the following, which are all out for review: 8252842: Extend jmap to support parallel heap dump 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out 8269685: Optimize HeapHprofBinWriter implementation 4890732: GZIPOutputStream doesn't support optional GZIP fields Votes are due by 2021-08-05 19:00 UTC. Only current JDK Committers [1] are eligible to vote on this nomination.? Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Best regards, Chris [1] https://openjdk.java.net/census [2] https://openjdk.java.net/projects/#committer-vote [3] https://github.com/openjdk/jdk/search?q=author-name%3A%22Lin+Zang%22&type=commits From johnsjiang at tencent.com Mon Aug 23 01:42:06 2021 From: johnsjiang at tencent.com (=?big5?B?am9obnNqaWFuZyimv7LvKQ==?=) Date: Mon, 23 Aug 2021 01:42:06 +0000 Subject: [Internet]CFV: New JDK Committer: Lin Zang References: <193c33fa-4059-0def-57f8-11b50d2a999e@oracle.com> Message-ID: <4e4ec46e175848cea64f2becc5ccfedf@tencent.com> Vote: yes John Jiang AT 2021/8/23 AM 3:14, Chris Plummer wrote: > I hereby nominate Lin Zang (lzang) to JDK Committer. > > Lin has contributed 21 patches [3] to hotspot, mostly in the > serviceability area. > Some of the more complex contributions include: > > 8215622: Add dump to file support for jmap ?histo > 8215624: Add parallel heap iteration for jmap ?histo > 8252103: Parallel heap inspection for ParallelScavengeHeap > 8252104: parallel heap inspection for ShenandoahHeap > 8257234: Add gz option to SA jmap to write a gzipped heap dump > 8241638: launcher time metrics always report 1 on Linux when > _JAVA_LAUNCHER_DEBUG is set > 8252105: Parallel heap inspection for ZcollectedHeap > 8256450: Add gz option to jmap to write a gzipped heap dump > > Lin is also currently working on the following, which are all out for > review: > > 8252842: Extend jmap to support parallel heap dump > 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java > timed out > 8269685: Optimize HeapHprofBinWriter implementation > 4890732: GZIPOutputStream doesn't support optional GZIP fields > > Votes are due by 2021-08-05 19:00 UTC. > > Only current JDK Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Best regards, > > Chris > > [1] https://openjdk.java.net/census > [2] https://openjdk.java.net/projects/#committer-vote > [3] > https://github.com/openjdk/jdk/search?q=author-name%3A%22Lin+Zang%22&type=commits > > > From kalinshi at tencent.com Mon Aug 23 01:53:26 2021 From: kalinshi at tencent.com (=?utf-8?B?a2FsaW5zaGko5pa95oWnKQ==?=) Date: Mon, 23 Aug 2021 01:53:26 +0000 Subject: =?utf-8?B?5Zue5aSNOiBbSW50ZXJuZXRdQ0ZWOiBOZXcgSkRLIENvbW1pdHRlcjogTGlu?= =?utf-8?Q?_Zang?= In-Reply-To: <193c33fa-4059-0def-57f8-11b50d2a999e@oracle.com> References: <193c33fa-4059-0def-57f8-11b50d2a999e@oracle.com> Message-ID: <3068cbb0212b498884df6f0e03272bce@tencent.com> Vote: yes Regards Hui -----????----- ???: jdk-dev ?? Chris Plummer ????: 2021?8?23? 3:14 ???: jdk-dev at openjdk.java.net ??: [Internet]CFV: New JDK Committer: Lin Zang I hereby nominate Lin Zang (lzang) to JDK Committer. Lin has contributed 21 patches [3] to hotspot, mostly in the serviceability area. Some of the more complex contributions include: 8215622: Add dump to file support for jmap ?histo 8215624: Add parallel heap iteration for jmap ?histo 8252103: Parallel heap inspection for ParallelScavengeHeap 8252104: parallel heap inspection for ShenandoahHeap 8257234: Add gz option to SA jmap to write a gzipped heap dump 8241638: launcher time metrics always report 1 on Linux when _JAVA_LAUNCHER_DEBUG is set 8252105: Parallel heap inspection for ZcollectedHeap 8256450: Add gz option to jmap to write a gzipped heap dump Lin is also currently working on the following, which are all out for review: 8252842: Extend jmap to support parallel heap dump 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out 8269685: Optimize HeapHprofBinWriter implementation 4890732: GZIPOutputStream doesn't support optional GZIP fields Votes are due by 2021-08-05 19:00 UTC. Only current JDK Committers [1] are eligible to vote on this nomination.? Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Best regards, Chris [1] https://openjdk.java.net/census [2] https://openjdk.java.net/projects/#committer-vote [3] https://github.com/openjdk/jdk/search?q=author-name%3A%22Lin+Zang%22&type=commits From chris.plummer at oracle.com Mon Aug 23 02:01:15 2021 From: chris.plummer at oracle.com (Chris Plummer) Date: Sun, 22 Aug 2021 19:01:15 -0700 Subject: CFV: New JDK Committer: Lin Zang In-Reply-To: <193c33fa-4059-0def-57f8-11b50d2a999e@oracle.com> References: <193c33fa-4059-0def-57f8-11b50d2a999e@oracle.com> Message-ID: <55b659a1-9f03-a872-3403-eec184c1468b@oracle.com> Minor correction: > Votes are due by 2021-08-05 19:00 UTC. That should be 2021-09-05. thanks, Chris On 8/22/21 12:13 PM, Chris Plummer wrote: > I hereby nominate Lin Zang (lzang) to JDK Committer. > > Lin has contributed 21 patches [3] to hotspot, mostly in the > serviceability area. > Some of the more complex contributions include: > > 8215622: Add dump to file support for jmap ?histo > 8215624: Add parallel heap iteration for jmap ?histo > 8252103: Parallel heap inspection for ParallelScavengeHeap > 8252104: parallel heap inspection for ShenandoahHeap > 8257234: Add gz option to SA jmap to write a gzipped heap dump > 8241638: launcher time metrics always report 1 on Linux when > _JAVA_LAUNCHER_DEBUG is set > 8252105: Parallel heap inspection for ZcollectedHeap > 8256450: Add gz option to jmap to write a gzipped heap dump > > Lin is also currently working on the following, which are all out for > review: > > 8252842: Extend jmap to support parallel heap dump > 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java > timed out > 8269685: Optimize HeapHprofBinWriter implementation > 4890732: GZIPOutputStream doesn't support optional GZIP fields > > Votes are due by 2021-08-05 19:00 UTC. > > Only current JDK Committers [1] are eligible to vote > on this nomination.? Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Best regards, > > Chris > > [1] https://openjdk.java.net/census > [2] https://openjdk.java.net/projects/#committer-vote > [3] > https://github.com/openjdk/jdk/search?q=author-name%3A%22Lin+Zang%22&type=commits > From jiefu at tencent.com Mon Aug 23 02:02:32 2021 From: jiefu at tencent.com (=?utf-8?B?amllZnUo5YKF5p2wKQ==?=) Date: Mon, 23 Aug 2021 02:02:32 +0000 Subject: [Internet]CFV: New JDK Committer: Lin Zang In-Reply-To: <193c33fa-4059-0def-57f8-11b50d2a999e@oracle.com> References: <193c33fa-4059-0def-57f8-11b50d2a999e@oracle.com> Message-ID: <63E93416-CC4A-4089-94A9-1E1124823FA2@tencent.com> Vote: yes. Best regards, Jie ?On 2021/8/23, 3:15 AM, "jdk-dev on behalf of Chris Plummer" wrote: I hereby nominate Lin Zang (lzang) to JDK Committer. Lin has contributed 21 patches [3] to hotspot, mostly in the serviceability area. Some of the more complex contributions include: 8215622: Add dump to file support for jmap ?histo 8215624: Add parallel heap iteration for jmap ?histo 8252103: Parallel heap inspection for ParallelScavengeHeap 8252104: parallel heap inspection for ShenandoahHeap 8257234: Add gz option to SA jmap to write a gzipped heap dump 8241638: launcher time metrics always report 1 on Linux when _JAVA_LAUNCHER_DEBUG is set 8252105: Parallel heap inspection for ZcollectedHeap 8256450: Add gz option to jmap to write a gzipped heap dump Lin is also currently working on the following, which are all out for review: 8252842: Extend jmap to support parallel heap dump 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out 8269685: Optimize HeapHprofBinWriter implementation 4890732: GZIPOutputStream doesn't support optional GZIP fields Votes are due by 2021-08-05 19:00 UTC. Only current JDK Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Best regards, Chris [1] https://openjdk.java.net/census [2] https://openjdk.java.net/projects/#committer-vote [3] https://github.com/openjdk/jdk/search?q=author-name%3A%22Lin+Zang%22&type=commits From felix.yang at huawei.com Mon Aug 23 02:12:44 2021 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Mon, 23 Aug 2021 02:12:44 +0000 Subject: CFV: New JDK Committer: Lin Zang In-Reply-To: <55b659a1-9f03-a872-3403-eec184c1468b@oracle.com> References: <193c33fa-4059-0def-57f8-11b50d2a999e@oracle.com> <55b659a1-9f03-a872-3403-eec184c1468b@oracle.com> Message-ID: <4cc995fbe2e24fda8bbe581cc8be58e4@huawei.com> Vote: yes Thanks, Felix > -----Original Message----- > From: jdk-dev [mailto:jdk-dev-retn at openjdk.java.net] On Behalf Of Chris > Plummer > Sent: Monday, August 23, 2021 10:01 AM > To: jdk-dev at openjdk.java.net > Subject: Re: CFV: New JDK Committer: Lin Zang > > Minor correction: > > > Votes are due by 2021-08-05 19:00 UTC. > > That should be 2021-09-05. > > thanks, > > Chris > > On 8/22/21 12:13 PM, Chris Plummer wrote: > > I hereby nominate Lin Zang (lzang) to JDK Committer. > > > > Lin has contributed 21 patches [3] to hotspot, mostly in the > > serviceability area. > > Some of the more complex contributions include: > > > > 8215622: Add dump to file support for jmap ?histo > > 8215624: Add parallel heap iteration for jmap ?histo > > 8252103: Parallel heap inspection for ParallelScavengeHeap > > 8252104: parallel heap inspection for ShenandoahHeap > > 8257234: Add gz option to SA jmap to write a gzipped heap dump > > 8241638: launcher time metrics always report 1 on Linux when > > _JAVA_LAUNCHER_DEBUG is set > > 8252105: Parallel heap inspection for ZcollectedHeap > > 8256450: Add gz option to jmap to write a gzipped heap dump > > > > Lin is also currently working on the following, which are all out for > > review: > > > > 8252842: Extend jmap to support parallel heap dump > > 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java > > timed out > > 8269685: Optimize HeapHprofBinWriter implementation > > 4890732: GZIPOutputStream doesn't support optional GZIP fields > > > > Votes are due by 2021-08-05 19:00 UTC. > > > > Only current JDK Committers [1] are eligible to vote on this > > nomination.? Votes must be cast in the open by replying to this > > mailing list. > > > > For Lazy Consensus voting instructions, see [2]. > > > > Best regards, > > > > Chris > > > > [1] https://openjdk.java.net/census > > [2] https://openjdk.java.net/projects/#committer-vote > > [3] > > https://github.com/openjdk/jdk/search?q=author- > name%3A%22Lin+Zang%22&t > > ype=commits > > > From felixxfyang at tencent.com Mon Aug 23 02:18:37 2021 From: felixxfyang at tencent.com (=?utf-8?B?ZmVsaXh4Znlhbmco5p2o5pmT5bOwKQ==?=) Date: Mon, 23 Aug 2021 02:18:37 +0000 Subject: [Internet]Re: CFV: New JDK Committer: Lin Zang In-Reply-To: <55b659a1-9f03-a872-3403-eec184c1468b@oracle.com> References: <193c33fa-4059-0def-57f8-11b50d2a999e@oracle.com> <55b659a1-9f03-a872-3403-eec184c1468b@oracle.com> Message-ID: <41B51F37-45BA-4C6B-B467-AFFAEE46EE35@tencent.com> Vote: Yes -Felix Yang ?? 2021/8/23 ??10:02??jdk-dev ?? Chris Plummer? ??: Minor correction: > Votes are due by 2021-08-05 19:00 UTC. That should be 2021-09-05. thanks, Chris On 8/22/21 12:13 PM, Chris Plummer wrote: > I hereby nominate Lin Zang (lzang) to JDK Committer. > > Lin has contributed 21 patches [3] to hotspot, mostly in the > serviceability area. > Some of the more complex contributions include: > > 8215622: Add dump to file support for jmap ?histo > 8215624: Add parallel heap iteration for jmap ?histo > 8252103: Parallel heap inspection for ParallelScavengeHeap > 8252104: parallel heap inspection for ShenandoahHeap > 8257234: Add gz option to SA jmap to write a gzipped heap dump > 8241638: launcher time metrics always report 1 on Linux when > _JAVA_LAUNCHER_DEBUG is set > 8252105: Parallel heap inspection for ZcollectedHeap > 8256450: Add gz option to jmap to write a gzipped heap dump > > Lin is also currently working on the following, which are all out for > review: > > 8252842: Extend jmap to support parallel heap dump > 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java > timed out > 8269685: Optimize HeapHprofBinWriter implementation > 4890732: GZIPOutputStream doesn't support optional GZIP fields > > Votes are due by 2021-08-05 19:00 UTC. > > Only current JDK Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Best regards, > > Chris > > [1] https://openjdk.java.net/census > [2] https://openjdk.java.net/projects/#committer-vote > [3] > https://github.com/openjdk/jdk/search?q=author-name%3A%22Lin+Zang%22&type=commits > From david.holmes at oracle.com Mon Aug 23 02:44:18 2021 From: david.holmes at oracle.com (David Holmes) Date: Mon, 23 Aug 2021 12:44:18 +1000 Subject: CFV: New JDK Committer: Lin Zang In-Reply-To: <193c33fa-4059-0def-57f8-11b50d2a999e@oracle.com> References: <193c33fa-4059-0def-57f8-11b50d2a999e@oracle.com> Message-ID: <6ad830c6-4d5c-f215-4813-959121e743f7@oracle.com> Vote: yes David On 23/08/2021 5:13 am, Chris Plummer wrote: > I hereby nominate Lin Zang (lzang) to JDK Committer. > > Lin has contributed 21 patches [3] to hotspot, mostly in the > serviceability area. > Some of the more complex contributions include: > > 8215622: Add dump to file support for jmap ?histo > 8215624: Add parallel heap iteration for jmap ?histo > 8252103: Parallel heap inspection for ParallelScavengeHeap > 8252104: parallel heap inspection for ShenandoahHeap > 8257234: Add gz option to SA jmap to write a gzipped heap dump > 8241638: launcher time metrics always report 1 on Linux when > _JAVA_LAUNCHER_DEBUG is set > 8252105: Parallel heap inspection for ZcollectedHeap > 8256450: Add gz option to jmap to write a gzipped heap dump > > Lin is also currently working on the following, which are all out for > review: > > 8252842: Extend jmap to support parallel heap dump > 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java > timed out > 8269685: Optimize HeapHprofBinWriter implementation > 4890732: GZIPOutputStream doesn't support optional GZIP fields > > Votes are due by 2021-08-05 19:00 UTC. > > Only current JDK Committers [1] are eligible to vote > on this nomination.? Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Best regards, > > Chris > > [1] https://openjdk.java.net/census > [2] https://openjdk.java.net/projects/#committer-vote > [3] > https://github.com/openjdk/jdk/search?q=author-name%3A%22Lin+Zang%22&type=commits > > From kevin.walls at oracle.com Mon Aug 23 08:45:53 2021 From: kevin.walls at oracle.com (Kevin Walls) Date: Mon, 23 Aug 2021 08:45:53 +0000 Subject: CFV: New JDK Committer: Lin Zang In-Reply-To: <193c33fa-4059-0def-57f8-11b50d2a999e@oracle.com> References: <193c33fa-4059-0def-57f8-11b50d2a999e@oracle.com> Message-ID: Vote: yes -----Original Message----- From: jdk-dev On Behalf Of Chris Plummer Sent: 22 August 2021 20:14 To: jdk-dev at openjdk.java.net Subject: CFV: New JDK Committer: Lin Zang I hereby nominate Lin Zang (lzang) to JDK Committer. Lin has contributed 21 patches [3] to hotspot, mostly in the serviceability area. Some of the more complex contributions include: 8215622: Add dump to file support for jmap ?histo 8215624: Add parallel heap iteration for jmap ?histo 8252103: Parallel heap inspection for ParallelScavengeHeap 8252104: parallel heap inspection for ShenandoahHeap 8257234: Add gz option to SA jmap to write a gzipped heap dump 8241638: launcher time metrics always report 1 on Linux when _JAVA_LAUNCHER_DEBUG is set 8252105: Parallel heap inspection for ZcollectedHeap 8256450: Add gz option to jmap to write a gzipped heap dump Lin is also currently working on the following, which are all out for review: 8252842: Extend jmap to support parallel heap dump 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out 8269685: Optimize HeapHprofBinWriter implementation 4890732: GZIPOutputStream doesn't support optional GZIP fields Votes are due by 2021-08-05 19:00 UTC. Only current JDK Committers [1] are eligible to vote on this nomination.? Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Best regards, Chris [1] https://openjdk.java.net/census [2] https://openjdk.java.net/projects/#committer-vote [3] https://github.com/openjdk/jdk/search?q=author-name%3A%22Lin+Zang%22&type=commits From sgehwolf at redhat.com Mon Aug 23 09:17:08 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 23 Aug 2021 11:17:08 +0200 Subject: CFV: New JDK Committer: Lin Zang In-Reply-To: <193c33fa-4059-0def-57f8-11b50d2a999e@oracle.com> References: <193c33fa-4059-0def-57f8-11b50d2a999e@oracle.com> Message-ID: <839f184c50296238a9953b5c8ab9499fbb17d100.camel@redhat.com> Vote: yes. On Sun, 2021-08-22 at 12:13 -0700, Chris Plummer wrote: > I hereby nominate Lin Zang (lzang) to JDK Committer. > > Lin has contributed 21 patches [3] to hotspot, mostly in the > serviceability area. > Some of the more complex contributions include: > > 8215622: Add dump to file support for jmap ?histo > 8215624: Add parallel heap iteration for jmap ?histo > 8252103: Parallel heap inspection for ParallelScavengeHeap > 8252104: parallel heap inspection for ShenandoahHeap > 8257234: Add gz option to SA jmap to write a gzipped heap dump > 8241638: launcher time metrics always report 1 on Linux when > _JAVA_LAUNCHER_DEBUG is set > 8252105: Parallel heap inspection for ZcollectedHeap > 8256450: Add gz option to jmap to write a gzipped heap dump > > Lin is also currently working on the following, which are all out for > review: > > 8252842: Extend jmap to support parallel heap dump > 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java > timed out > 8269685: Optimize HeapHprofBinWriter implementation > 4890732: GZIPOutputStream doesn't support optional GZIP fields > > Votes are due by 2021-08-05 19:00 UTC. > > Only current JDK Committers [1] are eligible to vote > on this nomination.? Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Best regards, > > Chris > > [1] https://openjdk.java.net/census > [2] https://openjdk.java.net/projects/#committer-vote > [3] > https://github.com/openjdk/jdk/search?q=author-name%3A%22Lin+Zang%22&type=commits > From lihuaming3 at huawei.com Mon Aug 23 09:23:39 2021 From: lihuaming3 at huawei.com (lihuaming (A)) Date: Mon, 23 Aug 2021 09:23:39 +0000 Subject: =?utf-8?B?562U5aSNOiBOZXcgSkRLIENvbW1pdHRlcjogTGluIFphbmc=?= In-Reply-To: <193c33fa-4059-0def-57f8-11b50d2a999e@oracle.com> References: <193c33fa-4059-0def-57f8-11b50d2a999e@oracle.com> Message-ID: <5592e60be1f049879084bfe2d156293a@huawei.com> Vote: yes -Hamlin Li -----????----- ???: jdk-dev [mailto:jdk-dev-retn at openjdk.java.net] ?? Chris Plummer ????: 2021?8?23? 3:14 ???: jdk-dev at openjdk.java.net ??: CFV: New JDK Committer: Lin Zang I hereby nominate Lin Zang (lzang) to JDK Committer. Lin has contributed 21 patches [3] to hotspot, mostly in the serviceability area. Some of the more complex contributions include: 8215622: Add dump to file support for jmap ?histo 8215624: Add parallel heap iteration for jmap ?histo 8252103: Parallel heap inspection for ParallelScavengeHeap 8252104: parallel heap inspection for ShenandoahHeap 8257234: Add gz option to SA jmap to write a gzipped heap dump 8241638: launcher time metrics always report 1 on Linux when _JAVA_LAUNCHER_DEBUG is set 8252105: Parallel heap inspection for ZcollectedHeap 8256450: Add gz option to jmap to write a gzipped heap dump Lin is also currently working on the following, which are all out for review: 8252842: Extend jmap to support parallel heap dump 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out 8269685: Optimize HeapHprofBinWriter implementation 4890732: GZIPOutputStream doesn't support optional GZIP fields Votes are due by 2021-08-05 19:00 UTC. Only current JDK Committers [1] are eligible to vote on this nomination.? Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Best regards, Chris [1] https://openjdk.java.net/census [2] https://openjdk.java.net/projects/#committer-vote [3] https://github.com/openjdk/jdk/search?q=author-name%3A%22Lin+Zang%22&type=commits From hohensee at amazon.com Mon Aug 23 11:17:21 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 23 Aug 2021 11:17:21 +0000 Subject: CFV: New JDK Committer: Lin Zang Message-ID: Vote: yes. ?-----Original Message----- From: jdk-dev on behalf of Chris Plummer Date: Sunday, August 22, 2021 at 12:14 PM To: "jdk-dev at openjdk.java.net" Subject: CFV: New JDK Committer: Lin Zang I hereby nominate Lin Zang (lzang) to JDK Committer. Lin has contributed 21 patches [3] to hotspot, mostly in the serviceability area. Some of the more complex contributions include: 8215622: Add dump to file support for jmap ?histo 8215624: Add parallel heap iteration for jmap ?histo 8252103: Parallel heap inspection for ParallelScavengeHeap 8252104: parallel heap inspection for ShenandoahHeap 8257234: Add gz option to SA jmap to write a gzipped heap dump 8241638: launcher time metrics always report 1 on Linux when _JAVA_LAUNCHER_DEBUG is set 8252105: Parallel heap inspection for ZcollectedHeap 8256450: Add gz option to jmap to write a gzipped heap dump Lin is also currently working on the following, which are all out for review: 8252842: Extend jmap to support parallel heap dump 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out 8269685: Optimize HeapHprofBinWriter implementation 4890732: GZIPOutputStream doesn't support optional GZIP fields Votes are due by 2021-08-05 19:00 UTC. Only current JDK Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Best regards, Chris [1] https://openjdk.java.net/census [2] https://openjdk.java.net/projects/#committer-vote [3] https://github.com/openjdk/jdk/search?q=author-name%3A%22Lin+Zang%22&type=commits From zgu at redhat.com Mon Aug 23 12:03:03 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 23 Aug 2021 08:03:03 -0400 Subject: CFV: New JDK Committer: Lin Zang In-Reply-To: <193c33fa-4059-0def-57f8-11b50d2a999e@oracle.com> References: <193c33fa-4059-0def-57f8-11b50d2a999e@oracle.com> Message-ID: Vote: yes -Zhengyu On 8/22/21 3:13 PM, Chris Plummer wrote: > I hereby nominate Lin Zang (lzang) to JDK Committer. > > Lin has contributed 21 patches [3] to hotspot, mostly in the > serviceability area. > Some of the more complex contributions include: > > 8215622: Add dump to file support for jmap ?histo > 8215624: Add parallel heap iteration for jmap ?histo > 8252103: Parallel heap inspection for ParallelScavengeHeap > 8252104: parallel heap inspection for ShenandoahHeap > 8257234: Add gz option to SA jmap to write a gzipped heap dump > 8241638: launcher time metrics always report 1 on Linux when > _JAVA_LAUNCHER_DEBUG is set > 8252105: Parallel heap inspection for ZcollectedHeap > 8256450: Add gz option to jmap to write a gzipped heap dump > > Lin is also currently working on the following, which are all out for > review: > > 8252842: Extend jmap to support parallel heap dump > 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java > timed out > 8269685: Optimize HeapHprofBinWriter implementation > 4890732: GZIPOutputStream doesn't support optional GZIP fields > > Votes are due by 2021-08-05 19:00 UTC. > > Only current JDK Committers [1] are eligible to vote > on this nomination.? Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Best regards, > > Chris > > [1] https://openjdk.java.net/census > [2] https://openjdk.java.net/projects/#committer-vote > [3] > https://github.com/openjdk/jdk/search?q=author-name%3A%22Lin+Zang%22&type=commits > > From mark.reinhold at oracle.com Mon Aug 23 22:33:38 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 23 Aug 2021 15:33:38 -0700 (PDT) Subject: JEP proposed to target JDK 18: 413: Code Snippets in Java API Documentation Message-ID: <20210823223338.66AA73EF9B7@eggemoggin.niobe.net> The following JEP is proposed to target JDK 18: 413: Code Snippets in Java API Documentation https://openjdk.java.net/jeps/413 Summary: Introduce an @snippet tag for JavaDoc's Standard Doclet, to simplify the inclusion of example source code in API documentation. Feedback on this proposal from JDK Project Committers and Reviewers [1] is more than welcome, as are reasoned objections. If no such objections are raised by 23:59 UTC on Monday, 30 August, or if they?re raised and then satisfactorily answered, then per the JEP 2.0 process proposal [2] I?ll target this JEP to JDK 18. - Mark [1] https://openjdk.java.net/census#jdk [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From forax at univ-mlv.fr Tue Aug 24 09:35:55 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 24 Aug 2021 11:35:55 +0200 (CEST) Subject: JEP proposed to target JDK 18: 413: Code Snippets in Java API Documentation In-Reply-To: <20210823223338.66AA73EF9B7@eggemoggin.niobe.net> References: <20210823223338.66AA73EF9B7@eggemoggin.niobe.net> Message-ID: <1814775366.570682.1629797755577.JavaMail.zimbra@u-pem.fr> Small change unrelated to what this JEP is about, the example should use orElseThrow() and not get(), as said in the javadoc of Optional.get() [1]. /** * The following code shows how to use {@code Optional.isPresent}: * {@snippet : * if (opt.isPresent()) { * System.out.println("opt: " + opt.orElseThrow()); // <-- here * } * } */ R?mi [1] https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/Optional.html#get() ----- Original Message ----- > From: "mark reinhold" > To: "jdk-dev" > Sent: Mardi 24 Ao?t 2021 00:33:38 > Subject: JEP proposed to target JDK 18: 413: Code Snippets in Java API Documentation > The following JEP is proposed to target JDK 18: > > 413: Code Snippets in Java API Documentation > https://openjdk.java.net/jeps/413 > > Summary: Introduce an @snippet tag for JavaDoc's Standard Doclet, to > simplify the inclusion of example source code in API documentation. > > Feedback on this proposal from JDK Project Committers and Reviewers [1] > is more than welcome, as are reasoned objections. If no such objections > are raised by 23:59 UTC on Monday, 30 August, or if they?re raised and > then satisfactorily answered, then per the JEP 2.0 process proposal [2] > I?ll target this JEP to JDK 18. > > - Mark > > > [1] https://openjdk.java.net/census#jdk > [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From cay.horstmann at gmail.com Tue Aug 24 09:49:04 2021 From: cay.horstmann at gmail.com (Cay Horstmann) Date: Tue, 24 Aug 2021 11:49:04 +0200 Subject: JEP proposed to target JDK 18: 413: Code Snippets in Java API Documentation In-Reply-To: <1814775366.570682.1629797755577.JavaMail.zimbra@u-pem.fr> References: <20210823223338.66AA73EF9B7@eggemoggin.niobe.net> <1814775366.570682.1629797755577.JavaMail.zimbra@u-pem.fr> Message-ID: <3ffaba0c-99ef-77d0-5ca9-975b9555165c@gmail.com> I thought orElseThrow was purposefully given a horrible name so that it would be used as a last resort, nudging programmers towards opt.ifPresent(System.out::println); Cheers, Cay On 24/08/2021 11:35, Remi Forax wrote: > Small change unrelated to what this JEP is about, the example should use orElseThrow() and not get(), > as said in the javadoc of Optional.get() [1]. > > /** > * The following code shows how to use {@code Optional.isPresent}: > * {@snippet : > * if (opt.isPresent()) { > * System.out.println("opt: " + opt.orElseThrow()); // <-- here > * } > * } > */ > > R?mi > > [1] https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/Optional.html#get() > > ----- Original Message ----- >> From: "mark reinhold" >> To: "jdk-dev" >> Sent: Mardi 24 Ao?t 2021 00:33:38 >> Subject: JEP proposed to target JDK 18: 413: Code Snippets in Java API Documentation > >> The following JEP is proposed to target JDK 18: >> >> 413: Code Snippets in Java API Documentation >> https://openjdk.java.net/jeps/413 >> >> Summary: Introduce an @snippet tag for JavaDoc's Standard Doclet, to >> simplify the inclusion of example source code in API documentation. >> >> Feedback on this proposal from JDK Project Committers and Reviewers [1] >> is more than welcome, as are reasoned objections. If no such objections >> are raised by 23:59 UTC on Monday, 30 August, or if they?re raised and >> then satisfactorily answered, then per the JEP 2.0 process proposal [2] >> I?ll target this JEP to JDK 18. >> >> - Mark >> >> >> [1] https://openjdk.java.net/census#jdk >> [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html -- Cay S. Horstmann | http://horstmann.com | mailto:cay at horstmann.com From lgxbslgx at gmail.com Tue Aug 24 13:22:25 2021 From: lgxbslgx at gmail.com (Guoxiong Li) Date: Tue, 24 Aug 2021 21:22:25 +0800 Subject: CFV: New JDK Committer: Lin Zang In-Reply-To: References: <193c33fa-4059-0def-57f8-11b50d2a999e@oracle.com> Message-ID: Vote: yes -- Guoxiong From christoph.langer at sap.com Tue Aug 24 21:26:33 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 24 Aug 2021 21:26:33 +0000 Subject: CFV: New JDK Committer: Lin Zang In-Reply-To: <193c33fa-4059-0def-57f8-11b50d2a999e@oracle.com> References: <193c33fa-4059-0def-57f8-11b50d2a999e@oracle.com> Message-ID: Vote: yes /Christoph > -----Original Message----- > From: jdk-dev On Behalf Of Chris > Plummer > Sent: Sonntag, 22. August 2021 21:14 > To: jdk-dev at openjdk.java.net > Subject: CFV: New JDK Committer: Lin Zang > > I hereby nominate Lin Zang (lzang) to JDK Committer. > > Lin has contributed 21 patches [3] to hotspot, mostly in the > serviceability area. > Some of the more complex contributions include: > > 8215622: Add dump to file support for jmap ?histo > 8215624: Add parallel heap iteration for jmap ?histo > 8252103: Parallel heap inspection for ParallelScavengeHeap > 8252104: parallel heap inspection for ShenandoahHeap > 8257234: Add gz option to SA jmap to write a gzipped heap dump > 8241638: launcher time metrics always report 1 on Linux when > _JAVA_LAUNCHER_DEBUG is set > 8252105: Parallel heap inspection for ZcollectedHeap > 8256450: Add gz option to jmap to write a gzipped heap dump > > Lin is also currently working on the following, which are all out for > review: > > 8252842: Extend jmap to support parallel heap dump > 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java > timed out > 8269685: Optimize HeapHprofBinWriter implementation > 4890732: GZIPOutputStream doesn't support optional GZIP fields > > Votes are due by 2021-08-05 19:00 UTC. > > Only current JDK Committers [1] are eligible to vote > on this nomination.? Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Best regards, > > Chris > > [1] https://openjdk.java.net/census > [2] https://openjdk.java.net/projects/#committer-vote > [3] > https://github.com/openjdk/jdk/search?q=author- > name%3A%22Lin+Zang%22&type=commits From mark.reinhold at oracle.com Fri Aug 27 17:20:40 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 27 Aug 2021 10:20:40 -0700 Subject: JEP proposed to target JDK 18: 400: UTF-8 by Default In-Reply-To: <20210818162000.B24DD3EF250@eggemoggin.niobe.net> References: <20210818162000.B24DD3EF250@eggemoggin.niobe.net> Message-ID: <20210827102040.394607927@eggemoggin.niobe.net> 2021/8/18 9:20:00 -0700, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 18: > > 400: UTF-8 by Default > https://openjdk.java.net/jeps/400 > > Summary: Specify UTF-8 as the default charset of the standard Java > APIs. With this change, APIs that depend upon the default charset > will behave consistently across all implementations, operating systems, > locales, and configurations. > > Feedback on this proposal from JDK Project Committers and Reviewers [1] > is more than welcome, as are reasoned objections. If no such objections > are raised by 23:59 UTC on Wednesday, 25 August, or if they?re raised > and then satisfactorily answered, then per the JEP 2.0 process proposal > [2] I?ll target this JEP to JDK 18. Hearing no objections, I?ve targeted this JEP to JDK 18. - Mark From denghui.ddh at alibaba-inc.com Mon Aug 30 05:45:53 2021 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Mon, 30 Aug 2021 13:45:53 +0800 Subject: =?UTF-8?B?Q0ZWOiBOZXcgSkRLIENvbW1pdHRlcjogTGluIFphbmc=?= Message-ID: <89b64302-83ca-426c-9588-61b87594e45e.denghui.ddh@alibaba-inc.com> Vote: yes Denghui > -----Original Message----- > From: jdk-dev On Behalf Of Chris > Plummer > Sent: Sonntag, 22. August 2021 21:14 > To: jdk-dev at openjdk.java.net> Subject: CFV: New JDK Committer: Lin Zang > > I hereby nominate Lin Zang (lzang) to JDK Committer. > > Lin has contributed 21 patches [3] to hotspot, mostly in the > serviceability area. > Some of the more complex contributions include: > > 8215622: Add dump to file support for jmap ?histo > 8215624: Add parallel heap iteration for jmap ?histo > 8252103: Parallel heap inspection for ParallelScavengeHeap > 8252104: parallel heap inspection for ShenandoahHeap > 8257234: Add gz option to SA jmap to write a gzipped heap dump > 8241638: launcher time metrics always report 1 on Linux when > _JAVA_LAUNCHER_DEBUG is set > 8252105: Parallel heap inspection for ZcollectedHeap > 8256450: Add gz option to jmap to write a gzipped heap dump > > Lin is also currently working on the following, which are all out for > review: > > 8252842: Extend jmap to support parallel heap dump > 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java > timed out > 8269685: Optimize HeapHprofBinWriter implementation > 4890732: GZIPOutputStream doesn't support optional GZIP fields > > Votes are due by 2021-08-05 19:00 UTC. > > Only current JDK Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Best regards, > > Chris > > [1] https://openjdk.java.net/census> [2] https://openjdk.java.net/projects/#committer-vote> [3] > https://github.com/openjdk/jdk/search?q=author-> name%3A%22Lin+Zang%22&type=commits