From jini at zeus.net.au Sat May 1 02:47:30 2021 From: jini at zeus.net.au (jini at zeus.net.au) Date: Sat, 1 May 2021 12:47:30 +1000 Subject: Preserving API's when removing implementations In-Reply-To: References: Message-ID: <98a9a1d3-1dde-b0c1-4919-ccb318eabff7@zeus.net.au> We are not allowed to distribute such libraries, as they are in the java namespace unless that's changed? On 1/05/2021 12:43 pm, Peter Firmstone wrote: > One trend I am noticing as features are removed from Java, is that API > that client code utilises is also removed, which prevents other > implementations from replacing lost features, where the Java > development community needs to continue supporting such features, it > breaks software that would otherwise continue to function with an > alternative implementation. > > Can we do something about preserving parts of these API's perhaps as > deprecated without their removal please? > > Perhaps include the API's in a separate compatibility module, these > shouldn't require further development and maintenance, they are just > there for backward compatible evolution of client code. > > Thank you. > -- Regards, Peter Firmstone 0498 286 363 Zeus Project Services Pty Ltd. From peter.firmstone at zeus.net.au Sat May 1 02:04:00 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Sat, 1 May 2021 12:04:00 +1000 Subject: Java Security: JEP: 411: Deprecate the Security Manager for Removal - What about Serialization? In-Reply-To: <20210415180500.5D0DE3E00E5@eggemoggin.niobe.net> References: <20210415180500.5D0DE3E00E5@eggemoggin.niobe.net> Message-ID: Having had a day to think about this JEP, I have a simple request, I'd like to add to this JEP. Because those of us who require Access Control functionality will have to remain with a legacy version of Java until EOL and following that need to maintain and backport security patches ourselves. Create a new JEP for deprecation and removal of Java's Serialization implementation.? Please remove Java Serialization first, then remove the Security Manager a version after that (Deprecating both now).? Make Java more secure first, before reducing security.? We know that Serialization will eventually be removed, and removing it will allow the community to maintain a community LTS version with fewer resources.? After removal, leave the public Serialization API in place, abstract without an implementation, to allow third party implementations to continue utilize and implement it and existing code to compile also add SerializerFactory to RMI. We've had much longer (at least 10 years notice) to understand why Java Serialization should be avoided and the luxury of many viable migration alternatives to implement, not to mention it's the king of maintenance burdens and security vulnerabilities. Don't get me wrong, removing Serialization will cause pain, but it's not chronic pain, because we can migrate to alternatives, we will still be able to migrate to later versions of Java, at least until the removal of Access Control. Clearly there is no way for a library to provide AccessController functionality, it's only possible to provide this functionality at the platform level, not so with Serialization. We develop software that works peer to peer / distributed that blurs the lines between server and client.? We realize this is no longer a target market for Java development, along with applets and client code. Fine grained access control is required to control access to sensitive data, to prevent unauthorised access. Now IoT, is often called the "Internet of S___t" because it lacks security. We realise there are shortcomings with Java Security, it's not perfect but it does work for access control, when only limited access is permitted, I am wondering how to maintain equivalent security without an AccessController?? What other languages or platforms do security well, that could be used to provide guidance? We put into practice the principle of least privilege, we have the ability to dynamically grant additional permission as needed, we also restrict the permissions that can be granted.?? Java 1.4 was modified to allow dynamically granted permission, even though it wasn't implemented by the Java Policy provider, it was intended to be extensible for developers to develop their own implementations, and we did. This is functionality that is currently working, it remains in use and under development it is not legacy code.?? It is the result of a significant investment of time and money and we lack the resources to rewrite it in another language that supports fine grained access control. We use dynamic code, via Maven :) In our software we use a ProtectionDomain to represent a remote server, because a thread only runs with the user's Subject (and that Subject must be carefully preserved for other threads), there is no way to represent the remote Server's Subject in a local domain , other than with a ProtectionDomain. ? Our software is peer to peer, clients can be servers and servers can also be clients.? Code to interact with the server is downloaded via Maven and loaded.? Any permission's granted to a user, are injected into the stack when run as the client Subject, to authenticate the user for the server and establish a secure connection, calls made by the client are run with the user's Subject on the server, again for access control purposes.? This functionality is beyond the capability of Java RMI, we aren't using Java RMI to do this.? This is very important to allow us to make fine grained access control decisions, or perform event notification callbacks over secure connections, without this feature, we can't make a secure connection with a callback, and you know what happens when you have to do something, but cannot do it securely??? We only grant network access directly back to the server, downloaded code has been verified and is not expected to cause denial of service, by consuming resources etc, but we don't want to grant third party access to files, or random network connections, we still have privacy obligations for third party information. We can allow a third party to use unsigned certificates to sign their jar files or use a checksum and we verify them using a secure connection to the server, prior to loading.?? We then dynamically grant permissions to the server's self signed Certificate (used to sign the jar file), or a ProtectionDomain, after authenticating the server and receiving a check sum or certificate from it.? So the client authenticates the server using signed TLS certificates (EG by letsencrypt.org or a trusted CA). We use self signed certificates on Jar files if we sign them, we are actually trusting the server entity in this case, eg a trusted company, but also placing restrictions on them. If we remove access control, third parties will be able to open local network connections and freely and use Java Serialization over unsecured connections, exposing us to an attacker who can use a gadget attack.? Presently they cannot open a network connection, access files or do much of anything without Permission.? All those protections will be removed with this JEP. from https://community.letsencrypt.org/t/do-you-support-code-signing/370 > Code-signing certificates as they?re used today are part of systems > that try to decide whether a software source is malicious or > legitimate. I don?t think Let?s Encrypt could easily play that kind of > role when issuing certificates free of charge with an automated > process without checking the real-world identity of the applicant. We > could confirm that a code signing certificate applicant controls a > domain name like iurewnrjewknkjqoiw.biz 408 > , but that doesn?t give users or > operating system developers much ability to know whether software that > that applicant publishes is trustworthy or malicious. The JVM is one of very few platforms that has sufficient capability to allow us to do this. If I could chose my pain, I would chose to remove Java Serialization first, before SecurityManager because while I understand the maintenance burden needs to be reduced for the ongoing viability of the Java platform, security is still of utmost importance, as the vulnerabilities of Java Serialization killed of client development. -- Regards, Peter Firmstone Zeus Project Services Pty Ltd. On 16/04/2021 4:05 am, mark.reinhold at oracle.com wrote: > https://openjdk.java.net/jeps/411 > > Summary: Deprecate the Security Manager for removal in a future > release. The Security Manager dates from Java 1.0. It has not been the > primary means of securing client-side Java code for many years, and it > has rarely been used to secure server-side code. To move Java forward, > we intend to deprecate the Security Manager for removal in concert with > the legacy Applet API (JEP 398). > > - Mark From peter.firmstone at zeus.net.au Sat May 1 02:27:58 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Sat, 1 May 2021 12:27:58 +1000 Subject: New candidate JEP: 407: Remove RMI Activation In-Reply-To: <20210326180148.E84233DD70B@eggemoggin.niobe.net> References: <20210326180148.E84233DD70B@eggemoggin.niobe.net> Message-ID: Can we retain the following API classes please, marked as deprecated, but not for removal? We have our own implementation of Activation, that we register with the RMI Registry. Removing these classes will cause many breakages and incompatibilities, we don't need the implementation of Activation. Apache River also uses these and has it's own implementation of Activation called Phoenix. The following interfaces: java.rmi.activation.ActivationInstantiator; java.rmi.activation.ActivationMonitor; java.rmi.activation.ActivationSystem; java.rmi.activation.Activator; The following Exceptions: java.rmi.activation.ActivateFailedException; java.rmi.activation.ActivationException; java.rmi.activation.UnknownObjectException; java.rmi.activation.ActivationException; java.rmi.activation.UnknownGroupException; The following classes: java.rmi.activation.ActivationID; java.rmi.activation.ActivationGroupDesc; java.rmi.activation.ActivationGroupDesc.CommandEnvironment; java.rmi.activation.ActivationGroupID; java.rmi.activation.ActivationDesc; -- Regards, Peter Firmstone Zeus Project Services Pty Ltd. On 27/03/2021 4:01 am, mark.reinhold at oracle.com wrote: > https://openjdk.java.net/jeps/407 > > Summary: Remove the Remote Method Invocation (RMI) Activation > mechanism, while preserving the rest of RMI. > > - Mark From peter.firmstone at zeus.net.au Sat May 1 02:43:23 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Sat, 1 May 2021 12:43:23 +1000 Subject: Preserving API's when removing implementations Message-ID: One trend I am noticing as features are removed from Java, is that API that client code utilises is also removed, which prevents other implementations from replacing lost features, where the Java development community needs to continue supporting such features, it breaks software that would otherwise continue to function with an alternative implementation. Can we do something about preserving parts of these API's perhaps as deprecated without their removal please? Perhaps include the API's in a separate compatibility module, these shouldn't require further development and maintenance, they are just there for backward compatible evolution of client code. Thank you. -- Regards, Peter Firmstone Zeus Project Services Pty Ltd. From cronier.jy at gmail.com Sat May 1 12:19:53 2021 From: cronier.jy at gmail.com (Jean-Yves Cronier) Date: Sat, 1 May 2021 14:19:53 +0200 Subject: Java Bug : Mutual HTTPS authentication not possible with a non-extractable private key with Apple/KeychainStore Message-ID: Description I have imported my personal certificate in macOS keychain with "non-extractable" option (cf. https://ss64.com/osx/security-export.html ). Private key is now protected, and we can't export private key from macOS KeyChain But I am unable to establish connexion with a web-API which require client certificate for mutual authentication with Java It work perfectly well with curl/git, and browsers (safari/chrome) <>System / OS / Java Runtime Information openjdk 11.0.11 macOS 11.3 <>Reproducing the Issue <>Steps to Reproduce 1. Add personal certificate with "non-extractable" option. Example with a personal certificate sent to me in a P12 file named "my-certificate.p12", with following command-line: security import my-certificate.p12 -x -P ? my-strong-password" 2. Connect a site require mutual authentication (for example : https://server.cryptomix.com/secure/ ) <>Expected Result Display content detail of selected client certificate <>Actual Result Error: No TLS client certificate presented <>Source code for an executable test case import javax.net.ssl.HttpsURLConnection; import java.io.IOException; import java.net.URL; import java.security.cert.X509Certificate; public class MutualAuthenticationTest { public static void main(String[] args) throws IOException { System.setProperty("javax.net.ssl.keyStoreType", "KeychainStore"); System.setProperty("javax.net.ssl.keyStore", "NONE"); System.setProperty("javax.net.ssl.keyStorePassword", "-"); testUrl(new URL("https://server.cryptomix.com/secure/")); } public static void testUrl(URL targetUrl) throws IOException { HttpsURLConnection con = (HttpsURLConnection) targetUrl.openConnection(); // Open the connection con.getResponseCode(); assert con.getLocalCertificates() != null && con.getLocalCertificates().length > 0 : "Must use a personnel certificate for mutual authentication"; X509Certificate personalCertificate = (X509Certificate) con.getLocalCertificates()[0]; assert personalCertificate.getSubjectDN() != null; } } <>Workaround No possible workaround on MacOS which Apple/KeychainStore NB : Perfectly work on Windows/MSCAPI with personnel certificate (with non-exportable private key option) From weijun.wang at oracle.com Mon May 3 14:03:38 2021 From: weijun.wang at oracle.com (Wei-Jun Wang) Date: Mon, 3 May 2021 14:03:38 +0000 Subject: Java Bug : Mutual HTTPS authentication not possible with a non-extractable private key with Apple/KeychainStore In-Reply-To: References: Message-ID: <11DE35CD-1019-4E2B-A86B-8EFDC44B9FDE@oracle.com> Hi Jean-Yves, On macOS there?s only native key/certificate management but no signature signing/verification. If you look at https://docs.oracle.com/javase/9/security/oracleproviders.htm, the Apple provider only implements KeyStore. If you need to use a key in client auth, it needs to extract that key and use another provider (SunRsaSign or SunEC) to use it. On the other hand, SunMSCAPI has implemented both KeyStore and Signature, therefore it can do both things inside the provider and the key does not need to be extracted. I?ve filed https://bugs.openjdk.java.net/browse/JDK-8266439. Thanks, Weijun > On May 1, 2021, at 8:19 AM, Jean-Yves Cronier wrote: > > Description > I have imported my personal certificate in macOS keychain with "non-extractable" option (cf. https://ss64.com/osx/security-export.html ). > Private key is now protected, and we can't export private key from macOS KeyChain > But I am unable to establish connexion with a web-API which require client certificate for mutual authentication with Java > It work perfectly well with curl/git, and browsers (safari/chrome) > <>System / OS / Java Runtime Information > openjdk 11.0.11 > macOS 11.3 > <>Reproducing the Issue > <>Steps to Reproduce > 1. Add personal certificate with "non-extractable" option. Example with a personal certificate sent to me in a P12 file named "my-certificate.p12", with following command-line: > security import my-certificate.p12 -x -P ? my-strong-password" > 2. Connect a site require mutual authentication (for example : https://server.cryptomix.com/secure/ ) > <>Expected Result > Display content detail of selected client certificate > <>Actual Result > Error: No TLS client certificate presented > <>Source code for an executable test case > import javax.net.ssl.HttpsURLConnection; > import java.io.IOException; > import java.net.URL; > import java.security.cert.X509Certificate; > > public class MutualAuthenticationTest { > public static void main(String[] args) throws IOException { > System.setProperty("javax.net.ssl.keyStoreType", "KeychainStore"); > System.setProperty("javax.net.ssl.keyStore", "NONE"); > System.setProperty("javax.net.ssl.keyStorePassword", "-"); > testUrl(new URL("https://server.cryptomix.com/secure/")); > } > > public static void testUrl(URL targetUrl) throws IOException { > HttpsURLConnection con = (HttpsURLConnection) targetUrl.openConnection(); > // Open the connection > con.getResponseCode(); > > assert con.getLocalCertificates() != null && con.getLocalCertificates().length > 0 : "Must use a personnel certificate for mutual authentication"; > X509Certificate personalCertificate = (X509Certificate) con.getLocalCertificates()[0]; > assert personalCertificate.getSubjectDN() != null; > } > } > <>Workaround > No possible workaround on MacOS which Apple/KeychainStore > NB : Perfectly work on Windows/MSCAPI with personnel certificate (with non-exportable private key option) From sean.mullan at oracle.com Mon May 3 13:48:02 2021 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 3 May 2021 09:48:02 -0400 Subject: Java Bug : Mutual HTTPS authentication not possible with a non-extractable private key with Apple/KeychainStore In-Reply-To: References: Message-ID: <0f69db56-460b-b88d-a2c5-6e8e6ab4bb55@oracle.com> -bcc jdk-dev This is not the proper alias for reporting issues. Please file a bug at https://bugreport.java.com/bugreport/ Thanks, Sean On 5/1/21 8:19 AM, Jean-Yves Cronier wrote: > Description > I have imported my personal certificate in macOS keychain with "non-extractable" option (cf. https://ss64.com/osx/security-export.html ). > Private key is now protected, and we can't export private key from macOS KeyChain > But I am unable to establish connexion with a web-API which require client certificate for mutual authentication with Java > It work perfectly well with curl/git, and browsers (safari/chrome) > <>System / OS / Java Runtime Information > openjdk 11.0.11 > macOS 11.3 > <>Reproducing the Issue > <>Steps to Reproduce > 1. Add personal certificate with "non-extractable" option. Example with a personal certificate sent to me in a P12 file named "my-certificate.p12", with following command-line: > security import my-certificate.p12 -x -P ? my-strong-password" > 2. Connect a site require mutual authentication (for example : https://server.cryptomix.com/secure/ ) > <>Expected Result > Display content detail of selected client certificate > <>Actual Result > Error: No TLS client certificate presented > <>Source code for an executable test case > import javax.net.ssl.HttpsURLConnection; > import java.io.IOException; > import java.net.URL; > import java.security.cert.X509Certificate; > > public class MutualAuthenticationTest { > public static void main(String[] args) throws IOException { > System.setProperty("javax.net.ssl.keyStoreType", "KeychainStore"); > System.setProperty("javax.net.ssl.keyStore", "NONE"); > System.setProperty("javax.net.ssl.keyStorePassword", "-"); > testUrl(new URL("https://server.cryptomix.com/secure/")); > } > > public static void testUrl(URL targetUrl) throws IOException { > HttpsURLConnection con = (HttpsURLConnection) targetUrl.openConnection(); > // Open the connection > con.getResponseCode(); > > assert con.getLocalCertificates() != null && con.getLocalCertificates().length > 0 : "Must use a personnel certificate for mutual authentication"; > X509Certificate personalCertificate = (X509Certificate) con.getLocalCertificates()[0]; > assert personalCertificate.getSubjectDN() != null; > } > } > <>Workaround > No possible workaround on MacOS which Apple/KeychainStore > NB : Perfectly work on Windows/MSCAPI with personnel certificate (with non-exportable private key option) > From ioi.lam at oracle.com Mon May 3 20:40:17 2021 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 3 May 2021 13:40:17 -0700 Subject: CFV: New JDK Reviewer: Jie Fu Message-ID: <5b19841d-14ab-e988-071f-40be6c09e5f6@oracle.com> I hereby nominate Jie Fu (jiefu)[0] to OpenJDK Reviewer. Jie is currently a JDK Committer and a member of the JVM team at Tencent. His main area of expertise is the JIT compiler and one of his notable contributions is the backend of C2 for mips. Now he is focusing on improving OpenJDK for data science and big data. He has made some significant contributions to Vector API and C2 compiler recently. His contributions also include GC, runtime, core libs, building/testing infrastructures and so on. Jie has more than 140 contributions in openjdk [1]. He is also active in Panama and has contributed 6 commits [2] in Vector API (Second Incubator). Votes are due by 14:00 PDT on Monday, the 17 of May, 2021 Only current OpenJDK Reviewers (and above) [3] 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 [4]. Thanks! Ioi [0] http://openjdk.java.net/census#jiefu [1] https://github.com/openjdk/jdk/search?q=author-name%3A%22Jie+Fu%22&type=commits [2] https://github.com/openjdk/panama-vector/pulls?q=is%3Apr+is%3Aclosed+author%3ADamonFool [3] https://openjdk.java.net/census#jdk [4] http://openjdk.java.net/projects/#reviewer-vote From vladimir.x.ivanov at oracle.com Mon May 3 20:42:43 2021 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 3 May 2021 23:42:43 +0300 Subject: CFV: New JDK Reviewer: Jie Fu In-Reply-To: <5b19841d-14ab-e988-071f-40be6c09e5f6@oracle.com> References: <5b19841d-14ab-e988-071f-40be6c09e5f6@oracle.com> Message-ID: <9d13278d-83a6-571e-f114-ed92bb72144f@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 03.05.2021 23:40, Ioi Lam wrote: > I hereby nominate Jie Fu (jiefu)[0] to OpenJDK Reviewer. From lois.foltan at oracle.com Mon May 3 21:28:09 2021 From: lois.foltan at oracle.com (Lois Foltan) Date: Mon, 3 May 2021 17:28:09 -0400 Subject: CFV: New JDK Reviewer: Jie Fu In-Reply-To: <5b19841d-14ab-e988-071f-40be6c09e5f6@oracle.com> References: <5b19841d-14ab-e988-071f-40be6c09e5f6@oracle.com> Message-ID: Vote: yes Thanks, Lois On 5/3/2021 4:40 PM, Ioi Lam wrote: > I hereby nominate Jie Fu (jiefu)[0] to OpenJDK Reviewer. > > Jie is currently a JDK Committer and a member of the JVM team at Tencent. > His main area of expertise is the JIT compiler and one of his notable > contributions is the backend of C2 for mips. > > Now he is focusing on improving OpenJDK for data science and big data. > He has made some significant contributions to Vector API and C2 compiler > recently. His contributions also include GC, runtime, core libs, > building/testing infrastructures and so on. > > Jie has more than 140 contributions in openjdk [1]. > > He is also active in Panama and has contributed 6 commits [2] > in Vector API (Second Incubator). > > > Votes are due by 14:00 PDT on Monday, the 17 of May, 2021 > > Only current OpenJDK Reviewers (and above) [3] 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 [4]. > > Thanks! > > Ioi > > [0] http://openjdk.java.net/census#jiefu > [1] > https://github.com/openjdk/jdk/search?q=author-name%3A%22Jie+Fu%22&type=commits > [2] > https://github.com/openjdk/panama-vector/pulls?q=is%3Apr+is%3Aclosed+author%3ADamonFool > [3] https://openjdk.java.net/census#jdk > [4] http://openjdk.java.net/projects/#reviewer-vote From vladimir.kozlov at oracle.com Mon May 3 21:44:10 2021 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 3 May 2021 14:44:10 -0700 Subject: CFV: New JDK Reviewer: Jie Fu In-Reply-To: <5b19841d-14ab-e988-071f-40be6c09e5f6@oracle.com> References: <5b19841d-14ab-e988-071f-40be6c09e5f6@oracle.com> Message-ID: <0ef7002e-33ce-0493-61c6-7230cfb049bb@oracle.com> Vote: yes Thanks, Vladimir K On 5/3/21 1:40 PM, Ioi Lam wrote: > I hereby nominate Jie Fu (jiefu)[0] to OpenJDK Reviewer. > > Jie is currently a JDK Committer and a member of the JVM team at Tencent. > His main area of expertise is the JIT compiler and one of his notable > contributions is the backend of C2 for mips. > > Now he is focusing on improving OpenJDK for data science and big data. > He has made some significant contributions to Vector API and C2 compiler > recently. His contributions also include GC, runtime, core libs, > building/testing infrastructures and so on. > > Jie has more than 140 contributions in openjdk [1]. > > He is also active in Panama and has contributed 6 commits [2] > in Vector API (Second Incubator). > > > Votes are due by 14:00 PDT on Monday, the 17 of May, 2021 > > Only current OpenJDK Reviewers (and above) [3] 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 [4]. > > Thanks! > > Ioi > > [0] http://openjdk.java.net/census#jiefu > [1] https://github.com/openjdk/jdk/search?q=author-name%3A%22Jie+Fu%22&type=commits > [2] https://github.com/openjdk/panama-vector/pulls?q=is%3Apr+is%3Aclosed+author%3ADamonFool > [3] https://openjdk.java.net/census#jdk > [4] http://openjdk.java.net/projects/#reviewer-vote From johnsjiang at tencent.com Mon May 3 22:37:04 2021 From: johnsjiang at tencent.com (=?iso-2022-jp?B?am9obnNqaWFuZygbJEI5Pmg1GyhCKQ==?=) Date: Mon, 3 May 2021 22:37:04 +0000 Subject: CFV: New JDK Reviewer: Jie Fu References: <5b19841d-14ab-e988-071f-40be6c09e5f6@oracle.com> Message-ID: <545c45e2f72549e1bc6c574a1de57dd2@tencent.com> Vote: yes Best regards, John Jiang 2021/5/4 AM 4:41, Ioi Lam: > I hereby nominate Jie Fu (jiefu)[0] to OpenJDK Reviewer. > > Jie is currently a JDK Committer and a member of the JVM team at Tencent. > His main area of expertise is the JIT compiler and one of his notable > contributions is the backend of C2 for mips. > > Now he is focusing on improving OpenJDK for data science and big data. > He has made some significant contributions to Vector API and C2 compiler > recently. His contributions also include GC, runtime, core libs, > building/testing infrastructures and so on. > > Jie has more than 140 contributions in openjdk [1]. > > He is also active in Panama and has contributed 6 commits [2] > in Vector API (Second Incubator). > > > Votes are due by 14:00 PDT on Monday, the 17 of May, 2021 > > Only current OpenJDK Reviewers (and above) [3] 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 [4]. > > Thanks! > > Ioi > > [0] http://openjdk.java.net/census#jiefu > [1] > https://github.com/openjdk/jdk/search?q=author-name%3A%22Jie+Fu%22&type=commits > [2] > https://github.com/openjdk/panama-vector/pulls?q=is%3Apr+is%3Aclosed+author%3ADamonFool > [3] https://openjdk.java.net/census#jdk > [4] http://openjdk.java.net/projects/#reviewer-vote > > From zgu at redhat.com Mon May 3 23:15:45 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 3 May 2021 19:15:45 -0400 Subject: CFV: New JDK Reviewer: Jie Fu In-Reply-To: <5b19841d-14ab-e988-071f-40be6c09e5f6@oracle.com> References: <5b19841d-14ab-e988-071f-40be6c09e5f6@oracle.com> Message-ID: <9d38f1da-81a7-5fa5-0eb3-82c1f74c10b4@redhat.com> vote: yes -Zhengyu On 5/3/21 4:40 PM, Ioi Lam wrote: > I hereby nominate Jie Fu (jiefu)[0] to OpenJDK Reviewer. > > Jie is currently a JDK Committer and a member of the JVM team at Tencent. > His main area of expertise is the JIT compiler and one of his notable > contributions is the backend of C2 for mips. > > Now he is focusing on improving OpenJDK for data science and big data. > He has made some significant contributions to Vector API and C2 compiler > recently. His contributions also include GC, runtime, core libs, > building/testing infrastructures and so on. > > Jie has more than 140 contributions in openjdk [1]. > > He is also active in Panama and has contributed 6 commits [2] > in Vector API (Second Incubator). > > > Votes are due by 14:00 PDT on Monday, the 17 of May, 2021 > > Only current OpenJDK Reviewers (and above) [3] 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 [4]. > > Thanks! > > Ioi > > [0] http://openjdk.java.net/census#jiefu > [1] > https://github.com/openjdk/jdk/search?q=author-name%3A%22Jie+Fu%22&type=commits > > [2] > https://github.com/openjdk/panama-vector/pulls?q=is%3Apr+is%3Aclosed+author%3ADamonFool > > [3] https://openjdk.java.net/census#jdk > [4] http://openjdk.java.net/projects/#reviewer-vote > From calvin.cheung at oracle.com Mon May 3 23:27:32 2021 From: calvin.cheung at oracle.com (calvin.cheung at oracle.com) Date: Mon, 3 May 2021 16:27:32 -0700 Subject: CFV: New JDK Reviewer: Jie Fu In-Reply-To: <5b19841d-14ab-e988-071f-40be6c09e5f6@oracle.com> References: <5b19841d-14ab-e988-071f-40be6c09e5f6@oracle.com> Message-ID: <116fd23b-ed54-001d-84ee-8855f970c7c1@oracle.com> Vote: yes Calvin On 5/3/21 1:40 PM, Ioi Lam wrote: > I hereby nominate Jie Fu (jiefu)[0] to OpenJDK Reviewer. From peter.firmstone at zeus.net.au Mon May 3 22:35:27 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Tue, 4 May 2021 08:35:27 +1000 Subject: Java Security: JEP: 411: Deprecate the Security Manager for Removal - What about Serialization? In-Reply-To: <64985afa-1d8b-cc6c-3283-4fd4ef0f5d1a@oracle.com> References: <20210415180500.5D0DE3E00E5@eggemoggin.niobe.net> <64985afa-1d8b-cc6c-3283-4fd4ef0f5d1a@oracle.com> Message-ID: On 4/05/2021 5:12 am, Sean Mullan wrote: > -bcc jdk-dev > -cc security-dev > > On 4/30/21 10:04 PM, Peter Firmstone wrote: >> >> >> In our software we use a ProtectionDomain to represent a remote >> server, because a thread only runs with the user's Subject (and that >> Subject must be carefully preserved for other threads), there is no >> way to represent the remote Server's Subject in a local domain , >> other than with a ProtectionDomain. ? Our software is peer to peer, >> clients can be servers and servers can also be clients.? Code to >> interact with the server is downloaded via Maven and loaded.? Any >> permission's granted to a user, are injected into the stack when run >> as the client Subject, to authenticate the user for the server and >> establish a secure connection, calls made by the client are run with >> the user's Subject on the server, again for access control purposes.? >> This functionality is beyond the capability of Java RMI, we aren't >> using Java RMI to do this.? This is very important to allow us to >> make fine grained access control decisions, or perform event >> notification callbacks over secure connections, without this feature, >> we can't make a secure connection with a callback, and you know what >> happens when you have to do something, but cannot do it securely??? >> We only grant network access directly back to the server, downloaded >> code has been verified and is not expected to cause denial of >> service, by consuming resources etc, but we don't want to grant third >> party access to files, or random network connections, we still have >> privacy obligations for third party information. >> >> We can allow a third party to use unsigned certificates to sign their >> jar files or use a checksum and we verify them using a secure >> connection to the server, prior to loading.?? We then dynamically >> grant permissions to the server's self signed Certificate (used to >> sign the jar file), or a ProtectionDomain, after authenticating the >> server and receiving a check sum or certificate from it.? So the >> client authenticates the server using signed TLS certificates (EG by >> letsencrypt.org or a trusted CA). We use self signed certificates on >> Jar files if we sign them, we are actually trusting the server entity >> in this case, eg a trusted company, but also placing restrictions on >> them. > > I am probably missing something, but I don't understand how this is > secure if you are using TLS server certificates as the basis for > authenticating signed code. These are two very different use cases. Clarifying the level of trust: 1. You have a trusted party, whom you trust to write their own code. 2. You run that code on your systems dynamically. 3. You trust the other party, but you either haven't or it's not practical to audit their code. 4. Using the principle of least privilege, you limit the ability of the other party's code to ensure they are unable observe data they shouldn't, eg a third party with whom you also do business. 5. While a trusted party (eg a supplier) could write code that caused denial of service, eg using up all available memory, there is no motivation for them to do so.? However there may be motivation for them to see quotes on your system from another supplier if they have access to it. The code is loaded dynamically, but before the jvm loads it, we authenticate the party that is asking us to load their code, after which we are basically asking them the question, is this the code you want us to load?? Please check that it hasn't been tampered with.?? The trusted party gives us a checksum, or a self signed certificate they used to sign the jar, we are then satisfied that we have received the software unaltered from the trusted party and not a MITM attack, so we load it.?? However we limit the permission of this software using the principle of least privilege.?? They don't get file permissions, they are only allowed to connect to the server they used to authenticate with. If a third party uses the same jar file, they don't gain the permissions granted to other parties, as it will be loaded into a separate ClassLoader with the permissions granted to that party only. > >> If we remove access control, third parties will be able to open local >> network connections and freely and use Java Serialization over >> unsecured connections, exposing us to an attacker who can use a >> gadget attack. Presently they cannot open a network connection, >> access files or do much of anything without Permission.? All those >> protections will be removed with this JEP. >> >> from https://community.letsencrypt.org/t/do-you-support-code-signing/370 >> >>> Code-signing certificates as they?re used today are part of systems >>> that try to decide whether a software source is malicious or >>> legitimate. I don?t think Let?s Encrypt could easily play that kind >>> of role when issuing certificates free of charge with an automated >>> process without checking the real-world identity of the applicant. >>> We could confirm that a code signing certificate applicant controls >>> a domain name like iurewnrjewknkjqoiw.biz 408 >>> , but that doesn?t give users or >>> operating system developers much ability to know whether software >>> that that applicant publishes is trustworthy or malicious. >> >> The JVM is one of very few platforms that has sufficient capability >> to allow us to do this. >> >> If I could chose my pain, I would chose to remove Java Serialization >> first, before SecurityManager because while I understand the >> maintenance burden needs to be reduced for the ongoing viability of >> the Java platform, security is still of utmost importance, as the >> vulnerabilities of Java Serialization killed of client development. > > I don't think it is appropriate to block deprecation of the Security > Manager until serialization is removed. Note that we have added > mechanisms such as Serialization Filters [1] to help applications > secure their serialization dependencies and that do not require a > Security Manager to be enabled. We also are continuing to look at > other improvements in this area, as well as introducing new features > such as Records that can be serialized more securely [2]. I'm not suggesting blocking deprecation of SecurityManager, I'm requesting blocking removal of SecurityManager until after Serialization has been removed.?? So deprecate SecurityManager, just don't mark it for removal yet.? Please mark SecurityManager for removal after Serialization has been removed.?? What follows is the reasoning for my request. We currently use SecurityManager and policy to prevent un-trusted connections which could otherwise use serialization or access sensitive data. ?? We only allow a limited subset re-implementation of serialization over trusted connections and permission must be granted before it can be used.? No trust established (TLS), then no Serialization.? Because we load code dynamically, we will not be able to profile it in advance, so we cannot create serialization whitelists because we have no way of knowing class names in advance, our only choice will be to disable Serialization entirely.?? At least with security policy, we can establish the permissions in advance. Presently the dynamically loaded code, contains a list of requested Permissions in META-INF, however they may not be granted, the security policy has a list of Permission's that are allowed to be granted based on the remote principal, the permissions granted will be the intersection of these two lists, requested and allowed permissions.? We can log permissions that are not granted.? This occurs dynamically at runtime.? A Permission requested may also be a subset of the Permissions allowed, because of implies checks.? So dynamically loaded code really does operate under least privilege principles.? You can't do that with Serialization filtering. Prior to the introduction of the Serialization's filtering mechanism, I re-implemented a subset of Java Serialization, focused on addressing vulnerabilities caused by gadget attacks. We did this when other companies solutions to addressing Java vulnerabilities was to remove Java altogether, which is why Java applets are no longer used.? Instead, we knuckled down and addressed the vulnerabilities. I had to remove circular links because they introduce security vulnerabilities, I also limited the number of bytes the stream can download before it must be reset, otherwise an IOException is thrown and control is returned to the caller.? It uses constructors, and all classes are expected to validate invariants.? We've discussed it previously.? Apart from Collection classes, serial form of existing classes has not been altered, instead classes have new Constructor's that are used to validate their de-serialized fields.? All fields have also undergone their own validation process.? J.B. called it atomic serialization, when we first discussed it, so that's what we call it. My first step was to re-implement deserialization and use that for some time with the new deserialization public API,? I'm currently implementing a public API for serialization.? After this I will introduce more serialization protocols that use the same API, at that time I may have to change the serial form of some classes, as Java serialization had a lot of complex features that other serialization protocols lack.? The deserialization api, is capable of supporting multiple serial forms, to allow class implementations to change them. Certain Java Collection classes are vulnerable to denial of service attacks, so they are not serialized, instead I have serializers that transfer the data, which is validated during deserialization, before populating the Java Collection classes via constructors.? This means any Collection class can be serialized, even those that don't implement Serializable, they all have the same serial form, so their serialized form basically respects the Collection interfaces of Map, Set and List, their bytes can be compared for equality, for example if two Map's are equal, their serialized bytes will also be equal. Furthermore serialization filters have the same complexity flaws as the Security Manager model, but in our case we use SecurityManager to grant a limited set of privileges that we are able to establish prior to loading dynamic code.??? We already have a profiling tool that generates policy files. Once SecurityManager is removed, third party code will have all permission's granted to the JVM, so they will be able to view files and make network connections.?? The serialization filters offer a similar level of complexity, but with less protection and less time for tool development.? No doubt this will require us to rethink the structure of our software and access control to sensitive data. Once we fixed Policy performance issues and created profiling tools for initial creation of policy files, which are used as a guide to create the requested permission lists and enable permissions to be granted dynamically at runtime, security becomes a significant benefit rather than a burden. To quote waratek: reference https://www.waratek.com/java-serialization-filtering/ > To configure Serialization Filtering, the application needs to first > be fully profiled. *Profiling* an app can be a complex process that > requires specialized tools and has to be performed by domain experts. > Typically, the process requires the app to run normally for a period > of time in order for all its paths to be executed. A dynamic profiling > tool can log the class names that are required for normal operation. > This list of class names will then be the basis of configuring the > white/black list of the Serialization Filters. And even after going > through this process, there is no guarantee that all of the execution > paths were run and all the required class names were logged. Of > course, the same process needs to be performed every time a new > release goes into production or even when a third-party library must > be upgraded. The lifecycle of this process becomes even more complex > since such any change in the Serialization Filters will first need to > go through QA and UAT before it reaches production. > > The Serialization Filtering mechanism follows a very similar approach > to the Security Manager > . > The Security Manager also works based on a whitelist > > and suffers from the same scalability problems. Java?s Security > Manager has proved to be unsuitable for enterprise, large-scale > environments, given that *it moves the responsibility of protecting > the system to the user*. The user is responsible for understanding the > application?s security requirements and technical details and > correctly configuring the security policy, which in essence is a > whitelist of permissions. Such security policies are typically very > complicated in enterprise applications that change frequently and > integrate with numerous different systems and components. The > *operational cost* of correctly configuring and maintaining such > security policies is so high that Security Manager is rarely deployed > in production environments [6 > ] [7 > ]. > I would elaborate that the above problems with SecurityManager have been address in practice, as we've had many years to address them, these solutions are not included with Java of course.? The responsibility is not with the user, but developers and administrators. Also it has become apparent to me, that Java is following in the footsteps of Unix.?? First workstations were replaced by cheaper PC's, so the workstation market was lost, then the PC version of Unix, Linux ate Unix's lunch in the Server market.? Java no longer has a client market, no longer on phones or the browser, some desktop deployments, it has largely retreated to servers.? Be careful not to diminish Java's market too much, lest Android eat Java's server market lunch.? Android has a newer fine grained security model, I don't know if it can be applied to a server environment.?? I don't mean to be inflammatory, just giving you ammunition, should you require it. -- Regards, Peter Firmstone Zeus Project Services Pty Ltd. > > --Sean > > [1] > https://docs.oracle.com/en/java/javase/16/core/serialization-filtering1.html#GUID-3ECB288D-E5BD-4412-892F-E9BB11D4C98A > [2] https://inside.java/2021/04/06/record-serialization-in-practise/ From peter.firmstone at zeus.net.au Mon May 3 22:42:59 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Tue, 4 May 2021 08:42:59 +1000 Subject: Java Security: JEP: 411: Deprecate the Security Manager for Removal - What about Serialization? In-Reply-To: References: <20210415180500.5D0DE3E00E5@eggemoggin.niobe.net> <64985afa-1d8b-cc6c-3283-4fd4ef0f5d1a@oracle.com> Message-ID: Clarification inline below On 4/05/2021 8:35 am, Peter Firmstone wrote: > On 4/05/2021 5:12 am, Sean Mullan wrote: >> -bcc jdk-dev >> -cc security-dev >> >> On 4/30/21 10:04 PM, Peter Firmstone wrote: >>> >>> >>> In our software we use a ProtectionDomain to represent a remote >>> server, because a thread only runs with the user's Subject (and that >>> Subject must be carefully preserved for other threads), there is no >>> way to represent the remote Server's Subject in a local domain , >>> other than with a ProtectionDomain. ? Our software is peer to peer, >>> clients can be servers and servers can also be clients.? Code to >>> interact with the server is downloaded via Maven and loaded.? Any >>> permission's granted to a user, are injected into the stack when run >>> as the client Subject, to authenticate the user for the server and >>> establish a secure connection, calls made by the client are run with >>> the user's Subject on the server, again for access control >>> purposes.? This functionality is beyond the capability of Java RMI, >>> we aren't using Java RMI to do this.? This is very important to >>> allow us to make fine grained access control decisions, or perform >>> event notification callbacks over secure connections, without this >>> feature, we can't make a secure connection with a callback, and you >>> know what happens when you have to do something, but cannot do it >>> securely??? We only grant network access directly back to the >>> server, downloaded code has been verified and is not expected to >>> cause denial of service, by consuming resources etc, but we don't >>> want to grant third party access to files, or random network >>> connections, we still have privacy obligations for third party >>> information. >>> >>> We can allow a third party to use unsigned certificates to sign >>> their jar files or use a checksum and we verify them using a secure >>> connection to the server, prior to loading. We then dynamically >>> grant permissions to the server's self signed Certificate (used to >>> sign the jar file), or a ProtectionDomain, after authenticating the >>> server and receiving a check sum or certificate from it.? So the >>> client authenticates the server using signed TLS certificates (EG by >>> letsencrypt.org or a trusted CA). We use self signed certificates on >>> Jar files if we sign them, we are actually trusting the server >>> entity in this case, eg a trusted company, but also placing >>> restrictions on them. >> >> I am probably missing something, but I don't understand how this is >> secure if you are using TLS server certificates as the basis for >> authenticating signed code. These are two very different use cases. > > > Clarifying the level of trust: > > 1. You have a trusted party, whom you trust to write their own code. > 2. You run that code on your systems dynamically. > 3. You trust the other party, but you either haven't or it's not > practical to audit their code. > 4. Using the principle of least privilege, you limit the ability of > the other party's code to ensure they are unable observe data they > shouldn't, eg a third party with whom you also do business. > 5. While a trusted party (eg a supplier) could write code that caused > denial of service, eg using up all available memory, there is no > motivation for them to do so.? However there may be motivation for > them to see quotes on your system from another supplier if they > have access to it. > > The code is loaded dynamically, but before the jvm loads it, we > authenticate the party that is asking us to load their code, after > which we are basically asking them the question, is this the code you > want us to load?? Please check that it hasn't been tampered with.?? > The trusted party gives us a checksum, or a self signed certificate > they used to sign the jar, we are then satisfied that we have received > the software unaltered from the trusted party and not a MITM attack, > so we load it.?? However we limit the permission of this software > using the principle of least privilege.?? They don't get file > permissions, they are only allowed to connect to the server they used > to authenticate with.? If a third party uses the same jar file, they > don't gain the permissions granted to other parties, as it will be > loaded into a separate ClassLoader with the permissions granted to > that party only. > Just to clarify, these are software logic interactions. > >> >>> If we remove access control, third parties will be able to open >>> local network connections and freely and use Java Serialization over >>> unsecured connections, exposing us to an attacker who can use a >>> gadget attack. Presently they cannot open a network connection, >>> access files or do much of anything without Permission.? All those >>> protections will be removed with this JEP. >>> >>> from >>> https://community.letsencrypt.org/t/do-you-support-code-signing/370 >>> >>>> Code-signing certificates as they?re used today are part of systems >>>> that try to decide whether a software source is malicious or >>>> legitimate. I don?t think Let?s Encrypt could easily play that kind >>>> of role when issuing certificates free of charge with an automated >>>> process without checking the real-world identity of the applicant. >>>> We could confirm that a code signing certificate applicant controls >>>> a domain name like iurewnrjewknkjqoiw.biz 408 >>>> , but that doesn?t give users or >>>> operating system developers much ability to know whether software >>>> that that applicant publishes is trustworthy or malicious. >>> >>> The JVM is one of very few platforms that has sufficient capability >>> to allow us to do this. >>> >>> If I could chose my pain, I would chose to remove Java Serialization >>> first, before SecurityManager because while I understand the >>> maintenance burden needs to be reduced for the ongoing viability of >>> the Java platform, security is still of utmost importance, as the >>> vulnerabilities of Java Serialization killed of client development. >> >> I don't think it is appropriate to block deprecation of the Security >> Manager until serialization is removed. Note that we have added >> mechanisms such as Serialization Filters [1] to help applications >> secure their serialization dependencies and that do not require a >> Security Manager to be enabled. We also are continuing to look at >> other improvements in this area, as well as introducing new features >> such as Records that can be serialized more securely [2]. > > I'm not suggesting blocking deprecation of SecurityManager, I'm > requesting blocking removal of SecurityManager until after > Serialization has been removed.?? So deprecate SecurityManager, just > don't mark it for removal yet.? Please mark SecurityManager for > removal after Serialization has been removed.?? What follows is the > reasoning for my request. > > We currently use SecurityManager and policy to prevent un-trusted > connections which could otherwise use serialization or access > sensitive data. ?? We only allow a limited subset re-implementation of > serialization over trusted connections and permission must be granted > before it can be used.? No trust established (TLS), then no > Serialization.? Because we load code dynamically, we will not be able > to profile it in advance, so we cannot create serialization whitelists > because we have no way of knowing class names in advance, our only > choice will be to disable Serialization entirely.?? At least with > security policy, we can establish the permissions in advance. > > Presently the dynamically loaded code, contains a list of requested > Permissions in META-INF, however they may not be granted, the security > policy has a list of Permission's that are allowed to be granted based > on the remote principal, the permissions granted will be the > intersection of these two lists, requested and allowed permissions.? > We can log permissions that are not granted.? This occurs dynamically > at runtime.? A Permission requested may also be a subset of the > Permissions allowed, because of implies checks.? So dynamically loaded > code really does operate under least privilege principles.? You can't > do that with Serialization filtering. > > Prior to the introduction of the Serialization's filtering mechanism, > I re-implemented a subset of Java Serialization, focused on addressing > vulnerabilities caused by gadget attacks. > > We did this when other companies solutions to addressing Java > vulnerabilities was to remove Java altogether, which is why Java > applets are no longer used.? Instead, we knuckled down and addressed > the vulnerabilities. > > I had to remove circular links because they introduce security > vulnerabilities, I also limited the number of bytes the stream can > download before it must be reset, otherwise an IOException is thrown > and control is returned to the caller.? It uses constructors, and all > classes are expected to validate invariants.? We've discussed it > previously.? Apart from Collection classes, serial form of existing > classes has not been altered, instead classes have new Constructor's > that are used to validate their de-serialized fields.? All fields have > also undergone their own validation process.? J.B. called it atomic > serialization, when we first discussed it, so that's what we call it. > > My first step was to re-implement deserialization and use that for > some time with the new deserialization public API,? I'm currently > implementing a public API for serialization.? After this I will > introduce more serialization protocols that use the same API, at that > time I may have to change the serial form of some classes, as Java > serialization had a lot of complex features that other serialization > protocols lack.? The deserialization api, is capable of supporting > multiple serial forms, to allow class implementations to change them. > > Certain Java Collection classes are vulnerable to denial of service > attacks, so they are not serialized, instead I have serializers that > transfer the data, which is validated during deserialization, before > populating the Java Collection classes via constructors.? This means > any Collection class can be serialized, even those that don't > implement Serializable, they all have the same serial form, so their > serialized form basically respects the Collection interfaces of Map, > Set and List, their bytes can be compared for equality, for example if > two Map's are equal, their serialized bytes will also be equal. > > Furthermore serialization filters have the same complexity flaws as > the Security Manager model, but in our case we use SecurityManager to > grant a limited set of privileges that we are able to establish prior > to loading dynamic code.??? We already have a profiling tool that > generates policy files. > > Once SecurityManager is removed, third party code will have all > permission's granted to the JVM, so they will be able to view files > and make network connections.?? The serialization filters offer a > similar level of complexity, but with less protection and less time > for tool development.? No doubt this will require us to rethink the > structure of our software and access control to sensitive data. > > Once we fixed Policy performance issues and created profiling tools > for initial creation of policy files, which are used as a guide to > create the requested permission lists and enable permissions to be > granted dynamically at runtime, security becomes a significant benefit > rather than a burden. > > To quote waratek: reference > https://www.waratek.com/java-serialization-filtering/ > >> To configure Serialization Filtering, the application needs to first >> be fully profiled. *Profiling* an app can be a complex process that >> requires specialized tools and has to be performed by domain experts. >> Typically, the process requires the app to run normally for a period >> of time in order for all its paths to be executed. A dynamic >> profiling tool can log the class names that are required for normal >> operation. This list of class names will then be the basis of >> configuring the white/black list of the Serialization Filters. And >> even after going through this process, there is no guarantee that all >> of the execution paths were run and all the required class names were >> logged. Of course, the same process needs to be performed every time >> a new release goes into production or even when a third-party library >> must be upgraded. The lifecycle of this process becomes even more >> complex since such any change in the Serialization Filters will first >> need to go through QA and UAT before it reaches production. >> >> The Serialization Filtering mechanism follows a very similar approach >> to the Security Manager >> . >> The Security Manager also works based on a whitelist >> >> and suffers from the same scalability problems. Java?s Security >> Manager has proved to be unsuitable for enterprise, large-scale >> environments, given that *it moves the responsibility of protecting >> the system to the user*. The user is responsible for understanding >> the application?s security requirements and technical details and >> correctly configuring the security policy, which in essence is a >> whitelist of permissions. Such security policies are typically very >> complicated in enterprise applications that change frequently and >> integrate with numerous different systems and components. The >> *operational cost* of correctly configuring and maintaining such >> security policies is so high that Security Manager is rarely deployed >> in production environments [6 >> ] [7 >> ]. >> > > I would elaborate that the above problems with SecurityManager have > been address in practice, as we've had many years to address them, > these solutions are not included with Java of course.? The > responsibility is not with the user, but developers and administrators. > > Also it has become apparent to me, that Java is following in the > footsteps of Unix.?? First workstations were replaced by cheaper PC's, > so the workstation market was lost, then the PC version of Unix, Linux > ate Unix's lunch in the Server market. Java no longer has a client > market, no longer on phones or the browser, some desktop deployments, > it has largely retreated to servers.? Be careful not to diminish > Java's market too much, lest Android eat Java's server market lunch.? > Android has a newer fine grained security model, I don't know if it > can be applied to a server environment.?? I don't mean to be > inflammatory, just giving you ammunition, should you require it. > > -- > Regards, > > Peter Firmstone > Zeus Project Services Pty Ltd. > > >> >> --Sean >> >> [1] >> https://docs.oracle.com/en/java/javase/16/core/serialization-filtering1.html#GUID-3ECB288D-E5BD-4412-892F-E9BB11D4C98A >> [2] https://inside.java/2021/04/06/record-serialization-in-practise/ -- Regards, Peter Firmstone 0498 286 363 Zeus Project Services Pty Ltd. From goetz.lindenmaier at sap.com Tue May 4 07:23:20 2021 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 4 May 2021 07:23:20 +0000 Subject: CFV: New JDK Reviewer: Jie Fu In-Reply-To: <5b19841d-14ab-e988-071f-40be6c09e5f6@oracle.com> References: <5b19841d-14ab-e988-071f-40be6c09e5f6@oracle.com> Message-ID: Vote: yes Best Goetz > -----Original Message----- > From: jdk-dev On Behalf Of Ioi Lam > Sent: Monday, May 3, 2021 10:40 PM > To: jdk-dev at openjdk.java.net > Subject: CFV: New JDK Reviewer: Jie Fu > > I hereby nominate Jie Fu (jiefu)[0] to OpenJDK Reviewer. > > Jie is currently a JDK Committer and a member of the JVM team at Tencent. > His main area of expertise is the JIT compiler and one of his notable > contributions is the backend of C2 for mips. > > Now he is focusing on improving OpenJDK for data science and big data. > He has made some significant contributions to Vector API and C2 compiler > recently. His contributions also include GC, runtime, core libs, > building/testing infrastructures and so on. > > Jie has more than 140 contributions in openjdk [1]. > > He is also active in Panama and has contributed 6 commits [2] > in Vector API (Second Incubator). > > > Votes are due by 14:00 PDT on Monday, the 17 of May, 2021 > > Only current OpenJDK Reviewers (and above) [3] 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 [4]. > > Thanks! > > Ioi > > [0] http://openjdk.java.net/census#jiefu > [1] > https://github.com/openjdk/jdk/search?q=author- > name%3A%22Jie+Fu%22&type=commits > [2] > https://github.com/openjdk/panama- > vector/pulls?q=is%3Apr+is%3Aclosed+author%3ADamonFool > [3] https://openjdk.java.net/census#jdk > [4] http://openjdk.java.net/projects/#reviewer-vote From sgehwolf at redhat.com Tue May 4 07:56:37 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 04 May 2021 09:56:37 +0200 Subject: CFV: New JDK Reviewer: Jie Fu In-Reply-To: <5b19841d-14ab-e988-071f-40be6c09e5f6@oracle.com> References: <5b19841d-14ab-e988-071f-40be6c09e5f6@oracle.com> Message-ID: <03baf7d9e38f527495c8ff96f7496c0ae4e10bd6.camel@redhat.com> Vote: yes On Mon, 2021-05-03 at 13:40 -0700, Ioi Lam wrote: > I hereby nominate Jie Fu (jiefu)[0] to OpenJDK Reviewer. From christoph.langer at sap.com Tue May 4 08:58:27 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 4 May 2021 08:58:27 +0000 Subject: CFV: New JDK Reviewer: Jie Fu In-Reply-To: <5b19841d-14ab-e988-071f-40be6c09e5f6@oracle.com> References: <5b19841d-14ab-e988-071f-40be6c09e5f6@oracle.com> Message-ID: Vote:yes /Christoph > -----Original Message----- > From: jdk-dev On Behalf Of Ioi Lam > Sent: Montag, 3. Mai 2021 22:40 > To: jdk-dev at openjdk.java.net > Subject: CFV: New JDK Reviewer: Jie Fu > > I hereby nominate Jie Fu (jiefu)[0] to OpenJDK Reviewer. > > Jie is currently a JDK Committer and a member of the JVM team at Tencent. > His main area of expertise is the JIT compiler and one of his notable > contributions is the backend of C2 for mips. > > Now he is focusing on improving OpenJDK for data science and big data. > He has made some significant contributions to Vector API and C2 compiler > recently. His contributions also include GC, runtime, core libs, > building/testing infrastructures and so on. > > Jie has more than 140 contributions in openjdk [1]. > > He is also active in Panama and has contributed 6 commits [2] > in Vector API (Second Incubator). > > > Votes are due by 14:00 PDT on Monday, the 17 of May, 2021 > > Only current OpenJDK Reviewers (and above) [3] 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 [4]. > > Thanks! > > Ioi > > [0] http://openjdk.java.net/census#jiefu > [1] > https://github.com/openjdk/jdk/search?q=author- > name%3A%22Jie+Fu%22&type=commits > [2] > https://github.com/openjdk/panama- > vector/pulls?q=is%3Apr+is%3Aclosed+author%3ADamonFool > [3] https://openjdk.java.net/census#jdk > [4] http://openjdk.java.net/projects/#reviewer-vote From tobias.hartmann at oracle.com Tue May 4 12:50:15 2021 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 4 May 2021 14:50:15 +0200 Subject: CFV: New JDK Reviewer: Jie Fu In-Reply-To: <5b19841d-14ab-e988-071f-40be6c09e5f6@oracle.com> References: <5b19841d-14ab-e988-071f-40be6c09e5f6@oracle.com> Message-ID: <49b8b1de-00f2-d0f4-cc5a-7d39b8d8e2a5@oracle.com> Vote: yes Best regards, Tobias On 03.05.21 22:40, Ioi Lam wrote: > I hereby nominate Jie Fu (jiefu)[0] to OpenJDK Reviewer. > > Jie is currently a JDK Committer and a member of the JVM team at Tencent. > His main area of expertise is the JIT compiler and one of his notable > contributions is the backend of C2 for mips. > > Now he is focusing on improving OpenJDK for data science and big data. > He has made some significant contributions to Vector API and C2 compiler > recently. His contributions also include GC, runtime, core libs, > building/testing infrastructures and so on. > > Jie has more than 140 contributions in openjdk [1]. > > He is also active in Panama and has contributed 6 commits [2] > in Vector API (Second Incubator). > > > Votes are due by 14:00 PDT on Monday, the 17 of May, 2021 > > Only current OpenJDK Reviewers (and above) [3] 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 [4]. > > Thanks! > > Ioi > > [0] http://openjdk.java.net/census#jiefu > [1] https://github.com/openjdk/jdk/search?q=author-name%3A%22Jie+Fu%22&type=commits > [2] https://github.com/openjdk/panama-vector/pulls?q=is%3Apr+is%3Aclosed+author%3ADamonFool > [3] https://openjdk.java.net/census#jdk > [4] http://openjdk.java.net/projects/#reviewer-vote From harold.seigel at oracle.com Tue May 4 12:51:14 2021 From: harold.seigel at oracle.com (Harold Seigel) Date: Tue, 4 May 2021 08:51:14 -0400 Subject: CFV: New JDK Reviewer: Jie Fu In-Reply-To: <5b19841d-14ab-e988-071f-40be6c09e5f6@oracle.com> References: <5b19841d-14ab-e988-071f-40be6c09e5f6@oracle.com> Message-ID: <569b4588-462e-628a-a7c4-b92c72addc0a@oracle.com> Vote: Yes Harold On 5/3/2021 4:40 PM, Ioi Lam wrote: > I hereby nominate Jie Fu (jiefu)[0] to OpenJDK Reviewer. > > Jie is currently a JDK Committer and a member of the JVM team at Tencent. > His main area of expertise is the JIT compiler and one of his notable > contributions is the backend of C2 for mips. > > Now he is focusing on improving OpenJDK for data science and big data. > He has made some significant contributions to Vector API and C2 compiler > recently. His contributions also include GC, runtime, core libs, > building/testing infrastructures and so on. > > Jie has more than 140 contributions in openjdk [1]. > > He is also active in Panama and has contributed 6 commits [2] > in Vector API (Second Incubator). > > > Votes are due by 14:00 PDT on Monday, the 17 of May, 2021 > > Only current OpenJDK Reviewers (and above) [3] 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 [4]. > > Thanks! > > Ioi > > [0] http://openjdk.java.net/census#jiefu > [1] > https://github.com/openjdk/jdk/search?q=author-name%3A%22Jie+Fu%22&type=commits > [2] > https://github.com/openjdk/panama-vector/pulls?q=is%3Apr+is%3Aclosed+author%3ADamonFool > [3] https://openjdk.java.net/census#jdk > [4] http://openjdk.java.net/projects/#reviewer-vote From thomas.stuefe at gmail.com Tue May 4 12:58:15 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 4 May 2021 14:58:15 +0200 Subject: CFV: New JDK Reviewer: Jie Fu In-Reply-To: <569b4588-462e-628a-a7c4-b92c72addc0a@oracle.com> References: <5b19841d-14ab-e988-071f-40be6c09e5f6@oracle.com> <569b4588-462e-628a-a7c4-b92c72addc0a@oracle.com> Message-ID: Vote: yes On Tue, May 4, 2021 at 2:51 PM Harold Seigel wrote: > Vote: Yes > > Harold > > On 5/3/2021 4:40 PM, Ioi Lam wrote: > > I hereby nominate Jie Fu (jiefu)[0] to OpenJDK Reviewer. > > > > Jie is currently a JDK Committer and a member of the JVM team at Tencent. > > His main area of expertise is the JIT compiler and one of his notable > > contributions is the backend of C2 for mips. > > > > Now he is focusing on improving OpenJDK for data science and big data. > > He has made some significant contributions to Vector API and C2 compiler > > recently. His contributions also include GC, runtime, core libs, > > building/testing infrastructures and so on. > > > > Jie has more than 140 contributions in openjdk [1]. > > > > He is also active in Panama and has contributed 6 commits [2] > > in Vector API (Second Incubator). > > > > > > Votes are due by 14:00 PDT on Monday, the 17 of May, 2021 > > > > Only current OpenJDK Reviewers (and above) [3] 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 [4]. > > > > Thanks! > > > > Ioi > > > > [0] http://openjdk.java.net/census#jiefu > > [1] > > > https://github.com/openjdk/jdk/search?q=author-name%3A%22Jie+Fu%22&type=commits > > [2] > > > https://github.com/openjdk/panama-vector/pulls?q=is%3Apr+is%3Aclosed+author%3ADamonFool > > [3] https://openjdk.java.net/census#jdk > > [4] http://openjdk.java.net/projects/#reviewer-vote > From zgu at redhat.com Tue May 4 13:31:32 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 4 May 2021 09:31:32 -0400 Subject: Can JDK-8027771 be opened? Message-ID: <39c8e874-3ad5-6c80-1b16-cab9ae0ac8e4@redhat.com> Hi, I am trying to backport JDK-8240690 to 8u, but seems has dependence on JDK-8027771 (Enhance thread contexts), which is private right now. Could some one provide information on JDK-8027771, if it can be opened? Thanks, -Zhengyu From Alan.Bateman at oracle.com Tue May 4 13:42:54 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 4 May 2021 14:42:54 +0100 Subject: Can JDK-8027771 be opened? In-Reply-To: <39c8e874-3ad5-6c80-1b16-cab9ae0ac8e4@redhat.com> References: <39c8e874-3ad5-6c80-1b16-cab9ae0ac8e4@redhat.com> Message-ID: <03a7158e-3762-9c2b-39bf-3c91f109988c@oracle.com> On 04/05/2021 14:31, Zhengyu Gu wrote: > Hi, > > I am trying to backport JDK-8240690 to 8u, but seems has dependence on > JDK-8027771 (Enhance thread contexts), which is private right now. > > Could some one provide information on JDK-8027771, if it can be opened? Sorry, it's a security issue so the JBS issue can't be changed. -Alan From vkempik at azul.com Tue May 4 14:00:12 2021 From: vkempik at azul.com (Vladimir Kempik) Date: Tue, 4 May 2021 14:00:12 +0000 Subject: Result: New jdk Committer: Anton Kozlov Message-ID: Voting for Anton Kozlov (akozlov) [1] is now closed. Yes: 29 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. best regards, -- Vladimir [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2021-April/005339.html From claes.redestad at oracle.com Tue May 4 14:36:12 2021 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 4 May 2021 16:36:12 +0200 Subject: Result: New jdk Reviewer: Jorn Vernee Message-ID: <62486add-e6f4-710c-b3cd-d9cd03a47171@oracle.com> Voting for Jorn Vernee (jvernee) [1] is now closed. Yes: 26 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Thanks! /Claes [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2021-April/005313.html From paul.sandoz at oracle.com Tue May 4 14:59:09 2021 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 4 May 2021 14:59:09 +0000 Subject: CFV: New JDK Reviewer: Jie Fu In-Reply-To: <5b19841d-14ab-e988-071f-40be6c09e5f6@oracle.com> References: <5b19841d-14ab-e988-071f-40be6c09e5f6@oracle.com> Message-ID: <08BE1932-0036-498E-94BE-F93B5C39D2E6@oracle.com> Vote: yes Paul. From hohensee at amazon.com Tue May 4 15:20:31 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 4 May 2021 15:20:31 +0000 Subject: CFV: New JDK Reviewer: Jie Fu Message-ID: Vote: yes ?-----Original Message----- From: jdk-dev on behalf of Ioi Lam Date: Monday, May 3, 2021 at 1:40 PM To: "jdk-dev at openjdk.java.net" Subject: CFV: New JDK Reviewer: Jie Fu I hereby nominate Jie Fu (jiefu)[0] to OpenJDK Reviewer. Jie is currently a JDK Committer and a member of the JVM team at Tencent. His main area of expertise is the JIT compiler and one of his notable contributions is the backend of C2 for mips. Now he is focusing on improving OpenJDK for data science and big data. He has made some significant contributions to Vector API and C2 compiler recently. His contributions also include GC, runtime, core libs, building/testing infrastructures and so on. Jie has more than 140 contributions in openjdk [1]. He is also active in Panama and has contributed 6 commits [2] in Vector API (Second Incubator). Votes are due by 14:00 PDT on Monday, the 17 of May, 2021 Only current OpenJDK Reviewers (and above) [3] 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 [4]. Thanks! Ioi [0] http://openjdk.java.net/census#jiefu [1] https://github.com/openjdk/jdk/search?q=author-name%3A%22Jie+Fu%22&type=commits [2] https://github.com/openjdk/panama-vector/pulls?q=is%3Apr+is%3Aclosed+author%3ADamonFool [3] https://openjdk.java.net/census#jdk [4] http://openjdk.java.net/projects/#reviewer-vote From peter.firmstone at zeus.net.au Tue May 4 02:49:14 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Tue, 4 May 2021 12:49:14 +1000 Subject: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: References: <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com> <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com> Message-ID: Thanks Ron, more discussion below. On 4/05/2021 9:24 am, Ron Pressler wrote: > > >> On 29 Apr 2021, at 13:06, Peter Firmstone >> > wrote: >> >> Is there a simpler way to limit permissions of library code? >> > > Limiting permissions of library code is a spectacular idea, and the > stack-dependent deep sandbox offered by the Security Manager > is the most spectacular software sandbox ever created. The problem is > that while the idea is terrific, it does not seem to work > in practice in any way that is simple and scalable enough to give > assured security for applications written by millions of developers. > That a select few could, perhaps, use it to build secure systems while > the rest just get a false impression of security is not a viable > security strategy for a popular platform. > I would argue that it is not just an idea, that we have been able to successfully use it in practice and have had enough time to write tools and develop software to get around the shortcomings of what ships by default with Java. Assured security is a dreamer's paradise, one morning to awaken with their reputation in tatters, and anyone who believes the dreamer is similarly disillusioned, it is only possible to make life very difficult for a determined attacker, in the hope they will go elsewhere, it's an evolutionary arms race. Developers who deploy security features, don't advertise it, doing so provides information for would be attackers and those who don't value security have little to protect.?? Therefore removing SecurityManager will have a delayed, but unexpected response, most developers haven't kept up with the pace of Java's development. Most changes to date have been very positive for Java, I'm looking forward to using the new Vector API. :) Java's policy provider isn't scalable, but we shouldn't use that as an example.? I can argue that Map isn't scalable because Hashtable isn't, while ignoring ConcurrentHashMap, I'm sure someone would correct me. Present me with an application that has trouble scaling and I will provide SecurityManager and Policy provider implementations that scale as well as the JVM can without a SecurityManager (once warmed up of course).?? There is a negligible performance penalty, but we're talking scalability.? Happy to accept a challenge. AccessController scales nicely.? I'm sure John Rose has had something to do with that, thank you John, it wasn't a wasted effort. The built in Java policy provider is static, therefore all permissions need to be known prior, but this was always just a toy, that's why there's a policy provider interface, it was understood from the beginning.? Our policy provider is dynamic, permissions are granted at runtime.? We also have a profiling tool that creates a policy file, to be edited of course, takes out all the guess work.?? I've attached two examples, took 5 minutes to produce, easy-peasy.? No I've never used the policy editing tool lol :)? That too was just a toy. If you read the generated policy files attached, you'll also notice some viral leaked permissions from Java platform code, note that my code only uses Java's public API, no implementation API's from jdk.internal.reflect or sun.* package namespaces are accessed directly. Yes, I'm sure millions of developers don't use the security infrastructure because they only have low value data to protect, or it belongs to someone else and developers that do, can use it incorrectly, it's probably worse to do the latter, but then people synchronize incorrectly too, but we don't remove synchronization because of that. I can say that I'm relatively confident that I use it correctly, feel free to point out where I'm doing it wrong of course https://github.com/pfirmstone/JGDMS Java's? security capabilities will be reduced as a result of SecurityManager's removal and I understand that we will no longer be able to provide fine grained access control to sensitive data and as security is intertwined throughout our software, that it will have significant impact.? I don't know how to replace that functionality, I've got nothing, zero, zit, zilch, nada. SecurityManager is not a theoretical feature that no one uses. Lets drop the excuses that it's just a theoretical, impractical thing that nobody uses, and say instead that we know that this does something important, it is very powerful, it is a deployed API that is in use, probably the only least privileged protection domain model that really works, but we are no longer supporting it moving forward because it is not well understood by those maintaining it and for this reason it creates a significant maintenance burden. > > There are simpler, and therefore more scalably-secure ways to either > sandbox an application or restrict the Java APIs > accessible to untrusted plugins. I don?t believe that semi-trusting > and selectively sandboxing third-party libraries that otherwise > make use of the full range of Java?s core APIs is cost-effective and > obviously secure. Companies need SMT solvers these days to > check the security of policy files that are much simpler than those > that would be required to sandbox arbitrary third-party libraries. Please provide some examples,? migration options suggestions will be appreciated. I'm only aware of simpler and therefore less secure ways. Scalability is not a valid argument, my implementation scales. I have a profiling tool that creates policy files, then you edit it, it's not that hard.? If you don't have a tool like that, then I can see it would be difficult, but that's why we learn to code, to automate manual tasks?? The more difficult component for developers is preserving a subject across threads preserving context and using privileged calls.? You need that for TLS connections.? That will still have to happen after SecurityManager's removal. But if you think having to preserve a Subject between threads is a chore, I have to preserve Subject's in threads on other JVM's. The SecurityManager is only one of the tools developers must consider for security, one must also be careful to validate invariants during construction and avoid shared access to mutable state. I think static analysis security auditing tools would be useful, to help developers. > >> Perhaps if we instead address the performance and usability issues, >> we could improve adoption,so it adds to Java's appeal, rather than >> detracting from it? >> > > Let's take is as a given that everyone here is interested in adding to > Java?s appeal, yet there might be disagreement over which > decision would do that. Clearly, those who propose removing the > Security Manager believe it will add to Java?s appeal, if for no > other reason than freeing resources to features many people actually > use, while also having a positive effect on security. IMHO Removal of SecurityManager will make Java less appealing to developers because it breaks the promise that our existing software will continue to work on later versions.?? See now you're not just removing something that has a good reason for removal, that was implemented badly, and has been replaced by a better API, this time it's different. With Serialization, we've been given more than ample notice to do something about migrating away from it, but OpenJDK paints over it and wastes resources adding features to putty and paint over it some more, features that no one uses.? Removing Serialization has greater appeal :) This step to remove SecurityManager is so sudden with no replacement options, it's a broken promise to developers, who've invested in Java. Removing SecurityManager has a significantly negative effect on security for me, just so you know.? I'm not happy about its proposed removal, but I realise there's not much I can do about it, other than request it be done in the least painful manner. I began learning Java over 20 years ago, I understand the need to keep Java relevant, however move quickly and break things is for younger software platforms. Once SecurityManager has been removed, we will lose control over who has access to sensitive data, so it's likely we will be stuck on the last version of Java that provides SecurityManager.? The best way I can see for those who need the level of security that SecurityManager provides is to maintain a community LTS edition on OpenJDK, it will be much easier to maintain and backport security patches if Serialization in its current form has been removed, as it will likely have been removed from later versions of Java by that time. Lets be clear Java will no longer be able to finely control access to sensitive data with the removal of SecurityManager.? I'm sure it will be a great bonus for OpenJDK dev's not to have to think about, but it will impact some developers significantly, who would like to do so with the least suffering possible. -- Regards, Peter Firmstone Zeus Project Services Pty Ltd. -------------- next part -------------- grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/lib/jinitests.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission javax.security.auth.AuthPermission "getSubject"; permission org.apache.river.api.io.DeSerializationPermission "MARSHALL"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\java", "execute"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\starter\\starter.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\dynamic-policy.properties", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\jsselogins", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\phoenix.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\truststore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\nonactivatablegroup-dl.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\qa1-lookupservice-dl.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\src\\org\\apache\\river\\test\\resources\\jinitest.policy", "read"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\"", "listen"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Phoenix\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "connect"; permission net.jini.security.GrantPermission "net.jini.security.AuthenticationPermission \"javax.security.auth.x500.X500Principal \\\"CN=Tester\\\" peer javax.security.auth.x500.X500Principal \\\"CN=Reggie\\\"\", \"connect\";"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1092", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1094", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1095", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1101", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1103", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1104", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1105", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1106", "accept,resolve"; permission java.net.SocketPermission "localhost:0", "listen,resolve"; permission java.net.SocketPermission "localhost:9080", "listen,resolve"; permission java.net.SocketPermission "localhost:9081", "listen,resolve"; permission java.net.SocketPermission "localhost:9082", "listen,resolve"; permission java.util.PropertyPermission "/", "read"; permission java.util.PropertyPermission "HOST", "read"; permission java.util.PropertyPermission "activation.jar", "read"; permission java.util.PropertyPermission "bouncy-jce.jar", "read"; permission java.util.PropertyPermission "bouncy-jsse.jar", "read"; permission java.util.PropertyPermission "classserver.jar", "read"; permission java.util.PropertyPermission "collections.jar", "read"; permission java.util.PropertyPermission "destroy.jar", "read"; permission java.util.PropertyPermission "disco.jar", "read"; permission java.util.PropertyPermission "fiddler-dl.jar", "read"; permission java.util.PropertyPermission "fiddler.jar", "read"; permission java.util.PropertyPermission "file.ext", "read"; permission java.util.PropertyPermission "globalclasspath", "read"; permission java.util.PropertyPermission "group.jar", "read"; permission java.util.PropertyPermission "high-scale-lib.jar", "read"; permission java.util.PropertyPermission "java.class.path", "read"; permission java.util.PropertyPermission "java.home", "read"; permission java.util.PropertyPermission "java.rmi.server.codebase", "read"; permission java.util.PropertyPermission "java.util.logging.config.file", "read"; permission java.util.PropertyPermission "jeri.jar", "read"; permission java.util.PropertyPermission "jgdms-rmi-tls.jar", "read"; permission java.util.PropertyPermission "jiniClassServer.adminName", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.port", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "jiniClassServer.dir", "read"; permission java.util.PropertyPermission "jiniClassServer.dir.0", "read"; permission java.util.PropertyPermission "jiniClassServer.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.impl.0", "read"; permission java.util.PropertyPermission "jiniClassServer.port", "read"; permission java.util.PropertyPermission "jiniClassServer.port.0", "read"; permission java.util.PropertyPermission "jiniClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "jiniClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "jiniClassServer.transient.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.type", "read"; permission java.util.PropertyPermission "jiniClassServer.type.0", "read"; permission java.util.PropertyPermission "jiniClassServer.type.1", "read"; permission java.util.PropertyPermission "jsk-dl.jar", "read"; permission java.util.PropertyPermission "jsk-lib.jar", "read"; permission java.util.PropertyPermission "jsk.iiop.jar", "read"; permission java.util.PropertyPermission "jsk.jrmp.jar", "read"; permission java.util.PropertyPermission "jsk.pref.jar", "read"; permission java.util.PropertyPermission "jsk.url.jar", "read"; permission java.util.PropertyPermission "loader.jar", "read"; permission java.util.PropertyPermission "mahalo-dl.jar", "read"; permission java.util.PropertyPermission "mahalo.jar", "read"; permission java.util.PropertyPermission "mercury-dl.jar", "read"; permission java.util.PropertyPermission "mercury.jar", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.adminName", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.classpath", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.classpath.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.codebase", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.codebase.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.component", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.component.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.impl", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.instances", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.integrityhash", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.integrityhash.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.membergroups", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.membergroups.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.policyfile", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.policyfile.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.port", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.port.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.preparername", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.preparername.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running.1", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.serviceConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.serviceConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.starterConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.starterConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.tojoin", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.tojoin.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.classpath", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.classpath.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.codebase", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.codebase.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.component", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.component.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.impl", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.impl.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.integrityhash", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.integrityhash.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.log", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.log.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.membergroups", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.membergroups.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.policyfile", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.policyfile.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.port", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.port.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.preparername", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.preparername.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running.1", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.serviceConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.serviceConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.starterConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.starterConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.tojoin", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.tojoin.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type.1", "read"; permission java.util.PropertyPermission "net.jini.discovery.announce", "read"; permission java.util.PropertyPermission "nonActivatableGroup.adminName", "read"; permission java.util.PropertyPermission "nonActivatableGroup.classpath", "read"; permission java.util.PropertyPermission "nonActivatableGroup.classpath.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.codebase", "read"; permission java.util.PropertyPermission "nonActivatableGroup.codebase.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.impl.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.integrityhash", "read"; permission java.util.PropertyPermission "nonActivatableGroup.integrityhash.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.classpath", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.classpath.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.codebase", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.codebase.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.impl.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.integrityhash", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.integrityhash.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.policyfile", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.policyfile.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvm", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvm.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvmargs", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvmargs.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.policyfile", "read"; permission java.util.PropertyPermission "nonActivatableGroup.policyfile.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvm", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvm.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvmargs", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvmargs.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.transient.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type.1", "read"; permission java.util.PropertyPermission "norm-dl.jar", "read"; permission java.util.PropertyPermission "norm.jar", "read"; permission java.util.PropertyPermission "org.apache.river.jsk.home", "read"; permission java.util.PropertyPermission "org.apache.river.jsk.port", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.dldir.9080", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.dldir.9081", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.globalvmargs", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.integrityhash", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.runjiniserver", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.runkitserver", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.securityproperties", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.serviceMode", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.shared", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.startDelay", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.testClassServer", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.testhosts", "read"; permission java.util.PropertyPermission "org.apache.river.qa.home", "read"; permission java.util.PropertyPermission "org.apache.river.qa.port", "read"; permission java.util.PropertyPermission "org.apache.river.test.home", "read"; permission java.util.PropertyPermission "org.apache.river.test.port", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.actClasspath", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.actCodebase", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTEvntLeaseExp", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTEvntNotify", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTListener", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTSrvcLeaseExp", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.nInstancesPerClass", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.outputRoot", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.policy", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.rmiCodebase", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.selectMethod", "read"; permission java.util.PropertyPermission "outrigger-dl.jar", "read"; permission java.util.PropertyPermission "outrigger-snaplogstore.jar", "read"; permission java.util.PropertyPermission "outrigger.jar", "read"; permission java.util.PropertyPermission "phoenix-common.jar", "read"; permission java.util.PropertyPermission "phoenix-dl.jar", "read"; permission java.util.PropertyPermission "phoenix-group.jar", "read"; permission java.util.PropertyPermission "phoenix-init.jar", "read"; permission java.util.PropertyPermission "phoenix.jar", "read"; permission java.util.PropertyPermission "platform.jar", "read"; permission java.util.PropertyPermission "policy.writer.jar", "read"; permission java.util.PropertyPermission "qaClassServer.adminName", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.port", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "qaClassServer.dir", "read"; permission java.util.PropertyPermission "qaClassServer.dir.0", "read"; permission java.util.PropertyPermission "qaClassServer.impl", "read"; permission java.util.PropertyPermission "qaClassServer.impl.0", "read"; permission java.util.PropertyPermission "qaClassServer.port", "read"; permission java.util.PropertyPermission "qaClassServer.port.0", "read"; permission java.util.PropertyPermission "qaClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "qaClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "qaClassServer.transient.impl", "read"; permission java.util.PropertyPermission "qaClassServer.type", "read"; permission java.util.PropertyPermission "qaClassServer.type.0", "read"; permission java.util.PropertyPermission "qaClassServer.type.1", "read"; permission java.util.PropertyPermission "reggie-dl.jar", "read"; permission java.util.PropertyPermission "reggie.jar", "read"; permission java.util.PropertyPermission "river.version", "read"; permission java.util.PropertyPermission "start.jar", "read"; permission java.util.PropertyPermission "testClassServer.adminName", "read"; permission java.util.PropertyPermission "testClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "testClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "testClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.port", "read"; permission java.util.PropertyPermission "testClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "testClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "testClassServer.dir", "read"; permission java.util.PropertyPermission "testClassServer.dir.0", "read"; permission java.util.PropertyPermission "testClassServer.impl", "read"; permission java.util.PropertyPermission "testClassServer.impl.0", "read"; permission java.util.PropertyPermission "testClassServer.port", "read"; permission java.util.PropertyPermission "testClassServer.port.0", "read"; permission java.util.PropertyPermission "testClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "testClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "testClassServer.transient.impl", "read"; permission java.util.PropertyPermission "testClassServer.type", "read"; permission java.util.PropertyPermission "testClassServer.type.0", "read"; permission java.util.PropertyPermission "testClassServer.type.1", "read"; permission java.util.PropertyPermission "user.dir", "read"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/lib/jiniharness.jar" { permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Test"; permission javax.security.auth.AuthPermission "doAsPrivileged"; permission java.lang.RuntimePermission "getenv.SOUL"; permission java.lang.RuntimePermission "setIO"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\test.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\soul\\soul.202105041128016443", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\src\\org\\apache\\river\\test\\spec\\lookupservice\\configs\\jsse\\default.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\src\\org\\apache\\river\\test\\spec\\lookupservice\\test_set02\\org\\apache\\river\\test\\spec\\lookupservice\\configs\\jsse\\default.config", "read"; permission java.io.FilePermission "org\\apache\\river\\test\\spec\\lookupservice\\configs\\jsse\\default.config", "read"; permission java.security.SecurityPermission "createPolicy.JiniPolicy"; permission java.security.SecurityPermission "getPolicy"; permission java.security.SecurityPermission "setPolicy"; permission java.util.PropertyPermission "line.separator", "read"; permission java.util.PropertyPermission "loader.requireDlPerm", "read"; permission java.util.PropertyPermission "net.jini.discovery.announce", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.defaultTestConfig", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.testhosts", "read"; permission java.util.PropertyPermission "testConfiguration", "read"; permission java.util.PropertyPermission "testFailureAnalyzers", "read"; permission java.util.PropertyPermission "user.dir", "read"; permission java.util.logging.LoggingPermission "control"; }; grant codebase "jrt:/jdk.crypto.mscapi" { permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.lang.RuntimePermission "loadLibrary.sunmscapi"; permission java.security.SecurityPermission "putProviderProperty.SunMSCAPI"; }; grant codebase "jrt:/jdk.security.jgss" { permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.security.SecurityPermission "putProviderProperty.JdkSASL"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/classserver-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\qa1-lookupservice-dl.jar", "read"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1094", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1095", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1103", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1104", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1106", "accept,resolve"; permission java.net.SocketPermission "localhost:9080", "listen,resolve"; permission java.net.SocketPermission "localhost:9081", "listen,resolve"; permission java.net.SocketPermission "localhost:9082", "listen,resolve"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar" { permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.reflect"; permission java.lang.RuntimePermission "createClassLoader"; permission java.lang.RuntimePermission "getClassLoader"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "connect,accept,resolve"; permission java.util.PropertyPermission "java.rmi.server.codebase", "read"; permission java.util.PropertyPermission "net.jini.loader.codebaseAnnotation", "read"; }; grant codebase "httpmd://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar;md5=336e846557a89bbdfad2070befb358a1", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission javax.security.auth.AuthPermission "getSubject"; permission org.apache.river.api.io.DeSerializationPermission "MARSHALL"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Phoenix\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "connect"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1101", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1105", "connect,resolve"; permission java.util.PropertyPermission "org.apache.river.reggie.enableImplToStubReplacement", "read"; }; grant codebase "jrt:/jdk.crypto.ec" { permission java.lang.RuntimePermission "accessClassInPackage.sun.security.jca"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.pkcs"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math.intpoly"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.x509"; permission java.lang.RuntimePermission "loadLibrary.sunec"; permission java.security.SecurityPermission "putProviderProperty.SunEC"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-url-integrity-3.1.1-SNAPSHOT.jar" { permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:"; }; grant codebase "httpmd://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar;md5=336e846557a89bbdfad2070befb358a1" { permission java.lang.RuntimePermission "createClassLoader"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "connect,accept,resolve"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-url-integrity-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission java.net.NetPermission "specifyStreamHandler"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\nonactivatablegroup-dl.jar", "read"; }; grant codebase "httpmd://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar;md5=336e846557a89bbdfad2070befb358a1" { permission java.lang.RuntimePermission "createClassLoader"; }; grant codebase "jrt:/jdk.crypto.cryptoki" { permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; }; grant codebase "jrt:/java.security.jgss" { permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.security.SecurityPermission "putProviderProperty.SunJGSS"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission javax.security.auth.AuthPermission "getSubject"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1101", "connect,resolve"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-platform-3.1.1-SNAPSHOT.jar" { permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission org.apache.river.jeri.internal.EndpointInternalsPermission "set"; permission java.io.SerializablePermission "enableSubclassImplementation"; permission java.io.SerializablePermission "enableSubstitution"; permission java.lang.reflect.ReflectPermission "suppressAccessChecks"; permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Test"; permission javax.security.auth.AuthPermission "doAsPrivileged"; permission javax.security.auth.AuthPermission "getLoginConfiguration"; permission javax.security.auth.AuthPermission "getSubject"; permission javax.security.auth.AuthPermission "getSubjectFromDomainCombiner"; permission javax.security.auth.AuthPermission "modifyPrincipals"; permission javax.security.auth.AuthPermission "modifyPrivateCredentials"; permission javax.security.auth.AuthPermission "modifyPublicCredentials"; permission javax.security.auth.AuthPermission "setLoginConfiguration"; permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.reflect"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.jca"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.krb5"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.pkcs"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.provider"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math.intpoly"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.x509"; permission java.lang.RuntimePermission "accessClassInPackage.sun.util.locale.provider"; permission java.lang.RuntimePermission "accessClassInPackage.sun.util.resources"; permission java.lang.RuntimePermission "accessDeclaredMembers"; permission java.lang.RuntimePermission "accessSystemModules"; permission java.lang.RuntimePermission "createClassLoader"; permission java.lang.RuntimePermission "createSecurityManager"; permission java.lang.RuntimePermission "getClassLoader"; permission java.lang.RuntimePermission "getProtectionDomain"; permission java.lang.RuntimePermission "getStackWalkerWithClassReference"; permission java.lang.RuntimePermission "getenv.SOUL"; permission java.lang.RuntimePermission "loadLibrary.net"; permission java.lang.RuntimePermission "loadLibrary.nio"; permission java.lang.RuntimePermission "loadLibrary.sunec"; permission java.lang.RuntimePermission "loadLibrary.sunmscapi"; permission java.lang.RuntimePermission "loadLibrary.zip"; permission java.lang.RuntimePermission "localeServiceProvider"; permission java.lang.RuntimePermission "loggerFinder"; permission java.lang.RuntimePermission "modifyThread"; permission java.lang.RuntimePermission "modifyThreadGroup"; permission java.lang.RuntimePermission "readFileDescriptor"; permission java.lang.RuntimePermission "reflectionFactoryAccess"; permission java.lang.RuntimePermission "setContextClassLoader"; permission java.lang.RuntimePermission "setIO"; permission java.lang.RuntimePermission "shutdownHooks"; permission java.lang.RuntimePermission "writeFileDescriptor"; permission org.apache.river.api.io.DeSerializationPermission "ATOMIC"; permission net.jini.io.context.ContextPermission "net.jini.io.context.ClientSubject.getClientSubject"; permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Tester\"", "read"; permission java.net.NetPermission "getCookieHandler"; permission java.net.NetPermission "getNetworkInformation"; permission java.net.NetPermission "getProxySelector"; permission java.net.NetPermission "getResponseCache"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\net.dll", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\nio.dll", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\sunec.dll", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\sunmscapi.dll", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\zip.dll", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\net.properties", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\policy\\unlimited", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\policy\\unlimited\\default_US_export.policy", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\policy\\unlimited\\default_local.policy", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\security\\blacklisted.certs", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\security\\cacerts", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\tzdb.dat", "read"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp", "read"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache1725612075511757359.tmp", "delete"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache1725612075511757359.tmp", "read"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache1725612075511757359.tmp", "write"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache3423522293513651042.tmp", "delete"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache3423522293513651042.tmp", "read"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache3423522293513651042.tmp", "write"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-url-integrity-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\test.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\jsselogins", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jiniharness.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jinitests.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\soul\\soul.202105041128016443", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\src\\org\\apache\\river\\test\\spec\\lookupservice\\configs\\jsse\\default.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\src\\org\\apache\\river\\test\\spec\\lookupservice\\test_set02\\org\\apache\\river\\test\\spec\\lookupservice\\configs\\jsse\\default.config", "read"; permission java.io.FilePermission "org\\apache\\river\\test\\spec\\lookupservice\\configs\\jsse\\default.config", "read"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\"", "listen"; permission java.security.SecurityPermission "createAccessControlContext"; permission java.security.SecurityPermission "createPolicy.JiniPolicy"; permission java.security.SecurityPermission "getDomainCombiner"; permission java.security.SecurityPermission "getPolicy"; permission java.security.SecurityPermission "getProperty.auth.login.defaultCallbackHandler"; permission java.security.SecurityPermission "getProperty.crypto.policy"; permission java.security.SecurityPermission "getProperty.jdk.certpath.disabledAlgorithms"; permission java.security.SecurityPermission "getProperty.jdk.security.caDistrustPolicies"; permission java.security.SecurityPermission "getProperty.jdk.security.provider.preferred"; permission java.security.SecurityPermission "getProperty.jdk.serialFilter"; permission java.security.SecurityPermission "getProperty.jdk.tls.disabledAlgorithms"; permission java.security.SecurityPermission "getProperty.jdk.tls.keyLimits"; permission java.security.SecurityPermission "getProperty.jdk.tls.legacyAlgorithms"; permission java.security.SecurityPermission "getProperty.jdk.tls.server.defaultDHEParameters"; permission java.security.SecurityPermission "getProperty.keystore.type"; permission java.security.SecurityPermission "getProperty.keystore.type.compat"; permission java.security.SecurityPermission "getProperty.login.config.url.1"; permission java.security.SecurityPermission "getProperty.login.configuration.provider"; permission java.security.SecurityPermission "getProperty.policy.allowSystemProperty"; permission java.security.SecurityPermission "getProperty.policy.expandProperties"; permission java.security.SecurityPermission "getProperty.securerandom.drbg.config"; permission java.security.SecurityPermission "getProperty.securerandom.source"; permission java.security.SecurityPermission "getProperty.security.provider.1"; permission java.security.SecurityPermission "getProperty.security.provider.10"; permission java.security.SecurityPermission "getProperty.security.provider.11"; permission java.security.SecurityPermission "getProperty.security.provider.12"; permission java.security.SecurityPermission "getProperty.security.provider.13"; permission java.security.SecurityPermission "getProperty.security.provider.14"; permission java.security.SecurityPermission "getProperty.security.provider.2"; permission java.security.SecurityPermission "getProperty.security.provider.3"; permission java.security.SecurityPermission "getProperty.security.provider.4"; permission java.security.SecurityPermission "getProperty.security.provider.5"; permission java.security.SecurityPermission "getProperty.security.provider.6"; permission java.security.SecurityPermission "getProperty.security.provider.7"; permission java.security.SecurityPermission "getProperty.security.provider.8"; permission java.security.SecurityPermission "getProperty.security.provider.9"; permission java.security.SecurityPermission "getProperty.ssl.TrustManagerFactory.algorithm"; permission java.security.SecurityPermission "putProviderProperty.JdkLDAP"; permission java.security.SecurityPermission "putProviderProperty.JdkSASL"; permission java.security.SecurityPermission "putProviderProperty.SUN"; permission java.security.SecurityPermission "putProviderProperty.SunEC"; permission java.security.SecurityPermission "putProviderProperty.SunJCE"; permission java.security.SecurityPermission "putProviderProperty.SunJGSS"; permission java.security.SecurityPermission "putProviderProperty.SunJSSE"; permission java.security.SecurityPermission "putProviderProperty.SunMSCAPI"; permission java.security.SecurityPermission "putProviderProperty.SunPCSC"; permission java.security.SecurityPermission "putProviderProperty.SunRsaSign"; permission java.security.SecurityPermission "putProviderProperty.SunSASL"; permission java.security.SecurityPermission "putProviderProperty.XMLDSig"; permission java.security.SecurityPermission "setPolicy"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "connect,accept,resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve"; permission java.util.PropertyPermission "*", "read,write"; permission java.util.logging.LoggingPermission "control"; permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; permission org.apache.river.thread.ThreadPoolPermission "getUserThreadPool"; }; grant codebase "httpmd://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar;md5=336e846557a89bbdfad2070befb358a1" { permission org.apache.river.api.io.DeSerializationPermission "ATOMIC"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/lib/jiniharness.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission javax.security.auth.AuthPermission "getSubject"; permission java.lang.RuntimePermission "exitVM.0"; permission org.apache.river.api.io.DeSerializationPermission "MARSHALL"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\java", "execute"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\starter\\starter.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\dynamic-policy.properties", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\jsselogins", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\phoenix.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\truststore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\nonactivatablegroup-dl.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\qa1-lookupservice-dl.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\src\\org\\apache\\river\\test\\resources\\jinitest.policy", "read"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\"", "listen"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Phoenix\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "connect"; permission net.jini.security.GrantPermission "net.jini.security.AuthenticationPermission \"javax.security.auth.x500.X500Principal \\\"CN=Tester\\\" peer javax.security.auth.x500.X500Principal \\\"CN=Reggie\\\"\", \"connect\";"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1092", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1094", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1095", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1101", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1103", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1104", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1105", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1106", "accept,resolve"; permission java.net.SocketPermission "localhost:0", "listen,resolve"; permission java.net.SocketPermission "localhost:9080", "listen,resolve"; permission java.net.SocketPermission "localhost:9081", "listen,resolve"; permission java.net.SocketPermission "localhost:9082", "listen,resolve"; permission java.util.PropertyPermission "/", "read"; permission java.util.PropertyPermission "HOST", "read"; permission java.util.PropertyPermission "activation.jar", "read"; permission java.util.PropertyPermission "bouncy-jce.jar", "read"; permission java.util.PropertyPermission "bouncy-jsse.jar", "read"; permission java.util.PropertyPermission "classserver.jar", "read"; permission java.util.PropertyPermission "collections.jar", "read"; permission java.util.PropertyPermission "destroy.jar", "read"; permission java.util.PropertyPermission "disco.jar", "read"; permission java.util.PropertyPermission "fiddler-dl.jar", "read"; permission java.util.PropertyPermission "fiddler.jar", "read"; permission java.util.PropertyPermission "file.ext", "read"; permission java.util.PropertyPermission "globalclasspath", "read"; permission java.util.PropertyPermission "group.jar", "read"; permission java.util.PropertyPermission "high-scale-lib.jar", "read"; permission java.util.PropertyPermission "java.class.path", "read"; permission java.util.PropertyPermission "java.home", "read"; permission java.util.PropertyPermission "java.rmi.server.codebase", "read"; permission java.util.PropertyPermission "java.util.logging.config.file", "read"; permission java.util.PropertyPermission "jeri.jar", "read"; permission java.util.PropertyPermission "jgdms-rmi-tls.jar", "read"; permission java.util.PropertyPermission "jiniClassServer.adminName", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.port", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "jiniClassServer.dir", "read"; permission java.util.PropertyPermission "jiniClassServer.dir.0", "read"; permission java.util.PropertyPermission "jiniClassServer.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.impl.0", "read"; permission java.util.PropertyPermission "jiniClassServer.port", "read"; permission java.util.PropertyPermission "jiniClassServer.port.0", "read"; permission java.util.PropertyPermission "jiniClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "jiniClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "jiniClassServer.transient.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.type", "read"; permission java.util.PropertyPermission "jiniClassServer.type.0", "read"; permission java.util.PropertyPermission "jiniClassServer.type.1", "read"; permission java.util.PropertyPermission "jsk-dl.jar", "read"; permission java.util.PropertyPermission "jsk-lib.jar", "read"; permission java.util.PropertyPermission "jsk.iiop.jar", "read"; permission java.util.PropertyPermission "jsk.jrmp.jar", "read"; permission java.util.PropertyPermission "jsk.pref.jar", "read"; permission java.util.PropertyPermission "jsk.url.jar", "read"; permission java.util.PropertyPermission "loader.jar", "read"; permission java.util.PropertyPermission "mahalo-dl.jar", "read"; permission java.util.PropertyPermission "mahalo.jar", "read"; permission java.util.PropertyPermission "mercury-dl.jar", "read"; permission java.util.PropertyPermission "mercury.jar", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.adminName", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.classpath", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.classpath.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.codebase", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.codebase.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.component", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.component.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.impl", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.instances", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.integrityhash", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.integrityhash.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.membergroups", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.membergroups.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.policyfile", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.policyfile.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.port", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.port.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.preparername", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.preparername.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running.1", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.serviceConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.serviceConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.starterConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.starterConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.tojoin", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.tojoin.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.classpath", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.classpath.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.codebase", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.codebase.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.component", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.component.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.impl", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.impl.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.integrityhash", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.integrityhash.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.log", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.log.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.membergroups", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.membergroups.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.policyfile", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.policyfile.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.port", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.port.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.preparername", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.preparername.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running.1", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.serviceConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.serviceConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.starterConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.starterConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.tojoin", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.tojoin.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type.1", "read"; permission java.util.PropertyPermission "net.jini.discovery.announce", "read"; permission java.util.PropertyPermission "nonActivatableGroup.adminName", "read"; permission java.util.PropertyPermission "nonActivatableGroup.classpath", "read"; permission java.util.PropertyPermission "nonActivatableGroup.classpath.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.codebase", "read"; permission java.util.PropertyPermission "nonActivatableGroup.codebase.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.impl.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.integrityhash", "read"; permission java.util.PropertyPermission "nonActivatableGroup.integrityhash.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.classpath", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.classpath.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.codebase", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.codebase.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.impl.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.integrityhash", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.integrityhash.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.policyfile", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.policyfile.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvm", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvm.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvmargs", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvmargs.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.policyfile", "read"; permission java.util.PropertyPermission "nonActivatableGroup.policyfile.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvm", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvm.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvmargs", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvmargs.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.transient.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type.1", "read"; permission java.util.PropertyPermission "norm-dl.jar", "read"; permission java.util.PropertyPermission "norm.jar", "read"; permission java.util.PropertyPermission "org.apache.river.jsk.home", "read"; permission java.util.PropertyPermission "org.apache.river.jsk.port", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.callAutoT", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.dldir.9080", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.dldir.9081", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.globalvmargs", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.integrityhash", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.nSecsWaitDestroy", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.runjiniserver", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.runkitserver", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.securityproperties", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.serviceMode", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.shared", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.startDelay", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.testClassServer", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.testhosts", "read"; permission java.util.PropertyPermission "org.apache.river.qa.home", "read"; permission java.util.PropertyPermission "org.apache.river.qa.port", "read"; permission java.util.PropertyPermission "org.apache.river.test.home", "read"; permission java.util.PropertyPermission "org.apache.river.test.port", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.actClasspath", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.actCodebase", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTEvntLeaseExp", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTEvntNotify", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTListener", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTSrvcLeaseExp", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.nInstancesPerClass", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.outputRoot", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.policy", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.rmiCodebase", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.selectMethod", "read"; permission java.util.PropertyPermission "os.name", "read"; permission java.util.PropertyPermission "outrigger-dl.jar", "read"; permission java.util.PropertyPermission "outrigger-snaplogstore.jar", "read"; permission java.util.PropertyPermission "outrigger.jar", "read"; permission java.util.PropertyPermission "phoenix-common.jar", "read"; permission java.util.PropertyPermission "phoenix-dl.jar", "read"; permission java.util.PropertyPermission "phoenix-group.jar", "read"; permission java.util.PropertyPermission "phoenix-init.jar", "read"; permission java.util.PropertyPermission "phoenix.jar", "read"; permission java.util.PropertyPermission "platform.jar", "read"; permission java.util.PropertyPermission "policy.writer.jar", "read"; permission java.util.PropertyPermission "qaClassServer.adminName", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.port", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "qaClassServer.dir", "read"; permission java.util.PropertyPermission "qaClassServer.dir.0", "read"; permission java.util.PropertyPermission "qaClassServer.impl", "read"; permission java.util.PropertyPermission "qaClassServer.impl.0", "read"; permission java.util.PropertyPermission "qaClassServer.port", "read"; permission java.util.PropertyPermission "qaClassServer.port.0", "read"; permission java.util.PropertyPermission "qaClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "qaClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "qaClassServer.transient.impl", "read"; permission java.util.PropertyPermission "qaClassServer.type", "read"; permission java.util.PropertyPermission "qaClassServer.type.0", "read"; permission java.util.PropertyPermission "qaClassServer.type.1", "read"; permission java.util.PropertyPermission "reggie-dl.jar", "read"; permission java.util.PropertyPermission "reggie.jar", "read"; permission java.util.PropertyPermission "river.version", "read"; permission java.util.PropertyPermission "start.jar", "read"; permission java.util.PropertyPermission "testClassServer.adminName", "read"; permission java.util.PropertyPermission "testClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "testClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "testClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.port", "read"; permission java.util.PropertyPermission "testClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "testClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "testClassServer.dir", "read"; permission java.util.PropertyPermission "testClassServer.dir.0", "read"; permission java.util.PropertyPermission "testClassServer.impl", "read"; permission java.util.PropertyPermission "testClassServer.impl.0", "read"; permission java.util.PropertyPermission "testClassServer.port", "read"; permission java.util.PropertyPermission "testClassServer.port.0", "read"; permission java.util.PropertyPermission "testClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "testClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "testClassServer.transient.impl", "read"; permission java.util.PropertyPermission "testClassServer.type", "read"; permission java.util.PropertyPermission "testClassServer.type.0", "read"; permission java.util.PropertyPermission "testClassServer.type.1", "read"; permission java.util.PropertyPermission "user.dir", "read"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib-dl/jgdms-lib-dl-3.1.1-SNAPSHOT.jar" { permission org.apache.river.api.io.DeSerializationPermission "ATOMIC"; }; grant codebase "jrt:/jdk.localedata" { permission java.lang.RuntimePermission "accessClassInPackage.sun.util.locale.provider"; permission java.lang.RuntimePermission "accessClassInPackage.sun.util.resources"; }; grant codebase "jrt:/java.smartcardio" { permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.security.SecurityPermission "putProviderProperty.SunPCSC"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-collections-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-platform-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission javax.security.auth.AuthPermission "getSubject"; permission java.lang.RuntimePermission "exitVM.0"; permission org.apache.river.api.io.DeSerializationPermission "MARSHALL"; permission java.net.NetPermission "specifyStreamHandler"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\java", "execute"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\starter\\starter.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\dynamic-policy.properties", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\jsselogins", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\phoenix.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\truststore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\nonactivatablegroup-dl.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\qa1-lookupservice-dl.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\src\\org\\apache\\river\\test\\resources\\jinitest.policy", "read"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\"", "listen"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Phoenix\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "accept"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "accept"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "connect"; permission net.jini.security.GrantPermission "net.jini.security.AuthenticationPermission \"javax.security.auth.x500.X500Principal \\\"CN=Tester\\\" peer javax.security.auth.x500.X500Principal \\\"CN=Reggie\\\"\", \"connect\";"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1092", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1094", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1095", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1101", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1103", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1104", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1105", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1106", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1107", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1123", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1176", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1187", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1188", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1198", "accept,resolve"; permission java.net.SocketPermission "localhost:0", "listen,resolve"; permission java.net.SocketPermission "localhost:9080", "listen,resolve"; permission java.net.SocketPermission "localhost:9081", "listen,resolve"; permission java.net.SocketPermission "localhost:9082", "listen,resolve"; permission java.util.PropertyPermission "/", "read"; permission java.util.PropertyPermission "HOST", "read"; permission java.util.PropertyPermission "activation.jar", "read"; permission java.util.PropertyPermission "bouncy-jce.jar", "read"; permission java.util.PropertyPermission "bouncy-jsse.jar", "read"; permission java.util.PropertyPermission "classserver.jar", "read"; permission java.util.PropertyPermission "collections.jar", "read"; permission java.util.PropertyPermission "destroy.jar", "read"; permission java.util.PropertyPermission "disco.jar", "read"; permission java.util.PropertyPermission "fiddler-dl.jar", "read"; permission java.util.PropertyPermission "fiddler.jar", "read"; permission java.util.PropertyPermission "file.ext", "read"; permission java.util.PropertyPermission "globalclasspath", "read"; permission java.util.PropertyPermission "group.jar", "read"; permission java.util.PropertyPermission "high-scale-lib.jar", "read"; permission java.util.PropertyPermission "java.class.path", "read"; permission java.util.PropertyPermission "java.home", "read"; permission java.util.PropertyPermission "java.rmi.server.codebase", "read"; permission java.util.PropertyPermission "java.util.logging.config.file", "read"; permission java.util.PropertyPermission "javax.net.ssl.trustStore", "read"; permission java.util.PropertyPermission "javax.net.ssl.trustStorePassword", "read"; permission java.util.PropertyPermission "javax.net.ssl.trustStoreType", "read"; permission java.util.PropertyPermission "jeri.jar", "read"; permission java.util.PropertyPermission "jgdms-rmi-tls.jar", "read"; permission java.util.PropertyPermission "jiniClassServer.adminName", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.port", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "jiniClassServer.dir", "read"; permission java.util.PropertyPermission "jiniClassServer.dir.0", "read"; permission java.util.PropertyPermission "jiniClassServer.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.impl.0", "read"; permission java.util.PropertyPermission "jiniClassServer.port", "read"; permission java.util.PropertyPermission "jiniClassServer.port.0", "read"; permission java.util.PropertyPermission "jiniClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "jiniClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "jiniClassServer.transient.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.type", "read"; permission java.util.PropertyPermission "jiniClassServer.type.0", "read"; permission java.util.PropertyPermission "jiniClassServer.type.1", "read"; permission java.util.PropertyPermission "jsk-dl.jar", "read"; permission java.util.PropertyPermission "jsk-lib.jar", "read"; permission java.util.PropertyPermission "jsk.iiop.jar", "read"; permission java.util.PropertyPermission "jsk.jrmp.jar", "read"; permission java.util.PropertyPermission "jsk.pref.jar", "read"; permission java.util.PropertyPermission "jsk.url.jar", "read"; permission java.util.PropertyPermission "loader.jar", "read"; permission java.util.PropertyPermission "mahalo-dl.jar", "read"; permission java.util.PropertyPermission "mahalo.jar", "read"; permission java.util.PropertyPermission "mercury-dl.jar", "read"; permission java.util.PropertyPermission "mercury.jar", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.adminName", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.classpath", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.classpath.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.codebase", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.codebase.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.component", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.component.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.impl", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.instances", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.integrityhash", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.integrityhash.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.membergroups", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.membergroups.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.policyfile", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.policyfile.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.port", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.port.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.preparername", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.preparername.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running.1", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.serviceConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.serviceConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.starterConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.starterConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.tojoin", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.tojoin.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.classpath", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.classpath.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.codebase", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.codebase.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.component", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.component.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.impl", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.impl.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.integrityhash", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.integrityhash.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.log", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.log.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.membergroups", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.membergroups.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.policyfile", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.policyfile.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.port", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.port.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.preparername", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.preparername.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running.1", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.serviceConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.serviceConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.starterConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.starterConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.tojoin", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.tojoin.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type.1", "read"; permission java.util.PropertyPermission "net.jini.discovery.announce", "read"; permission java.util.PropertyPermission "nonActivatableGroup.adminName", "read"; permission java.util.PropertyPermission "nonActivatableGroup.classpath", "read"; permission java.util.PropertyPermission "nonActivatableGroup.classpath.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.codebase", "read"; permission java.util.PropertyPermission "nonActivatableGroup.codebase.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.impl.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.integrityhash", "read"; permission java.util.PropertyPermission "nonActivatableGroup.integrityhash.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.classpath", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.classpath.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.codebase", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.codebase.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.impl.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.integrityhash", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.integrityhash.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.policyfile", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.policyfile.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvm", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvm.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvmargs", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvmargs.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.policyfile", "read"; permission java.util.PropertyPermission "nonActivatableGroup.policyfile.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvm", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvm.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvmargs", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvmargs.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.transient.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type.1", "read"; permission java.util.PropertyPermission "norm-dl.jar", "read"; permission java.util.PropertyPermission "norm.jar", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxClientSessionDuration", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxServerSessionDuration", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.trustManagerFactoryAlgorithm", "read"; permission java.util.PropertyPermission "org.apache.river.jsk.home", "read"; permission java.util.PropertyPermission "org.apache.river.jsk.port", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.callAutoT", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.dldir.9080", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.dldir.9081", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.globalvmargs", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.integrityhash", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.nSecsWaitDestroy", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.runjiniserver", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.runkitserver", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.securityproperties", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.serviceMode", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.shared", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.startDelay", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.testClassServer", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.testhosts", "read"; permission java.util.PropertyPermission "org.apache.river.qa.home", "read"; permission java.util.PropertyPermission "org.apache.river.qa.port", "read"; permission java.util.PropertyPermission "org.apache.river.reggie.enableImplToStubReplacement", "read"; permission java.util.PropertyPermission "org.apache.river.test.home", "read"; permission java.util.PropertyPermission "org.apache.river.test.port", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.actClasspath", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.actCodebase", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTEvntLeaseExp", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTEvntNotify", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTListener", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTSrvcLeaseExp", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.nInstancesPerClass", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.outputRoot", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.policy", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.rmiCodebase", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.selectMethod", "read"; permission java.util.PropertyPermission "os.name", "read"; permission java.util.PropertyPermission "outrigger-dl.jar", "read"; permission java.util.PropertyPermission "outrigger-snaplogstore.jar", "read"; permission java.util.PropertyPermission "outrigger.jar", "read"; permission java.util.PropertyPermission "phoenix-common.jar", "read"; permission java.util.PropertyPermission "phoenix-dl.jar", "read"; permission java.util.PropertyPermission "phoenix-group.jar", "read"; permission java.util.PropertyPermission "phoenix-init.jar", "read"; permission java.util.PropertyPermission "phoenix.jar", "read"; permission java.util.PropertyPermission "platform.jar", "read"; permission java.util.PropertyPermission "policy.writer.jar", "read"; permission java.util.PropertyPermission "qaClassServer.adminName", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.port", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "qaClassServer.dir", "read"; permission java.util.PropertyPermission "qaClassServer.dir.0", "read"; permission java.util.PropertyPermission "qaClassServer.impl", "read"; permission java.util.PropertyPermission "qaClassServer.impl.0", "read"; permission java.util.PropertyPermission "qaClassServer.port", "read"; permission java.util.PropertyPermission "qaClassServer.port.0", "read"; permission java.util.PropertyPermission "qaClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "qaClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "qaClassServer.transient.impl", "read"; permission java.util.PropertyPermission "qaClassServer.type", "read"; permission java.util.PropertyPermission "qaClassServer.type.0", "read"; permission java.util.PropertyPermission "qaClassServer.type.1", "read"; permission java.util.PropertyPermission "reggie-dl.jar", "read"; permission java.util.PropertyPermission "reggie.jar", "read"; permission java.util.PropertyPermission "river.version", "read"; permission java.util.PropertyPermission "start.jar", "read"; permission java.util.PropertyPermission "testClassServer.adminName", "read"; permission java.util.PropertyPermission "testClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "testClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "testClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.port", "read"; permission java.util.PropertyPermission "testClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "testClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "testClassServer.dir", "read"; permission java.util.PropertyPermission "testClassServer.dir.0", "read"; permission java.util.PropertyPermission "testClassServer.impl", "read"; permission java.util.PropertyPermission "testClassServer.impl.0", "read"; permission java.util.PropertyPermission "testClassServer.port", "read"; permission java.util.PropertyPermission "testClassServer.port.0", "read"; permission java.util.PropertyPermission "testClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "testClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "testClassServer.transient.impl", "read"; permission java.util.PropertyPermission "testClassServer.type", "read"; permission java.util.PropertyPermission "testClassServer.type.0", "read"; permission java.util.PropertyPermission "testClassServer.type.1", "read"; permission java.util.PropertyPermission "user.dir", "read"; permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-jeri-3.1.1-SNAPSHOT.jar" { permission org.apache.river.jeri.internal.EndpointInternalsPermission "set"; permission java.io.SerializablePermission "enableSubclassImplementation"; permission java.io.SerializablePermission "enableSubstitution"; permission java.lang.reflect.ReflectPermission "suppressAccessChecks"; permission javax.security.auth.AuthPermission "getSubject"; permission java.lang.RuntimePermission "getClassLoader"; permission java.lang.RuntimePermission "modifyThread"; permission java.lang.RuntimePermission "modifyThreadGroup"; permission java.lang.RuntimePermission "setContextClassLoader"; permission org.apache.river.api.io.DeSerializationPermission "ATOMIC"; permission net.jini.io.context.ContextPermission "net.jini.io.context.ClientSubject.getClientSubject"; permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Tester\"", "read"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\"", "listen"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1107", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1123", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1176", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1187", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1188", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1198", "accept,resolve"; permission java.util.PropertyPermission "org.apache.river.jeri.connection.mux.client.initialInboundRation", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.connection.mux.server.initialInboundRation", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.connectionTimeout", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.dgc.checkInterval", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.dgc.cleanInterval", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.dgc.leaseValue", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.dgc.minimumDuration", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.handshakeTimeout", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.server.suppressStackTraces", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.certificateType", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.cipherSuites", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jceProvider", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jsseProvider", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.secureRandomAlgorithm", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.sslProtocol", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.tcp.useNIO", "read"; permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; permission org.apache.river.thread.ThreadPoolPermission "getUserThreadPool"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/lib/jinitests.jar" { permission java.lang.RuntimePermission "createClassLoader"; permission java.util.PropertyPermission "loader.requireDlPerm", "read"; permission java.util.PropertyPermission "net.jini.discovery.announce", "read"; }; grant codebase "jrt:/jdk.security.auth" { permission javax.security.auth.AuthPermission "modifyPrincipals"; permission javax.security.auth.AuthPermission "modifyPrivateCredentials"; permission javax.security.auth.AuthPermission "modifyPublicCredentials"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.krb5"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.lang.RuntimePermission "getProtectionDomain"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jiniharness.jar", "read"; }; grant codebase "jrt:/java.xml.crypto" { permission java.security.SecurityPermission "putProviderProperty.XMLDSig"; permission java.util.PropertyPermission "java.specification.version", "read"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-jeri-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission javax.security.auth.AuthPermission "getSubject"; permission org.apache.river.api.io.DeSerializationPermission "MARSHALL"; permission java.io.FilePermission "harness\\trust\\truststore", "read"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\"", "listen"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Phoenix\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "accept"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "accept"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "connect"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1092", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1101", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1105", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1107", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1123", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1176", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1187", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1188", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1198", "accept,resolve"; permission java.net.SocketPermission "localhost:0", "listen,resolve"; permission java.util.PropertyPermission "javax.net.ssl.trustStore", "read"; permission java.util.PropertyPermission "javax.net.ssl.trustStorePassword", "read"; permission java.util.PropertyPermission "javax.net.ssl.trustStoreType", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxClientSessionDuration", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxServerSessionDuration", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.trustManagerFactoryAlgorithm", "read"; permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; }; grant codebase "httpmd://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar;md5=02e8620ac1109684fa26b78ee6e69387" { permission org.apache.river.api.io.DeSerializationPermission "ATOMIC"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-collections-3.1.1-SNAPSHOT.jar" { permission java.lang.RuntimePermission "getClassLoader"; permission java.lang.RuntimePermission "modifyThread"; permission java.lang.RuntimePermission "modifyThreadGroup"; permission java.lang.RuntimePermission "setContextClassLoader"; permission java.lang.RuntimePermission "shutdownHooks"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\"", "listen"; permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1107", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1123", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1176", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1187", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1188", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1198", "accept,resolve"; permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; permission org.apache.river.thread.ThreadPoolPermission "getUserThreadPool"; }; grant codebase "httpmd://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar;md5=336e846557a89bbdfad2070befb358a1" { permission java.lang.RuntimePermission "createClassLoader"; }; grant codebase "httpmd://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar;md5=336e846557a89bbdfad2070befb358a1" { permission java.lang.RuntimePermission "createClassLoader"; }; -------------- next part -------------- grant principal javax.security.auth.x500.X500Principal "CN=Tester" { permission net.jini.security.AccessPermission "org.apache.river.reggie.proxy.Registrar.renewLeases"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-platform-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission java.util.PropertyPermission "java.security.policy", "read"; permission java.util.PropertyPermission "java.security.policy", "write"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.security.SecurityPermission "createPolicy.JiniPolicy"; permission java.security.SecurityPermission "getPolicy"; permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass"; permission java.security.SecurityPermission "setPolicy"; permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";"; permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie"; permission javax.security.auth.AuthPermission "doAsPrivileged"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; permission java.lang.RuntimePermission "accessDeclaredMembers"; permission java.lang.RuntimePermission "createClassLoader"; permission java.lang.RuntimePermission "setContextClassLoader"; permission java.lang.reflect.ReflectPermission "suppressAccessChecks"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-collections-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read"; }; grant codebase "jrt:/jdk.crypto.cryptoki" { permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; }; grant codebase "jrt:/jdk.localedata" { permission java.lang.RuntimePermission "accessClassInPackage.sun.util.locale.provider"; permission java.lang.RuntimePermission "accessClassInPackage.sun.util.resources"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-collections-3.1.1-SNAPSHOT.jar" { permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; permission org.apache.river.thread.ThreadPoolPermission "getUserThreadPool"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "listen"; permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1093", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1102", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1115", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1122", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1166", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1179", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1186", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1197", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1199", "accept,resolve"; permission java.lang.RuntimePermission "getClassLoader"; permission java.lang.RuntimePermission "modifyThread"; permission java.lang.RuntimePermission "modifyThreadGroup"; permission java.lang.RuntimePermission "setContextClassLoader"; permission java.lang.RuntimePermission "shutdownHooks"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-discovery-providers-3.1.1-SNAPSHOT.jar" { permission org.apache.river.jeri.internal.EndpointInternalsPermission "get"; permission javax.security.auth.AuthPermission "getSubject"; permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Reggie\"", "read"; }; grant principal javax.security.auth.x500.X500Principal "CN=Tester" { permission net.jini.security.AccessPermission "net.jini.admin.Administrable.getAdmin"; permission net.jini.security.AccessPermission "org.apache.river.admin.DestroyAdmin.destroy"; permission net.jini.security.AccessPermission "org.apache.river.reggie.proxy.Registrar.lookup"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/service-starter-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Reggie" { permission java.util.PropertyPermission "javax.net.ssl.trustStore", "read"; permission java.util.PropertyPermission "javax.net.ssl.trustStorePassword", "read"; permission java.util.PropertyPermission "javax.net.ssl.trustStoreType", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.certificateType", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.cipherSuites", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jceProvider", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jsseProvider", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxClientSessionDuration", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxServerSessionDuration", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.secureRandomAlgorithm", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.sslProtocol", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.trustManagerFactoryAlgorithm", "read"; permission java.util.PropertyPermission "org.apache.river.qa.home", "read"; permission java.util.PropertyPermission "org.apache.river.reggie.enableImplToStubReplacement", "read"; permission org.apache.river.api.io.DeSerializationPermission "MARSHALL"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read"; permission java.io.FilePermission "harness\\trust\\truststore", "read"; permission java.security.SecurityPermission "getPolicy"; permission net.jini.security.GrantPermission "net.jini.security.AuthenticationPermission \"javax.security.auth.x500.X500Principal \\\"CN=Reggie\\\" peer javax.security.auth.x500.X500Principal \\\"CN=Tester\\\"\", \"connect\";"; permission javax.security.auth.AuthPermission "getSubject"; permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "accept"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect"; permission java.net.SocketPermission "224.0.1.84", "connect,accept,resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1097", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1102", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1105", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1115", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1117", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1122", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1166", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1179", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1186", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1197", "accept,resolve"; permission java.net.SocketPermission "[ff05:0:0:0:0:0:0:156]", "connect,accept,resolve"; permission java.net.SocketPermission "localhost:0", "listen,resolve"; permission java.net.SocketPermission "localhost:4160", "listen,resolve"; permission java.lang.RuntimePermission "shutdownHooks"; permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.jeri.internal.runtime"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/reggie-service-3.1.1-SNAPSHOT.jar" { permission java.util.PropertyPermission "java.net.preferIPv6Addresses", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.portAbitraryIfInUse", "read"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-jeri-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Reggie" { permission java.util.PropertyPermission "javax.net.ssl.trustStore", "read"; permission java.util.PropertyPermission "javax.net.ssl.trustStorePassword", "read"; permission java.util.PropertyPermission "javax.net.ssl.trustStoreType", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.certificateType", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.cipherSuites", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jceProvider", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jsseProvider", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxClientSessionDuration", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxServerSessionDuration", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.secureRandomAlgorithm", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.sslProtocol", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.trustManagerFactoryAlgorithm", "read"; permission org.apache.river.api.io.DeSerializationPermission "MARSHALL"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "harness\\trust\\truststore", "read"; permission java.security.SecurityPermission "getPolicy"; permission net.jini.security.GrantPermission "net.jini.security.AuthenticationPermission \"javax.security.auth.x500.X500Principal \\\"CN=Reggie\\\" peer javax.security.auth.x500.X500Principal \\\"CN=Tester\\\"\", \"connect\";"; permission javax.security.auth.AuthPermission "getSubject"; permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "listen"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "accept"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "connect"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1102", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1105", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1115", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1122", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1166", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1179", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1186", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1197", "accept,resolve"; permission java.net.SocketPermission "localhost:0", "listen,resolve"; permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.jeri.internal.runtime"; }; grant codebase "jrt:/java.smartcardio" { permission java.security.SecurityPermission "putProviderProperty.SunPCSC"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; }; grant codebase "jrt:/jdk.crypto.mscapi" { permission java.security.SecurityPermission "putProviderProperty.SunMSCAPI"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.lang.RuntimePermission "loadLibrary.sunmscapi"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/lib/nonactivatablegroup.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission java.util.PropertyPermission "java.security.policy", "read"; permission java.util.PropertyPermission "java.security.policy", "write"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.security.SecurityPermission "createPolicy.JiniPolicy"; permission java.security.SecurityPermission "getPolicy"; permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass"; permission java.security.SecurityPermission "setPolicy"; permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";"; permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie"; permission javax.security.auth.AuthPermission "doAsPrivileged"; permission java.lang.RuntimePermission "accessDeclaredMembers"; permission java.lang.RuntimePermission "createClassLoader"; permission java.lang.RuntimePermission "setContextClassLoader"; permission java.lang.reflect.ReflectPermission "suppressAccessChecks"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib-dl/reggie-dl-3.1.1-SNAPSHOT.jar" { permission org.apache.river.api.io.DeSerializationPermission "ATOMIC"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/service-starter-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission java.util.PropertyPermission "java.security.policy", "read"; permission java.util.PropertyPermission "java.security.policy", "write"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.security.SecurityPermission "createPolicy.JiniPolicy"; permission java.security.SecurityPermission "getPolicy"; permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass"; permission java.security.SecurityPermission "setPolicy"; permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";"; permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie"; permission javax.security.auth.AuthPermission "doAsPrivileged"; permission java.lang.RuntimePermission "accessDeclaredMembers"; permission java.lang.RuntimePermission "createClassLoader"; permission java.lang.RuntimePermission "setContextClassLoader"; permission java.lang.reflect.ReflectPermission "suppressAccessChecks"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Reggie" { permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib-dl/reggie-dl-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Reggie" { permission java.util.PropertyPermission "org.apache.river.reggie.enableImplToStubReplacement", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; }; grant codebase "jrt:/jdk.security.jgss" { permission java.security.SecurityPermission "putProviderProperty.JdkSASL"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; }; grant principal javax.security.auth.x500.X500Principal "CN=Tester" { permission net.jini.security.AccessPermission "org.apache.river.reggie.proxy.Registrar.lookup"; permission net.jini.security.AccessPermission "org.apache.river.reggie.proxy.Registrar.renewLeases"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar" { permission java.util.PropertyPermission "java.rmi.server.codebase", "read"; permission java.util.PropertyPermission "net.jini.loader.codebaseAnnotation", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9082/qa1-lookupservice-dl.jar", "GET:"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve"; permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.reflect"; permission java.lang.RuntimePermission "createClassLoader"; permission java.lang.RuntimePermission "getClassLoader"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-collections-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Reggie" { permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; permission java.net.SocketPermission "[ff05:0:0:0:0:0:0:156]", "connect,accept,resolve"; }; grant principal javax.security.auth.x500.X500Principal "CN=Tester" { permission net.jini.security.AccessPermission "org.apache.river.reggie.proxy.Registrar.lookup"; permission net.jini.security.AccessPermission "org.apache.river.reggie.proxy.Registrar.renewLeases"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-jeri-3.1.1-SNAPSHOT.jar" { permission java.util.PropertyPermission "java.security.policy", "read"; permission java.util.PropertyPermission "java.security.policy", "write"; permission java.util.PropertyPermission "org.apache.river.jeri.connection.mux.client.initialInboundRation", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.connection.mux.server.initialInboundRation", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.connectionTimeout", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.dgc.checkInterval", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.dgc.cleanInterval", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.dgc.leaseValue", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.dgc.minimumDuration", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.handshakeTimeout", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.kerberos.KerberosEndpoint.maxCacheSize", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.kerberos.KerberosEndpoint.maxGssContextRetries", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.kerberos.KerberosEndpoint.minGssContextLifetime", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.server.suppressStackTraces", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.tcp.useNIO", "read"; permission org.apache.river.api.io.DeSerializationPermission "ATOMIC"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\starter\\starter.config", "read"; permission java.io.SerializablePermission "enableSubclassImplementation"; permission java.io.SerializablePermission "enableSubstitution"; permission net.jini.export.ExportPermission "exportRemoteInterface.org.apache.river.qa.harness.NonActivatableGroup"; permission org.apache.river.jeri.internal.EndpointInternalsPermission "get"; permission org.apache.river.jeri.internal.EndpointInternalsPermission "set"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.security.SecurityPermission "createPolicy.JiniPolicy"; permission java.security.SecurityPermission "getPolicy"; permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass"; permission java.security.SecurityPermission "setPolicy"; permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";"; permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie"; permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Test"; permission javax.security.auth.AuthPermission "doAsPrivileged"; permission javax.security.auth.AuthPermission "getSubject"; permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; permission org.apache.river.thread.ThreadPoolPermission "getUserThreadPool"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "listen"; permission net.jini.io.context.ContextPermission "net.jini.io.context.ClientSubject.getClientSubject"; permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Reggie\"", "read"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve"; permission java.net.SocketPermission "[0:0:0:0:0:0:0:0]", "resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1093", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1102", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1115", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1122", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1166", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1179", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1186", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1197", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1199", "accept,resolve"; permission java.net.SocketPermission "localhost:0", "listen,resolve"; permission java.lang.RuntimePermission "accessDeclaredMembers"; permission java.lang.RuntimePermission "createClassLoader"; permission java.lang.RuntimePermission "exitVM.0"; permission java.lang.RuntimePermission "getClassLoader"; permission java.lang.RuntimePermission "modifyThread"; permission java.lang.RuntimePermission "modifyThreadGroup"; permission java.lang.RuntimePermission "setContextClassLoader"; permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.qa.harness"; permission java.lang.reflect.ReflectPermission "suppressAccessChecks"; }; grant codebase "httpmd://DESKTOP-R0ORPA2:9082/qa1-lookupservice-dl.jar;sha=2d4933c826a47df4166159c612c71f164cf71677" { permission java.lang.RuntimePermission "createClassLoader"; }; grant principal javax.security.auth.x500.X500Principal "CN=Tester" { permission net.jini.security.AccessPermission "org.apache.river.reggie.proxy.Registrar.lookup"; permission net.jini.security.AccessPermission "org.apache.river.reggie.proxy.Registrar.renewLeases"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-url-integrity-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib-dl/jgdms-lib-dl-3.1.1-SNAPSHOT.jar" { permission org.apache.river.api.io.DeSerializationPermission "ATOMIC"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-discovery-providers-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Reggie" { permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "accept"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read"; permission java.lang.RuntimePermission "createClassLoader"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-platform-3.1.1-SNAPSHOT.jar" { permission java.util.PropertyPermission "*", "read,write"; permission org.apache.river.api.io.DeSerializationPermission "ATOMIC"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\net.dll", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\nio.dll", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\sunec.dll", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\sunmscapi.dll", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\zip.dll", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\net.properties", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\java.policy", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\policy\\unlimited", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\policy\\unlimited\\default_US_export.policy", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\policy\\unlimited\\default_local.policy", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\security\\blacklisted.certs", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\security\\cacerts", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\tzdb.dat", "read"; permission java.io.FilePermission "C:\\Users\\peter\\.java.policy", "read"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp", "read"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache6039440544431131695.tmp", "delete"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache6039440544431131695.tmp", "read"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache6039440544431131695.tmp", "write"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-discovery-providers-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-platform-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-url-integrity-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\service-starter-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\starter\\starter.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy.new", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy.new", "write"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\jsselogins", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jiniharness.jar", "read"; permission java.io.FilePermission "file:\\C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read"; permission java.net.NetPermission "getCookieHandler"; permission java.net.NetPermission "getNetworkInformation"; permission java.net.NetPermission "getProxySelector"; permission java.net.NetPermission "getResponseCache"; permission java.io.SerializablePermission "enableSubclassImplementation"; permission java.io.SerializablePermission "enableSubstitution"; permission net.jini.export.ExportPermission "exportRemoteInterface.org.apache.river.qa.harness.NonActivatableGroup"; permission org.apache.river.jeri.internal.EndpointInternalsPermission "get"; permission org.apache.river.jeri.internal.EndpointInternalsPermission "set"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9082/qa1-lookupservice-dl.jar", "GET:"; permission java.security.SecurityPermission "createAccessControlContext"; permission java.security.SecurityPermission "createPolicy.JiniPolicy"; permission java.security.SecurityPermission "getDomainCombiner"; permission java.security.SecurityPermission "getPolicy"; permission java.security.SecurityPermission "getProperty.auth.login.defaultCallbackHandler"; permission java.security.SecurityPermission "getProperty.crypto.policy"; permission java.security.SecurityPermission "getProperty.jdk.certpath.disabledAlgorithms"; permission java.security.SecurityPermission "getProperty.jdk.security.caDistrustPolicies"; permission java.security.SecurityPermission "getProperty.jdk.security.provider.preferred"; permission java.security.SecurityPermission "getProperty.jdk.serialFilter"; permission java.security.SecurityPermission "getProperty.jdk.tls.disabledAlgorithms"; permission java.security.SecurityPermission "getProperty.jdk.tls.keyLimits"; permission java.security.SecurityPermission "getProperty.jdk.tls.legacyAlgorithms"; permission java.security.SecurityPermission "getProperty.jdk.tls.server.defaultDHEParameters"; permission java.security.SecurityPermission "getProperty.keystore.type"; permission java.security.SecurityPermission "getProperty.keystore.type.compat"; permission java.security.SecurityPermission "getProperty.login.config.url.1"; permission java.security.SecurityPermission "getProperty.login.configuration.provider"; permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass"; permission java.security.SecurityPermission "getProperty.org.apache.river.start.servicePolicyProvider"; permission java.security.SecurityPermission "getProperty.policy.allowSystemProperty"; permission java.security.SecurityPermission "getProperty.policy.expandProperties"; permission java.security.SecurityPermission "getProperty.policy.url.1"; permission java.security.SecurityPermission "getProperty.policy.url.2"; permission java.security.SecurityPermission "getProperty.policy.url.3"; permission java.security.SecurityPermission "getProperty.securerandom.drbg.config"; permission java.security.SecurityPermission "getProperty.securerandom.source"; permission java.security.SecurityPermission "getProperty.security.provider.1"; permission java.security.SecurityPermission "getProperty.security.provider.10"; permission java.security.SecurityPermission "getProperty.security.provider.11"; permission java.security.SecurityPermission "getProperty.security.provider.12"; permission java.security.SecurityPermission "getProperty.security.provider.13"; permission java.security.SecurityPermission "getProperty.security.provider.14"; permission java.security.SecurityPermission "getProperty.security.provider.2"; permission java.security.SecurityPermission "getProperty.security.provider.3"; permission java.security.SecurityPermission "getProperty.security.provider.4"; permission java.security.SecurityPermission "getProperty.security.provider.5"; permission java.security.SecurityPermission "getProperty.security.provider.6"; permission java.security.SecurityPermission "getProperty.security.provider.7"; permission java.security.SecurityPermission "getProperty.security.provider.8"; permission java.security.SecurityPermission "getProperty.security.provider.9"; permission java.security.SecurityPermission "getProperty.ssl.TrustManagerFactory.algorithm"; permission java.security.SecurityPermission "putProviderProperty.JdkLDAP"; permission java.security.SecurityPermission "putProviderProperty.JdkSASL"; permission java.security.SecurityPermission "putProviderProperty.SUN"; permission java.security.SecurityPermission "putProviderProperty.SunEC"; permission java.security.SecurityPermission "putProviderProperty.SunJCE"; permission java.security.SecurityPermission "putProviderProperty.SunJGSS"; permission java.security.SecurityPermission "putProviderProperty.SunJSSE"; permission java.security.SecurityPermission "putProviderProperty.SunMSCAPI"; permission java.security.SecurityPermission "putProviderProperty.SunPCSC"; permission java.security.SecurityPermission "putProviderProperty.SunRsaSign"; permission java.security.SecurityPermission "putProviderProperty.SunSASL"; permission java.security.SecurityPermission "putProviderProperty.XMLDSig"; permission java.security.SecurityPermission "setPolicy"; permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";"; permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie"; permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Test"; permission javax.security.auth.AuthPermission "doAsPrivileged"; permission javax.security.auth.AuthPermission "getLoginConfiguration"; permission javax.security.auth.AuthPermission "getSubject"; permission javax.security.auth.AuthPermission "getSubjectFromDomainCombiner"; permission javax.security.auth.AuthPermission "modifyPrincipals"; permission javax.security.auth.AuthPermission "modifyPrivateCredentials"; permission javax.security.auth.AuthPermission "modifyPublicCredentials"; permission javax.security.auth.AuthPermission "setLoginConfiguration"; permission java.util.logging.LoggingPermission "control"; permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; permission org.apache.river.thread.ThreadPoolPermission "getUserThreadPool"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "listen"; permission net.jini.io.context.ContextPermission "net.jini.io.context.ClientSubject.getClientSubject"; permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Reggie\"", "read"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve"; permission java.net.SocketPermission "[0:0:0:0:0:0:0:0]", "resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1093", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1102", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1115", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1122", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1166", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1179", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1186", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1197", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1199", "accept,resolve"; permission java.net.SocketPermission "localhost:0", "listen,resolve"; permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.reflect"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.jca"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.krb5"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.pkcs"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.provider"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math.intpoly"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.x509"; permission java.lang.RuntimePermission "accessClassInPackage.sun.util.locale.provider"; permission java.lang.RuntimePermission "accessClassInPackage.sun.util.resources"; permission java.lang.RuntimePermission "accessDeclaredMembers"; permission java.lang.RuntimePermission "accessSystemModules"; permission java.lang.RuntimePermission "createClassLoader"; permission java.lang.RuntimePermission "createSecurityManager"; permission java.lang.RuntimePermission "exitVM.0"; permission java.lang.RuntimePermission "getClassLoader"; permission java.lang.RuntimePermission "getProtectionDomain"; permission java.lang.RuntimePermission "getStackWalkerWithClassReference"; permission java.lang.RuntimePermission "loadLibrary.net"; permission java.lang.RuntimePermission "loadLibrary.nio"; permission java.lang.RuntimePermission "loadLibrary.sunec"; permission java.lang.RuntimePermission "loadLibrary.sunmscapi"; permission java.lang.RuntimePermission "loadLibrary.zip"; permission java.lang.RuntimePermission "localeServiceProvider"; permission java.lang.RuntimePermission "loggerFinder"; permission java.lang.RuntimePermission "modifyThread"; permission java.lang.RuntimePermission "modifyThreadGroup"; permission java.lang.RuntimePermission "reflectionFactoryAccess"; permission java.lang.RuntimePermission "setContextClassLoader"; permission java.lang.RuntimePermission "setIO"; permission java.lang.RuntimePermission "shutdownHooks"; permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.qa.harness"; permission java.lang.reflect.ReflectPermission "suppressAccessChecks"; }; grant codebase "jrt:/jdk.crypto.ec" { permission java.security.SecurityPermission "putProviderProperty.SunEC"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.jca"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.pkcs"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math.intpoly"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.x509"; permission java.lang.RuntimePermission "loadLibrary.sunec"; }; grant codebase "jrt:/jdk.security.auth" { permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jiniharness.jar", "read"; permission javax.security.auth.AuthPermission "modifyPrincipals"; permission javax.security.auth.AuthPermission "modifyPrivateCredentials"; permission javax.security.auth.AuthPermission "modifyPublicCredentials"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.krb5"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.lang.RuntimePermission "getProtectionDomain"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/service-starter-3.1.1-SNAPSHOT.jar" { permission java.util.PropertyPermission "*", "read,write"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\net.dll", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\sunmscapi.dll", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\zip.dll", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\java.policy", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\security\\blacklisted.certs", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\security\\cacerts", "read"; permission java.io.FilePermission "C:\\Users\\peter\\.java.policy", "read"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache6039440544431131695.tmp", "delete"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache6039440544431131695.tmp", "read"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache6039440544431131695.tmp", "write"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-discovery-providers-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-platform-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-url-integrity-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy.new", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy.new", "write"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jiniharness.jar", "read"; permission java.io.FilePermission "file:\\C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read"; permission java.net.NetPermission "getCookieHandler"; permission java.net.NetPermission "getProxySelector"; permission java.net.NetPermission "getResponseCache"; permission java.io.SerializablePermission "enableSubclassImplementation"; permission java.io.SerializablePermission "enableSubstitution"; permission org.apache.river.jeri.internal.EndpointInternalsPermission "get"; permission org.apache.river.jeri.internal.EndpointInternalsPermission "set"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9082/qa1-lookupservice-dl.jar", "GET:"; permission java.security.SecurityPermission "createAccessControlContext"; permission java.security.SecurityPermission "getDomainCombiner"; permission java.security.SecurityPermission "getPolicy"; permission java.security.SecurityPermission "getProperty.auth.login.defaultCallbackHandler"; permission java.security.SecurityPermission "getProperty.jdk.certpath.disabledAlgorithms"; permission java.security.SecurityPermission "getProperty.jdk.security.caDistrustPolicies"; permission java.security.SecurityPermission "getProperty.jdk.tls.disabledAlgorithms"; permission java.security.SecurityPermission "getProperty.jdk.tls.keyLimits"; permission java.security.SecurityPermission "getProperty.jdk.tls.legacyAlgorithms"; permission java.security.SecurityPermission "getProperty.jdk.tls.server.defaultDHEParameters"; permission java.security.SecurityPermission "getProperty.keystore.type"; permission java.security.SecurityPermission "getProperty.keystore.type.compat"; permission java.security.SecurityPermission "getProperty.org.apache.river.start.servicePolicyProvider"; permission java.security.SecurityPermission "getProperty.policy.allowSystemProperty"; permission java.security.SecurityPermission "getProperty.policy.expandProperties"; permission java.security.SecurityPermission "getProperty.policy.url.1"; permission java.security.SecurityPermission "getProperty.policy.url.2"; permission java.security.SecurityPermission "getProperty.policy.url.3"; permission java.security.SecurityPermission "getProperty.securerandom.drbg.config"; permission java.security.SecurityPermission "getProperty.ssl.TrustManagerFactory.algorithm"; permission java.security.SecurityPermission "putProviderProperty.JdkLDAP"; permission java.security.SecurityPermission "putProviderProperty.JdkSASL"; permission java.security.SecurityPermission "putProviderProperty.SunJGSS"; permission java.security.SecurityPermission "putProviderProperty.SunMSCAPI"; permission java.security.SecurityPermission "putProviderProperty.SunPCSC"; permission java.security.SecurityPermission "putProviderProperty.SunSASL"; permission java.security.SecurityPermission "putProviderProperty.XMLDSig"; permission javax.security.auth.AuthPermission "getLoginConfiguration"; permission javax.security.auth.AuthPermission "getSubject"; permission javax.security.auth.AuthPermission "getSubjectFromDomainCombiner"; permission javax.security.auth.AuthPermission "modifyPrincipals"; permission javax.security.auth.AuthPermission "modifyPrivateCredentials"; permission javax.security.auth.AuthPermission "modifyPublicCredentials"; permission java.util.logging.LoggingPermission "control"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "listen"; permission net.jini.io.context.ContextPermission "net.jini.io.context.ClientSubject.getClientSubject"; permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Reggie\"", "read"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1102", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1115", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1122", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1166", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1179", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1186", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1197", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1199", "accept,resolve"; permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.reflect"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.jca"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.pkcs"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math.intpoly"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.x509"; permission java.lang.RuntimePermission "accessDeclaredMembers"; permission java.lang.RuntimePermission "createClassLoader"; permission java.lang.RuntimePermission "createSecurityManager"; permission java.lang.RuntimePermission "exitVM.0"; permission java.lang.RuntimePermission "getClassLoader"; permission java.lang.RuntimePermission "getProtectionDomain"; permission java.lang.RuntimePermission "getStackWalkerWithClassReference"; permission java.lang.RuntimePermission "loadLibrary.net"; permission java.lang.RuntimePermission "loadLibrary.sunmscapi"; permission java.lang.RuntimePermission "loadLibrary.zip"; permission java.lang.RuntimePermission "localeServiceProvider"; permission java.lang.RuntimePermission "modifyThread"; permission java.lang.RuntimePermission "modifyThreadGroup"; permission java.lang.RuntimePermission "setContextClassLoader"; permission java.lang.reflect.ReflectPermission "suppressAccessChecks"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-platform-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Reggie" { permission java.util.PropertyPermission "javax.net.ssl.trustStore", "read"; permission java.util.PropertyPermission "javax.net.ssl.trustStorePassword", "read"; permission java.util.PropertyPermission "javax.net.ssl.trustStoreType", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.certificateType", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.cipherSuites", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jceProvider", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jsseProvider", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxClientSessionDuration", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxServerSessionDuration", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.secureRandomAlgorithm", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.sslProtocol", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.trustManagerFactoryAlgorithm", "read"; permission java.util.PropertyPermission "org.apache.river.qa.home", "read"; permission java.util.PropertyPermission "org.apache.river.reggie.enableImplToStubReplacement", "read"; permission org.apache.river.api.io.DeSerializationPermission "MARSHALL"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read"; permission java.io.FilePermission "harness\\trust\\truststore", "read"; permission java.security.SecurityPermission "getPolicy"; permission net.jini.security.GrantPermission "net.jini.security.AuthenticationPermission \"javax.security.auth.x500.X500Principal \\\"CN=Reggie\\\" peer javax.security.auth.x500.X500Principal \\\"CN=Tester\\\"\", \"connect\";"; permission javax.security.auth.AuthPermission "getSubject"; permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "accept"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect"; permission java.net.SocketPermission "224.0.1.84", "connect,accept,resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1097", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1102", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1105", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1115", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1117", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1122", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1166", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1179", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1186", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1197", "accept,resolve"; permission java.net.SocketPermission "[ff05:0:0:0:0:0:0:156]", "connect,accept,resolve"; permission java.net.SocketPermission "localhost:0", "listen,resolve"; permission java.net.SocketPermission "localhost:4160", "listen,resolve"; permission java.lang.RuntimePermission "shutdownHooks"; permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.jeri.internal.runtime"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/reggie-service-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Reggie" { permission java.util.PropertyPermission "org.apache.river.qa.home", "read"; permission org.apache.river.api.io.DeSerializationPermission "MARSHALL"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read"; permission java.security.SecurityPermission "getPolicy"; permission net.jini.security.GrantPermission "net.jini.security.AuthenticationPermission \"javax.security.auth.x500.X500Principal \\\"CN=Reggie\\\" peer javax.security.auth.x500.X500Principal \\\"CN=Tester\\\"\", \"connect\";"; permission javax.security.auth.AuthPermission "getSubject"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "accept"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect"; permission java.net.SocketPermission "224.0.1.84", "connect,accept,resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1102", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1105", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1115", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1122", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1166", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1179", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1186", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1197", "accept,resolve"; permission java.net.SocketPermission "[ff05:0:0:0:0:0:0:156]", "connect,accept,resolve"; permission java.net.SocketPermission "localhost:0", "listen,resolve"; permission java.net.SocketPermission "localhost:4160", "listen,resolve"; permission java.lang.RuntimePermission "shutdownHooks"; permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.jeri.internal.runtime"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/reggie-service-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read"; permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie"; permission javax.security.auth.AuthPermission "doAsPrivileged"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/lib/nonactivatablegroup.jar" { permission java.util.PropertyPermission "java.security.policy", "read"; permission java.util.PropertyPermission "java.security.policy", "write"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\starter\\starter.config", "read"; permission net.jini.export.ExportPermission "exportRemoteInterface.org.apache.river.qa.harness.NonActivatableGroup"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.security.SecurityPermission "createPolicy.JiniPolicy"; permission java.security.SecurityPermission "getPolicy"; permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass"; permission java.security.SecurityPermission "setPolicy"; permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";"; permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie"; permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Test"; permission javax.security.auth.AuthPermission "doAsPrivileged"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1093", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1199", "accept,resolve"; permission java.net.SocketPermission "localhost:0", "listen,resolve"; permission java.lang.RuntimePermission "accessDeclaredMembers"; permission java.lang.RuntimePermission "createClassLoader"; permission java.lang.RuntimePermission "exitVM.0"; permission java.lang.RuntimePermission "setContextClassLoader"; permission java.lang.RuntimePermission "setIO"; permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.qa.harness"; permission java.lang.reflect.ReflectPermission "suppressAccessChecks"; }; grant principal javax.security.auth.x500.X500Principal "CN=Tester" { permission net.jini.security.AccessPermission "org.apache.river.reggie.proxy.Registrar.lookup"; permission net.jini.security.AccessPermission "org.apache.river.reggie.proxy.Registrar.renewLeases"; }; grant codebase "jrt:/java.security.jgss" { permission java.security.SecurityPermission "putProviderProperty.SunJGSS"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; }; grant principal javax.security.auth.x500.X500Principal "CN=Tester" { permission net.jini.security.AccessPermission "net.jini.admin.Administrable.getAdmin"; permission net.jini.security.AccessPermission "net.jini.export.CodebaseAccessor.getClassAnnotation"; permission net.jini.security.AccessPermission "net.jini.export.CodebaseAccessor.getEncodedCerts"; permission net.jini.security.AccessPermission "org.apache.river.reggie.proxy.Registrar.notiFy"; permission net.jini.security.AccessPermission "org.apache.river.reggie.proxy.Registrar.register"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-url-integrity-3.1.1-SNAPSHOT.jar" { permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9082/qa1-lookupservice-dl.jar", "GET:"; }; grant codebase "jrt:/java.xml.crypto" { permission java.util.PropertyPermission "java.specification.version", "read"; permission java.security.SecurityPermission "putProviderProperty.XMLDSig"; }; From ron.pressler at oracle.com Tue May 4 16:39:14 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Tue, 4 May 2021 16:39:14 +0000 Subject: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: References: <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com> <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com> Message-ID: <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com> On 4 May 2021, at 03:49, Peter Firmstone > wrote: Yes, I'm sure millions of developers don't use the security infrastructure because they only have low value data to protect, or it belongs to someone else and developers that do, can use it incorrectly, it's probably worse to do the latter, but then people synchronize incorrectly too, but we don't remove synchronization because of that. The Security Manager hasn?t been a central part of Java?s server-side security for years. Some of the most critical and best-secured systems in the world are written in Java, and they don?t use the Security Manager, so let?s not equate a particular sandboxing mechanism designed for untrusted code with security. Lets drop the excuses that it's just a theoretical, impractical thing that nobody uses, and say instead that we know that this does something important, it is very powerful, it is a deployed API that is in use, probably the only least privileged protection domain model that really works, but we are no longer supporting it moving forward because it is not well understood by those maintaining it and for this reason it creates a significant maintenance burden. I have to disagree on all counts here. Also, I want to emphasise that if Security Manager were an important security feature for Java these days, then ?some people have been able to make it effective? is the very opposite of ?works? when it comes to security and a mainstream language. You can believe that the maintainers misunderstand this feature ? that is a very bold claim ? but even if it were true it doesn?t change the following empirical facts: 1. SM is not used as a central security Java feature, 2. It is used at all by very few projects, and 3. it is a heavy maintenance burden. Maybe the reasons for these is misunderstanding or general incompetence but that doesn?t change the reality. Please provide some examples, migration options suggestions will be appreciated. I?ve jotted down some thoughts in a blog post: https://inside.java/2021/04/23/security-and-sandboxing-post-securitymanager/ With Serialization, we've been given more than ample notice to do something about migrating away from it, but OpenJDK paints over it and wastes resources adding features to putty and paint over it some more, features that no one uses. Removing Serialization has greater appeal :) This step to remove SecurityManager is so sudden with no replacement options, it's a broken promise to developers, who've invested in Java. Removing SecurityManager has a significantly negative effect on security for me, just so you know. I'm not happy about its proposed removal, but I realise there's not much I can do about it, other than request it be done in the least painful manner. I began learning Java over 20 years ago, I understand the need to keep Java relevant, however move quickly and break things is for younger software platforms. Not everyone has to agree on every priority decision, and the process doesn?t require convincing every last Java developer. But it is not sudden, and there will be alternatives for those aspects of Security Manager that many people use. I don?t think it is fair to harm millions of Java developers by diverting resources from features they want to features very few people want, as long as a reasonable removal process is employed, and I think it is here. Once SecurityManager has been removed, we will lose control over who has access to sensitive data, so it's likely we will be stuck on the last version of Java that provides SecurityManager. The best way I can see for those who need the level of security that SecurityManager provides is to maintain a community LTS edition on OpenJDK, it will be much easier to maintain and backport security patches if Serialization in its current form has been removed, as it will likely have been removed from later versions of Java by that time. I disagree. Lets be clear Java will no longer be able to finely control access to sensitive data with the removal of SecurityManager. I'm sure it will be a great bonus for OpenJDK dev's not to have to think about, but it will impact some developers significantly, who would like to do so with the least suffering possible. I wouldn?t say Java (or anything else, for that matter) is ?able" to do it now, except in the sense that people (scientists) are able (in a billion- dollar particle accelerator) to transmute lead into gold (a few atoms). We?ve had twenty five years to convince the world this could work, the world isn?t buying, and our job isn?t to sell ideas but to serve millions of developers. It?s time to move on. ? Ron From ron.pressler at oracle.com Tue May 4 17:06:57 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Tue, 4 May 2021 17:06:57 +0000 Subject: Preserving API's when removing implementations In-Reply-To: References: Message-ID: <1F114304-451E-4C62-928A-3B8118CC8AF3@oracle.com> Can you explain the use-case? If the code is still maintained, then it can be changed. If it isn?t maintained then you?re opting to run unmaintained software and you might as well ship it with an unmaintained runtime. Sounds like you want to update the runtime but not the software it runs. Why? ? Ron > On 1 May 2021, at 03:43, Peter Firmstone wrote: > > One trend I am noticing as features are removed from Java, is that API that client code utilises is also removed, which prevents other implementations from replacing lost features, where the Java development community needs to continue supporting such features, it breaks software that would otherwise continue to function with an alternative implementation. > > Can we do something about preserving parts of these API's perhaps as deprecated without their removal please? > > Perhaps include the API's in a separate compatibility module, these shouldn't require further development and maintenance, they are just there for backward compatible evolution of client code. > > Thank you. > > -- > Regards, > Peter Firmstone > Zeus Project Services Pty Ltd. > From zgu at redhat.com Tue May 4 18:46:27 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 4 May 2021 14:46:27 -0400 Subject: Can JDK-8027771 be opened? In-Reply-To: <03a7158e-3762-9c2b-39bf-3c91f109988c@oracle.com> References: <39c8e874-3ad5-6c80-1b16-cab9ae0ac8e4@redhat.com> <03a7158e-3762-9c2b-39bf-3c91f109988c@oracle.com> Message-ID: <99a0466a-2554-dd8b-7253-568a1ca1c751@redhat.com> On 5/4/21 9:42 AM, Alan Bateman wrote: > On 04/05/2021 14:31, Zhengyu Gu wrote: >> Hi, >> >> I am trying to backport JDK-8240690 to 8u, but seems has dependence on >> JDK-8027771 (Enhance thread contexts), which is private right now. >> >> Could some one provide information on JDK-8027771, if it can be opened? > > Sorry, it's a security issue so the JBS issue can't be changed. Okay. Thanks, Alan. -Zhengyu > > -Alan > From stuart.marks at oracle.com Tue May 4 19:55:18 2021 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 4 May 2021 12:55:18 -0700 Subject: New candidate JEP: 407: Remove RMI Activation In-Reply-To: References: <20210326180148.E84233DD70B@eggemoggin.niobe.net> Message-ID: <5ee85ce6-0963-d7a4-44d0-a5547ad938c4@oracle.com> JEP 407 is about removing all of these APIs and implementations. The deprecation step was done by JEP 385, which was delivered in Java 15. I guess you're proposing that this JEP should change to do something like removing the implementation while leaving the APIs. This can't be done, for a few reasons. 1. The point of having APIs in the JDK is for applications and external libraries to use them to access abstractions and behaviors that are provided by the JDK. The JDK is not in the business of maintaining APIs in support of abstractions and behaviors it is no longer defining, providing, or specifying. 2. These APIs all have specifications that require certain behaviors. You can't just leave the types around and nothing else. For example, the exception classes all have constructors, and those constructors actually have to construct something. The exceptions are all serializable, they have a well-defined serialization format, and can be serialized and deserialized as well. The concrete classes have methods that can be called. All these require specifications and behaviors that are tested. The goal of this JEP is to remove from the JDK the burden of maintaining all of that. 3. There are a few places in the RMI internals where special-case treatment is provided to activatable objects or stubs. These behaviors are internal only and cannot be maintained after RMI Activation has been removed from the JDK. It's not clear to me that Apache River or Phoenix will continue to work properly on a JDK without Activation, even if all the APIs are left around, as they are likely to be implicitly relying such behaviors. As near as we can tell, there is vanishingly small usage of RMI Activation in the Java community in general. RMI Activation (and RMI itself, for that matter) have not evolved in the past 15 years or so. Furthermore, there has been virtually no demand for new features or evolution of RMI-related technologies for most of that time. It's hard to escape the conclusion that this it's all obsolete. I can appreciate that this puts Apache River and Phoenix into a difficult position. I don't think though that the answer is for the RMI APIs to hang around in future versions of the JDK. I don't know if they'll help, but let me toss out a couple ideas: - Several vendors offer long-term support for earlier releases of the JDK that contain all the Activation APIs and implementations. These will continue to be available for a significant period of time, allowing existing implementations to run unchanged. - As I noted above, the RMI-related technologies in the JDK haven't evolved for the past 15 years. I can't help but think that this has been an impediment to evolving things that are depending upon it. If Apache River/Phoenix continue to be developed, it would be wise to develop a migration plan away from dependencies on RMI-related APIs and implementations exist in the JDK. This will probably allow River and Phoenix to get rid of a bunch of technical debt. s'marks On 4/30/21 7:27 PM, Peter Firmstone wrote: > Can we retain the following API classes please, marked as deprecated, but not for > removal? > > We have our own implementation of Activation, that we register with the RMI Registry. > > Removing these classes will cause many breakages and incompatibilities, we don't > need the implementation of Activation. > > Apache River also uses these and has it's own implementation of Activation called > Phoenix. > > The following interfaces: > > java.rmi.activation.ActivationInstantiator; > java.rmi.activation.ActivationMonitor; > java.rmi.activation.ActivationSystem; > java.rmi.activation.Activator; > > The following Exceptions: > > java.rmi.activation.ActivateFailedException; > java.rmi.activation.ActivationException; > java.rmi.activation.UnknownObjectException; > java.rmi.activation.ActivationException; > java.rmi.activation.UnknownGroupException; > > The following classes: > > java.rmi.activation.ActivationID; > java.rmi.activation.ActivationGroupDesc; > java.rmi.activation.ActivationGroupDesc.CommandEnvironment; > java.rmi.activation.ActivationGroupID; > java.rmi.activation.ActivationDesc; > From javalists at cbfiddle.com Tue May 4 20:33:39 2021 From: javalists at cbfiddle.com (Alan Snyder) Date: Tue, 4 May 2021 13:33:39 -0700 Subject: New candidate JEP: 407: Remove RMI Activation In-Reply-To: <5ee85ce6-0963-d7a4-44d0-a5547ad938c4@oracle.com> References: <20210326180148.E84233DD70B@eggemoggin.niobe.net> <5ee85ce6-0963-d7a4-44d0-a5547ad938c4@oracle.com> Message-ID: <78B90F52-BCB8-48BA-9C3B-E5EB02875DCB@cbfiddle.com> I know nothing about RMI Activation, but am curious about the general issue being raised. I understand the issue to be allowing application code that use these classes to continue to work using the third party implementations that they currently use. What would be the implications of moving this chunk of code into a separate library that could be managed by a third party? I can think of one obstacle, which is the rule that prevents third party code from defining symbols in the ?java.*? package name space. Could an exception be carved out? Technically, does the implementation of RMI Activation require (versus ?currently use?) private services of the JDK? The request implies that it does not. Your answer implies that it does. Alan > On May 4, 2021, at 12:55 PM, Stuart Marks wrote: > > JEP 407 is about removing all of these APIs and implementations. The deprecation step was done by JEP 385, which was delivered in Java 15. I guess you're proposing that this JEP should change to do something like removing the implementation while leaving the APIs. > > This can't be done, for a few reasons. > > 1. The point of having APIs in the JDK is for applications and external libraries to use them to access abstractions and behaviors that are provided by the JDK. The JDK is not in the business of maintaining APIs in support of abstractions and behaviors it is no longer defining, providing, or specifying. > > 2. These APIs all have specifications that require certain behaviors. You can't just leave the types around and nothing else. For example, the exception classes all have constructors, and those constructors actually have to construct something. The exceptions are all serializable, they have a well-defined serialization format, and can be serialized and deserialized as well. The concrete classes have methods that can be called. All these require specifications and behaviors that are tested. The goal of this JEP is to remove from the JDK the burden of maintaining all of that. > > 3. There are a few places in the RMI internals where special-case treatment is provided to activatable objects or stubs. These behaviors are internal only and cannot be maintained after RMI Activation has been removed from the JDK. It's not clear to me that Apache River or Phoenix will continue to work properly on a JDK without Activation, even if all the APIs are left around, as they are likely to be implicitly relying such behaviors. > > As near as we can tell, there is vanishingly small usage of RMI Activation in the Java community in general. RMI Activation (and RMI itself, for that matter) have not evolved in the past 15 years or so. Furthermore, there has been virtually no demand for new features or evolution of RMI-related technologies for most of that time. It's hard to escape the conclusion that this it's all obsolete. > > I can appreciate that this puts Apache River and Phoenix into a difficult position. I don't think though that the answer is for the RMI APIs to hang around in future versions of the JDK. I don't know if they'll help, but let me toss out a couple ideas: > > - Several vendors offer long-term support for earlier releases of the JDK that contain all the Activation APIs and implementations. These will continue to be available for a significant period of time, allowing existing implementations to run unchanged. > > - As I noted above, the RMI-related technologies in the JDK haven't evolved for the past 15 years. I can't help but think that this has been an impediment to evolving things that are depending upon it. If Apache River/Phoenix continue to be developed, it would be wise to develop a migration plan away from dependencies on RMI-related APIs and implementations exist in the JDK. This will probably allow River and Phoenix to get rid of a bunch of technical debt. > > s'marks > > > > > > On 4/30/21 7:27 PM, Peter Firmstone wrote: >> Can we retain the following API classes please, marked as deprecated, but not for removal? >> We have our own implementation of Activation, that we register with the RMI Registry. >> Removing these classes will cause many breakages and incompatibilities, we don't need the implementation of Activation. >> Apache River also uses these and has it's own implementation of Activation called Phoenix. >> The following interfaces: >> java.rmi.activation.ActivationInstantiator; >> java.rmi.activation.ActivationMonitor; >> java.rmi.activation.ActivationSystem; >> java.rmi.activation.Activator; >> The following Exceptions: >> java.rmi.activation.ActivateFailedException; >> java.rmi.activation.ActivationException; >> java.rmi.activation.UnknownObjectException; >> java.rmi.activation.ActivationException; >> java.rmi.activation.UnknownGroupException; >> The following classes: >> java.rmi.activation.ActivationID; >> java.rmi.activation.ActivationGroupDesc; >> java.rmi.activation.ActivationGroupDesc.CommandEnvironment; >> java.rmi.activation.ActivationGroupID; >> java.rmi.activation.ActivationDesc; > From stuart.marks at oracle.com Tue May 4 23:05:11 2021 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 4 May 2021 16:05:11 -0700 Subject: [External] : Re: New candidate JEP: 407: Remove RMI Activation In-Reply-To: <370d853a-ed69-3735-f490-de12760fd3b4@zeus.net.au> References: <20210326180148.E84233DD70B@eggemoggin.niobe.net> <5ee85ce6-0963-d7a4-44d0-a5547ad938c4@oracle.com> <78B90F52-BCB8-48BA-9C3B-E5EB02875DCB@cbfiddle.com> <370d853a-ed69-3735-f490-de12760fd3b4@zeus.net.au> Message-ID: <0d095ea2-eb99-3b1f-3dba-3ed6e2e1ad37@oracle.com> I'm not in charge of the namespace rules, and I can't change them. Note that the entire Java EE ecosystem was transferred into a different namespace under Jakarta EE, and they've kept moving forward, so the namespace issue is not at all insurmountable. My point about the support for RMI Activation inside the RMI internals is that it complicates the story. We can't just "leave the APIs in but remove the implementation" because some of the implementation requires support from the RMI internals won't there. Maybe there's a way for some kind of "external" activation to work around the lack of this support; I don't know. s'marks On 5/4/21 3:28 PM, Peter Firmstone wrote: > Thanks Alan, > > That's basically it in a nutshell, API we depend on is being remove that we have no > way of replacing, our software is of course maintained, current and fully functional. > > We just need permission to do load these classes ourselves and make our own library > using the java.* namespace, change the rule please. > > Regards, > > Peter. > > > On 5/05/2021 6:33 am, Alan Snyder wrote: >> I know nothing about RMI Activation, but am curious about the general issue being >> raised. >> >> I understand the issue to be allowing application code that use these classes to >> continue to work using the third party implementations that they currently use. >> >> What would be the implications of moving this chunk of code into a separate >> library that could be managed by a third party? >> >> I can think of one obstacle, which is the rule that prevents third party code from >> defining symbols in the ?java.*? package name space. Could an exception be carved >> out? >> >> Technically, does the implementation of RMI Activation require (versus ?currently >> use?) private services of the JDK? The request implies that it does not. Your >> answer implies that it does. >> >> ?? Alan >> >> >> >> >> >> >>> On May 4, 2021, at 12:55 PM, Stuart Marks wrote: >>> >>> JEP 407 is about removing all of these APIs and implementations. The deprecation >>> step was done by JEP 385, which was delivered in Java 15. I guess you're >>> proposing that this JEP should change to do something like removing the >>> implementation while leaving the APIs. >>> >>> This can't be done, for a few reasons. >>> >>> 1. The point of having APIs in the JDK is for applications and external libraries >>> to use them to access abstractions and behaviors that are provided by the JDK. >>> The JDK is not in the business of maintaining APIs in support of abstractions and >>> behaviors it is no longer defining, providing, or specifying. >>> >>> 2. These APIs all have specifications that require certain behaviors. You can't >>> just leave the types around and nothing else. For example, the exception classes >>> all have constructors, and those constructors actually have to construct >>> something. The exceptions are all serializable, they have a well-defined >>> serialization format, and can be serialized and deserialized as well. The >>> concrete classes have methods that can be called. All these require >>> specifications and behaviors that are tested. The goal of this JEP is to remove >>> from the JDK the burden of maintaining all of that. >>> >>> 3. There are a few places in the RMI internals where special-case treatment is >>> provided to activatable objects or stubs. These behaviors are internal only and >>> cannot be maintained after RMI Activation has been removed from the JDK. It's not >>> clear to me that Apache River or Phoenix will continue to work properly on a JDK >>> without Activation, even if all the APIs are left around, as they are likely to >>> be implicitly relying such behaviors. >>> >>> As near as we can tell, there is vanishingly small usage of RMI Activation in the >>> Java community in general. RMI Activation (and RMI itself, for that matter) have >>> not evolved in the past 15 years or so. Furthermore, there has been virtually no >>> demand for new features or evolution of RMI-related technologies for most of that >>> time. It's hard to escape the conclusion that this it's all obsolete. >>> >>> I can appreciate that this puts Apache River and Phoenix into a difficult >>> position. I don't think though that the answer is for the RMI APIs to hang around >>> in future versions of the JDK. I don't know if they'll help, but let me toss out >>> a couple ideas: >>> >>> - Several vendors offer long-term support for earlier releases of the JDK that >>> contain all the Activation APIs and implementations. These will continue to be >>> available for a significant period of time, allowing existing implementations to >>> run unchanged. >>> >>> - As I noted above, the RMI-related technologies in the JDK haven't evolved for >>> the past 15 years. I can't help but think that this has been an impediment to >>> evolving things that are depending upon it. If Apache River/Phoenix continue to >>> be developed, it would be wise to develop a migration plan away from dependencies >>> on RMI-related APIs and implementations exist in the JDK. This will probably >>> allow River and Phoenix to get rid of a bunch of technical debt. >>> >>> s'marks >>> >>> >>> >>> >>> >>> On 4/30/21 7:27 PM, Peter Firmstone wrote: >>>> Can we retain the following API classes please, marked as deprecated, but not >>>> for removal? >>>> We have our own implementation of Activation, that we register with the RMI >>>> Registry. >>>> Removing these classes will cause many breakages and incompatibilities, we don't >>>> need the implementation of Activation. >>>> Apache River also uses these and has it's own implementation of Activation >>>> called Phoenix. >>>> The following interfaces: >>>> java.rmi.activation.ActivationInstantiator; >>>> java.rmi.activation.ActivationMonitor; >>>> java.rmi.activation.ActivationSystem; >>>> java.rmi.activation.Activator; >>>> The following Exceptions: >>>> java.rmi.activation.ActivateFailedException; >>>> java.rmi.activation.ActivationException; >>>> java.rmi.activation.UnknownObjectException; >>>> java.rmi.activation.ActivationException; >>>> java.rmi.activation.UnknownGroupException; >>>> The following classes: >>>> java.rmi.activation.ActivationID; >>>> java.rmi.activation.ActivationGroupDesc; >>>> java.rmi.activation.ActivationGroupDesc.CommandEnvironment; >>>> java.rmi.activation.ActivationGroupID; >>>> java.rmi.activation.ActivationDesc; > From peter.firmstone at zeus.net.au Tue May 4 22:28:20 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Wed, 5 May 2021 08:28:20 +1000 Subject: New candidate JEP: 407: Remove RMI Activation In-Reply-To: <78B90F52-BCB8-48BA-9C3B-E5EB02875DCB@cbfiddle.com> References: <20210326180148.E84233DD70B@eggemoggin.niobe.net> <5ee85ce6-0963-d7a4-44d0-a5547ad938c4@oracle.com> <78B90F52-BCB8-48BA-9C3B-E5EB02875DCB@cbfiddle.com> Message-ID: <370d853a-ed69-3735-f490-de12760fd3b4@zeus.net.au> Thanks Alan, That's basically it in a nutshell, API we depend on is being remove that we have no way of replacing, our software is of course maintained, current and fully functional. We just need permission to do load these classes ourselves and make our own library using the java.* namespace, change the rule please. Regards, Peter. On 5/05/2021 6:33 am, Alan Snyder wrote: > I know nothing about RMI Activation, but am curious about the general issue being raised. > > I understand the issue to be allowing application code that use these classes to continue to work using the third party implementations that they currently use. > > What would be the implications of moving this chunk of code into a separate library that could be managed by a third party? > > I can think of one obstacle, which is the rule that prevents third party code from defining symbols in the ?java.*? package name space. Could an exception be carved out? > > Technically, does the implementation of RMI Activation require (versus ?currently use?) private services of the JDK? The request implies that it does not. Your answer implies that it does. > > Alan > > > > > > >> On May 4, 2021, at 12:55 PM, Stuart Marks wrote: >> >> JEP 407 is about removing all of these APIs and implementations. The deprecation step was done by JEP 385, which was delivered in Java 15. I guess you're proposing that this JEP should change to do something like removing the implementation while leaving the APIs. >> >> This can't be done, for a few reasons. >> >> 1. The point of having APIs in the JDK is for applications and external libraries to use them to access abstractions and behaviors that are provided by the JDK. The JDK is not in the business of maintaining APIs in support of abstractions and behaviors it is no longer defining, providing, or specifying. >> >> 2. These APIs all have specifications that require certain behaviors. You can't just leave the types around and nothing else. For example, the exception classes all have constructors, and those constructors actually have to construct something. The exceptions are all serializable, they have a well-defined serialization format, and can be serialized and deserialized as well. The concrete classes have methods that can be called. All these require specifications and behaviors that are tested. The goal of this JEP is to remove from the JDK the burden of maintaining all of that. >> >> 3. There are a few places in the RMI internals where special-case treatment is provided to activatable objects or stubs. These behaviors are internal only and cannot be maintained after RMI Activation has been removed from the JDK. It's not clear to me that Apache River or Phoenix will continue to work properly on a JDK without Activation, even if all the APIs are left around, as they are likely to be implicitly relying such behaviors. >> >> As near as we can tell, there is vanishingly small usage of RMI Activation in the Java community in general. RMI Activation (and RMI itself, for that matter) have not evolved in the past 15 years or so. Furthermore, there has been virtually no demand for new features or evolution of RMI-related technologies for most of that time. It's hard to escape the conclusion that this it's all obsolete. >> >> I can appreciate that this puts Apache River and Phoenix into a difficult position. I don't think though that the answer is for the RMI APIs to hang around in future versions of the JDK. I don't know if they'll help, but let me toss out a couple ideas: >> >> - Several vendors offer long-term support for earlier releases of the JDK that contain all the Activation APIs and implementations. These will continue to be available for a significant period of time, allowing existing implementations to run unchanged. >> >> - As I noted above, the RMI-related technologies in the JDK haven't evolved for the past 15 years. I can't help but think that this has been an impediment to evolving things that are depending upon it. If Apache River/Phoenix continue to be developed, it would be wise to develop a migration plan away from dependencies on RMI-related APIs and implementations exist in the JDK. This will probably allow River and Phoenix to get rid of a bunch of technical debt. >> >> s'marks >> >> >> >> >> >> On 4/30/21 7:27 PM, Peter Firmstone wrote: >>> Can we retain the following API classes please, marked as deprecated, but not for removal? >>> We have our own implementation of Activation, that we register with the RMI Registry. >>> Removing these classes will cause many breakages and incompatibilities, we don't need the implementation of Activation. >>> Apache River also uses these and has it's own implementation of Activation called Phoenix. >>> The following interfaces: >>> java.rmi.activation.ActivationInstantiator; >>> java.rmi.activation.ActivationMonitor; >>> java.rmi.activation.ActivationSystem; >>> java.rmi.activation.Activator; >>> The following Exceptions: >>> java.rmi.activation.ActivateFailedException; >>> java.rmi.activation.ActivationException; >>> java.rmi.activation.UnknownObjectException; >>> java.rmi.activation.ActivationException; >>> java.rmi.activation.UnknownGroupException; >>> The following classes: >>> java.rmi.activation.ActivationID; >>> java.rmi.activation.ActivationGroupDesc; >>> java.rmi.activation.ActivationGroupDesc.CommandEnvironment; >>> java.rmi.activation.ActivationGroupID; >>> java.rmi.activation.ActivationDesc; -- Regards, Peter Firmstone 0498 286 363 Zeus Project Services Pty Ltd. From ron.pressler at oracle.com Wed May 5 00:08:36 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Wed, 5 May 2021 00:08:36 +0000 Subject: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com> References: <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com> <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com> <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com> Message-ID: <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com> Resent with plain-text formatting (I hope) & corrections/rephrasing > On 4 May 2021, at 03:49, Peter Firmstone wrote: > > > Yes, I'm sure millions of developers don't use the security infrastructure because they only have low value data to protect, or it belongs to someone else and developers that do, can use it incorrectly, it's probably worse to do the latter, but then people synchronize incorrectly too, but we don't remove synchronization because of that. > The Security Manager hasn?t been a central part of Java?s server-side security for years. Some of the most critical and best-secured systems in the world are written in Java, and they don?t use the Security Manager, so let?s not equate a particular sandboxing mechanism designed for untrusted code with security. > Lets drop the excuses that it's just a theoretical, impractical thing that nobody uses, and say instead that we know that this does something important, it is very powerful, it is a deployed API that is in use, probably the only least privileged protection domain model that really works, but we are no longer supporting it moving forward because it is not well understood by those maintaining it and for this reason it creates a significant maintenance burden. I have to disagree on all counts here. Also, I want to emphasise that if Security Manager were an important security feature for Java these days, then "some people have been able to make it effective" is the very opposite of ?works? when it comes to security and a mainstream language. A mechanism that confuses most people is still undesirable even if a small minority uses it correctly. You can believe that the maintainers misunderstand this feature ? that is a very bold claim ? but even if it were true it doesn?t change the following empirical facts: 1. SM is not used as a central security Java feature, 2. It is used at all by very few projects, and 3. it is a heavy maintenance burden. Maybe the reasons for these is misunderstanding or general incompetence but that doesn?t change the reality. We need to work in the world we have, not the one we wish we had. > Please provide some examples, migration options suggestions will be appreciated. I?ve jotted down some thoughts in a blog post: https://inside.java/2021/04/23/security-and-sandboxing-post-securitymanager/ > With Serialization, we've been given more than ample notice to do something about migrating away from it, but OpenJDK paints over it and wastes resources adding features to putty and paint over it some more, features that no one uses. Removing Serialization has greater appeal :) > > This step to remove SecurityManager is so sudden with no replacement options, it's a broken promise to developers, who've invested in Java. > > Removing SecurityManager has a significantly negative effect on security for me, just so you know. I'm not happy about its proposed removal, but I realise there's not much I can do about it, other than request it be done in the least painful manner. > > I began learning Java over 20 years ago, I understand the need to keep Java relevant, however move quickly and break things is for younger software platforms. Not everyone has to agree with every priority decision, and the process doesn?t require convincing every last Java developer. But it is not sudden, and there will be alternatives for those aspects of Security Manager that more people use. I don?t think it is fair to harm millions of Java developers by diverting resources from features they want to features very few people want, as long as a reasonable removal process is employed, and I think it is here. > Once SecurityManager has been removed, we will lose control over who has access to sensitive data, so it's likely we will be stuck on the last version of Java that provides SecurityManager. The best way I can see for those who need the level of security that SecurityManager provides is to maintain a community LTS edition on OpenJDK, it will be much easier to maintain and backport security patches if Serialization in its current form has been removed, as it will likely have been removed from later versions of Java by that time. I disagree. I don?t think that the Security Manager offers a higher level of security, just a very elaborate and fine-grained one. > Lets be clear Java will no longer be able to finely control access to sensitive data with the removal of SecurityManager. I'm sure it will be a great bonus for OpenJDK dev's not to have to think about, but it will impact some developers significantly, who would like to do so with the least suffering possible. I wouldn?t say Java (or anything else, for that matter) is ?able" to do it now, except in the sense that people (scientists) are able (in a billion-dollar particle accelerator) to transmute lead into gold (a few atoms). We?ve had twenty five years to convince the world this could work, the world isn?t buying, and our job isn?t to sell ideas but to serve millions of developers by giving them what we believe they need now, not what we wished they wanted. ? Ron From jini at zeus.net.au Wed May 5 05:23:41 2021 From: jini at zeus.net.au (Peter Firmstone) Date: Wed, 5 May 2021 15:23:41 +1000 Subject: New candidate JEP: 407: Remove RMI Activation In-Reply-To: <5ee85ce6-0963-d7a4-44d0-a5547ad938c4@oracle.com> References: <20210326180148.E84233DD70B@eggemoggin.niobe.net> <5ee85ce6-0963-d7a4-44d0-a5547ad938c4@oracle.com> Message-ID: <052eb6a2-064f-3843-5a84-c24b78def7ae@zeus.net.au> On 5/05/2021 5:55 am, Stuart Marks wrote: > As near as we can tell, there is vanishingly small usage of RMI > Activation in the Java community in general. RMI Activation (and RMI > itself, for that matter) have not evolved in the past 15 years or so. > Furthermore, there has been virtually no demand for new features or > evolution of RMI-related technologies for most of that time. It's hard > to escape the conclusion that this it's all obsolete. Yep, RMI isn't much chop by today's standard, I would also say that it's obsolete, old and clunky.?? The only use we have for RMI is for RMI registry and maybe visualvm. I did write TLS Socket factory's for RMI, that utilize the calling thread's subject for authentication so it can be used with JAAS. We use something far better than RMI today, but it's not well known, which allows us to use Kerberos, or TLS1.3 (using session ticket extensions) and preserve the calling context between JVM's, so that multiple JVM's work together as one. https://github.com/pfirmstone/JGDMS/tree/trunk/JGDMS/jgdms-jeri This JEP doesn't affect us as much as JEP 411, we could have removed our activation implementation, which has continued to evolve, but with JEP 411, Java's future migration path is unclear, I don't think this matters anymore. -- Regards, Peter Firmstone From peter.firmstone at zeus.net.au Wed May 5 04:04:41 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Wed, 5 May 2021 14:04:41 +1000 Subject: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com> References: <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com> <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com> <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com> <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com> Message-ID: A VALUABLE LESSON FOR ANY JAVA DEVELOPER: DON'T PUBLISH ANY java.* package namespace API'S THAT MAY BE AT RISK OF LATER REMOVAL IN YOUR API,? java.* API's ONCE REMOVED CANNOT BE REPLACED.? IF YOU ARE CONCERNED SOMETHING MAY BE REMOVED IN FUTURE, SUBCLASS IT IN YOUR API, OR CREATE AN INTERFACE WITH SUBCLASS DECORATOR, SO THAT YOU HAVE SOME CONTROL OVER BACKWARD COMPATIBLE API EVOLUTION. On 5/05/2021 10:08 am, Ron Pressler wrote: > Resent with plain-text formatting (I hope) & corrections/rephrasing > >> On 4 May 2021, at 03:49, Peter Firmstone wrote: >> >> >> Yes, I'm sure millions of developers don't use the security infrastructure because they only have low value data to protect, or it belongs to someone else and developers that do, can use it incorrectly, it's probably worse to do the latter, but then people synchronize incorrectly too, but we don't remove synchronization because of that. >> > The Security Manager hasn?t been a central part of Java?s server-side security for years. Some of the most critical and > best-secured systems in the world are written in Java, and they don?t use the Security Manager, so let?s not equate a > particular sandboxing mechanism designed for untrusted code with security. Got any example best-secured systems? I think we are talking past each other here.?? You keep talking about untrusted code, which sounds like applets to me.? I've read and still have a copy of Li Gong's book, applets were only one of the considerations.? I am talking about authorization and access control.? We use and develop distributed or p2p systems, we don't allow untrusted code to run at all, never ever, that's a dumb idea, so lets stop talking about untrusted code, we don't use that.? ? We do utilize dynamic downloaded code from others and use dynamic class loading, we verify this prior to loading.? We check it's authorized to run before running it.? Again I repeat, we do not run untrusted code, that would allow an attacker to cause denial of service etc, the JVM has no control over badly behaving code. We've been using this since Java 1.4, to control access to networks, file systems and other custom permissions we created, it is used to protect access to sensitive data.? We are still using it.? I understand access control will be removed: https://docs.oracle.com/javase/8/docs/technotes/guides/security/spec/security-spec.doc4.html#20389 We would like to continue restricting access to data after the above is removed.? Will Java be introducing new Role Based Access Control API or something similar? Our software will fail to run on Java after the above is removed.?? I understand we have to remove access control functionality from our software for it to continue functioning? We do need to understand how this will impact security, I think you are trying to convince me or yourself that security will not be impacted?? We can't just assume we can remove access control and our software will be no less secure. What is the new API for access control in Java? Obviously we won't have a call stack with domains, I don't know how we will transfer the user Subject to other threads, for TLS and Kerberos connections.? No doubt something is planned. Is the recommendation simply not to upgrade Java until new access control API is developed? >> Please provide some examples, migration options suggestions will be appreciated. > I?ve jotted down some thoughts in a blog post: https://inside.java/2021/04/23/security-and-sandboxing-post-securitymanager/ Noted, a good start.? I get the feeling this JEP is being rushed through however, with little regard for those of us who were foolish enough to use Java's security API's and will have to suffer the consequences. > > >> With Serialization, we've been given more than ample notice to do something about migrating away from it, but OpenJDK paints over it and wastes resources adding features to putty and paint over it some more, features that no one uses. Removing Serialization has greater appeal :) >> >> This step to remove SecurityManager is so sudden with no replacement options, it's a broken promise to developers, who've invested in Java. >> >> Removing SecurityManager has a significantly negative effect on security for me, just so you know. I'm not happy about its proposed removal, but I realise there's not much I can do about it, other than request it be done in the least painful manner. >> >> I began learning Java over 20 years ago, I understand the need to keep Java relevant, however move quickly and break things is for younger software platforms. > > Not everyone has to agree with every priority decision, and the process doesn?t require convincing every last Java developer. But > it is not sudden, and there will be alternatives for those aspects of Security Manager that more people use. I don?t think it is fair > to harm millions of Java developers by diverting resources from features they want to features very few people want, as long as > a reasonable removal process is employed, and I think it is here. > >> Once SecurityManager has been removed, we will lose control over who has access to sensitive data, so it's likely we will be stuck on the last version of Java that provides SecurityManager. The best way I can see for those who need the level of security that SecurityManager provides is to maintain a community LTS edition on OpenJDK, it will be much easier to maintain and backport security patches if Serialization in its current form has been removed, as it will likely have been removed from later versions of Java by that time. > I disagree. I don?t think that the Security Manager offers a higher level of security, just a very elaborate and fine-grained one. Right now I can limit network access using a permission, or I can prevent file access, database access, or even access to objects themselves.? This is for generally well behaved party's, but we still have to have controls in place. https://www.acsac.org/2009/program/keynotes/gong.pdf Regarding a higher level of security: Q1. What does an attacker who is using serialization as an attack vector want to gain? A1. Property: intellectual, fiat currency, identity theft etc. Q2. Why does an attacker use Serialization as the attack vector? A2. Because it allows an attacker to create any object they like in the JVM, even inject code, the attacker first attempts privilege escalation.? Java makes this easy, because the implementation doesn't place an unprivileged ProtectionDomain onto the call stack.? A simple initial fix would have been to modify the AccessControlContext to include an unprivileged ProtectionDomain on the call stack when a user creates an instance of ObjectInputStream.?? Granted there were still cases of JVM classes that deserialized into a doPrivileged call that needed to be addressed. Q3. SecurityManager and policy providers use whitlists.?? The complaint about SecurityManager is that whitelisting is too complex.? Why entertain a new white listing api for Java Serialization, when complexity is the argument for removing SecurityManager, but it's even worse than SecurityManager, at least with the policy whitelist you have some forward knowledge. A3. Any ideas? > >> Lets be clear Java will no longer be able to finely control access to sensitive data with the removal of SecurityManager. I'm sure it will be a great bonus for OpenJDK dev's not to have to think about, but it will impact some developers significantly, who would like to do so with the least suffering possible. > I wouldn?t say Java (or anything else, for that matter) is ?able" to do it now, except in the sense that people (scientists) are > able (in a billion-dollar particle accelerator) to transmute lead into gold (a few atoms). We?ve had twenty five years to convince the world this could work, the world isn?t buying, and our job isn?t to sell ideas but to serve millions of developers by giving them > what we believe they need now, not what we wished they wanted. > > ? Ron Of course Java is "able" to do access control, it's well documented, I have working examples.? No security defense is 100% effective, if you look at the history of defenses, they continue to evolve.? Just because ObjectInputStream was a huge security hole, it didn't inject an unprivileged ProtectionDomain onto the stack, which would have stopped a number of deserialization gadgets.?? ObjectInputStream runs as privileged code, tut, tut, tut!?? Perl taint mode anyone? Java 6 introduced a security feature where an object will not be constructed if Object's constructor is not called, so that invariants must be satisfied before object creation.? Java Serialziation bypasses this.? Prior to Java 6, objects could be left in a partially constructed state and obtained via a finalizer attack. Besides, serialization whitelists don't protect against denial of service, so why have them at all if you using trusted systems and TLS connections?? Java Serialization should never be used to process untrusted data, because it doesn't and cannot validate invariants until after objects are constructed which is too late. As soon as you implement Serializable, all the effort you put into defensively coding constructors can be bypassed.?? So why code defensively at all if we leave a back door wide open anyway?? All code is trusted now right, soon we can make sure all connections are secure, so we don't need to worry about input validation anymore either right, because the users are trusted now too? Maybe we should just whitelist the classes allowed to run on the JVM and not worry about coding defensively?? Sounds silly, well that's how it sounds to me, just thought I'd put it into perspective. Java Serialization still compromises the security of the JVM because it doesn't prevent object creation if invariants aren't satisfied, the vulnerability is still there, and future attackers will find a way take advantage of it for that reason. It is clear that no further progress will be made in this matter and I will simply have to live with the consequences. Stick a fork in me, because I'm done. -- Regards, Peter Firmstone Zeus Project Services Pty Ltd. From ron.pressler at oracle.com Wed May 5 13:12:16 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Wed, 5 May 2021 13:12:16 +0000 Subject: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: References: <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com> <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com> <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com> <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com> Message-ID: > On 5 May 2021, at 05:04, Peter Firmstone wrote: > > A VALUABLE LESSON FOR ANY JAVA DEVELOPER: DON'T PUBLISH ANY java.* package namespace API'S THAT MAY BE AT RISK OF LATER REMOVAL IN YOUR API, java.* API's ONCE REMOVED CANNOT BE REPLACED. IF YOU ARE CONCERNED SOMETHING MAY BE REMOVED IN FUTURE, SUBCLASS IT IN YOUR API, OR CREATE AN INTERFACE WITH SUBCLASS DECORATOR, SO THAT YOU HAVE SOME CONTROL OVER BACKWARD COMPATIBLE API EVOLUTION. Any API has a non-zero risk of removal after decades of use, and that risk is commensurate with its level of use. I think this is always true, and that everyone already knows that and finds that acceptable, because it?s better than any other alternative. In this particular case, we?re discussing the removal of an API after three decades of use, with under 0.1% of codebases making use of it. > > Got any example best-secured systems? I would hope that Apple's, Amazon?s, Google?s and my bank?s systems, many of which are Java, are secure. > > I think we are talking past each other here. You keep talking about untrusted code, which sounds like applets to me. I've read and still have a copy of Li Gong's book, applets were only one of the considerations. I am talking about authorization and access control. We use and develop distributed or p2p systems, we don't allow untrusted code to run at all, never ever, that's a dumb idea, so lets stop talking about untrusted code, we don't use that. We do utilize dynamic downloaded code from others and use dynamic class loading, we verify this prior to loading. We check it's authorized to run before running it. Again I repeat, we do not run untrusted code, that would allow an attacker to cause denial of service etc, the JVM has no control over badly behaving code. The whole design of the security manager as a ?path-dependent? deep sandbox is built around untrusted code, hence all the stack-walking and doPrivileged. Trusted code means assumed not to be malicious. As such, what you want to protect against is vulnerabilities. Since you don?t know where they are, you place the entire application in a sandbox that?s both more airtight and less complex than the Security Manager. That is, in fact, how most people do it. > > Of course Java is "able" to do access control, it's well documented, I have working examples. No security defense is 100% effective, if you look at the history of defenses, they continue to evolve. Just because ObjectInputStream was a huge security hole, it didn't inject an unprivileged ProtectionDomain onto the stack, which would have stopped a number of deserialization gadgets. ObjectInputStream runs as privileged code, tut, tut, tut! Perl taint mode anyone? We are not talking about authorisation or access control. We?re talking about the Security Manager?s design and implementation which is about code domains and stack-dependence. Serialisation?s security is one thing and the Security Manager is a whole other thing. > > Java 6 introduced a security feature where an object will not be constructed if Object's constructor is not called, so that invariants must be satisfied before object creation. Java Serialziation bypasses this. Prior to Java 6, objects could be left in a partially constructed state and obtained via a finalizer attack. > > Besides, serialization whitelists don't protect against denial of service, so why have them at all if you using trusted systems and TLS connections? Java Serialization should never be used to process untrusted data, because it doesn't and cannot validate invariants until after objects are constructed which is too late. As soon as you implement Serializable, all the effort you put into defensively coding constructors can be bypassed. So why code defensively at all if we leave a back door wide open anyway? All code is trusted now right, soon we can make sure all connections are secure, so we don't need to worry about input validation anymore either right, because the users are trusted now too? Maybe we should just whitelist the classes allowed to run on the JVM and not worry about coding defensively? Sounds silly, well that's how it sounds to me, just thought I'd put it into perspective. > > Java Serialization still compromises the security of the JVM because it doesn't prevent object creation if invariants aren't satisfied, the vulnerability is still there, and future attackers will find a way take advantage of it for that reason. > > It is clear that no further progress will be made in this matter and I will simply have to live with the consequences. Stick a fork in me, because I'm done. You are conflating the Security Manager with security. A lot of security work has been going on in the JDK for the past few years (and will continue for as long Java exists), but not in the code-protection-domain-sandbox known as the Security Manager. ? Ron From peter.firmstone at zeus.net.au Wed May 5 12:23:03 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Wed, 5 May 2021 22:23:03 +1000 Subject: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com> References: <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com> <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com> <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com> <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com> Message-ID: On 5/05/2021 10:08 am, Ron Pressler wrote: > I wouldn?t say Java (or anything else, for that matter) is ?able" to do it now, except in the sense that people (scientists) are > able (in a billion-dollar particle accelerator) to transmute lead into gold (a few atoms). We?ve had twenty five years to convince the world this could work, the world isn?t buying, and our job isn?t to sell ideas but to serve millions of developers by giving them > what we believe they need now, not what we wished they wanted. > > ? Ron We just want our software to work Ron, we invest years of time and effort, we just want it to work.? We don't want to have to test and rework it for every Java release, you are creating too much maintenance for us to keep up with. You'll be serving fewer and fewer developers as more and more are left behind as breakages accumulate.? I was at least keeping up and testing newer releases, even though we still only build on Java 8. Last I checked the stats, 58% were using Java 8, 23% using Java 11 and 6% of developers using 12 or newer. I think you'll have trouble selling it as you say, we won't have time to learn and implement new language features if we're too busy fixing breakages. Hard life creates hard people, hard people create easy life, easy life creates soft people, soft people create hard life. -- Regards, Peter Firmstone My personal opinion only. From sean.mullan at oracle.com Wed May 5 12:55:51 2021 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 5 May 2021 08:55:51 -0400 Subject: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: References: <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com> <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com> <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com> <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com> Message-ID: <119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com> -bcc jdk-dev -cc security-dev On 5/5/21 12:04 AM, Peter Firmstone wrote: > > I think we are talking past each other here.?? You keep talking about > untrusted code, which sounds like applets to me.? I've read and still > have a copy of Li Gong's book, applets were only one of the > considerations.? I am talking about authorization and access control. We > use and develop distributed or p2p systems, we don't allow untrusted > code to run at all, never ever, that's a dumb idea, so lets stop talking > about untrusted code, we don't use that.? ? We do utilize dynamic > downloaded code from others and use dynamic class loading, we verify > this prior to loading.? We check it's authorized to run before running > it.? Again I repeat, we do not run untrusted code, that would allow an > attacker to cause denial of service etc, the JVM has no control over > badly behaving code. But you use self-signed certificates to sign the code that will be run. There is no trust in self-signed certificates unless you have previously used some out-of-band mechanism to trust the public key. I still don't understand why this is not the same as running untrusted code, even if the code is sandboxed. And trusting the TLS server is not an equivalent basis of trust. > We've been using this since Java 1.4, to control access to networks, > file systems and other custom permissions we created, it is used to > protect access to sensitive data.? We are still using it.? I understand > access control will be removed: > > https://docs.oracle.com/javase/8/docs/technotes/guides/security/spec/security-spec.doc4.html#20389 > > > We would like to continue restricting access to data after the above is > removed.? Will Java be introducing new Role Based Access Control API or > something similar? > > Our software will fail to run on Java after the above is removed.?? I > understand we have to remove access control functionality from our > software for it to continue functioning? We do need to understand how > this will impact security, I think you are trying to convince me or > yourself that security will not be impacted?? We can't just assume we > can remove access control and our software will be no less secure. > > What is the new API for access control in Java. > Obviously we won't have a call stack with domains, I don't know how we > will transfer the user Subject to other threads, for TLS and Kerberos > connections.? No doubt something is planned. There is a plan for preserving the capability to transfer Subjects to other threads. It is described in the JEP: https://openjdk.java.net/jeps/411#Alternate-JAAS-APIs --Sean > > Is the recommendation simply not to upgrade Java until new access > control API is developed? > > > >>> Please provide some examples,? migration options suggestions will be >>> appreciated. >> I?ve jotted down some thoughts in a blog post: >> https://inside.java/2021/04/23/security-and-sandboxing-post-securitymanager/ >> > > Noted, a good start.? I get the feeling this JEP is being rushed through > however, with little regard for those of us who were foolish enough to > use Java's security API's and will have to suffer the consequences. > > >> >> >>> With Serialization, we've been given more than ample notice to do >>> something about migrating away from it, but OpenJDK paints over it >>> and wastes resources adding features to putty and paint over it some >>> more, features that no one uses.? Removing Serialization has greater >>> appeal :) >>> >>> This step to remove SecurityManager is so sudden with no replacement >>> options, it's a broken promise to developers, who've invested in Java. >>> >>> Removing SecurityManager has a significantly negative effect on >>> security for me, just so you know.? I'm not happy about its proposed >>> removal, but I realise there's not much I can do about it, other than >>> request it be done in the least painful manner. >>> >>> I began learning Java over 20 years ago, I understand the need to >>> keep Java relevant, however move quickly and break things is for >>> younger software platforms. >> >> Not everyone has to agree with every priority decision, and the >> process doesn?t require convincing every last Java developer. But >> it is not sudden, and there will be alternatives for those aspects of >> Security Manager that more people use. I don?t think it is fair >> to harm millions of Java developers by diverting resources from >> features they want to features very few people want, as long as >> a reasonable removal process is employed, and I think it is here. >> >>> Once SecurityManager has been removed, we will lose control over who >>> has access to sensitive data, so it's likely we will be stuck on the >>> last version of Java that provides SecurityManager.? The best way I >>> can see for those who need the level of security that SecurityManager >>> provides is to maintain a community LTS edition on OpenJDK, it will >>> be much easier to maintain and backport security patches if >>> Serialization in its current form has been removed, as it will likely >>> have been removed from later versions of Java by that time. >> I disagree. I don?t think that the Security Manager offers a higher >> level of security, just a very elaborate and fine-grained one. > > Right now I can limit network access using a permission, or I can > prevent file access, database access, or even access to objects > themselves.? This is for generally well behaved party's, but we still > have to have controls in place. > > https://www.acsac.org/2009/program/keynotes/gong.pdf > > Regarding a higher level of security: > > Q1. What does an attacker who is using serialization as an attack vector > want to gain? > > A1. Property: intellectual, fiat currency, identity theft etc. > > Q2. Why does an attacker use Serialization as the attack vector? > > A2. Because it allows an attacker to create any object they like in the > JVM, even inject code, the attacker first attempts privilege > escalation.? Java makes this easy, because the implementation doesn't > place an unprivileged ProtectionDomain onto the call stack.? A simple > initial fix would have been to modify the AccessControlContext to > include an unprivileged ProtectionDomain on the call stack when a user > creates an instance of ObjectInputStream.?? Granted there were still > cases of JVM classes that deserialized into a doPrivileged call that > needed to be addressed. > > Q3. SecurityManager and policy providers use whitlists.?? The complaint > about SecurityManager is that whitelisting is too complex.? Why > entertain a new white listing api for Java Serialization, when > complexity is the argument for removing SecurityManager, but it's even > worse than SecurityManager, at least with the policy whitelist you have > some forward knowledge. > > A3. Any ideas? > > >> >>> Lets be clear Java will no longer be able to finely control access to >>> sensitive data with the removal of SecurityManager.? I'm sure it will >>> be a great bonus for OpenJDK dev's not to have to think about, but it >>> will impact some developers significantly, who would like to do so >>> with the least suffering possible. >> I wouldn?t say Java (or anything else, for that matter) is ?able" to >> do it now, except in the sense that people (scientists) are >> able (in a billion-dollar particle accelerator) to transmute lead into >> gold (a few atoms). We?ve had twenty five years to convince the world >> this could work, the world isn?t buying, and our job isn?t to sell >> ideas but to serve millions of developers by giving them >> what we believe they need now, not what we wished they wanted. >> >> ? Ron > > Of course Java is "able" to do access control, it's well documented, I > have working examples.? No security defense is 100% effective, if you > look at the history of defenses, they continue to evolve.? Just because > ObjectInputStream was a huge security hole, it didn't inject an > unprivileged ProtectionDomain onto the stack, which would have stopped a > number of deserialization gadgets.?? ObjectInputStream runs as > privileged code, tut, tut, tut!?? Perl taint mode anyone? > > Java 6 introduced a security feature where an object will not be > constructed if Object's constructor is not called, so that invariants > must be satisfied before object creation.? Java Serialziation bypasses > this.? Prior to Java 6, objects could be left in a partially constructed > state and obtained via a finalizer attack. > > Besides, serialization whitelists don't protect against denial of > service, so why have them at all if you using trusted systems and TLS > connections?? Java Serialization should never be used to process > untrusted data, because it doesn't and cannot validate invariants until > after objects are constructed which is too late. As soon as you > implement Serializable, all the effort you put into defensively coding > constructors can be bypassed.?? So why code defensively at all if we > leave a back door wide open anyway?? All code is trusted now right, soon > we can make sure all connections are secure, so we don't need to worry > about input validation anymore either right, because the users are > trusted now too? Maybe we should just whitelist the classes allowed to > run on the JVM and not worry about coding defensively?? Sounds silly, > well that's how it sounds to me, just thought I'd put it into perspective. > > Java Serialization still compromises the security of the JVM because it > doesn't prevent object creation if invariants aren't satisfied, the > vulnerability is still there, and future attackers will find a way take > advantage of it for that reason. > > It is clear that no further progress will be made in this matter and I > will simply have to live with the consequences. Stick a fork in me, > because I'm done. > From peter.tribble at gmail.com Wed May 5 15:02:51 2021 From: peter.tribble at gmail.com (Peter Tribble) Date: Wed, 5 May 2021 16:02:51 +0100 Subject: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: References: <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com> <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com> <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com> <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com> Message-ID: On Wed, May 5, 2021 at 2:13 PM Ron Pressler wrote: > > > > On 5 May 2021, at 05:04, Peter Firmstone > wrote: > > > > A VALUABLE LESSON FOR ANY JAVA DEVELOPER: DON'T PUBLISH ANY java.* > package namespace API'S THAT MAY BE AT RISK OF LATER REMOVAL IN YOUR API, > java.* API's ONCE REMOVED CANNOT BE REPLACED. IF YOU ARE CONCERNED > SOMETHING MAY BE REMOVED IN FUTURE, SUBCLASS IT IN YOUR API, OR CREATE AN > INTERFACE WITH SUBCLASS DECORATOR, SO THAT YOU HAVE SOME CONTROL OVER > BACKWARD COMPATIBLE API EVOLUTION. > > Any API has a non-zero risk of removal after decades of use, and that risk > is commensurate with its level of use. I think > this is always true, and that everyone already knows that and finds that > acceptable, because it?s better than any other > alternative. In this particular case, we?re discussing the removal of an > API after three decades of use, with under 0.1% > of codebases making use of it. > It appears that my employer's codebase is in that 0.1%. I've looked around the JEP, and your article, and it isn't clear to me if there's a viable alternative to a Security Manager for us. We run server-side code, including a commercial library, and simply need to ensure that its behaviour remains within defined limits. For our own code, we know whether a file or network access is legitimate, because we can add the appropriate checks to the code. For this 3rd-party code, we simply install a security manager before calling it and uninstall it afterwards. We can't modify the code; we can't implement a sandbox at the system level (we do anyway, but the point is that we need to impose conditional access controls depending on which java code is running). We have no particular tie to the existing APIs, but the ability to apply sufficiently fine-grained permissions to sections of code is one that has value to us. > > > > Got any example best-secured systems? > > I would hope that Apple's, Amazon?s, Google?s and my bank?s systems, many > of which are Java, are secure. > > > > > I think we are talking past each other here. You keep talking about > untrusted code, which sounds like applets to me. I've read and still have > a copy of Li Gong's book, applets were only one of the considerations. I > am talking about authorization and access control. We use and develop > distributed or p2p systems, we don't allow untrusted code to run at all, > never ever, that's a dumb idea, so lets stop talking about untrusted code, > we don't use that. We do utilize dynamic downloaded code from others and > use dynamic class loading, we verify this prior to loading. We check it's > authorized to run before running it. Again I repeat, we do not run > untrusted code, that would allow an attacker to cause denial of service > etc, the JVM has no control over badly behaving code. > > The whole design of the security manager as a ?path-dependent? deep > sandbox is built around untrusted code, hence > all the stack-walking and doPrivileged. Trusted code means assumed not to > be malicious. As such, what you want to protect > against is vulnerabilities. Since you don?t know where they are, you place > the entire application in a sandbox that?s > both more airtight and less complex than the Security Manager. That is, in > fact, how most people do it. > > > > > Of course Java is "able" to do access control, it's well documented, I > have working examples. No security defense is 100% effective, if you look > at the history of defenses, they continue to evolve. Just because > ObjectInputStream was a huge security hole, it didn't inject an > unprivileged ProtectionDomain onto the stack, which would have stopped a > number of deserialization gadgets. ObjectInputStream runs as privileged > code, tut, tut, tut! Perl taint mode anyone? > > We are not talking about authorisation or access control. We?re talking > about the Security Manager?s design and implementation > which is about code domains and stack-dependence. Serialisation?s security > is one thing and the Security Manager is a whole other > thing. > > > > > Java 6 introduced a security feature where an object will not be > constructed if Object's constructor is not called, so that invariants must > be satisfied before object creation. Java Serialziation bypasses this. > Prior to Java 6, objects could be left in a partially constructed state and > obtained via a finalizer attack. > > > > Besides, serialization whitelists don't protect against denial of > service, so why have them at all if you using trusted systems and TLS > connections? Java Serialization should never be used to process untrusted > data, because it doesn't and cannot validate invariants until after objects > are constructed which is too late. As soon as you implement Serializable, > all the effort you put into defensively coding constructors can be > bypassed. So why code defensively at all if we leave a back door wide > open anyway? All code is trusted now right, soon we can make sure all > connections are secure, so we don't need to worry about input validation > anymore either right, because the users are trusted now too? Maybe we > should just whitelist the classes allowed to run on the JVM and not worry > about coding defensively? Sounds silly, well that's how it sounds to me, > just thought I'd put it into perspective. > > > > Java Serialization still compromises the security of the JVM because it > doesn't prevent object creation if invariants aren't satisfied, the > vulnerability is still there, and future attackers will find a way take > advantage of it for that reason. > > > > It is clear that no further progress will be made in this matter and I > will simply have to live with the consequences. Stick a fork in me, because > I'm done. > > You are conflating the Security Manager with security. A lot of security > work has been going on in the JDK for the past few years > (and will continue for as long Java exists), but not in the > code-protection-domain-sandbox known as the Security Manager. > > ? Ron > > -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ From geertjan.wielenga at googlemail.com Wed May 5 15:13:21 2021 From: geertjan.wielenga at googlemail.com (Geertjan Wielenga) Date: Wed, 5 May 2021 17:13:21 +0200 Subject: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: References: <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com> <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com> <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com> <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com> Message-ID: Not sure where that "under 0.1% of codebases making use of it" phrase is based on -- or even whether that is relevant (i.e., its not only the codebases that will be impacted but the users of those codebases). Anyway, pointed this out before on behalf of NetBeans users here, we're using it too: https://blogs.apache.org/netbeans/entry/jep-411-deprecate-the-security Gj On Wed, May 5, 2021 at 5:04 PM Peter Tribble wrote: > > > On Wed, May 5, 2021 at 2:13 PM Ron Pressler > wrote: > >> >> >> > On 5 May 2021, at 05:04, Peter Firmstone >> wrote: >> > >> > A VALUABLE LESSON FOR ANY JAVA DEVELOPER: DON'T PUBLISH ANY java.* >> package namespace API'S THAT MAY BE AT RISK OF LATER REMOVAL IN YOUR API, >> java.* API's ONCE REMOVED CANNOT BE REPLACED. IF YOU ARE CONCERNED >> SOMETHING MAY BE REMOVED IN FUTURE, SUBCLASS IT IN YOUR API, OR CREATE AN >> INTERFACE WITH SUBCLASS DECORATOR, SO THAT YOU HAVE SOME CONTROL OVER >> BACKWARD COMPATIBLE API EVOLUTION. >> >> Any API has a non-zero risk of removal after decades of use, and that >> risk is commensurate with its level of use. I think >> this is always true, and that everyone already knows that and finds that >> acceptable, because it?s better than any other >> alternative. In this particular case, we?re discussing the removal of an >> API after three decades of use, with under 0.1% >> of codebases making use of it. >> > > It appears that my employer's codebase is in that 0.1%. > > I've looked around the JEP, and your article, and it isn't clear to me if > there's > a viable alternative to a Security Manager for us. We run server-side code, > including a commercial library, and simply need to ensure that its > behaviour > remains within defined limits. For our own code, we know whether a file or > network access is legitimate, because we can add the appropriate checks to > the code. For this 3rd-party code, we simply install a security manager > before > calling it and uninstall it afterwards. We can't modify the code; we can't > implement > a sandbox at the system level (we do anyway, but the point is that we need > to > impose conditional access controls depending on which java code is > running). > > We have no particular tie to the existing APIs, but the ability to apply > sufficiently > fine-grained permissions to sections of code is one that has value to us. > > >> > >> > Got any example best-secured systems? >> >> I would hope that Apple's, Amazon?s, Google?s and my bank?s systems, many >> of which are Java, are secure. >> >> > >> > I think we are talking past each other here. You keep talking about >> untrusted code, which sounds like applets to me. I've read and still have >> a copy of Li Gong's book, applets were only one of the considerations. I >> am talking about authorization and access control. We use and develop >> distributed or p2p systems, we don't allow untrusted code to run at all, >> never ever, that's a dumb idea, so lets stop talking about untrusted code, >> we don't use that. We do utilize dynamic downloaded code from others and >> use dynamic class loading, we verify this prior to loading. We check it's >> authorized to run before running it. Again I repeat, we do not run >> untrusted code, that would allow an attacker to cause denial of service >> etc, the JVM has no control over badly behaving code. >> >> The whole design of the security manager as a ?path-dependent? deep >> sandbox is built around untrusted code, hence >> all the stack-walking and doPrivileged. Trusted code means assumed not to >> be malicious. As such, what you want to protect >> against is vulnerabilities. Since you don?t know where they are, you >> place the entire application in a sandbox that?s >> both more airtight and less complex than the Security Manager. That is, >> in fact, how most people do it. >> >> > >> > Of course Java is "able" to do access control, it's well documented, I >> have working examples. No security defense is 100% effective, if you look >> at the history of defenses, they continue to evolve. Just because >> ObjectInputStream was a huge security hole, it didn't inject an >> unprivileged ProtectionDomain onto the stack, which would have stopped a >> number of deserialization gadgets. ObjectInputStream runs as privileged >> code, tut, tut, tut! Perl taint mode anyone? >> >> We are not talking about authorisation or access control. We?re talking >> about the Security Manager?s design and implementation >> which is about code domains and stack-dependence. Serialisation?s >> security is one thing and the Security Manager is a whole other >> thing. >> >> > >> > Java 6 introduced a security feature where an object will not be >> constructed if Object's constructor is not called, so that invariants must >> be satisfied before object creation. Java Serialziation bypasses this. >> Prior to Java 6, objects could be left in a partially constructed state and >> obtained via a finalizer attack. >> > >> > Besides, serialization whitelists don't protect against denial of >> service, so why have them at all if you using trusted systems and TLS >> connections? Java Serialization should never be used to process untrusted >> data, because it doesn't and cannot validate invariants until after objects >> are constructed which is too late. As soon as you implement Serializable, >> all the effort you put into defensively coding constructors can be >> bypassed. So why code defensively at all if we leave a back door wide >> open anyway? All code is trusted now right, soon we can make sure all >> connections are secure, so we don't need to worry about input validation >> anymore either right, because the users are trusted now too? Maybe we >> should just whitelist the classes allowed to run on the JVM and not worry >> about coding defensively? Sounds silly, well that's how it sounds to me, >> just thought I'd put it into perspective. >> > >> > Java Serialization still compromises the security of the JVM because it >> doesn't prevent object creation if invariants aren't satisfied, the >> vulnerability is still there, and future attackers will find a way take >> advantage of it for that reason. >> > >> > It is clear that no further progress will be made in this matter and I >> will simply have to live with the consequences. Stick a fork in me, because >> I'm done. >> >> You are conflating the Security Manager with security. A lot of security >> work has been going on in the JDK for the past few years >> (and will continue for as long Java exists), but not in the >> code-protection-domain-sandbox known as the Security Manager. >> >> ? Ron >> >> > > -- > -Peter Tribble > http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ > From daniel.fuchs at oracle.com Wed May 5 17:45:16 2021 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 5 May 2021 18:45:16 +0100 Subject: CFV: New JDK Reviewer: Jie Fu In-Reply-To: <5b19841d-14ab-e988-071f-40be6c09e5f6@oracle.com> References: <5b19841d-14ab-e988-071f-40be6c09e5f6@oracle.com> Message-ID: Vote: yes best regards, -- daniel On 03/05/2021 21:40, Ioi Lam wrote: > I hereby nominate Jie Fu (jiefu)[0] to OpenJDK Reviewer. From philip.race at oracle.com Wed May 5 19:24:06 2021 From: philip.race at oracle.com (Philip Race) Date: Wed, 5 May 2021 12:24:06 -0700 Subject: CFV: New JDK Reviewer: Alexander Matveev Message-ID: I hereby nominate Alexander Matveev (matvee[1]) to the role of JDK Project Reviewer. Alexander is currently a JDK committer, and has been a long time member of the Java client team at Oracle notably working in the area of media technologies for the OpenJFX [2] project in which he is a reviewer. He has made substantial contributions [3] to the development of the jpackage[4] tool and has made 37 additional individual contributions [5] to the JDK project. In addition he has already been active in reviewing changes on the appropriate OpenJDK mailing lists. 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 19:30 UTC on 19th May 2021. -Phil [1] https://openjdk.java.net/census#almatvee [2] https://openjdk.java.net/projects/openjfx/ [3] commit 264573c9ce730ed421725b8986db4e3eb5124c47 Author: Andy Herrick Date:?? Thu Dec 5 11:25:33 2019 -0500 ??? 8212780: Packaging Tool Implementation ??? Co-authored-by: Alexey Semenyuk ??? Co-authored-by: Alexander Matveev ??? Co-authored-by: Kevin Rushforth ??? Co-authored-by: Philip Race ??? Reviewed-by: asemenyuk, almatvee, herrick, kcr, prr, erikj, ihse, rriggs, mchung, alanb [4] https://openjdk.java.net/jeps/392 [5] git log --author matvee --format='%h %s' 5b43b39e55a 8263154: [macos] DMG builds have finder errors 55d56495098 8263157: [macos]: java.library.path is being set incorrectly fa43f926ab2 8261845: File permissions of packages built by jpackage bec60432ecb 8259570: (macos) tools/jpackage tests fails with 'hdiutil: couldn't eject "disk2" - Resource busy' eb1c8a15b6a 8257924: Use full path when running external executable from jpackage e6b4c4d7162 8238781: [macos] jpackage tests failed due to "hdiutil: convert failed" in various ways a265c201386 8255619: Localized WinResources.properties have MsiInstallerStrings_en.wxl resource c35e1a284b9 8255947: [macos] Signed macOS jpackage app doesn't filter spurious '-psn' argument 8ca59c9e2eb 8255206: [macos] LicenseTest fails on macOS 11 5a57945f1af 8231591: [TESTBUG] Create additional two phase jpackage tests ac9d1b08ee4 8223187: Remove setLocale() call in jpackage native launcher 89d75304119 8250803: pkgbuild failed with exit code 134 45c4d9d5196 8250646: hdiutil detach fix JDK-8245311 still fails sometimes 084e15bca3d 8248905: [macos] symbolic links not properly resolved bbddae55522 8248248: [macos] EmptyFolderPackageTest.java fails EmptyFolderPackageTest-dmg-setup.scpt exited with 134 code f8a06bc497e 8245311: [macos] misc package tests failed due to "execution error: Finder got an error: AppleEvent timed out." be04c8c7244 8249256: [macos] Add EmptyFolderPackageTest test to problem list 55e7003fd51 8248059: [macos] EmptyFolderPackageTest.java failed "hdiutil: create failed - No child processes" f45d121128d 8248255: [macos] Add failing DMG tests to problem list 9584e01d24c 8225251: Minimise import statements in jpackage sources 976c4693057 8236282: [macos] Find permanent solution to macOS test timeout problem JDK-8235738 6f5e8a2aa3a 8237908: [TESTBUG] [macos] Add support to jtreg helpers to unpack pkg packages 93d89d3bf36 8242786: [macos] tools/jpackage/share/IconTest.java fails: ABORT trying to dequeue work 52be8949e74 8245788: EmptyFolderPackageTest fails on Windows 10 191fe75c0f0 8233215: jpackage doesn't allow enough flexibility for file type binding 5868c76ec6e 8233166: jpackage tool skips empty directories 49002194fb6 8249264: Build validate-headers task fails after JDK-8248261 231a8408b2e 8248261: Add timestamps to jpackage and jpackage tests verbose output ed05d576030 8223955: Eliminate or reduce mixing of old File API and new Path/Files APIs 47cc808b989 8232841: [TESTBUG] [macos] SigningPackageTest fails when untrusted certificates exist on machine f8f98bdbffc 8237607: [macos] Signing app bundle with jpackage fails if runtime is already signed 529587547cd 8235955: [dmg] DMG creation fails without error message if previous DMG was not ejected e104b4cee19 8235954: [dmg] Default DMG background tiff of jpackage not retina ready c751493f0c6 8235738: [macos] tools/jpackage tests timeout on macOS a51b5ae9c4f 8235252: Repair run_tests.sh by locating jtreg locally 57991084944 8234284: [dmg] Change DMG background image to TIFF b29f62ce516 8235767: Compilation failure caused by JDK-8212780: Packaging Tool Implementation [6] https://openjdk.java.net/census [7] https://openjdk.java.net/projects/#reviewer-vote From philip.race at oracle.com Wed May 5 19:24:50 2021 From: philip.race at oracle.com (Philip Race) Date: Wed, 5 May 2021 12:24:50 -0700 Subject: CFV: New JDK Reviewer: Alexander Matveev In-Reply-To: References: Message-ID: <1d536e8e-c3cb-3bcd-512e-ada4fee76dd9@oracle.com> Vote: yes -phil. From alexander.zuev at oracle.com Wed May 5 19:41:41 2021 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Wed, 5 May 2021 12:41:41 -0700 Subject: CFV: New JDK Reviewer: Alexander Matveev In-Reply-To: References: Message-ID: <0aa0e9cc-440d-f8ca-7b38-10d0bab35fd1@oracle.com> Vote: yes /Alex From andy.herrick at oracle.com Wed May 5 20:13:54 2021 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 5 May 2021 16:13:54 -0400 Subject: CFV: New JDK Reviewer: Alexander Matveev In-Reply-To: References: Message-ID: <3f0785c3-4607-1a66-7e70-592e869b482d@oracle.com> vote: yes /Andy On 5/5/2021 3:24 PM, Philip Race wrote: > I hereby nominate Alexander Matveev (matvee[1]) to the role of JDK > Project Reviewer. > > Alexander is currently a JDK committer, and has been a long time > member of the Java client team at Oracle > notably working in the area of media technologies for the OpenJFX [2] > project in which he is a reviewer. > > He has made substantial contributions [3] to the development of the > jpackage[4] tool > and has made 37 additional individual contributions [5] to the JDK > project. > > In addition he has already been active in reviewing changes on the > appropriate OpenJDK mailing lists. > > 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 19:30 UTC on 19th May 2021. > > -Phil > > [1] https://openjdk.java.net/census#almatvee > > [2] https://openjdk.java.net/projects/openjfx/ > > [3] commit 264573c9ce730ed421725b8986db4e3eb5124c47 > Author: Andy Herrick > Date:?? Thu Dec 5 11:25:33 2019 -0500 > > ??? 8212780: Packaging Tool Implementation > > ??? Co-authored-by: Alexey Semenyuk > ??? Co-authored-by: Alexander Matveev > ??? Co-authored-by: Kevin Rushforth > ??? Co-authored-by: Philip Race > ??? Reviewed-by: asemenyuk, almatvee, herrick, kcr, prr, erikj, ihse, > rriggs, mchung, alanb > > [4] https://openjdk.java.net/jeps/392 > > [5] git log --author matvee --format='%h %s' > 5b43b39e55a 8263154: [macos] DMG builds have finder errors > 55d56495098 8263157: [macos]: java.library.path is being set incorrectly > fa43f926ab2 8261845: File permissions of packages built by jpackage > bec60432ecb 8259570: (macos) tools/jpackage tests fails with 'hdiutil: > couldn't eject "disk2" - Resource busy' > eb1c8a15b6a 8257924: Use full path when running external executable > from jpackage > e6b4c4d7162 8238781: [macos] jpackage tests failed due to "hdiutil: > convert failed" in various ways > a265c201386 8255619: Localized WinResources.properties have > MsiInstallerStrings_en.wxl resource > c35e1a284b9 8255947: [macos] Signed macOS jpackage app doesn't filter > spurious '-psn' argument > 8ca59c9e2eb 8255206: [macos] LicenseTest fails on macOS 11 > 5a57945f1af 8231591: [TESTBUG] Create additional two phase jpackage tests > ac9d1b08ee4 8223187: Remove setLocale() call in jpackage native launcher > 89d75304119 8250803: pkgbuild failed with exit code 134 > 45c4d9d5196 8250646: hdiutil detach fix JDK-8245311 still fails sometimes > 084e15bca3d 8248905: [macos] symbolic links not properly resolved > bbddae55522 8248248: [macos] EmptyFolderPackageTest.java fails > EmptyFolderPackageTest-dmg-setup.scpt exited with 134 code > f8a06bc497e 8245311: [macos] misc package tests failed due to > "execution error: Finder got an error: AppleEvent timed out." > be04c8c7244 8249256: [macos] Add EmptyFolderPackageTest test to > problem list > 55e7003fd51 8248059: [macos] EmptyFolderPackageTest.java failed > "hdiutil: create failed - No child processes" > f45d121128d 8248255: [macos] Add failing DMG tests to problem list > 9584e01d24c 8225251: Minimise import statements in jpackage sources > 976c4693057 8236282: [macos] Find permanent solution to macOS test > timeout problem JDK-8235738 > 6f5e8a2aa3a 8237908: [TESTBUG] [macos] Add support to jtreg helpers to > unpack pkg packages > 93d89d3bf36 8242786: [macos] tools/jpackage/share/IconTest.java fails: > ABORT trying to dequeue work > 52be8949e74 8245788: EmptyFolderPackageTest fails on Windows 10 > 191fe75c0f0 8233215: jpackage doesn't allow enough flexibility for > file type binding > 5868c76ec6e 8233166: jpackage tool skips empty directories > 49002194fb6 8249264: Build validate-headers task fails after JDK-8248261 > 231a8408b2e 8248261: Add timestamps to jpackage and jpackage tests > verbose output > ed05d576030 8223955: Eliminate or reduce mixing of old File API and > new Path/Files APIs > 47cc808b989 8232841: [TESTBUG] [macos] SigningPackageTest fails when > untrusted certificates exist on machine > f8f98bdbffc 8237607: [macos] Signing app bundle with jpackage fails if > runtime is already signed > 529587547cd 8235955: [dmg] DMG creation fails without error message if > previous DMG was not ejected > e104b4cee19 8235954: [dmg] Default DMG background tiff of jpackage not > retina ready > c751493f0c6 8235738: [macos] tools/jpackage tests timeout on macOS > a51b5ae9c4f 8235252: Repair run_tests.sh by locating jtreg locally > 57991084944 8234284: [dmg] Change DMG background image to TIFF > b29f62ce516 8235767: Compilation failure caused by JDK-8212780: > Packaging Tool Implementation > > [6] https://openjdk.java.net/census > > [7] https://openjdk.java.net/projects/#reviewer-vote > From daniel.daugherty at oracle.com Wed May 5 20:14:03 2021 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Wed, 5 May 2021 16:14:03 -0400 Subject: CFV: New JDK Reviewer: Alexander Matveev In-Reply-To: References: Message-ID: <5d796da5-f242-45b5-5d34-0cd63a4d23bb@oracle.com> Vote: yes Dan On 5/5/21 3:24 PM, Philip Race wrote: > I hereby nominate Alexander Matveev (matvee[1]) to the role of JDK > Project Reviewer. > > Alexander is currently a JDK committer, and has been a long time > member of the Java client team at Oracle > notably working in the area of media technologies for the OpenJFX [2] > project in which he is a reviewer. > > He has made substantial contributions [3] to the development of the > jpackage[4] tool > and has made 37 additional individual contributions [5] to the JDK > project. > > In addition he has already been active in reviewing changes on the > appropriate OpenJDK mailing lists. > > 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 19:30 UTC on 19th May 2021. > > -Phil > > [1] https://openjdk.java.net/census#almatvee > > [2] https://openjdk.java.net/projects/openjfx/ > > [3] commit 264573c9ce730ed421725b8986db4e3eb5124c47 > Author: Andy Herrick > Date:?? Thu Dec 5 11:25:33 2019 -0500 > > ??? 8212780: Packaging Tool Implementation > > ??? Co-authored-by: Alexey Semenyuk > ??? Co-authored-by: Alexander Matveev > ??? Co-authored-by: Kevin Rushforth > ??? Co-authored-by: Philip Race > ??? Reviewed-by: asemenyuk, almatvee, herrick, kcr, prr, erikj, ihse, > rriggs, mchung, alanb > > [4] https://openjdk.java.net/jeps/392 > > [5] git log --author matvee --format='%h %s' > 5b43b39e55a 8263154: [macos] DMG builds have finder errors > 55d56495098 8263157: [macos]: java.library.path is being set incorrectly > fa43f926ab2 8261845: File permissions of packages built by jpackage > bec60432ecb 8259570: (macos) tools/jpackage tests fails with 'hdiutil: > couldn't eject "disk2" - Resource busy' > eb1c8a15b6a 8257924: Use full path when running external executable > from jpackage > e6b4c4d7162 8238781: [macos] jpackage tests failed due to "hdiutil: > convert failed" in various ways > a265c201386 8255619: Localized WinResources.properties have > MsiInstallerStrings_en.wxl resource > c35e1a284b9 8255947: [macos] Signed macOS jpackage app doesn't filter > spurious '-psn' argument > 8ca59c9e2eb 8255206: [macos] LicenseTest fails on macOS 11 > 5a57945f1af 8231591: [TESTBUG] Create additional two phase jpackage tests > ac9d1b08ee4 8223187: Remove setLocale() call in jpackage native launcher > 89d75304119 8250803: pkgbuild failed with exit code 134 > 45c4d9d5196 8250646: hdiutil detach fix JDK-8245311 still fails sometimes > 084e15bca3d 8248905: [macos] symbolic links not properly resolved > bbddae55522 8248248: [macos] EmptyFolderPackageTest.java fails > EmptyFolderPackageTest-dmg-setup.scpt exited with 134 code > f8a06bc497e 8245311: [macos] misc package tests failed due to > "execution error: Finder got an error: AppleEvent timed out." > be04c8c7244 8249256: [macos] Add EmptyFolderPackageTest test to > problem list > 55e7003fd51 8248059: [macos] EmptyFolderPackageTest.java failed > "hdiutil: create failed - No child processes" > f45d121128d 8248255: [macos] Add failing DMG tests to problem list > 9584e01d24c 8225251: Minimise import statements in jpackage sources > 976c4693057 8236282: [macos] Find permanent solution to macOS test > timeout problem JDK-8235738 > 6f5e8a2aa3a 8237908: [TESTBUG] [macos] Add support to jtreg helpers to > unpack pkg packages > 93d89d3bf36 8242786: [macos] tools/jpackage/share/IconTest.java fails: > ABORT trying to dequeue work > 52be8949e74 8245788: EmptyFolderPackageTest fails on Windows 10 > 191fe75c0f0 8233215: jpackage doesn't allow enough flexibility for > file type binding > 5868c76ec6e 8233166: jpackage tool skips empty directories > 49002194fb6 8249264: Build validate-headers task fails after JDK-8248261 > 231a8408b2e 8248261: Add timestamps to jpackage and jpackage tests > verbose output > ed05d576030 8223955: Eliminate or reduce mixing of old File API and > new Path/Files APIs > 47cc808b989 8232841: [TESTBUG] [macos] SigningPackageTest fails when > untrusted certificates exist on machine > f8f98bdbffc 8237607: [macos] Signing app bundle with jpackage fails if > runtime is already signed > 529587547cd 8235955: [dmg] DMG creation fails without error message if > previous DMG was not ejected > e104b4cee19 8235954: [dmg] Default DMG background tiff of jpackage not > retina ready > c751493f0c6 8235738: [macos] tools/jpackage tests timeout on macOS > a51b5ae9c4f 8235252: Repair run_tests.sh by locating jtreg locally > 57991084944 8234284: [dmg] Change DMG background image to TIFF > b29f62ce516 8235767: Compilation failure caused by JDK-8212780: > Packaging Tool Implementation > > [6] https://openjdk.java.net/census > > [7] https://openjdk.java.net/projects/#reviewer-vote > From brian.burkhalter at oracle.com Wed May 5 20:34:56 2021 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 5 May 2021 20:34:56 +0000 Subject: CFV: New JDK Reviewer: Alexander Matveev In-Reply-To: References: Message-ID: Vote: yes On May 5, 2021, at 12:24 PM, Philip Race > wrote: I hereby nominate Alexander Matveev (matvee[1]) to the role of JDK Project Reviewer. From alexey.semenyuk at oracle.com Wed May 5 21:10:07 2021 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Wed, 5 May 2021 17:10:07 -0400 Subject: CFV: New JDK Reviewer: Alexander Matveev In-Reply-To: References: Message-ID: <06705746-5d5f-a8df-9ddf-46b6414f19b3@oracle.com> Vote: yes - Alexey On 5/5/2021 3:24 PM, Philip Race wrote: > I hereby nominate Alexander Matveev (matvee[1]) to the role of JDK > Project Reviewer. > > Alexander is currently a JDK committer, and has been a long time > member of the Java client team at Oracle > notably working in the area of media technologies for the OpenJFX [2] > project in which he is a reviewer. > > He has made substantial contributions [3] to the development of the > jpackage[4] tool > and has made 37 additional individual contributions [5] to the JDK > project. > > In addition he has already been active in reviewing changes on the > appropriate OpenJDK mailing lists. > > 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 19:30 UTC on 19th May 2021. > > -Phil > > [1] https://openjdk.java.net/census#almatvee > > [2] https://openjdk.java.net/projects/openjfx/ > > [3] commit 264573c9ce730ed421725b8986db4e3eb5124c47 > Author: Andy Herrick > Date:?? Thu Dec 5 11:25:33 2019 -0500 > > ??? 8212780: Packaging Tool Implementation > > ??? Co-authored-by: Alexey Semenyuk > ??? Co-authored-by: Alexander Matveev > ??? Co-authored-by: Kevin Rushforth > ??? Co-authored-by: Philip Race > ??? Reviewed-by: asemenyuk, almatvee, herrick, kcr, prr, erikj, ihse, > rriggs, mchung, alanb > > [4] https://openjdk.java.net/jeps/392 > > [5] git log --author matvee --format='%h %s' > 5b43b39e55a 8263154: [macos] DMG builds have finder errors > 55d56495098 8263157: [macos]: java.library.path is being set incorrectly > fa43f926ab2 8261845: File permissions of packages built by jpackage > bec60432ecb 8259570: (macos) tools/jpackage tests fails with 'hdiutil: > couldn't eject "disk2" - Resource busy' > eb1c8a15b6a 8257924: Use full path when running external executable > from jpackage > e6b4c4d7162 8238781: [macos] jpackage tests failed due to "hdiutil: > convert failed" in various ways > a265c201386 8255619: Localized WinResources.properties have > MsiInstallerStrings_en.wxl resource > c35e1a284b9 8255947: [macos] Signed macOS jpackage app doesn't filter > spurious '-psn' argument > 8ca59c9e2eb 8255206: [macos] LicenseTest fails on macOS 11 > 5a57945f1af 8231591: [TESTBUG] Create additional two phase jpackage tests > ac9d1b08ee4 8223187: Remove setLocale() call in jpackage native launcher > 89d75304119 8250803: pkgbuild failed with exit code 134 > 45c4d9d5196 8250646: hdiutil detach fix JDK-8245311 still fails sometimes > 084e15bca3d 8248905: [macos] symbolic links not properly resolved > bbddae55522 8248248: [macos] EmptyFolderPackageTest.java fails > EmptyFolderPackageTest-dmg-setup.scpt exited with 134 code > f8a06bc497e 8245311: [macos] misc package tests failed due to > "execution error: Finder got an error: AppleEvent timed out." > be04c8c7244 8249256: [macos] Add EmptyFolderPackageTest test to > problem list > 55e7003fd51 8248059: [macos] EmptyFolderPackageTest.java failed > "hdiutil: create failed - No child processes" > f45d121128d 8248255: [macos] Add failing DMG tests to problem list > 9584e01d24c 8225251: Minimise import statements in jpackage sources > 976c4693057 8236282: [macos] Find permanent solution to macOS test > timeout problem JDK-8235738 > 6f5e8a2aa3a 8237908: [TESTBUG] [macos] Add support to jtreg helpers to > unpack pkg packages > 93d89d3bf36 8242786: [macos] tools/jpackage/share/IconTest.java fails: > ABORT trying to dequeue work > 52be8949e74 8245788: EmptyFolderPackageTest fails on Windows 10 > 191fe75c0f0 8233215: jpackage doesn't allow enough flexibility for > file type binding > 5868c76ec6e 8233166: jpackage tool skips empty directories > 49002194fb6 8249264: Build validate-headers task fails after JDK-8248261 > 231a8408b2e 8248261: Add timestamps to jpackage and jpackage tests > verbose output > ed05d576030 8223955: Eliminate or reduce mixing of old File API and > new Path/Files APIs > 47cc808b989 8232841: [TESTBUG] [macos] SigningPackageTest fails when > untrusted certificates exist on machine > f8f98bdbffc 8237607: [macos] Signing app bundle with jpackage fails if > runtime is already signed > 529587547cd 8235955: [dmg] DMG creation fails without error message if > previous DMG was not ejected > e104b4cee19 8235954: [dmg] Default DMG background tiff of jpackage not > retina ready > c751493f0c6 8235738: [macos] tools/jpackage tests timeout on macOS > a51b5ae9c4f 8235252: Repair run_tests.sh by locating jtreg locally > 57991084944 8234284: [dmg] Change DMG background image to TIFF > b29f62ce516 8235767: Compilation failure caused by JDK-8212780: > Packaging Tool Implementation > > [6] https://openjdk.java.net/census > > [7] https://openjdk.java.net/projects/#reviewer-vote > From brent.christian at oracle.com Thu May 6 00:00:03 2021 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 5 May 2021 17:00:03 -0700 Subject: CFV: New JDK Reviewer: Alexander Matveev In-Reply-To: References: Message-ID: <1deb6860-ec3a-eff9-068f-bc24f7c93ab3@oracle.com> Vote: Yes On 5/5/21 12:24 PM, Philip Race wrote: > I hereby nominate Alexander Matveev (matvee[1]) to the role of JDK > Project Reviewer. > From alexander.zvegintsev at oracle.com Thu May 6 00:03:10 2021 From: alexander.zvegintsev at oracle.com (alexander.zvegintsev at oracle.com) Date: Thu, 6 May 2021 02:03:10 +0200 Subject: CFV: New JDK Reviewer: Alexander Matveev In-Reply-To: References: Message-ID: Vote: yes Thanks, Alexander. On 05/05/2021 21:24, Philip Race wrote: > I hereby nominate Alexander Matveev (matvee[1]) to the role of JDK > Project Reviewer. > > Alexander is currently a JDK committer, and has been a long time > member of the Java client team at Oracle > notably working in the area of media technologies for the OpenJFX [2] > project in which he is a reviewer. > > He has made substantial contributions [3] to the development of the > jpackage[4] tool > and has made 37 additional individual contributions [5] to the JDK > project. > > In addition he has already been active in reviewing changes on the > appropriate OpenJDK mailing lists. > > 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 19:30 UTC on 19th May 2021. > > -Phil > > [1] https://openjdk.java.net/census#almatvee > > [2] https://openjdk.java.net/projects/openjfx/ > > [3] commit 264573c9ce730ed421725b8986db4e3eb5124c47 > Author: Andy Herrick > Date:?? Thu Dec 5 11:25:33 2019 -0500 > > ??? 8212780: Packaging Tool Implementation > > ??? Co-authored-by: Alexey Semenyuk > ??? Co-authored-by: Alexander Matveev > ??? Co-authored-by: Kevin Rushforth > ??? Co-authored-by: Philip Race > ??? Reviewed-by: asemenyuk, almatvee, herrick, kcr, prr, erikj, ihse, > rriggs, mchung, alanb > > [4] https://openjdk.java.net/jeps/392 > > [5] git log --author matvee --format='%h %s' > 5b43b39e55a 8263154: [macos] DMG builds have finder errors > 55d56495098 8263157: [macos]: java.library.path is being set incorrectly > fa43f926ab2 8261845: File permissions of packages built by jpackage > bec60432ecb 8259570: (macos) tools/jpackage tests fails with 'hdiutil: > couldn't eject "disk2" - Resource busy' > eb1c8a15b6a 8257924: Use full path when running external executable > from jpackage > e6b4c4d7162 8238781: [macos] jpackage tests failed due to "hdiutil: > convert failed" in various ways > a265c201386 8255619: Localized WinResources.properties have > MsiInstallerStrings_en.wxl resource > c35e1a284b9 8255947: [macos] Signed macOS jpackage app doesn't filter > spurious '-psn' argument > 8ca59c9e2eb 8255206: [macos] LicenseTest fails on macOS 11 > 5a57945f1af 8231591: [TESTBUG] Create additional two phase jpackage tests > ac9d1b08ee4 8223187: Remove setLocale() call in jpackage native launcher > 89d75304119 8250803: pkgbuild failed with exit code 134 > 45c4d9d5196 8250646: hdiutil detach fix JDK-8245311 still fails sometimes > 084e15bca3d 8248905: [macos] symbolic links not properly resolved > bbddae55522 8248248: [macos] EmptyFolderPackageTest.java fails > EmptyFolderPackageTest-dmg-setup.scpt exited with 134 code > f8a06bc497e 8245311: [macos] misc package tests failed due to > "execution error: Finder got an error: AppleEvent timed out." > be04c8c7244 8249256: [macos] Add EmptyFolderPackageTest test to > problem list > 55e7003fd51 8248059: [macos] EmptyFolderPackageTest.java failed > "hdiutil: create failed - No child processes" > f45d121128d 8248255: [macos] Add failing DMG tests to problem list > 9584e01d24c 8225251: Minimise import statements in jpackage sources > 976c4693057 8236282: [macos] Find permanent solution to macOS test > timeout problem JDK-8235738 > 6f5e8a2aa3a 8237908: [TESTBUG] [macos] Add support to jtreg helpers to > unpack pkg packages > 93d89d3bf36 8242786: [macos] tools/jpackage/share/IconTest.java fails: > ABORT trying to dequeue work > 52be8949e74 8245788: EmptyFolderPackageTest fails on Windows 10 > 191fe75c0f0 8233215: jpackage doesn't allow enough flexibility for > file type binding > 5868c76ec6e 8233166: jpackage tool skips empty directories > 49002194fb6 8249264: Build validate-headers task fails after JDK-8248261 > 231a8408b2e 8248261: Add timestamps to jpackage and jpackage tests > verbose output > ed05d576030 8223955: Eliminate or reduce mixing of old File API and > new Path/Files APIs > 47cc808b989 8232841: [TESTBUG] [macos] SigningPackageTest fails when > untrusted certificates exist on machine > f8f98bdbffc 8237607: [macos] Signing app bundle with jpackage fails if > runtime is already signed > 529587547cd 8235955: [dmg] DMG creation fails without error message if > previous DMG was not ejected > e104b4cee19 8235954: [dmg] Default DMG background tiff of jpackage not > retina ready > c751493f0c6 8235738: [macos] tools/jpackage tests timeout on macOS > a51b5ae9c4f 8235252: Repair run_tests.sh by locating jtreg locally > 57991084944 8234284: [dmg] Change DMG background image to TIFF > b29f62ce516 8235767: Compilation failure caused by JDK-8212780: > Packaging Tool Implementation > > [6] https://openjdk.java.net/census > > [7] https://openjdk.java.net/projects/#reviewer-vote > From jayathirth.d.v at oracle.com Thu May 6 05:17:38 2021 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 6 May 2021 05:17:38 +0000 Subject: CFV: New JDK Reviewer: Alexander Matveev In-Reply-To: References: Message-ID: Vote : Yes. Thanks, Jay > On 06-May-2021, at 12:54 AM, Philip Race wrote: > > I hereby nominate Alexander Matveev (matvee[1]) to the role of JDK Project Reviewer. > > Alexander is currently a JDK committer, and has been a long time member of the Java client team at Oracle > notably working in the area of media technologies for the OpenJFX [2] project in which he is a reviewer. > > He has made substantial contributions [3] to the development of the jpackage[4] tool > and has made 37 additional individual contributions [5] to the JDK project. > > In addition he has already been active in reviewing changes on the appropriate OpenJDK mailing lists. > > 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 19:30 UTC on 19th May 2021. > > -Phil > > [1] https://openjdk.java.net/census#almatvee > > [2] https://openjdk.java.net/projects/openjfx/ > > [3] commit 264573c9ce730ed421725b8986db4e3eb5124c47 > Author: Andy Herrick > Date: Thu Dec 5 11:25:33 2019 -0500 > > 8212780: Packaging Tool Implementation > > Co-authored-by: Alexey Semenyuk > Co-authored-by: Alexander Matveev > Co-authored-by: Kevin Rushforth > Co-authored-by: Philip Race > Reviewed-by: asemenyuk, almatvee, herrick, kcr, prr, erikj, ihse, rriggs, mchung, alanb > > [4] https://openjdk.java.net/jeps/392 > > [5] git log --author matvee --format='%h %s' > 5b43b39e55a 8263154: [macos] DMG builds have finder errors > 55d56495098 8263157: [macos]: java.library.path is being set incorrectly > fa43f926ab2 8261845: File permissions of packages built by jpackage > bec60432ecb 8259570: (macos) tools/jpackage tests fails with 'hdiutil: couldn't eject "disk2" - Resource busy' > eb1c8a15b6a 8257924: Use full path when running external executable from jpackage > e6b4c4d7162 8238781: [macos] jpackage tests failed due to "hdiutil: convert failed" in various ways > a265c201386 8255619: Localized WinResources.properties have MsiInstallerStrings_en.wxl resource > c35e1a284b9 8255947: [macos] Signed macOS jpackage app doesn't filter spurious '-psn' argument > 8ca59c9e2eb 8255206: [macos] LicenseTest fails on macOS 11 > 5a57945f1af 8231591: [TESTBUG] Create additional two phase jpackage tests > ac9d1b08ee4 8223187: Remove setLocale() call in jpackage native launcher > 89d75304119 8250803: pkgbuild failed with exit code 134 > 45c4d9d5196 8250646: hdiutil detach fix JDK-8245311 still fails sometimes > 084e15bca3d 8248905: [macos] symbolic links not properly resolved > bbddae55522 8248248: [macos] EmptyFolderPackageTest.java fails EmptyFolderPackageTest-dmg-setup.scpt exited with 134 code > f8a06bc497e 8245311: [macos] misc package tests failed due to "execution error: Finder got an error: AppleEvent timed out." > be04c8c7244 8249256: [macos] Add EmptyFolderPackageTest test to problem list > 55e7003fd51 8248059: [macos] EmptyFolderPackageTest.java failed "hdiutil: create failed - No child processes" > f45d121128d 8248255: [macos] Add failing DMG tests to problem list > 9584e01d24c 8225251: Minimise import statements in jpackage sources > 976c4693057 8236282: [macos] Find permanent solution to macOS test timeout problem JDK-8235738 > 6f5e8a2aa3a 8237908: [TESTBUG] [macos] Add support to jtreg helpers to unpack pkg packages > 93d89d3bf36 8242786: [macos] tools/jpackage/share/IconTest.java fails: ABORT trying to dequeue work > 52be8949e74 8245788: EmptyFolderPackageTest fails on Windows 10 > 191fe75c0f0 8233215: jpackage doesn't allow enough flexibility for file type binding > 5868c76ec6e 8233166: jpackage tool skips empty directories > 49002194fb6 8249264: Build validate-headers task fails after JDK-8248261 > 231a8408b2e 8248261: Add timestamps to jpackage and jpackage tests verbose output > ed05d576030 8223955: Eliminate or reduce mixing of old File API and new Path/Files APIs > 47cc808b989 8232841: [TESTBUG] [macos] SigningPackageTest fails when untrusted certificates exist on machine > f8f98bdbffc 8237607: [macos] Signing app bundle with jpackage fails if runtime is already signed > 529587547cd 8235955: [dmg] DMG creation fails without error message if previous DMG was not ejected > e104b4cee19 8235954: [dmg] Default DMG background tiff of jpackage not retina ready > c751493f0c6 8235738: [macos] tools/jpackage tests timeout on macOS > a51b5ae9c4f 8235252: Repair run_tests.sh by locating jtreg locally > 57991084944 8234284: [dmg] Change DMG background image to TIFF > b29f62ce516 8235767: Compilation failure caused by JDK-8212780: Packaging Tool Implementation > > [6] https://openjdk.java.net/census > > [7] https://openjdk.java.net/projects/#reviewer-vote > From peter.firmstone at zeus.net.au Thu May 6 00:00:52 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Thu, 6 May 2021 10:00:52 +1000 Subject: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: References: <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com> <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com> <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com> <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com> Message-ID: <7546bda1-d05b-6a3d-62a8-cc0af49294d9@zeus.net.au> Thanks Peter, This is a similar use case, we are using trusted code also, but we are preventing unauthorized access to sensitive data.? I think they will discover there are many use cases like this and there will be many existing deployed systems that are not on github or wherever they've obtained their figures from that will break as a result.?? It's an API that is used in such a way that if your application makes use of it,? shotgun surgery must be prescribed to remove it,? and there will be code that people don't have source code for that will just break and that's it. It's about access control, not applets or untrusted code. @Ron, please stop deliberately conflating access control with untrusted code and security! @Ron Please stop pretending it doesn't work or that it requires a physics degree and a billion dollar budget, it's just code, maybe you should investigate and try to understand it how it works before disregarding it. Just in case you anyone missed it I've attached it again, it is easy to comply with principles of least privilege using a tool to generate policy files, then edited, which also happens to provide you with an audit of every access check and you do this prior to populating it with sensitive data. It's all about access control and it's an established api, which you rightly point out has been with the platform a long time, so there will be an accumulation of uses people aren't aware of. -- Regards, Peter Firmstone On 6/05/2021 1:02 am, Peter Tribble wrote: > > > On Wed, May 5, 2021 at 2:13 PM Ron Pressler > wrote: > > > > > On 5 May 2021, at 05:04, Peter Firmstone > > > wrote: > > > > A VALUABLE LESSON FOR ANY JAVA DEVELOPER: DON'T PUBLISH ANY > java.* package namespace API'S THAT MAY BE AT RISK OF LATER > REMOVAL IN YOUR API,? java.* API's ONCE REMOVED CANNOT BE > REPLACED.? IF YOU ARE CONCERNED SOMETHING MAY BE REMOVED IN > FUTURE, SUBCLASS IT IN YOUR API, OR CREATE AN INTERFACE WITH > SUBCLASS DECORATOR, SO THAT YOU HAVE SOME CONTROL OVER BACKWARD > COMPATIBLE API EVOLUTION. > > Any API has a non-zero risk of removal after decades of use, and > that risk is commensurate with its level of use. I think > this is always true, and that everyone already knows that and > finds that acceptable, because it?s better than any other > alternative. In this particular case, we?re discussing the removal > of an API after three decades of use, with under 0.1% > of codebases making use of it. > > > It appears that my employer's codebase is in that 0.1%. > > I've looked around the JEP, and your article, and it isn't clear to me > if there's > a viable alternative to a Security Manager for us. We run server-side > code, > including a commercial library, and simply need to ensure that its > behaviour > remains within defined limits. For our own code, we know whether a file or > network access is legitimate, because we can add the appropriate checks to > the code. For this 3rd-party code, we simply install a security > manager before > calling it and uninstall it afterwards. We can't modify the code; we > can't implement > a sandbox at the system level (we do anyway, but the point is that we > need to > impose conditional access controls depending on which java code is > running). > > We have no particular tie to the existing APIs, but the ability to > apply sufficiently > fine-grained permissions to sections of code is one that has value to us. > > > > > Got any example best-secured systems? > > I would hope that Apple's, Amazon?s, Google?s and my bank?s > systems, many of which are Java, are secure. > > > > > I think we are talking past each other here.? ?You keep talking > about untrusted code, which sounds like applets to me.? I've read > and still have a copy of Li Gong's book, applets were only one of > the considerations.? I am talking about authorization and access > control.? We use and develop distributed or p2p systems, we don't > allow untrusted code to run at all, never ever, that's a dumb > idea, so lets stop talking about untrusted code, we don't use > that.? ? We do utilize dynamic downloaded code from others and use > dynamic class loading, we verify this prior to loading.? We check > it's authorized to run before running it.? Again I repeat, we do > not run untrusted code, that would allow an attacker to cause > denial of service etc, the JVM has no control over badly behaving > code. > > The whole design of the security manager as a ?path-dependent? > deep sandbox is built around untrusted code, hence > all the stack-walking and doPrivileged. Trusted code means assumed > not to be malicious. As such, what you want to protect > against is vulnerabilities. Since you don?t know where they are, > you place the entire application in a sandbox that?s > both more airtight and less complex than the Security Manager. > That is, in fact, how most people do it. > > > > > Of course Java is "able" to do access control, it's well > documented, I have working examples.? No security defense is 100% > effective, if you look at the history of defenses, they continue > to evolve.? Just because ObjectInputStream was a huge security > hole, it didn't inject an unprivileged ProtectionDomain onto the > stack, which would have stopped a number of deserialization > gadgets. ?ObjectInputStream runs as privileged code, tut, tut, > tut! ?Perl taint mode anyone? > > We are not talking about authorisation or access control. We?re > talking about the Security Manager?s design and implementation > which is about code domains and stack-dependence. Serialisation?s > security is one thing and the Security Manager is a whole other > thing. > > > > > Java 6 introduced a security feature where an object will not be > constructed if Object's constructor is not called, so that > invariants must be satisfied before object creation.? Java > Serialziation bypasses this.? Prior to Java 6, objects could be > left in a partially constructed state and obtained via a finalizer > attack. > > > > Besides, serialization whitelists don't protect against denial > of service, so why have them at all if you using trusted systems > and TLS connections?? Java Serialization should never be used to > process untrusted data, because it doesn't and cannot validate > invariants until after objects are constructed which is too late. > As soon as you implement Serializable, all the effort you put into > defensively coding constructors can be bypassed.? ?So why code > defensively at all if we leave a back door wide open anyway?? All > code is trusted now right, soon we can make sure all connections > are secure, so we don't need to worry about input validation > anymore either right, because the users are trusted now too? Maybe > we should just whitelist the classes allowed to run on the JVM and > not worry about coding defensively?? Sounds silly, well that's how > it sounds to me, just thought I'd put it into perspective. > > > > Java Serialization still compromises the security of the JVM > because it doesn't prevent object creation if invariants aren't > satisfied, the vulnerability is still there, and future attackers > will find a way take advantage of it for that reason. > > > > It is clear that no further progress will be made in this matter > and I will simply have to live with the consequences. Stick a fork > in me, because I'm done. > > You are conflating the Security Manager with security. A lot of > security work has been going on in the JDK for the past few years > (and will continue for as long Java exists), but not in the > code-protection-domain-sandbox known as the Security Manager. > > ? Ron > > > > -- > -Peter Tribble > http://www.petertribble.co.uk/ - > http://ptribble.blogspot.com/ -------------- next part -------------- grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/lib/jinitests.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission javax.security.auth.AuthPermission "getSubject"; permission org.apache.river.api.io.DeSerializationPermission "MARSHALL"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\java", "execute"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\starter\\starter.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\dynamic-policy.properties", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\jsselogins", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\phoenix.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\truststore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\nonactivatablegroup-dl.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\qa1-lookupservice-dl.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\src\\org\\apache\\river\\test\\resources\\jinitest.policy", "read"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\"", "listen"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Phoenix\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "connect"; permission net.jini.security.GrantPermission "net.jini.security.AuthenticationPermission \"javax.security.auth.x500.X500Principal \\\"CN=Tester\\\" peer javax.security.auth.x500.X500Principal \\\"CN=Reggie\\\"\", \"connect\";"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4506", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4509", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4510", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4526", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4529", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4530", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4531", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4532", "accept,resolve"; permission java.net.SocketPermission "localhost:0", "listen,resolve"; permission java.net.SocketPermission "localhost:9080", "listen,resolve"; permission java.net.SocketPermission "localhost:9081", "listen,resolve"; permission java.net.SocketPermission "localhost:9082", "listen,resolve"; permission java.util.PropertyPermission "/", "read"; permission java.util.PropertyPermission "HOST", "read"; permission java.util.PropertyPermission "activation.jar", "read"; permission java.util.PropertyPermission "bouncy-jce.jar", "read"; permission java.util.PropertyPermission "bouncy-jsse.jar", "read"; permission java.util.PropertyPermission "classserver.jar", "read"; permission java.util.PropertyPermission "collections.jar", "read"; permission java.util.PropertyPermission "destroy.jar", "read"; permission java.util.PropertyPermission "disco.jar", "read"; permission java.util.PropertyPermission "fiddler-dl.jar", "read"; permission java.util.PropertyPermission "fiddler.jar", "read"; permission java.util.PropertyPermission "file.ext", "read"; permission java.util.PropertyPermission "globalclasspath", "read"; permission java.util.PropertyPermission "group.jar", "read"; permission java.util.PropertyPermission "high-scale-lib.jar", "read"; permission java.util.PropertyPermission "java.class.path", "read"; permission java.util.PropertyPermission "java.home", "read"; permission java.util.PropertyPermission "java.rmi.server.codebase", "read"; permission java.util.PropertyPermission "java.util.logging.config.file", "read"; permission java.util.PropertyPermission "jeri.jar", "read"; permission java.util.PropertyPermission "jgdms-rmi-tls.jar", "read"; permission java.util.PropertyPermission "jiniClassServer.adminName", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.port", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "jiniClassServer.dir", "read"; permission java.util.PropertyPermission "jiniClassServer.dir.0", "read"; permission java.util.PropertyPermission "jiniClassServer.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.impl.0", "read"; permission java.util.PropertyPermission "jiniClassServer.port", "read"; permission java.util.PropertyPermission "jiniClassServer.port.0", "read"; permission java.util.PropertyPermission "jiniClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "jiniClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "jiniClassServer.transient.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.type", "read"; permission java.util.PropertyPermission "jiniClassServer.type.0", "read"; permission java.util.PropertyPermission "jiniClassServer.type.1", "read"; permission java.util.PropertyPermission "jsk-dl.jar", "read"; permission java.util.PropertyPermission "jsk-lib.jar", "read"; permission java.util.PropertyPermission "jsk.iiop.jar", "read"; permission java.util.PropertyPermission "jsk.jrmp.jar", "read"; permission java.util.PropertyPermission "jsk.pref.jar", "read"; permission java.util.PropertyPermission "jsk.url.jar", "read"; permission java.util.PropertyPermission "loader.jar", "read"; permission java.util.PropertyPermission "mahalo-dl.jar", "read"; permission java.util.PropertyPermission "mahalo.jar", "read"; permission java.util.PropertyPermission "mercury-dl.jar", "read"; permission java.util.PropertyPermission "mercury.jar", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.adminName", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.classpath", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.classpath.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.codebase", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.codebase.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.component", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.component.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.impl", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.instances", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.integrityhash", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.integrityhash.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.membergroups", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.membergroups.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.policyfile", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.policyfile.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.port", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.port.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.preparername", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.preparername.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running.1", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.serviceConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.serviceConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.starterConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.starterConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.tojoin", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.tojoin.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.classpath", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.classpath.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.codebase", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.codebase.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.component", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.component.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.impl", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.impl.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.integrityhash", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.integrityhash.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.log", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.log.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.membergroups", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.membergroups.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.policyfile", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.policyfile.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.port", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.port.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.preparername", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.preparername.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running.1", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.serviceConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.serviceConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.starterConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.starterConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.tojoin", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.tojoin.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type.1", "read"; permission java.util.PropertyPermission "net.jini.discovery.announce", "read"; permission java.util.PropertyPermission "nonActivatableGroup.adminName", "read"; permission java.util.PropertyPermission "nonActivatableGroup.classpath", "read"; permission java.util.PropertyPermission "nonActivatableGroup.classpath.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.codebase", "read"; permission java.util.PropertyPermission "nonActivatableGroup.codebase.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.impl.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.integrityhash", "read"; permission java.util.PropertyPermission "nonActivatableGroup.integrityhash.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.classpath", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.classpath.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.codebase", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.codebase.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.impl.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.integrityhash", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.integrityhash.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.policyfile", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.policyfile.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvm", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvm.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvmargs", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvmargs.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.policyfile", "read"; permission java.util.PropertyPermission "nonActivatableGroup.policyfile.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvm", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvm.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvmargs", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvmargs.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.transient.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type.1", "read"; permission java.util.PropertyPermission "norm-dl.jar", "read"; permission java.util.PropertyPermission "norm.jar", "read"; permission java.util.PropertyPermission "org.apache.river.jsk.home", "read"; permission java.util.PropertyPermission "org.apache.river.jsk.port", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.dldir.9080", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.dldir.9081", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.globalvmargs", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.integrityhash", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.runjiniserver", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.runkitserver", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.securityproperties", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.serviceMode", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.shared", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.startDelay", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.testClassServer", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.testhosts", "read"; permission java.util.PropertyPermission "org.apache.river.qa.home", "read"; permission java.util.PropertyPermission "org.apache.river.qa.port", "read"; permission java.util.PropertyPermission "org.apache.river.test.home", "read"; permission java.util.PropertyPermission "org.apache.river.test.port", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.actClasspath", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.actCodebase", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTEvntLeaseExp", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTEvntNotify", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTListener", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTSrvcLeaseExp", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.nInstancesPerClass", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.outputRoot", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.policy", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.rmiCodebase", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.selectMethod", "read"; permission java.util.PropertyPermission "outrigger-dl.jar", "read"; permission java.util.PropertyPermission "outrigger-snaplogstore.jar", "read"; permission java.util.PropertyPermission "outrigger.jar", "read"; permission java.util.PropertyPermission "phoenix-common.jar", "read"; permission java.util.PropertyPermission "phoenix-dl.jar", "read"; permission java.util.PropertyPermission "phoenix-group.jar", "read"; permission java.util.PropertyPermission "phoenix-init.jar", "read"; permission java.util.PropertyPermission "phoenix.jar", "read"; permission java.util.PropertyPermission "platform.jar", "read"; permission java.util.PropertyPermission "policy.writer.jar", "read"; permission java.util.PropertyPermission "qaClassServer.adminName", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.port", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "qaClassServer.dir", "read"; permission java.util.PropertyPermission "qaClassServer.dir.0", "read"; permission java.util.PropertyPermission "qaClassServer.impl", "read"; permission java.util.PropertyPermission "qaClassServer.impl.0", "read"; permission java.util.PropertyPermission "qaClassServer.port", "read"; permission java.util.PropertyPermission "qaClassServer.port.0", "read"; permission java.util.PropertyPermission "qaClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "qaClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "qaClassServer.transient.impl", "read"; permission java.util.PropertyPermission "qaClassServer.type", "read"; permission java.util.PropertyPermission "qaClassServer.type.0", "read"; permission java.util.PropertyPermission "qaClassServer.type.1", "read"; permission java.util.PropertyPermission "reggie-dl.jar", "read"; permission java.util.PropertyPermission "reggie.jar", "read"; permission java.util.PropertyPermission "river.version", "read"; permission java.util.PropertyPermission "start.jar", "read"; permission java.util.PropertyPermission "testClassServer.adminName", "read"; permission java.util.PropertyPermission "testClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "testClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "testClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.port", "read"; permission java.util.PropertyPermission "testClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "testClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "testClassServer.dir", "read"; permission java.util.PropertyPermission "testClassServer.dir.0", "read"; permission java.util.PropertyPermission "testClassServer.impl", "read"; permission java.util.PropertyPermission "testClassServer.impl.0", "read"; permission java.util.PropertyPermission "testClassServer.port", "read"; permission java.util.PropertyPermission "testClassServer.port.0", "read"; permission java.util.PropertyPermission "testClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "testClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "testClassServer.transient.impl", "read"; permission java.util.PropertyPermission "testClassServer.type", "read"; permission java.util.PropertyPermission "testClassServer.type.0", "read"; permission java.util.PropertyPermission "testClassServer.type.1", "read"; permission java.util.PropertyPermission "user.dir", "read"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/lib/jiniharness.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission javax.security.auth.AuthPermission "getSubject"; permission java.lang.RuntimePermission "exitVM.0"; permission org.apache.river.api.io.DeSerializationPermission "MARSHALL"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\java", "execute"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\starter\\starter.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\dynamic-policy.properties", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\jsselogins", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\phoenix.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\truststore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\nonactivatablegroup-dl.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\qa1-lookupservice-dl.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\src\\org\\apache\\river\\test\\resources\\jinitest.policy", "read"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\"", "listen"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Phoenix\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "connect"; permission net.jini.security.GrantPermission "net.jini.security.AuthenticationPermission \"javax.security.auth.x500.X500Principal \\\"CN=Tester\\\" peer javax.security.auth.x500.X500Principal \\\"CN=Reggie\\\"\", \"connect\";"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4506", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4509", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4510", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4526", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4529", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4530", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4531", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4532", "accept,resolve"; permission java.net.SocketPermission "localhost:0", "listen,resolve"; permission java.net.SocketPermission "localhost:9080", "listen,resolve"; permission java.net.SocketPermission "localhost:9081", "listen,resolve"; permission java.net.SocketPermission "localhost:9082", "listen,resolve"; permission java.util.PropertyPermission "/", "read"; permission java.util.PropertyPermission "HOST", "read"; permission java.util.PropertyPermission "activation.jar", "read"; permission java.util.PropertyPermission "bouncy-jce.jar", "read"; permission java.util.PropertyPermission "bouncy-jsse.jar", "read"; permission java.util.PropertyPermission "classserver.jar", "read"; permission java.util.PropertyPermission "collections.jar", "read"; permission java.util.PropertyPermission "destroy.jar", "read"; permission java.util.PropertyPermission "disco.jar", "read"; permission java.util.PropertyPermission "fiddler-dl.jar", "read"; permission java.util.PropertyPermission "fiddler.jar", "read"; permission java.util.PropertyPermission "file.ext", "read"; permission java.util.PropertyPermission "globalclasspath", "read"; permission java.util.PropertyPermission "group.jar", "read"; permission java.util.PropertyPermission "high-scale-lib.jar", "read"; permission java.util.PropertyPermission "java.class.path", "read"; permission java.util.PropertyPermission "java.home", "read"; permission java.util.PropertyPermission "java.rmi.server.codebase", "read"; permission java.util.PropertyPermission "java.util.logging.config.file", "read"; permission java.util.PropertyPermission "jeri.jar", "read"; permission java.util.PropertyPermission "jgdms-rmi-tls.jar", "read"; permission java.util.PropertyPermission "jiniClassServer.adminName", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.port", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "jiniClassServer.dir", "read"; permission java.util.PropertyPermission "jiniClassServer.dir.0", "read"; permission java.util.PropertyPermission "jiniClassServer.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.impl.0", "read"; permission java.util.PropertyPermission "jiniClassServer.port", "read"; permission java.util.PropertyPermission "jiniClassServer.port.0", "read"; permission java.util.PropertyPermission "jiniClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "jiniClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "jiniClassServer.transient.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.type", "read"; permission java.util.PropertyPermission "jiniClassServer.type.0", "read"; permission java.util.PropertyPermission "jiniClassServer.type.1", "read"; permission java.util.PropertyPermission "jsk-dl.jar", "read"; permission java.util.PropertyPermission "jsk-lib.jar", "read"; permission java.util.PropertyPermission "jsk.iiop.jar", "read"; permission java.util.PropertyPermission "jsk.jrmp.jar", "read"; permission java.util.PropertyPermission "jsk.pref.jar", "read"; permission java.util.PropertyPermission "jsk.url.jar", "read"; permission java.util.PropertyPermission "loader.jar", "read"; permission java.util.PropertyPermission "mahalo-dl.jar", "read"; permission java.util.PropertyPermission "mahalo.jar", "read"; permission java.util.PropertyPermission "mercury-dl.jar", "read"; permission java.util.PropertyPermission "mercury.jar", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.adminName", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.classpath", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.classpath.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.codebase", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.codebase.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.component", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.component.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.impl", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.instances", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.integrityhash", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.integrityhash.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.membergroups", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.membergroups.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.policyfile", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.policyfile.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.port", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.port.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.preparername", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.preparername.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running.1", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.serviceConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.serviceConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.starterConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.starterConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.tojoin", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.tojoin.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.classpath", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.classpath.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.codebase", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.codebase.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.component", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.component.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.impl", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.impl.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.integrityhash", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.integrityhash.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.log", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.log.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.membergroups", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.membergroups.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.policyfile", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.policyfile.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.port", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.port.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.preparername", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.preparername.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running.1", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.serviceConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.serviceConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.starterConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.starterConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.tojoin", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.tojoin.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type.1", "read"; permission java.util.PropertyPermission "net.jini.discovery.announce", "read"; permission java.util.PropertyPermission "nonActivatableGroup.adminName", "read"; permission java.util.PropertyPermission "nonActivatableGroup.classpath", "read"; permission java.util.PropertyPermission "nonActivatableGroup.classpath.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.codebase", "read"; permission java.util.PropertyPermission "nonActivatableGroup.codebase.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.impl.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.integrityhash", "read"; permission java.util.PropertyPermission "nonActivatableGroup.integrityhash.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.classpath", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.classpath.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.codebase", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.codebase.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.impl.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.integrityhash", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.integrityhash.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.policyfile", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.policyfile.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvm", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvm.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvmargs", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvmargs.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.policyfile", "read"; permission java.util.PropertyPermission "nonActivatableGroup.policyfile.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvm", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvm.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvmargs", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvmargs.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.transient.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type.1", "read"; permission java.util.PropertyPermission "norm-dl.jar", "read"; permission java.util.PropertyPermission "norm.jar", "read"; permission java.util.PropertyPermission "org.apache.river.jsk.home", "read"; permission java.util.PropertyPermission "org.apache.river.jsk.port", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.callAutoT", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.dldir.9080", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.dldir.9081", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.globalvmargs", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.integrityhash", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.nSecsWaitDestroy", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.runjiniserver", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.runkitserver", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.securityproperties", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.serviceMode", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.shared", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.startDelay", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.testClassServer", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.testhosts", "read"; permission java.util.PropertyPermission "org.apache.river.qa.home", "read"; permission java.util.PropertyPermission "org.apache.river.qa.port", "read"; permission java.util.PropertyPermission "org.apache.river.test.home", "read"; permission java.util.PropertyPermission "org.apache.river.test.port", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.actClasspath", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.actCodebase", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTEvntLeaseExp", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTEvntNotify", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTListener", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTSrvcLeaseExp", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.nInstancesPerClass", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.outputRoot", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.policy", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.rmiCodebase", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.selectMethod", "read"; permission java.util.PropertyPermission "os.name", "read"; permission java.util.PropertyPermission "outrigger-dl.jar", "read"; permission java.util.PropertyPermission "outrigger-snaplogstore.jar", "read"; permission java.util.PropertyPermission "outrigger.jar", "read"; permission java.util.PropertyPermission "phoenix-common.jar", "read"; permission java.util.PropertyPermission "phoenix-dl.jar", "read"; permission java.util.PropertyPermission "phoenix-group.jar", "read"; permission java.util.PropertyPermission "phoenix-init.jar", "read"; permission java.util.PropertyPermission "phoenix.jar", "read"; permission java.util.PropertyPermission "platform.jar", "read"; permission java.util.PropertyPermission "policy.writer.jar", "read"; permission java.util.PropertyPermission "qaClassServer.adminName", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.port", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "qaClassServer.dir", "read"; permission java.util.PropertyPermission "qaClassServer.dir.0", "read"; permission java.util.PropertyPermission "qaClassServer.impl", "read"; permission java.util.PropertyPermission "qaClassServer.impl.0", "read"; permission java.util.PropertyPermission "qaClassServer.port", "read"; permission java.util.PropertyPermission "qaClassServer.port.0", "read"; permission java.util.PropertyPermission "qaClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "qaClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "qaClassServer.transient.impl", "read"; permission java.util.PropertyPermission "qaClassServer.type", "read"; permission java.util.PropertyPermission "qaClassServer.type.0", "read"; permission java.util.PropertyPermission "qaClassServer.type.1", "read"; permission java.util.PropertyPermission "reggie-dl.jar", "read"; permission java.util.PropertyPermission "reggie.jar", "read"; permission java.util.PropertyPermission "river.version", "read"; permission java.util.PropertyPermission "start.jar", "read"; permission java.util.PropertyPermission "testClassServer.adminName", "read"; permission java.util.PropertyPermission "testClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "testClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "testClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.port", "read"; permission java.util.PropertyPermission "testClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "testClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "testClassServer.dir", "read"; permission java.util.PropertyPermission "testClassServer.dir.0", "read"; permission java.util.PropertyPermission "testClassServer.impl", "read"; permission java.util.PropertyPermission "testClassServer.impl.0", "read"; permission java.util.PropertyPermission "testClassServer.port", "read"; permission java.util.PropertyPermission "testClassServer.port.0", "read"; permission java.util.PropertyPermission "testClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "testClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "testClassServer.transient.impl", "read"; permission java.util.PropertyPermission "testClassServer.type", "read"; permission java.util.PropertyPermission "testClassServer.type.0", "read"; permission java.util.PropertyPermission "testClassServer.type.1", "read"; permission java.util.PropertyPermission "user.dir", "read"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/lib/jiniharness.jar" { permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Test"; permission javax.security.auth.AuthPermission "doAsPrivileged"; permission java.lang.RuntimePermission "getenv.SOUL"; permission java.lang.RuntimePermission "setIO"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\test.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\soul\\soul.202105041751026391", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\src\\org\\apache\\river\\test\\spec\\lookupservice\\configs\\jsse\\default.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\src\\org\\apache\\river\\test\\spec\\lookupservice\\test_set02\\org\\apache\\river\\test\\spec\\lookupservice\\configs\\jsse\\default.config", "read"; permission java.io.FilePermission "org\\apache\\river\\test\\spec\\lookupservice\\configs\\jsse\\default.config", "read"; permission java.security.SecurityPermission "createPolicy.JiniPolicy"; permission java.security.SecurityPermission "getPolicy"; permission java.security.SecurityPermission "setPolicy"; permission java.util.PropertyPermission "line.separator", "read"; permission java.util.PropertyPermission "loader.requireDlPerm", "read"; permission java.util.PropertyPermission "net.jini.discovery.announce", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.defaultTestConfig", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.testhosts", "read"; permission java.util.PropertyPermission "testConfiguration", "read"; permission java.util.PropertyPermission "testFailureAnalyzers", "read"; permission java.util.PropertyPermission "user.dir", "read"; permission java.util.logging.LoggingPermission "control"; }; grant codebase "jrt:/java.smartcardio" { permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.security.SecurityPermission "putProviderProperty.SunPCSC"; }; grant codebase "httpmd://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar;md5=a28068d398d636dd8fbeace7df8faa77" { permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission javax.security.auth.AuthPermission "getSubject"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4526", "connect,resolve"; }; grant codebase "httpmd://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar;md5=a28068d398d636dd8fbeace7df8faa77", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission javax.security.auth.AuthPermission "getSubject"; permission org.apache.river.api.io.DeSerializationPermission "MARSHALL"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Phoenix\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "connect"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4526", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4531", "connect,resolve"; permission java.util.PropertyPermission "org.apache.river.reggie.enableImplToStubReplacement", "read"; }; grant codebase "jrt:/jdk.crypto.mscapi" { permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.lang.RuntimePermission "loadLibrary.sunmscapi"; permission java.security.SecurityPermission "putProviderProperty.SunMSCAPI"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib-dl/jgdms-lib-dl-3.1.1-SNAPSHOT.jar" { permission org.apache.river.api.io.DeSerializationPermission "ATOMIC"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-url-integrity-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission java.net.NetPermission "specifyStreamHandler"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\nonactivatablegroup-dl.jar", "read"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar" { permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.reflect"; permission java.lang.RuntimePermission "createClassLoader"; permission java.lang.RuntimePermission "getClassLoader"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "connect,accept,resolve"; permission java.util.PropertyPermission "java.rmi.server.codebase", "read"; permission java.util.PropertyPermission "net.jini.loader.codebaseAnnotation", "read"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-collections-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; }; grant codebase "jrt:/java.security.jgss" { permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.security.SecurityPermission "putProviderProperty.SunJGSS"; }; grant codebase "httpmd://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar;md5=c1233e711b1fc12d6df366839f425ebd" { permission org.apache.river.api.io.DeSerializationPermission "ATOMIC"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-platform-3.1.1-SNAPSHOT.jar" { permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; permission org.apache.river.thread.ThreadPoolPermission "getUserThreadPool"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.io.SerializablePermission "enableSubclassImplementation"; permission java.io.SerializablePermission "enableSubstitution"; permission org.apache.river.jeri.internal.EndpointInternalsPermission "set"; permission java.lang.reflect.ReflectPermission "suppressAccessChecks"; permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Test"; permission javax.security.auth.AuthPermission "doAsPrivileged"; permission javax.security.auth.AuthPermission "getLoginConfiguration"; permission javax.security.auth.AuthPermission "getSubject"; permission javax.security.auth.AuthPermission "getSubjectFromDomainCombiner"; permission javax.security.auth.AuthPermission "modifyPrincipals"; permission javax.security.auth.AuthPermission "modifyPrivateCredentials"; permission javax.security.auth.AuthPermission "modifyPublicCredentials"; permission javax.security.auth.AuthPermission "setLoginConfiguration"; permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.reflect"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.jca"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.krb5"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.pkcs"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.provider"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math.intpoly"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.x509"; permission java.lang.RuntimePermission "accessClassInPackage.sun.util.locale.provider"; permission java.lang.RuntimePermission "accessClassInPackage.sun.util.resources"; permission java.lang.RuntimePermission "accessDeclaredMembers"; permission java.lang.RuntimePermission "accessSystemModules"; permission java.lang.RuntimePermission "createClassLoader"; permission java.lang.RuntimePermission "createSecurityManager"; permission java.lang.RuntimePermission "getClassLoader"; permission java.lang.RuntimePermission "getProtectionDomain"; permission java.lang.RuntimePermission "getStackWalkerWithClassReference"; permission java.lang.RuntimePermission "getenv.SOUL"; permission java.lang.RuntimePermission "loadLibrary.net"; permission java.lang.RuntimePermission "loadLibrary.nio"; permission java.lang.RuntimePermission "loadLibrary.sunec"; permission java.lang.RuntimePermission "loadLibrary.sunmscapi"; permission java.lang.RuntimePermission "loadLibrary.zip"; permission java.lang.RuntimePermission "localeServiceProvider"; permission java.lang.RuntimePermission "loggerFinder"; permission java.lang.RuntimePermission "modifyThread"; permission java.lang.RuntimePermission "modifyThreadGroup"; permission java.lang.RuntimePermission "readFileDescriptor"; permission java.lang.RuntimePermission "reflectionFactoryAccess"; permission java.lang.RuntimePermission "setContextClassLoader"; permission java.lang.RuntimePermission "setIO"; permission java.lang.RuntimePermission "shutdownHooks"; permission java.lang.RuntimePermission "writeFileDescriptor"; permission org.apache.river.api.io.DeSerializationPermission "ATOMIC"; permission net.jini.io.context.ContextPermission "net.jini.io.context.ClientSubject.getClientSubject"; permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Tester\"", "read"; permission java.net.NetPermission "getCookieHandler"; permission java.net.NetPermission "getNetworkInformation"; permission java.net.NetPermission "getProxySelector"; permission java.net.NetPermission "getResponseCache"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\net.dll", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\nio.dll", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\sunec.dll", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\sunmscapi.dll", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\zip.dll", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\net.properties", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\policy\\unlimited", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\policy\\unlimited\\default_US_export.policy", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\policy\\unlimited\\default_local.policy", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\security\\blacklisted.certs", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\security\\cacerts", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\tzdb.dat", "read"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp", "read"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache13530489763375062441.tmp", "delete"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache13530489763375062441.tmp", "read"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache13530489763375062441.tmp", "write"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache6285608515666175907.tmp", "delete"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache6285608515666175907.tmp", "read"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache6285608515666175907.tmp", "write"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-url-integrity-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\test.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\jsselogins", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jiniharness.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jinitests.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\soul\\soul.202105041751026391", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\src\\org\\apache\\river\\test\\spec\\lookupservice\\configs\\jsse\\default.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\src\\org\\apache\\river\\test\\spec\\lookupservice\\test_set02\\org\\apache\\river\\test\\spec\\lookupservice\\configs\\jsse\\default.config", "read"; permission java.io.FilePermission "org\\apache\\river\\test\\spec\\lookupservice\\configs\\jsse\\default.config", "read"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\"", "listen"; permission java.security.SecurityPermission "createAccessControlContext"; permission java.security.SecurityPermission "createPolicy.JiniPolicy"; permission java.security.SecurityPermission "getDomainCombiner"; permission java.security.SecurityPermission "getPolicy"; permission java.security.SecurityPermission "getProperty.auth.login.defaultCallbackHandler"; permission java.security.SecurityPermission "getProperty.crypto.policy"; permission java.security.SecurityPermission "getProperty.jdk.certpath.disabledAlgorithms"; permission java.security.SecurityPermission "getProperty.jdk.security.caDistrustPolicies"; permission java.security.SecurityPermission "getProperty.jdk.security.provider.preferred"; permission java.security.SecurityPermission "getProperty.jdk.serialFilter"; permission java.security.SecurityPermission "getProperty.jdk.tls.disabledAlgorithms"; permission java.security.SecurityPermission "getProperty.jdk.tls.keyLimits"; permission java.security.SecurityPermission "getProperty.jdk.tls.legacyAlgorithms"; permission java.security.SecurityPermission "getProperty.jdk.tls.server.defaultDHEParameters"; permission java.security.SecurityPermission "getProperty.keystore.type"; permission java.security.SecurityPermission "getProperty.keystore.type.compat"; permission java.security.SecurityPermission "getProperty.login.config.url.1"; permission java.security.SecurityPermission "getProperty.login.configuration.provider"; permission java.security.SecurityPermission "getProperty.policy.allowSystemProperty"; permission java.security.SecurityPermission "getProperty.policy.expandProperties"; permission java.security.SecurityPermission "getProperty.securerandom.drbg.config"; permission java.security.SecurityPermission "getProperty.securerandom.source"; permission java.security.SecurityPermission "getProperty.security.provider.1"; permission java.security.SecurityPermission "getProperty.security.provider.10"; permission java.security.SecurityPermission "getProperty.security.provider.11"; permission java.security.SecurityPermission "getProperty.security.provider.12"; permission java.security.SecurityPermission "getProperty.security.provider.13"; permission java.security.SecurityPermission "getProperty.security.provider.14"; permission java.security.SecurityPermission "getProperty.security.provider.2"; permission java.security.SecurityPermission "getProperty.security.provider.3"; permission java.security.SecurityPermission "getProperty.security.provider.4"; permission java.security.SecurityPermission "getProperty.security.provider.5"; permission java.security.SecurityPermission "getProperty.security.provider.6"; permission java.security.SecurityPermission "getProperty.security.provider.7"; permission java.security.SecurityPermission "getProperty.security.provider.8"; permission java.security.SecurityPermission "getProperty.security.provider.9"; permission java.security.SecurityPermission "getProperty.ssl.TrustManagerFactory.algorithm"; permission java.security.SecurityPermission "putProviderProperty.JdkLDAP"; permission java.security.SecurityPermission "putProviderProperty.JdkSASL"; permission java.security.SecurityPermission "putProviderProperty.SUN"; permission java.security.SecurityPermission "putProviderProperty.SunEC"; permission java.security.SecurityPermission "putProviderProperty.SunJCE"; permission java.security.SecurityPermission "putProviderProperty.SunJGSS"; permission java.security.SecurityPermission "putProviderProperty.SunJSSE"; permission java.security.SecurityPermission "putProviderProperty.SunMSCAPI"; permission java.security.SecurityPermission "putProviderProperty.SunPCSC"; permission java.security.SecurityPermission "putProviderProperty.SunRsaSign"; permission java.security.SecurityPermission "putProviderProperty.SunSASL"; permission java.security.SecurityPermission "putProviderProperty.XMLDSig"; permission java.security.SecurityPermission "setPolicy"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "connect,accept,resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve"; permission java.util.PropertyPermission "*", "read,write"; permission java.util.logging.LoggingPermission "control"; }; grant codebase "jrt:/jdk.security.jgss" { permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.security.SecurityPermission "putProviderProperty.JdkSASL"; }; grant codebase "httpmd://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar;md5=a28068d398d636dd8fbeace7df8faa77" { permission org.apache.river.api.io.DeSerializationPermission "ATOMIC"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; }; grant codebase "jrt:/jdk.crypto.ec" { permission java.lang.RuntimePermission "accessClassInPackage.sun.security.jca"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.pkcs"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math.intpoly"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.x509"; permission java.lang.RuntimePermission "loadLibrary.sunec"; permission java.security.SecurityPermission "putProviderProperty.SunEC"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-jeri-3.1.1-SNAPSHOT.jar" { permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; permission org.apache.river.thread.ThreadPoolPermission "getUserThreadPool"; permission java.io.SerializablePermission "enableSubclassImplementation"; permission java.io.SerializablePermission "enableSubstitution"; permission org.apache.river.jeri.internal.EndpointInternalsPermission "set"; permission java.lang.reflect.ReflectPermission "suppressAccessChecks"; permission javax.security.auth.AuthPermission "getSubject"; permission java.lang.RuntimePermission "getClassLoader"; permission java.lang.RuntimePermission "modifyThread"; permission java.lang.RuntimePermission "modifyThreadGroup"; permission java.lang.RuntimePermission "setContextClassLoader"; permission org.apache.river.api.io.DeSerializationPermission "ATOMIC"; permission net.jini.io.context.ContextPermission "net.jini.io.context.ClientSubject.getClientSubject"; permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Tester\"", "read"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\"", "listen"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4533", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4555", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4580", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4596", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4604", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4605", "accept,resolve"; permission java.util.PropertyPermission "org.apache.river.jeri.connection.mux.client.initialInboundRation", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.connection.mux.server.initialInboundRation", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.connectionTimeout", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.dgc.checkInterval", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.dgc.cleanInterval", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.dgc.leaseValue", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.dgc.minimumDuration", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.handshakeTimeout", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.server.suppressStackTraces", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.certificateType", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.cipherSuites", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jceProvider", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jsseProvider", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.secureRandomAlgorithm", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.sslProtocol", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.tcp.useNIO", "read"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-url-integrity-3.1.1-SNAPSHOT.jar" { permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-jeri-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; permission javax.security.auth.AuthPermission "getSubject"; permission org.apache.river.api.io.DeSerializationPermission "MARSHALL"; permission java.io.FilePermission "harness\\trust\\truststore", "read"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\"", "listen"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Phoenix\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "accept"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "accept"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "connect"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4506", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4526", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4531", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4533", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4555", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4580", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4596", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4604", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4605", "accept,resolve"; permission java.net.SocketPermission "localhost:0", "listen,resolve"; permission java.util.PropertyPermission "javax.net.ssl.trustStore", "read"; permission java.util.PropertyPermission "javax.net.ssl.trustStorePassword", "read"; permission java.util.PropertyPermission "javax.net.ssl.trustStoreType", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxClientSessionDuration", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxServerSessionDuration", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.trustManagerFactoryAlgorithm", "read"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/lib/jinitests.jar" { permission java.lang.RuntimePermission "createClassLoader"; permission java.util.PropertyPermission "loader.requireDlPerm", "read"; permission java.util.PropertyPermission "net.jini.discovery.announce", "read"; }; grant codebase "jrt:/jdk.security.auth" { permission javax.security.auth.AuthPermission "modifyPrincipals"; permission javax.security.auth.AuthPermission "modifyPrivateCredentials"; permission javax.security.auth.AuthPermission "modifyPublicCredentials"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.krb5"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.lang.RuntimePermission "getProtectionDomain"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jiniharness.jar", "read"; }; grant codebase "jrt:/jdk.crypto.cryptoki" { permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/classserver-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\qa1-lookupservice-dl.jar", "read"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4509", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4510", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4529", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4530", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4532", "accept,resolve"; permission java.net.SocketPermission "localhost:9080", "listen,resolve"; permission java.net.SocketPermission "localhost:9081", "listen,resolve"; permission java.net.SocketPermission "localhost:9082", "listen,resolve"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-collections-3.1.1-SNAPSHOT.jar" { permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; permission org.apache.river.thread.ThreadPoolPermission "getUserThreadPool"; permission java.lang.RuntimePermission "getClassLoader"; permission java.lang.RuntimePermission "modifyThread"; permission java.lang.RuntimePermission "modifyThreadGroup"; permission java.lang.RuntimePermission "setContextClassLoader"; permission java.lang.RuntimePermission "shutdownHooks"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\"", "listen"; permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4533", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4555", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4580", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4596", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4604", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4605", "accept,resolve"; }; grant codebase "jrt:/jdk.localedata" { permission java.lang.RuntimePermission "accessClassInPackage.sun.util.locale.provider"; permission java.lang.RuntimePermission "accessClassInPackage.sun.util.resources"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-platform-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; permission javax.security.auth.AuthPermission "getSubject"; permission java.lang.RuntimePermission "exitVM.0"; permission org.apache.river.api.io.DeSerializationPermission "MARSHALL"; permission java.net.NetPermission "specifyStreamHandler"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\java", "execute"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\starter\\starter.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\dynamic-policy.properties", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\jsselogins", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\phoenix.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\truststore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\nonactivatablegroup-dl.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\qa1-lookupservice-dl.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\src\\org\\apache\\river\\test\\resources\\jinitest.policy", "read"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\"", "listen"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Phoenix\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "accept"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "accept"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "connect"; permission net.jini.security.GrantPermission "net.jini.security.AuthenticationPermission \"javax.security.auth.x500.X500Principal \\\"CN=Tester\\\" peer javax.security.auth.x500.X500Principal \\\"CN=Reggie\\\"\", \"connect\";"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4506", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4509", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4510", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4526", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4529", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4530", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4531", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4532", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4533", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4555", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4580", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4596", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4604", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4605", "accept,resolve"; permission java.net.SocketPermission "localhost:0", "listen,resolve"; permission java.net.SocketPermission "localhost:9080", "listen,resolve"; permission java.net.SocketPermission "localhost:9081", "listen,resolve"; permission java.net.SocketPermission "localhost:9082", "listen,resolve"; permission java.util.PropertyPermission "/", "read"; permission java.util.PropertyPermission "HOST", "read"; permission java.util.PropertyPermission "activation.jar", "read"; permission java.util.PropertyPermission "bouncy-jce.jar", "read"; permission java.util.PropertyPermission "bouncy-jsse.jar", "read"; permission java.util.PropertyPermission "classserver.jar", "read"; permission java.util.PropertyPermission "collections.jar", "read"; permission java.util.PropertyPermission "destroy.jar", "read"; permission java.util.PropertyPermission "disco.jar", "read"; permission java.util.PropertyPermission "fiddler-dl.jar", "read"; permission java.util.PropertyPermission "fiddler.jar", "read"; permission java.util.PropertyPermission "file.ext", "read"; permission java.util.PropertyPermission "globalclasspath", "read"; permission java.util.PropertyPermission "group.jar", "read"; permission java.util.PropertyPermission "high-scale-lib.jar", "read"; permission java.util.PropertyPermission "java.class.path", "read"; permission java.util.PropertyPermission "java.home", "read"; permission java.util.PropertyPermission "java.rmi.server.codebase", "read"; permission java.util.PropertyPermission "java.util.logging.config.file", "read"; permission java.util.PropertyPermission "javax.net.ssl.trustStore", "read"; permission java.util.PropertyPermission "javax.net.ssl.trustStorePassword", "read"; permission java.util.PropertyPermission "javax.net.ssl.trustStoreType", "read"; permission java.util.PropertyPermission "jeri.jar", "read"; permission java.util.PropertyPermission "jgdms-rmi-tls.jar", "read"; permission java.util.PropertyPermission "jiniClassServer.adminName", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.port", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "jiniClassServer.dir", "read"; permission java.util.PropertyPermission "jiniClassServer.dir.0", "read"; permission java.util.PropertyPermission "jiniClassServer.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.impl.0", "read"; permission java.util.PropertyPermission "jiniClassServer.port", "read"; permission java.util.PropertyPermission "jiniClassServer.port.0", "read"; permission java.util.PropertyPermission "jiniClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "jiniClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "jiniClassServer.transient.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.type", "read"; permission java.util.PropertyPermission "jiniClassServer.type.0", "read"; permission java.util.PropertyPermission "jiniClassServer.type.1", "read"; permission java.util.PropertyPermission "jsk-dl.jar", "read"; permission java.util.PropertyPermission "jsk-lib.jar", "read"; permission java.util.PropertyPermission "jsk.iiop.jar", "read"; permission java.util.PropertyPermission "jsk.jrmp.jar", "read"; permission java.util.PropertyPermission "jsk.pref.jar", "read"; permission java.util.PropertyPermission "jsk.url.jar", "read"; permission java.util.PropertyPermission "loader.jar", "read"; permission java.util.PropertyPermission "mahalo-dl.jar", "read"; permission java.util.PropertyPermission "mahalo.jar", "read"; permission java.util.PropertyPermission "mercury-dl.jar", "read"; permission java.util.PropertyPermission "mercury.jar", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.adminName", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.classpath", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.classpath.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.codebase", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.codebase.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.component", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.component.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.impl", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.instances", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.integrityhash", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.integrityhash.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.membergroups", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.membergroups.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.policyfile", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.policyfile.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.port", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.port.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.preparername", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.preparername.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running.1", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.serviceConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.serviceConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.starterConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.starterConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.tojoin", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.tojoin.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.classpath", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.classpath.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.codebase", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.codebase.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.component", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.component.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.impl", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.impl.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.integrityhash", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.integrityhash.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.log", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.log.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.membergroups", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.membergroups.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.policyfile", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.policyfile.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.port", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.port.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.preparername", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.preparername.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running.1", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.serviceConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.serviceConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.starterConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.starterConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.tojoin", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.tojoin.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type.1", "read"; permission java.util.PropertyPermission "net.jini.discovery.announce", "read"; permission java.util.PropertyPermission "nonActivatableGroup.adminName", "read"; permission java.util.PropertyPermission "nonActivatableGroup.classpath", "read"; permission java.util.PropertyPermission "nonActivatableGroup.classpath.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.codebase", "read"; permission java.util.PropertyPermission "nonActivatableGroup.codebase.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.impl.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.integrityhash", "read"; permission java.util.PropertyPermission "nonActivatableGroup.integrityhash.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.classpath", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.classpath.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.codebase", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.codebase.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.impl.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.integrityhash", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.integrityhash.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.policyfile", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.policyfile.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvm", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvm.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvmargs", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvmargs.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.policyfile", "read"; permission java.util.PropertyPermission "nonActivatableGroup.policyfile.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvm", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvm.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvmargs", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvmargs.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.transient.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type.1", "read"; permission java.util.PropertyPermission "norm-dl.jar", "read"; permission java.util.PropertyPermission "norm.jar", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxClientSessionDuration", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxServerSessionDuration", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.trustManagerFactoryAlgorithm", "read"; permission java.util.PropertyPermission "org.apache.river.jsk.home", "read"; permission java.util.PropertyPermission "org.apache.river.jsk.port", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.callAutoT", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.dldir.9080", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.dldir.9081", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.globalvmargs", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.integrityhash", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.nSecsWaitDestroy", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.runjiniserver", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.runkitserver", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.securityproperties", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.serviceMode", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.shared", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.startDelay", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.testClassServer", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.testhosts", "read"; permission java.util.PropertyPermission "org.apache.river.qa.home", "read"; permission java.util.PropertyPermission "org.apache.river.qa.port", "read"; permission java.util.PropertyPermission "org.apache.river.reggie.enableImplToStubReplacement", "read"; permission java.util.PropertyPermission "org.apache.river.test.home", "read"; permission java.util.PropertyPermission "org.apache.river.test.port", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.actClasspath", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.actCodebase", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTEvntLeaseExp", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTEvntNotify", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTListener", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTSrvcLeaseExp", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.nInstancesPerClass", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.outputRoot", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.policy", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.rmiCodebase", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.selectMethod", "read"; permission java.util.PropertyPermission "os.name", "read"; permission java.util.PropertyPermission "outrigger-dl.jar", "read"; permission java.util.PropertyPermission "outrigger-snaplogstore.jar", "read"; permission java.util.PropertyPermission "outrigger.jar", "read"; permission java.util.PropertyPermission "phoenix-common.jar", "read"; permission java.util.PropertyPermission "phoenix-dl.jar", "read"; permission java.util.PropertyPermission "phoenix-group.jar", "read"; permission java.util.PropertyPermission "phoenix-init.jar", "read"; permission java.util.PropertyPermission "phoenix.jar", "read"; permission java.util.PropertyPermission "platform.jar", "read"; permission java.util.PropertyPermission "policy.writer.jar", "read"; permission java.util.PropertyPermission "qaClassServer.adminName", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.port", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "qaClassServer.dir", "read"; permission java.util.PropertyPermission "qaClassServer.dir.0", "read"; permission java.util.PropertyPermission "qaClassServer.impl", "read"; permission java.util.PropertyPermission "qaClassServer.impl.0", "read"; permission java.util.PropertyPermission "qaClassServer.port", "read"; permission java.util.PropertyPermission "qaClassServer.port.0", "read"; permission java.util.PropertyPermission "qaClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "qaClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "qaClassServer.transient.impl", "read"; permission java.util.PropertyPermission "qaClassServer.type", "read"; permission java.util.PropertyPermission "qaClassServer.type.0", "read"; permission java.util.PropertyPermission "qaClassServer.type.1", "read"; permission java.util.PropertyPermission "reggie-dl.jar", "read"; permission java.util.PropertyPermission "reggie.jar", "read"; permission java.util.PropertyPermission "river.version", "read"; permission java.util.PropertyPermission "start.jar", "read"; permission java.util.PropertyPermission "testClassServer.adminName", "read"; permission java.util.PropertyPermission "testClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "testClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "testClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.port", "read"; permission java.util.PropertyPermission "testClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "testClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "testClassServer.dir", "read"; permission java.util.PropertyPermission "testClassServer.dir.0", "read"; permission java.util.PropertyPermission "testClassServer.impl", "read"; permission java.util.PropertyPermission "testClassServer.impl.0", "read"; permission java.util.PropertyPermission "testClassServer.port", "read"; permission java.util.PropertyPermission "testClassServer.port.0", "read"; permission java.util.PropertyPermission "testClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "testClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "testClassServer.transient.impl", "read"; permission java.util.PropertyPermission "testClassServer.type", "read"; permission java.util.PropertyPermission "testClassServer.type.0", "read"; permission java.util.PropertyPermission "testClassServer.type.1", "read"; permission java.util.PropertyPermission "user.dir", "read"; }; grant codebase "jrt:/java.xml.crypto" { permission java.security.SecurityPermission "putProviderProperty.XMLDSig"; permission java.util.PropertyPermission "java.specification.version", "read"; }; From dmitry.markov at oracle.com Thu May 6 08:32:25 2021 From: dmitry.markov at oracle.com (Dmitrii Markov) Date: Thu, 6 May 2021 08:32:25 +0000 Subject: CFV: New JDK Reviewer: Alexander Matveev In-Reply-To: References: Message-ID: <0ED75211-6286-47F8-B30A-C3F6DF227E78@oracle.com> Vote: Yes Regards, Dmitry > On 5 May 2021, at 20:24, Philip Race wrote: > > I hereby nominate Alexander Matveev (matvee[1]) to the role of JDK Project Reviewer. > > Alexander is currently a JDK committer, and has been a long time member of the Java client team at Oracle > notably working in the area of media technologies for the OpenJFX [2] project in which he is a reviewer. > > He has made substantial contributions [3] to the development of the jpackage[4] tool > and has made 37 additional individual contributions [5] to the JDK project. > > In addition he has already been active in reviewing changes on the appropriate OpenJDK mailing lists. > > 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 19:30 UTC on 19th May 2021. > > -Phil > > [1] https://openjdk.java.net/census#almatvee > > [2] https://openjdk.java.net/projects/openjfx/ > > [3] commit 264573c9ce730ed421725b8986db4e3eb5124c47 > Author: Andy Herrick > Date: Thu Dec 5 11:25:33 2019 -0500 > > 8212780: Packaging Tool Implementation > > Co-authored-by: Alexey Semenyuk > Co-authored-by: Alexander Matveev > Co-authored-by: Kevin Rushforth > Co-authored-by: Philip Race > Reviewed-by: asemenyuk, almatvee, herrick, kcr, prr, erikj, ihse, rriggs, mchung, alanb > > [4] https://openjdk.java.net/jeps/392 > > [5] git log --author matvee --format='%h %s' > 5b43b39e55a 8263154: [macos] DMG builds have finder errors > 55d56495098 8263157: [macos]: java.library.path is being set incorrectly > fa43f926ab2 8261845: File permissions of packages built by jpackage > bec60432ecb 8259570: (macos) tools/jpackage tests fails with 'hdiutil: couldn't eject "disk2" - Resource busy' > eb1c8a15b6a 8257924: Use full path when running external executable from jpackage > e6b4c4d7162 8238781: [macos] jpackage tests failed due to "hdiutil: convert failed" in various ways > a265c201386 8255619: Localized WinResources.properties have MsiInstallerStrings_en.wxl resource > c35e1a284b9 8255947: [macos] Signed macOS jpackage app doesn't filter spurious '-psn' argument > 8ca59c9e2eb 8255206: [macos] LicenseTest fails on macOS 11 > 5a57945f1af 8231591: [TESTBUG] Create additional two phase jpackage tests > ac9d1b08ee4 8223187: Remove setLocale() call in jpackage native launcher > 89d75304119 8250803: pkgbuild failed with exit code 134 > 45c4d9d5196 8250646: hdiutil detach fix JDK-8245311 still fails sometimes > 084e15bca3d 8248905: [macos] symbolic links not properly resolved > bbddae55522 8248248: [macos] EmptyFolderPackageTest.java fails EmptyFolderPackageTest-dmg-setup.scpt exited with 134 code > f8a06bc497e 8245311: [macos] misc package tests failed due to "execution error: Finder got an error: AppleEvent timed out." > be04c8c7244 8249256: [macos] Add EmptyFolderPackageTest test to problem list > 55e7003fd51 8248059: [macos] EmptyFolderPackageTest.java failed "hdiutil: create failed - No child processes" > f45d121128d 8248255: [macos] Add failing DMG tests to problem list > 9584e01d24c 8225251: Minimise import statements in jpackage sources > 976c4693057 8236282: [macos] Find permanent solution to macOS test timeout problem JDK-8235738 > 6f5e8a2aa3a 8237908: [TESTBUG] [macos] Add support to jtreg helpers to unpack pkg packages > 93d89d3bf36 8242786: [macos] tools/jpackage/share/IconTest.java fails: ABORT trying to dequeue work > 52be8949e74 8245788: EmptyFolderPackageTest fails on Windows 10 > 191fe75c0f0 8233215: jpackage doesn't allow enough flexibility for file type binding > 5868c76ec6e 8233166: jpackage tool skips empty directories > 49002194fb6 8249264: Build validate-headers task fails after JDK-8248261 > 231a8408b2e 8248261: Add timestamps to jpackage and jpackage tests verbose output > ed05d576030 8223955: Eliminate or reduce mixing of old File API and new Path/Files APIs > 47cc808b989 8232841: [TESTBUG] [macos] SigningPackageTest fails when untrusted certificates exist on machine > f8f98bdbffc 8237607: [macos] Signing app bundle with jpackage fails if runtime is already signed > 529587547cd 8235955: [dmg] DMG creation fails without error message if previous DMG was not ejected > e104b4cee19 8235954: [dmg] Default DMG background tiff of jpackage not retina ready > c751493f0c6 8235738: [macos] tools/jpackage tests timeout on macOS > a51b5ae9c4f 8235252: Repair run_tests.sh by locating jtreg locally > 57991084944 8234284: [dmg] Change DMG background image to TIFF > b29f62ce516 8235767: Compilation failure caused by JDK-8212780: Packaging Tool Implementation > > [6] https://openjdk.java.net/census > > [7] https://openjdk.java.net/projects/#reviewer-vote > From mark.reinhold at oracle.com Tue May 4 16:33:23 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 04 May 2021 09:33:23 -0700 Subject: Result: New jdk Committer: Anton Kozlov In-Reply-To: References: Message-ID: <20210504093323.309466310@eggemoggin.niobe.net> 2021/5/4 7:00:12 -0700, Vladimir Kempik : > Voting for Anton Kozlov (akozlov) [1] is now closed. > > Yes: 29 > Veto: 0 > Abstain: 0 > > According to the Bylaws definition of Lazy Consensus, this is > sufficient to approve the nomination. So recorded. - Mark From mark.reinhold at oracle.com Wed May 5 22:17:56 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 5 May 2021 15:17:56 -0700 (PDT) Subject: JEP proposed to target JDK 17: 409: Sealed Classes Message-ID: <20210505221756.55F613E2C15@eggemoggin.niobe.net> The following JEP is proposed to target JDK 17: 409: Sealed Classes https://openjdk.java.net/jeps/409 Summary: Enhance the Java programming language with sealed classes and interfaces. Sealed classes and interfaces restrict which other classes or interfaces may extend or implement them. 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, 12 May, 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 17. - Mark [1] https://openjdk.java.net/census#jdk [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From mark.reinhold at oracle.com Thu May 6 22:37:07 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 6 May 2021 15:37:07 -0700 (PDT) Subject: New candidate JEP: 415: Context-Specific Deserialization Filters Message-ID: <20210506223707.46CC23E2F2C@eggemoggin.niobe.net> https://openjdk.java.net/jeps/415 Summary: Allow applications to configure context-specific and dynamically-selected deserialization filters via a JVM-wide filter factory that is invoked to select a filter for each individual deserialization operation. - Mark From peter.firmstone at zeus.net.au Fri May 7 00:44:01 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Fri, 7 May 2021 10:44:01 +1000 Subject: New candidate JEP: 415: Context-Specific Deserialization Filters In-Reply-To: <20210506223707.46CC23E2F2C@eggemoggin.niobe.net> References: <20210506223707.46CC23E2F2C@eggemoggin.niobe.net> Message-ID: <22cbe84e-82f7-d6ff-7a1a-b30a961828a9@zeus.net.au> While I'm not against such a thing, it indicates increasing complexity in the game of de-serialization whack-a-mole. It also suggests people are using Java Serialization to process un-trusted data. I think that Serialization Filter's are a design mistake, we should just enable the existing Java Serialization to be turned off completely.? The time spent writing these things should be spent implementing new Serialization API's. A property or command line argument that cannot be changed at runtime to switch off Java Serialization would be appreciated. A new public API for Serialization which includes Object level input validation and failure atomicity needs to be designed that is suitable for use with many Serialization protocols. Serialization is a public interface, we should start declaring it as such. -- Regards, Peter. On 7/05/2021 8:37 am, mark.reinhold at oracle.com wrote: > https://openjdk.java.net/jeps/415 > > Summary: Allow applications to configure context-specific and > dynamically-selected deserialization filters via a JVM-wide filter > factory that is invoked to select a filter for each individual > deserialization operation. > > - Mark From roger.riggs at oracle.com Fri May 7 21:30:30 2021 From: roger.riggs at oracle.com (Roger Riggs) Date: Fri, 7 May 2021 17:30:30 -0400 Subject: New candidate JEP: 415: Context-Specific Deserialization Filters In-Reply-To: <22cbe84e-82f7-d6ff-7a1a-b30a961828a9@zeus.net.au> References: <20210506223707.46CC23E2F2C@eggemoggin.niobe.net> <22cbe84e-82f7-d6ff-7a1a-b30a961828a9@zeus.net.au> Message-ID: Hi Peter, Point noted, but does not address existing production apps dependent on serialization. We've been encouraging developers to use other serialization mechanisms for years. As of JDK 9, JEP 290 can specify a filter on the command line to reject all classes. ?...? "-Djdk.serialFilter=!*" ... Regards, Roger On 5/6/21 8:44 PM, Peter Firmstone wrote: > While I'm not against such a thing, it indicates increasing complexity > in the game of de-serialization whack-a-mole. > > It also suggests people are using Java Serialization to process > un-trusted data. > > I think that Serialization Filter's are a design mistake, we should > just enable the existing Java Serialization to be turned off > completely.? The time spent writing these things should be spent > implementing new Serialization API's. > > A property or command line argument that cannot be changed at runtime > to switch off Java Serialization would be appreciated. > > A new public API for Serialization which includes Object level input > validation and failure atomicity needs to be designed that is suitable > for use with many Serialization protocols. > > Serialization is a public interface, we should start declaring it as > such. > From thihup at gmail.com Sat May 8 18:48:05 2021 From: thihup at gmail.com (Thiago Henrique Hupner) Date: Sat, 8 May 2021 15:48:05 -0300 Subject: Mailing list for JDK Dynalink Message-ID: Hi all. I'd like to know which mailing list is the correct to talk about the JDK Dynalink. Best regards From peter.firmstone at zeus.net.au Fri May 7 22:24:13 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Sat, 8 May 2021 08:24:13 +1000 Subject: New candidate JEP: 415: Context-Specific Deserialization Filters In-Reply-To: References: <20210506223707.46CC23E2F2C@eggemoggin.niobe.net> <22cbe84e-82f7-d6ff-7a1a-b30a961828a9@zeus.net.au> Message-ID: <2467d800-2c2a-d3cd-2cce-209b8df296c2@zeus.net.au> Roger, Can we make properties specified from the command line immutable? So code can't switch it back on again.? It's not much good if code can change a property, there will be no SecurityManager to prevent it from doing so in future. Not trying to sandbox, just want to keep the security holes closed. Thanks, Peter. On 8/05/2021 7:30 am, Roger Riggs wrote: > Hi Peter, > > Point noted, but does not address existing production apps dependent > on serialization. > We've been encouraging developers to use other serialization > mechanisms for years. > > As of JDK 9, JEP 290 can specify a filter on the command line to > reject all classes. > > ?...? "-Djdk.serialFilter=!*" ... > > Regards, Roger > > > On 5/6/21 8:44 PM, Peter Firmstone wrote: >> While I'm not against such a thing, it indicates increasing >> complexity in the game of de-serialization whack-a-mole. >> >> It also suggests people are using Java Serialization to process >> un-trusted data. >> >> I think that Serialization Filter's are a design mistake, we should >> just enable the existing Java Serialization to be turned off >> completely.? The time spent writing these things should be spent >> implementing new Serialization API's. >> >> A property or command line argument that cannot be changed at runtime >> to switch off Java Serialization would be appreciated. >> >> A new public API for Serialization which includes Object level input >> validation and failure atomicity needs to be designed that is >> suitable for use with many Serialization protocols. >> >> Serialization is a public interface, we should start declaring it as >> such. >> > From Alan.Bateman at oracle.com Sun May 9 07:31:16 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 9 May 2021 08:31:16 +0100 Subject: Mailing list for JDK Dynalink In-Reply-To: References: Message-ID: <4f1b7094-f96c-4cb5-1a99-eb7f6fc2e6c4@oracle.com> On 08/05/2021 19:48, Thiago Henrique Hupner wrote: > Hi all. > > I'd like to know which mailing list is the correct to talk > about the JDK Dynalink. > It would have been nashorn-dev originally but more recently core-libs-dev (as Nashorn is no longer bundled with the JDK). -Alan From roger.riggs at oracle.com Mon May 10 17:36:08 2021 From: roger.riggs at oracle.com (Roger Riggs) Date: Mon, 10 May 2021 13:36:08 -0400 Subject: New candidate JEP: 415: Context-Specific Deserialization Filters In-Reply-To: <2467d800-2c2a-d3cd-2cce-209b8df296c2@zeus.net.au> References: <20210506223707.46CC23E2F2C@eggemoggin.niobe.net> <22cbe84e-82f7-d6ff-7a1a-b30a961828a9@zeus.net.au> <2467d800-2c2a-d3cd-2cce-209b8df296c2@zeus.net.au> Message-ID: Hi Peter, There is a set of properties who values are read at startup and cached so changes later do not affect behavior.? The serial filter properties are cached. For example, java.home, user.home, user.dir, user.name, java.library.path, java.io.tmpdir. Regards, Roger On 5/7/21 6:24 PM, Peter Firmstone wrote: > Roger, > > Can we make properties specified from the command line immutable? > > So code can't switch it back on again.? It's not much good if code can > change a property, there will be no SecurityManager to prevent it from > doing so in future. > > Not trying to sandbox, just want to keep the security holes closed. > > Thanks, > > Peter. > > On 8/05/2021 7:30 am, Roger Riggs wrote: >> Hi Peter, >> >> Point noted, but does not address existing production apps dependent >> on serialization. >> We've been encouraging developers to use other serialization >> mechanisms for years. >> >> As of JDK 9, JEP 290 can specify a filter on the command line to >> reject all classes. >> >> ?...? "-Djdk.serialFilter=!*" ... >> >> Regards, Roger >> >> >> On 5/6/21 8:44 PM, Peter Firmstone wrote: >>> While I'm not against such a thing, it indicates increasing >>> complexity in the game of de-serialization whack-a-mole. >>> >>> It also suggests people are using Java Serialization to process >>> un-trusted data. >>> >>> I think that Serialization Filter's are a design mistake, we should >>> just enable the existing Java Serialization to be turned off >>> completely.? The time spent writing these things should be spent >>> implementing new Serialization API's. >>> >>> A property or command line argument that cannot be changed at >>> runtime to switch off Java Serialization would be appreciated. >>> >>> A new public API for Serialization which includes Object level input >>> validation and failure atomicity needs to be designed that is >>> suitable for use with many Serialization protocols. >>> >>> Serialization is a public interface, we should start declaring it as >>> such. >>> >> From peter.firmstone at zeus.net.au Mon May 10 23:00:43 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Tue, 11 May 2021 09:00:43 +1000 Subject: New candidate JEP: 415: Context-Specific Deserialization Filters In-Reply-To: References: <20210506223707.46CC23E2F2C@eggemoggin.niobe.net> <22cbe84e-82f7-d6ff-7a1a-b30a961828a9@zeus.net.au> <2467d800-2c2a-d3cd-2cce-209b8df296c2@zeus.net.au> Message-ID: <6a1a4445-983f-0b53-79b9-ec647de664e6@zeus.net.au> Thanks Roger, That's good to know. Currently we do allow some serialization, but only over authenticated (client and server) encrypted connections, I'll be looking to eliminate serialization altogether in preparation for JEP 411. It would have been easier to have a Permission that determined whether a library was permitted to perform de-serialization, but I realize this isn't the direction that Java's is going in. Regards, Peter. On 11/05/2021 3:36 am, Roger Riggs wrote: > Hi Peter, > > There is a set of properties who values are read at startup and cached > so changes later do not affect behavior.? The serial filter properties > are cached. > > For example, java.home, user.home, user.dir, user.name, > java.library.path, java.io.tmpdir. > > Regards, Roger > > > On 5/7/21 6:24 PM, Peter Firmstone wrote: >> Roger, >> >> Can we make properties specified from the command line immutable? >> >> So code can't switch it back on again.? It's not much good if code >> can change a property, there will be no SecurityManager to prevent it >> from doing so in future. >> >> Not trying to sandbox, just want to keep the security holes closed. >> >> Thanks, >> >> Peter. >> >> On 8/05/2021 7:30 am, Roger Riggs wrote: >>> Hi Peter, >>> >>> Point noted, but does not address existing production apps dependent >>> on serialization. >>> We've been encouraging developers to use other serialization >>> mechanisms for years. >>> >>> As of JDK 9, JEP 290 can specify a filter on the command line to >>> reject all classes. >>> >>> ?...? "-Djdk.serialFilter=!*" ... >>> >>> Regards, Roger >>> >>> >>> On 5/6/21 8:44 PM, Peter Firmstone wrote: >>>> While I'm not against such a thing, it indicates increasing >>>> complexity in the game of de-serialization whack-a-mole. >>>> >>>> It also suggests people are using Java Serialization to process >>>> un-trusted data. >>>> >>>> I think that Serialization Filter's are a design mistake, we should >>>> just enable the existing Java Serialization to be turned off >>>> completely.? The time spent writing these things should be spent >>>> implementing new Serialization API's. >>>> >>>> A property or command line argument that cannot be changed at >>>> runtime to switch off Java Serialization would be appreciated. >>>> >>>> A new public API for Serialization which includes Object level >>>> input validation and failure atomicity needs to be designed that is >>>> suitable for use with many Serialization protocols. >>>> >>>> Serialization is a public interface, we should start declaring it >>>> as such. >>>> >>> > From mark.reinhold at oracle.com Tue May 11 16:53:59 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 11 May 2021 09:53:59 -0700 (PDT) Subject: JEP proposed to target JDK 17: 414: Vector API (Second Incubator) Message-ID: <20210511165359.046CE3E36AA@eggemoggin.niobe.net> The following JEP is proposed to target JDK 17: 414: Vector API (Second Incubator) https://openjdk.java.net/jeps/414 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. 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 Tuesday, 18 May, 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 17. - Mark [1] https://openjdk.java.net/census#jdk [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From jini at zeus.net.au Tue May 11 21:05:31 2021 From: jini at zeus.net.au (jini at zeus.net.au) Date: Wed, 12 May 2021 07:05:31 +1000 Subject: New candidate JEP: 415: Context-Specific Deserialization Filters & JEP 411 In-Reply-To: References: <20210506223707.46CC23E2F2C@eggemoggin.niobe.net> <22cbe84e-82f7-d6ff-7a1a-b30a961828a9@zeus.net.au> <2467d800-2c2a-d3cd-2cce-209b8df296c2@zeus.net.au> Message-ID: HI Roger, You are right, filters help those using existing software because they're unlikely to rewrite it.?? We use TLS connections to protect Java serialization, as a configuration concern, but these will break after JEP 411. So an attacker that wanted to use serialization as an attack vector, would need to be the first to use Java Serialization, in order to first change the System property, then cause the static field ObjectInputFilter.Config.serialFilter to be initialized, which might actually be possible on a system that doesn't use Java Serialization at all, because it leaves serialFilter in an uninitialized state.?? If a SecurityManager is in place, the attacker requires a PropertyPermission and SerializablePermission("serialFilter").?? We currently use the principle of least privilege, so we have a SecurityManager and policies in place, however these will be removed in future due to JEP 411. Any chance we can have SerializablePermission("deserialize")??? I know SecurityManager will be removed, but having the permission would allow us to prevent third party library code from using ObjectInputStream to deserialize. Replacement of Java serialization, as an exercise (when you have the opportunity to modify code): First with your filter parameter to disable serialization: ???? [java] May 11, 2021 4:45:56 PM java.io.ObjectInputFilter$Config lambda$static$0 ???? [java] INFO: Creating serialization filter from !* ???? [java] java.io.InvalidClassException: filter status: REJECTED ???? [java]???? at java.base/java.io.ObjectInputStream.filterCheck(ObjectInputStream.java:1356) ???? [java]???? at java.base/java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1992) ???? [java]???? at java.base/java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1868) ???? [java]???? at java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2161) ???? [java]???? at java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1685) ???? [java]???? at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:499) ???? [java]???? at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:457) ???? [java]???? at org.apache.river.qa.harness.MasterTest.main(MasterTest.java:117) ???? [java] Unexpected exception: ???? [java] java.io.IOException: The pipe is being closed ???? [java]???? at java.base/java.io.FileOutputStream.writeBytes(Native Method) ???? [java]???? at java.base/java.io.FileOutputStream.write(FileOutputStream.java:347) ???? [java]???? at java.base/java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:81) ???? [java]???? at java.base/java.io.BufferedOutputStream.write(BufferedOutputStream.java:127) ???? [java]???? at java.base/java.io.ObjectOutputStream$BlockDataOutputStream.drain(ObjectOutputStream.java:1893) ???? [java]???? at java.base/java.io.ObjectOutputStream$BlockDataOutputStream.setBlockDataMode(ObjectOutputStream.java:1802) ???? [java]???? at java.base/java.io.ObjectOutputStream.writeNonProxyDesc(ObjectOutputStream.java:1295) ???? [java]???? at java.base/java.io.ObjectOutputStream.writeClassDesc(ObjectOutputStream.java:1240) ???? [java]???? at java.base/java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1436) ???? [java]???? at java.base/java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1187) ???? [java]???? at java.base/java.io.ObjectOutputStream.writeFatalException(ObjectOutputStream.java:1609) ???? [java]???? at java.base/java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:356) ???? [java]???? at org.apache.river.qa.harness.MasterHarness.runTestOtherVM(MasterHarness.java:884) ???? [java]???? at org.apache.river.qa.harness.MasterHarness.access$200(MasterHarness.java:123) ???? [java]???? at org.apache.river.qa.harness.MasterHarness$TestRunner.run(MasterHarness.java:617) ???? [java]???? at org.apache.river.qa.harness.MasterHarness.runTests(MasterHarness.java:444) ???? [java]???? at org.apache.river.qa.harness.QARunner.main(QARunner.java:67) Then replacing ObjectInputStream and ObjectOutputStream with Atomic failure input validation equivalent implementations, note how circular links are not supported: ???? [java] May 11, 2021 4:54:50 PM java.io.ObjectInputFilter$Config lambda$static$0 ???? [java] INFO: Creating serialization filter from !* ???? [java] java.io.StreamCorruptedException: Unable to read field: resolver, class java.lang.Object ???? [java] while deserializing an object instance of: org.apache.river.qa.harness.QAConfig ???? [java]???? at org.apache.river.api.io.AtomicMarshalInputStream.readFieldValues(AtomicMarshalInputStream.java:1308) ???? [java]???? at org.apache.river.api.io.AtomicMarshalInputStream.readFields(AtomicMarshalInputStream.java:1200) ???? [java]???? at org.apache.river.api.io.AtomicMarshalInputStream.instantiateAtomicSerialOrDiscard(AtomicMarshalInputStream.java:2792) ???? [java]???? at org.apache.river.api.io.AtomicMarshalInputStream.readNewObject(AtomicMarshalInputStream.java:2536) ???? [java]???? at org.apache.river.api.io.AtomicMarshalInputStream.readNonPrimitiveContent(AtomicMarshalInputStream.java:967) ???? [java]???? at org.apache.river.api.io.AtomicMarshalInputStream.readObject(AtomicMarshalInputStream.java:3026) ???? [java]???? at org.apache.river.api.io.AtomicMarshalInputStream.readObjectOverride(AtomicMarshalInputStream.java:2926) ???? [java]???? at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:490) ???? [java]???? at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:457) ???? [java]???? at org.apache.river.qa.harness.MasterTest.main(MasterTest.java:118) ???? [java] Caused by: java.io.StreamCorruptedException: Unable to read field: config, class java.lang.Object ???? [java] while deserializing an object instance of: org.apache.river.qa.harness.Resolver ???? [java]???? at org.apache.river.api.io.AtomicMarshalInputStream.readFieldValues(AtomicMarshalInputStream.java:1308) ???? [java]???? at org.apache.river.api.io.AtomicMarshalInputStream.readFields(AtomicMarshalInputStream.java:1200) ???? [java]???? at org.apache.river.api.io.AtomicMarshalInputStream.instantiateAtomicSerialOrDiscard(AtomicMarshalInputStream.java:2792) ???? [java]???? at org.apache.river.api.io.AtomicMarshalInputStream.readNewObject(AtomicMarshalInputStream.java:2536) ???? [java]???? at org.apache.river.api.io.AtomicMarshalInputStream.readNonPrimitiveContent(AtomicMarshalInputStream.java:967) ???? [java]???? at org.apache.river.api.io.AtomicMarshalInputStream.readObject(AtomicMarshalInputStream.java:3026) ???? [java]???? at org.apache.river.api.io.AtomicMarshalInputStream.readFieldValues(AtomicMarshalInputStream.java:1268) ???? [java]???? ... 9 more ???? [java] Caused by: org.apache.river.api.io.CircularReferenceException: Circular reference ???? [java]???? at org.apache.river.api.io.AtomicMarshalInputStream.registeredObjectRead(AtomicMarshalInputStream.java:3178) ???? [java]???? at org.apache.river.api.io.AtomicMarshalInputStream.readCyclicReference(AtomicMarshalInputStream.java:1037) ???? [java]???? at org.apache.river.api.io.AtomicMarshalInputStream.readNonPrimitiveContent(AtomicMarshalInputStream.java:991) ???? [java]???? at org.apache.river.api.io.AtomicMarshalInputStream.readObject(AtomicMarshalInputStream.java:3026) ???? [java]???? at org.apache.river.api.io.AtomicMarshalInputStream.readFieldValues(AtomicMarshalInputStream.java:1268) ???? [java]???? ... 15 more Then another circular reference to fix: ???? [java] May 11, 2021 6:10:18 PM java.io.ObjectInputFilter$Config lambda$static$0 ???? [java] INFO: Creating serialization filter from !* ???? [java] java.io.StreamCorruptedException: Unable to read field: td, class java.lang.Object ???? [java] while deserializing an object instance of: org.apache.river.qa.harness.QAConfig ???? [java]???? at org.apache.river.api.io.AtomicMarshalInputStream.readFieldValues(AtomicMarshalInputStream.java:1308) ???? [java]???? at org.apache.river.api.io.AtomicMarshalInputStream.readFields(AtomicMarshalInputStream.java:1200) ???? [java]???? at org.apache.river.api.io.AtomicMarshalInputStream.instantiateAtomicSerialOrDiscard(AtomicMarshalInputStream.java:2792) ???? [java]???? at org.apache.river.api.io.AtomicMarshalInputStream.readNewObject(AtomicMarshalInputStream.java:2536) ???? [java]???? at org.apache.river.api.io.AtomicMarshalInputStream.readNonPrimitiveContent(AtomicMarshalInputStream.java:967) ???? [java]???? at org.apache.river.api.io.AtomicMarshalInputStream.readObject(AtomicMarshalInputStream.java:3026) ???? [java]???? at org.apache.river.api.io.AtomicMarshalInputStream.readObjectOverride(AtomicMarshalInputStream.java:2926) ???? [java]???? at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:490) ???? [java]???? at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:457) ???? [java]???? at org.apache.river.qa.harness.MasterTest.main(MasterTest.java:118) ???? [java] Caused by: java.io.StreamCorruptedException: Unable to read field: config, class java.lang.Object ???? [java] while deserializing an object instance of: org.apache.river.qa.harness.TestDescription ???? [java]???? at org.apache.river.api.io.AtomicMarshalInputStream.readFieldValues(AtomicMarshalInputStream.java:1308) ???? [java]???? at org.apache.river.api.io.AtomicMarshalInputStream.readFields(AtomicMarshalInputStream.java:1200) ???? [java]???? at org.apache.river.api.io.AtomicMarshalInputStream.instantiateAtomicSerialOrDiscard(AtomicMarshalInputStream.java:2792) ???? [java]???? at org.apache.river.api.io.AtomicMarshalInputStream.readNewObject(AtomicMarshalInputStream.java:2536) ???? [java]???? at org.apache.river.api.io.AtomicMarshalInputStream.readNonPrimitiveContent(AtomicMarshalInputStream.java:967) ???? [java]???? at org.apache.river.api.io.AtomicMarshalInputStream.readObject(AtomicMarshalInputStream.java:3026) ???? [java]???? at org.apache.river.api.io.AtomicMarshalInputStream.readFieldValues(AtomicMarshalInputStream.java:1268) ???? [java]???? ... 9 more ???? [java] Caused by: org.apache.river.api.io.CircularReferenceException: Circular reference ???? [java]???? at org.apache.river.api.io.AtomicMarshalInputStream.registeredObjectRead(AtomicMarshalInputStream.java:3178) ???? [java]???? at org.apache.river.api.io.AtomicMarshalInputStream.readCyclicReference(AtomicMarshalInputStream.java:1037) ???? [java]???? at org.apache.river.api.io.AtomicMarshalInputStream.readNonPrimitiveContent(AtomicMarshalInputStream.java:991) ???? [java]???? at org.apache.river.api.io.AtomicMarshalInputStream.readObject(AtomicMarshalInputStream.java:3026) ???? [java]???? at org.apache.river.api.io.AtomicMarshalInputStream.readFieldValues(AtomicMarshalInputStream.java:1268) ???? [java]???? ... 15 more Then something else that uses Java serialization: ???? [java] May 11, 2021 7:21:20 PM java.io.ObjectInputFilter$Config lambda$static$0 ???? [java] INFO: Creating serialization filter from !* ???? [java] ???? [java] TIME: 7:21:21 pm ???? [java] ???? [java] MasterTest.doTest INFO: ???? [java] ============================== CALLING CONSTRUCT() ============================== ???? [java] ???? [java] QAConfig.genIntegrityCodebase WARNING: WARNING: file not found for codebase http://DESKTOP-R0ORPA2:9081/nonactivatablegroup-dl.jar in directory C:\Users\peter\Documents\NetBeansProjects\JGDMS\qa\lib, DISCARDING ???? [java] ???? [java] TIME: 7:21:22 pm ???? [java] ???? [java] Test process was destroyed and returned code 1 ???? [java] org/apache/river/test/spec/lookupservice/test_set02/LeaseMapRenew.td ???? [java] Test Failed: Construct Failed: org.apache.river.qa.harness.TestException: Problem creating service for net.jini.core.lookup.ServiceRegistrar; nested exception is: ???? [java]???? Failed to start the shared nonactivatable group; nested exception is: ???? [java]???? NonActivatableGroupAdmin: Failed to exec the group; nested exception is: ???? [java]???? filter status: REJECTED Then another use of Java Serialization: ? [java] May 11, 2021 7:55:09 PM java.io.ObjectInputFilter$Config lambda$static$0 ???? [java] INFO: Creating serialization filter from !* ???? [java] ???? [java] TIME: 7:55:09 pm ???? [java] ???? [java] MasterTest.doTest INFO: ???? [java] ============================== CALLING CONSTRUCT() ============================== ???? [java] ???? [java] QAConfig.genIntegrityCodebase WARNING: WARNING: file not found for codebase http://DESKTOP-R0ORPA2:9081/nonactivatablegroup-dl.jar in directory C:\Users\peter\Documents\NetBeansProjects\JGDMS\qa\lib, DISCARDING ???? [java] NonActGrp-out: May 11, 2021 7:55:11 PM java.io.ObjectInputFilter$Config lambda$static$0 ???? [java] NonActGrp-out: INFO: Creating serialization filter from !* ???? [java] org.apache.river.qa.harness.TestException: Problem creating service for net.jini.core.lookup.ServiceRegistrar; nested exception is: ???? [java]???? RemoteException in server thread; nested exception is: ???? [java]???? java.rmi.RemoteException: Create failed; nested exception is: ???? [java]???? java.io.InvalidClassException: filter status: REJECTED ???? [java]???? at org.apache.river.qa.harness.NonActivatableServiceStarterAdmin.start(NonActivatableServiceStarterAdmin.java:157) ???? [java]???? at org.apache.river.qa.harness.AdminManager.startService(AdminManager.java:639) ???? [java]???? at org.apache.river.qa.harness.AdminManager.startService(AdminManager.java:660) ???? [java]???? at org.apache.river.qa.harness.AdminManager.startLookupService(AdminManager.java:679) ???? [java]???? at org.apache.river.test.spec.lookupservice.QATestRegistrar.construct(QATestRegistrar.java:468) ???? [java]???? at org.apache.river.test.spec.lookupservice.test_set02.LeaseMapRenew.construct(LeaseMapRenew.java:113) ???? [java]???? at org.apache.river.qa.harness.MasterTest.doTest(MasterTest.java:241) ???? [java]???? at org.apache.river.qa.harness.MasterTest.access$000(MasterTest.java:51) ???? [java]???? at org.apache.river.qa.harness.MasterTest$1.run(MasterTest.java:187) ???? [java]???? at java.base/java.security.AccessController.doPrivileged(AccessController.java:391) ???? [java]???? at java.base/javax.security.auth.Subject.doAsPrivileged(Subject.java:486) ???? [java]???? at org.apache.river.qa.harness.MasterTest.doTestWithLogin(MasterTest.java:184) ???? [java]???? at org.apache.river.qa.harness.MasterTest.main(MasterTest.java:163) ???? [java] Caused by: java.rmi.ServerException: RemoteException in server thread; nested exception is: ???? [java]???? java.rmi.RemoteException: Create failed; nested exception is: ???? [java]???? java.io.InvalidClassException: filter status: REJECTED ???? [java]???? at net.jini.jeri.BasicInvocationDispatcher.dispatch(BasicInvocationDispatcher.java:746) ???? [java]???? at net.jini.jeri.AtomicInvocationDispatcher.dispatch(AtomicInvocationDispatcher.java:251) ???? [java]???? at org.apache.river.jeri.internal.runtime.Target$2.run(Target.java:493) ???? [java]???? at net.jini.export.ServerContext.doWithServerContext(ServerContext.java:113) ???? [java]???? at org.apache.river.jeri.internal.runtime.Target.dispatch(Target.java:490) ???? [java]???? at org.apache.river.jeri.internal.runtime.Target.access$000(Target.java:57) ???? [java]???? at org.apache.river.jeri.internal.runtime.Target$1.run(Target.java:466) ???? [java]???? at java.security.AccessController.doPrivileged(AccessController.java:691) ???? [java]???? at org.apache.river.jeri.internal.runtime.Target.dispatch(Target.java:463) ???? [java]???? at org.apache.river.jeri.internal.runtime.Target.dispatch(Target.java:428) ???? [java]???? at org.apache.river.jeri.internal.runtime.DgcRequestDispatcher.dispatch(DgcRequestDispatcher.java:207) ???? [java]???? at net.jini.jeri.connection.ServerConnectionManager$Dispatcher.dispatch(ServerConnectionManager.java:147) ???? [java]???? at org.apache.river.jeri.internal.mux.MuxServer$1$1.run(MuxServer.java:247) ???? [java]???? at java.security.AccessController.doPrivileged(AccessController.java:391) ???? [java]???? at org.apache.river.jeri.internal.mux.MuxServer$1.run(MuxServer.java:243) ???? [java]???? at org.apache.river.thread.ThreadPool$Task.run(ThreadPool.java:172) ???? [java]???? at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) ???? [java]???? at java.util.concurrent.FutureTask.run(FutureTask.java:264) ???? [java]???? at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) ???? [java]???? at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630) ???? [java]???? at java.lang.Thread.run(Thread.java:832) ???? [java]???? at org.apache.river.jeri.internal.runtime.Util.__________EXCEPTION_RECEIVED_FROM_SERVER__________(Util.java:113) ???? [java]???? at org.apache.river.jeri.internal.runtime.Util.exceptionReceivedFromServer(Util.java:106) ???? [java]???? at net.jini.jeri.BasicInvocationHandler.unmarshalThrow(BasicInvocationHandler.java:1433) ???? [java]???? at net.jini.jeri.BasicInvocationHandler.invokeRemoteMethodOnce(BasicInvocationHandler.java:914) ???? [java]???? at net.jini.jeri.BasicInvocationHandler.invokeRemoteMethod(BasicInvocationHandler.java:728) ???? [java]???? at net.jini.jeri.BasicInvocationHandler.invoke(BasicInvocationHandler.java:597) ???? [java]???? at net.jini.jeri.AtomicInvocationHandler.invoke(AtomicInvocationHandler.java:315) ???? [java]???? at org.apache.river.qa.harness.$Proxy3.startService(Unknown Source) ???? [java]???? at org.apache.river.qa.harness.NonActivatableServiceStarterAdmin.start(NonActivatableServiceStarterAdmin.java:149) ???? [java]???? ... 12 more ???? [java] Caused by: java.rmi.RemoteException: Create failed; nested exception is: ???? [java]???? java.io.InvalidClassException: filter status: REJECTED ???? [java]???? at org.apache.river.qa.harness.GroupImpl.startService(GroupImpl.java:163) ???? [java]???? at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ???? [java]???? at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ???? [java]???? at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ???? [java]???? at java.lang.reflect.Method.invoke(Method.java:564) ???? [java]???? at net.jini.jeri.BasicInvocationDispatcher.invoke(BasicInvocationDispatcher.java:1288) ???? [java]???? at net.jini.jeri.BasicInvocationDispatcher.dispatch(BasicInvocationDispatcher.java:710) ???? [java]???? at net.jini.jeri.AtomicInvocationDispatcher.dispatch(AtomicInvocationDispatcher.java:251) ???? [java]???? at org.apache.river.jeri.internal.runtime.Target$2.run(Target.java:493) ???? [java]???? at net.jini.export.ServerContext.doWithServerContext(ServerContext.java:113) ???? [java]???? at org.apache.river.jeri.internal.runtime.Target.dispatch(Target.java:490) ???? [java]???? at org.apache.river.jeri.internal.runtime.Target.access$000(Target.java:57) ???? [java]???? at org.apache.river.jeri.internal.runtime.Target$1.run(Target.java:466) ???? [java]???? at java.security.AccessController.doPrivileged(AccessController.java:691) ???? [java]???? at org.apache.river.jeri.internal.runtime.Target.dispatch(Target.java:463) ???? [java]???? at org.apache.river.jeri.internal.runtime.Target.dispatch(Target.java:428) ???? [java]???? at org.apache.river.jeri.internal.runtime.DgcRequestDispatcher.dispatch(DgcRequestDispatcher.java:207) ???? [java]???? at net.jini.jeri.connection.ServerConnectionManager$Dispatcher.dispatch(ServerConnectionManager.java:147) ???? [java]???? at org.apache.river.jeri.internal.mux.MuxServer$1$1.run(MuxServer.java:247) ???? [java]???? at java.security.AccessController.doPrivileged(AccessController.java:391) ???? [java]???? at org.apache.river.jeri.internal.mux.MuxServer$1.run(MuxServer.java:243) ???? [java]???? at org.apache.river.thread.ThreadPool$Task.run(ThreadPool.java:172) ???? [java]???? at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) ???? [java]???? at java.util.concurrent.FutureTask.run(FutureTask.java:264) ???? [java]???? at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) ???? [java]???? at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630) ???? [java]???? at java.lang.Thread.run(Thread.java:832) ???? [java] Caused by: java.io.InvalidClassException: filter status: REJECTED ???? [java]???? at java.io.ObjectInputStream.filterCheck(ObjectInputStream.java:1356) ???? [java]???? at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1992) ???? [java]???? at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1868) ???? [java]???? at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2161) ???? [java]???? at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1685) ???? [java]???? at java.io.ObjectInputStream.readObject(ObjectInputStream.java:499) ???? [java]???? at java.io.ObjectInputStream.readObject(ObjectInputStream.java:457) ???? [java]???? at net.jini.io.MarshalledInstance.get(MarshalledInstance.java:611) ???? [java]???? at net.jini.io.MarshalledInstance.get(MarshalledInstance.java:527) ???? [java]???? at org.apache.river.start.NonActivatableServiceDescriptor.create(NonActivatableServiceDescriptor.java:729) ???? [java]???? at org.apache.river.qa.harness.GroupImpl.doInit(GroupImpl.java:204) ???? [java]???? at org.apache.river.qa.harness.GroupImpl.access$000(GroupImpl.java:47) ???? [java]???? at org.apache.river.qa.harness.GroupImpl$1.run(GroupImpl.java:186) ???? [java]???? at org.apache.river.qa.harness.GroupImpl$1.run(GroupImpl.java:183) ???? [java]???? at java.security.AccessController.doPrivileged(AccessController.java:691) ???? [java]???? at javax.security.auth.Subject.doAsPrivileged(Subject.java:552) ???? [java]???? at org.apache.river.qa.harness.GroupImpl.doInitWithLogin(GroupImpl.java:180) ???? [java]???? at org.apache.river.qa.harness.GroupImpl.startService(GroupImpl.java:154) ???? [java]???? ... 26 more ???? [java] MasterTest.doTest INFO: ???? [java] ============================ CALLING TEARDOWN() ============================= Another use of Java Serialization: ? [java] May 11, 2021 8:01:49 PM java.io.ObjectInputFilter$Config lambda$static$0 ???? [java] INFO: Creating serialization filter from !* ???? [java] ???? [java] TIME: 8:01:50 pm ???? [java] ???? [java] MasterTest.doTest INFO: ???? [java] ============================== CALLING CONSTRUCT() ============================== ???? [java] ???? [java] QAConfig.genIntegrityCodebase WARNING: WARNING: file not found for codebase http://DESKTOP-R0ORPA2:9081/nonactivatablegroup-dl.jar in directory C:\Users\peter\Documents\NetBeansProjects\JGDMS\qa\lib, DISCARDING ???? [java] NonActGrp-out: May 11, 2021 8:01:51 PM java.io.ObjectInputFilter$Config lambda$static$0 ???? [java] NonActGrp-out: INFO: Creating serialization filter from !* ???? [java] MasterTest.doTest INFO: ???? [java] =============================== CALLING RUN() =============================== ???? [java] ???? [java] java.rmi.UnmarshalException: error unmarshalling return; nested exception is: ???? [java]???? java.io.InvalidClassException: filter status: REJECTED ???? [java]???? at org.apache.river.reggie.proxy.RegistrarProxy.lookup(RegistrarProxy.java:173) ???? [java]???? at org.apache.river.test.spec.lookupservice.QATestUtils.doLookup(QATestUtils.java:651) ???? [java]???? at org.apache.river.test.spec.lookupservice.test_set02.LeaseMapRenew.run(LeaseMapRenew.java:189) ???? [java]???? at org.apache.river.qa.harness.MasterTest.doTest(MasterTest.java:277) ???? [java]???? at org.apache.river.qa.harness.MasterTest.access$000(MasterTest.java:51) ???? [java]???? at org.apache.river.qa.harness.MasterTest$1.run(MasterTest.java:187) ???? [java]???? at java.base/java.security.AccessController.doPrivileged(AccessController.java:391) ???? [java]???? at java.base/javax.security.auth.Subject.doAsPrivileged(Subject.java:486) ???? [java]???? at org.apache.river.qa.harness.MasterTest.doTestWithLogin(MasterTest.java:184) ???? [java]???? at org.apache.river.qa.harness.MasterTest.main(MasterTest.java:163) ???? [java] Caused by: java.io.InvalidClassException: filter status: REJECTED ???? [java]???? at java.base/java.io.ObjectInputStream.filterCheck(ObjectInputStream.java:1356) ???? [java]???? at java.base/java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1992) ???? [java]???? at java.base/java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1868) ???? [java]???? at java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2161) ???? [java]???? at java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1685) ???? [java]???? at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:499) ???? [java]???? at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:457) ???? [java]???? at net.jini.io.MarshalledInstance.get(MarshalledInstance.java:611) ???? [java]???? at net.jini.io.MarshalledInstance.get(MarshalledInstance.java:527) ???? [java]???? at net.jini.io.MarshalledInstance.get(MarshalledInstance.java:442) ???? [java]???? at org.apache.river.proxy.MarshalledWrapper.get(MarshalledWrapper.java:217) ???? [java]???? at org.apache.river.reggie.proxy.RegistrarProxy.lookup(RegistrarProxy.java:171) ???? [java]???? ... 9 more ???? [java] ???? [java] TIME: 8:04:28 pm ???? [java] ???? [java] MasterTest.doTest INFO: ???? [java] ============================ CALLING TEARDOWN() ============================= Finally a working test without using Java Serialization: ? [java] May 11, 2021 8:10:33 PM java.io.ObjectInputFilter$Config lambda$static$0 ???? [java] INFO: Creating serialization filter from !* ???? [java] ???? [java] TIME: 8:10:34 pm ???? [java] ???? [java] MasterTest.doTest INFO: ???? [java] ============================== CALLING CONSTRUCT() ============================== ???? [java] ???? [java] QAConfig.genIntegrityCodebase WARNING: WARNING: file not found for codebase http://DESKTOP-R0ORPA2:9081/nonactivatablegroup-dl.jar in directory C:\Users\peter\Documents\NetBeansProjects\JGDMS\qa\lib, DISCARDING ???? [java] NonActGrp-out: May 11, 2021 8:10:35 PM java.io.ObjectInputFilter$Config lambda$static$0 ???? [java] NonActGrp-out: INFO: Creating serialization filter from !* ???? [java] MasterTest.doTest INFO: ???? [java] =============================== CALLING RUN() =============================== ???? [java] ???? [java] ???? [java] TIME: 8:19:13 pm ???? [java] ???? [java] MasterTest.doTest INFO: ???? [java] ============================ CALLING TEARDOWN() ============================= ???? [java] ???? [java] ???? [java] TIME: 8:19:24 pm ???? [java] ???? [java] Test process was destroyed and returned code 0 ???? [java] org/apache/river/test/spec/lookupservice/test_set02/LeaseMapRenew.td ???? [java] Test Passed: OK ???? [java] ???? [java] ???? [java] ----------------------------------------- ???? [java] ???? [java] SUMMARY ================================= ???? [java] ???? [java] org/apache/river/test/spec/lookupservice/test_set02/LeaseMapRenew.td ???? [java] Test Passed: OK ???? [java] ???? [java] ----------------------------------------- On 11/05/2021 3:36 am, Roger Riggs wrote: > Hi Peter, > > There is a set of properties who values are read at startup and cached > so changes later do not affect behavior.? The serial filter properties > are cached. > > For example, java.home, user.home, user.dir, user.name, > java.library.path, java.io.tmpdir. > > Regards, Roger > > > On 5/7/21 6:24 PM, Peter Firmstone wrote: >> Roger, >> >> Can we make properties specified from the command line immutable? >> >> So code can't switch it back on again.? It's not much good if code >> can change a property, there will be no SecurityManager to prevent it >> from doing so in future. >> >> Not trying to sandbox, just want to keep the security holes closed. >> >> Thanks, >> >> Peter. >> >> On 8/05/2021 7:30 am, Roger Riggs wrote: >>> Hi Peter, >>> >>> Point noted, but does not address existing production apps dependent >>> on serialization. >>> We've been encouraging developers to use other serialization >>> mechanisms for years. >>> >>> As of JDK 9, JEP 290 can specify a filter on the command line to >>> reject all classes. >>> >>> ?...? "-Djdk.serialFilter=!*" ... >>> >>> Regards, Roger >>> >>> >>> On 5/6/21 8:44 PM, Peter Firmstone wrote: >>>> While I'm not against such a thing, it indicates increasing >>>> complexity in the game of de-serialization whack-a-mole. >>>> >>>> It also suggests people are using Java Serialization to process >>>> un-trusted data. >>>> >>>> I think that Serialization Filter's are a design mistake, we should >>>> just enable the existing Java Serialization to be turned off >>>> completely.? The time spent writing these things should be spent >>>> implementing new Serialization API's. >>>> >>>> A property or command line argument that cannot be changed at >>>> runtime to switch off Java Serialization would be appreciated. >>>> >>>> A new public API for Serialization which includes Object level >>>> input validation and failure atomicity needs to be designed that is >>>> suitable for use with many Serialization protocols. >>>> >>>> Serialization is a public interface, we should start declaring it >>>> as such. >>>> >>> > -- Regards, Peter Firmstone 0498 286 363 Zeus Project Services Pty Ltd. From stuart.marks at oracle.com Wed May 12 00:45:04 2021 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 11 May 2021 17:45:04 -0700 Subject: Result: New JDK Committer: Ian Graves Message-ID: <3d7d0eb7-f04a-bc4f-5412-118dc68133a1@oracle.com> Voting for Ian Graves (igraves) [1] is now closed. Yes: 36 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. s'marks [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2021-April/005385.html From goetz.lindenmaier at sap.com Wed May 12 13:40:02 2021 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 12 May 2021 13:40:02 +0000 Subject: Resigning as PowerPC/AIX Port Project Lead In-Reply-To: References: Message-ID: Hi Volker, many thanks for initiating and driving the ppc/aix port up to now! And yes, SAP proposes Martin Doerr[1] as new lead of the PowerPC/AIX Port Project [2][3][4]. In the future, SAP will concentrate on supporting linuxppc64le (little endian) in jdk/jdk, jdk17 and jdk11. I.e., SAP will assure best quality by continuously building and testing these repositories. IBM will take the responsibility of the AIX port. The linuxppc64 (big endian) port will be discontinued [5] as it is nowadays superseded by the little endian port. SAP will also terminate its testing efforts of the ppc platforms in OpenJDK 8u [6]. IBM will continue the support of linuxppc64 (le, be) in 8 and 11. Naturally, SAP will always respond to issues raised against the linuxppc64, linuxppc64le or aixppc64 ports in any jdk version with appropriate effort. Best regards, Goetz and Tim [1] http://openjdk.java.net/census#mdoerr [2] http://openjdk.java.net/census#ppc-aix-port [3] http://openjdk.java.net/projects/ppc-aix-port/ [4] https://wiki.openjdk.java.net/display/PPCAIXPort [5] The last releases where SAP tests linuxppc64 will be 11.0.12 and 17. [6] The last release of 8 where SAP tests linuxppc64 and aix will be the July 2021 security update. > -----Original Message----- > From: Volker Simonis > Sent: Wednesday, May 12, 2021 3:26 PM > To: ppc-aix-port-dev ; porters- > dev at openjdk.java.net; discuss at openjdk.java.net > Cc: Dalibor Topic ; Lindenmaier, Goetz > > Subject: Resigning as PowerPC/AIX Port Project Lead > > I hereby resign as PowerPC/AIX Port Project Lead. > > The PowerPC/AIX Port [1] was proposed almost exactly 9 years ago [2]. > It was the first externally contributed, full OpenJDK port and paved > the way for subsequent porting projects like aarch64 and s390. It was > also the beginning of a fruitful cooperation between SAP, IBM and > Oracle who have all contributed to the success of this project. > > While PowerPC and especially AIX can still be seen as "niche" > platforms, the presence of the PowerPC/AIX Port in the OpenJDK main > line has helped to considerably improve and streamline the whole code > base. I hope this mutually beneficial collaboration will continue in > the future and would like to propose Martin Doerr (mdoerr [3]) as new > Project Lead. > > Martin is a true PowerPC/Itanium expert and a real memory model > wizard. He's a long term member of the SAP JVM team, an OpenJDK > Reviewer and a member of the OpenJDK HotSpot and Members Groups [3]. > > In the end, and according to the OpenJDK Bylaws, the Lead of the > sponsoring group (Dalibor Topic from the Porters Group) needs to > assign a new Project Lead [4]. I for myself can't think of any better > candidate and warmly recommend Martin for this position. > > Thank you and best regards, > Volker > > [1] https://wiki.openjdk.java.net/display/PPCAIXPort > [2] http://mail.openjdk.java.net/pipermail/announce/2012- > May/000125.html > [3] http://openjdk.java.net/census#mdoerr > [4] http://openjdk.java.net/bylaws#project-lead From martin.doerr at sap.com Wed May 12 14:00:37 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 12 May 2021 14:00:37 +0000 Subject: AW: Resigning as PowerPC/AIX Port Project Lead In-Reply-To: References: , Message-ID: Hi Volker and G?tz, thank you for all the work you have done regarding the PowerPC/AIX Port! The job was often tough, but you never gave up. It was a great achievement which I?d like to emphasize again. I appreciate the nomination as new lead and I?ll be glad to accept. I?m looking forward to continue the collaboration with IBM/RedHat and Oracle. Best regards, Martin Von: Lindenmaier, Goetz Datum: Mittwoch, 12. Mai 2021 um 15:40 An: Volker Simonis , ppc-aix-port-dev , porters-dev at openjdk.java.net , discuss at openjdk.java.net , Doerr, Martin , jdk-dev , jdk-updates-dev at openjdk.java.net , jdk8u-dev at openjdk.java.net Cc: Dalibor Topic , 'Tim Ellison' Betreff: RE: Resigning as PowerPC/AIX Port Project Lead Hi Volker, many thanks for initiating and driving the ppc/aix port up to now! And yes, SAP proposes Martin Doerr[1] as new lead of the PowerPC/AIX Port Project [2][3][4]. In the future, SAP will concentrate on supporting linuxppc64le (little endian) in jdk/jdk, jdk17 and jdk11. I.e., SAP will assure best quality by continuously building and testing these repositories. IBM will take the responsibility of the AIX port. The linuxppc64 (big endian) port will be discontinued [5] as it is nowadays superseded by the little endian port. SAP will also terminate its testing efforts of the ppc platforms in OpenJDK 8u [6]. IBM will continue the support of linuxppc64 (le, be) in 8 and 11. Naturally, SAP will always respond to issues raised against the linuxppc64, linuxppc64le or aixppc64 ports in any jdk version with appropriate effort. Best regards, Goetz and Tim [1] http://openjdk.java.net/census#mdoerr [2] http://openjdk.java.net/census#ppc-aix-port [3] http://openjdk.java.net/projects/ppc-aix-port/ [4] https://wiki.openjdk.java.net/display/PPCAIXPort [5] The last releases where SAP tests linuxppc64 will be 11.0.12 and 17. [6] The last release of 8 where SAP tests linuxppc64 and aix will be the July 2021 security update. > -----Original Message----- > From: Volker Simonis > Sent: Wednesday, May 12, 2021 3:26 PM > To: ppc-aix-port-dev ; porters- > dev at openjdk.java.net; discuss at openjdk.java.net > Cc: Dalibor Topic ; Lindenmaier, Goetz > > Subject: Resigning as PowerPC/AIX Port Project Lead > > I hereby resign as PowerPC/AIX Port Project Lead. > > The PowerPC/AIX Port [1] was proposed almost exactly 9 years ago [2]. > It was the first externally contributed, full OpenJDK port and paved > the way for subsequent porting projects like aarch64 and s390. It was > also the beginning of a fruitful cooperation between SAP, IBM and > Oracle who have all contributed to the success of this project. > > While PowerPC and especially AIX can still be seen as "niche" > platforms, the presence of the PowerPC/AIX Port in the OpenJDK main > line has helped to considerably improve and streamline the whole code > base. I hope this mutually beneficial collaboration will continue in > the future and would like to propose Martin Doerr (mdoerr [3]) as new > Project Lead. > > Martin is a true PowerPC/Itanium expert and a real memory model > wizard. He's a long term member of the SAP JVM team, an OpenJDK > Reviewer and a member of the OpenJDK HotSpot and Members Groups [3]. > > In the end, and according to the OpenJDK Bylaws, the Lead of the > sponsoring group (Dalibor Topic from the Porters Group) needs to > assign a new Project Lead [4]. I for myself can't think of any better > candidate and warmly recommend Martin for this position. > > Thank you and best regards, > Volker > > [1] https://wiki.openjdk.java.net/display/PPCAIXPort > [2] http://mail.openjdk.java.net/pipermail/announce/2012- > May/000125.html > [3] http://openjdk.java.net/census#mdoerr > [4] http://openjdk.java.net/bylaws#project-lead From dalibor.topic at oracle.com Wed May 12 15:03:19 2021 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 12 May 2021 17:03:19 +0200 Subject: [External] : AW: Resigning as PowerPC/AIX Port Project Lead In-Reply-To: References: Message-ID: <5addb455-5353-e833-c8f7-f35e72f319dc@oracle.com> Hi Volker & team, Thank you all for your efforts on the port, and in particular to Volker for having stepped up as Project Lead and having contributed a lot of effort to make the PowerPC/AIX Port the exemplary porting Project within the Porters Group in terms of its documentation, JEP, and integration into mainline that all the subsequent ports could and did heavily benefit from. In my capacity as the Porters Group Lead, I'll be happy to appoint Martin as the new Project Lead, and to wish him ongoing success. I'll send a separate e-mail to that effect to the ppc-aix-port-dev mailing list, and let the Registrar know about the change. cheers, dalibor topic On 12.05.2021 16:00, Doerr, Martin wrote: > Hi Volker and G?tz, > > thank you for all the work you have done regarding the PowerPC/AIX Port! > > The job was often tough, but you never gave up. It was a great > achievement which I?d like to emphasize again. > > I appreciate the nomination as new lead and I?ll be glad to accept. I?m > looking forward to continue the collaboration with IBM/RedHat and Oracle. > > Best regards, > > Martin > > *Von: *Lindenmaier, Goetz > *Datum: *Mittwoch, 12. Mai 2021 um 15:40 > *An: *Volker Simonis , ppc-aix-port-dev > , porters-dev at openjdk.java.net > , discuss at openjdk.java.net > , Doerr, Martin , > jdk-dev , jdk-updates-dev at openjdk.java.net > , jdk8u-dev at openjdk.java.net > > *Cc: *Dalibor Topic , 'Tim Ellison' > > *Betreff: *RE: Resigning as PowerPC/AIX Port Project Lead > > Hi > > Volker, many thanks for initiating and driving the ppc/aix > port up to now! > > And yes, SAP proposes Martin Doerr[1] as new lead of the > PowerPC/AIX Port Project [2][3][4]. > > In the future, SAP will concentrate on supporting > linuxppc64le (little endian) in jdk/jdk, jdk17 and jdk11. I.e., SAP > will assure best quality by continuously building and testing these > repositories.? IBM will take the responsibility of the AIX port. > > The linuxppc64 (big endian) port will be discontinued [5] as it > is nowadays superseded by the little endian port. SAP will also > terminate its testing efforts of the ppc platforms in OpenJDK 8u [6]. > IBM will continue the support of linuxppc64 (le, be) in 8 and 11. > > Naturally, SAP will always respond to issues raised against the > linuxppc64, linuxppc64le or aixppc64 ports in any jdk version > with appropriate effort. > > Best regards, > Goetz and Tim > > [1] http://openjdk.java.net/census#mdoerr > > [2] http://openjdk.java.net/census#ppc-aix-port > > [3] http://openjdk.java.net/projects/ppc-aix-port/ > > [4] https://wiki.openjdk.java.net/display/PPCAIXPort > > [5] The last releases where SAP tests linuxppc64 will be 11.0.12 and 17. > [6] The last release of 8 where SAP tests linuxppc64 and aix will be > ??? the July 2021 security update. > > > > > > -----Original Message----- > > From: Volker Simonis > > Sent: Wednesday, May 12, 2021 3:26 PM > > To: ppc-aix-port-dev ; porters- > > dev at openjdk.java.net; discuss at openjdk.java.net > > Cc: Dalibor Topic ; Lindenmaier, Goetz > > > > Subject: Resigning as PowerPC/AIX Port Project Lead > > > > I hereby resign as PowerPC/AIX Port Project Lead. > > > > The PowerPC/AIX Port [1] was proposed almost exactly 9 years ago [2]. > > It was the first externally contributed, full OpenJDK port and paved > > the way for subsequent porting projects like aarch64 and s390. It was > > also the beginning of a fruitful cooperation between SAP, IBM and > > Oracle who have all contributed to the success of this project. > > > > While PowerPC and especially AIX can still be seen as "niche" > > platforms, the presence of the PowerPC/AIX Port in the OpenJDK main > > line has helped to considerably improve and streamline the whole code > > base. I hope this mutually beneficial collaboration will continue in > > the future and would like to propose Martin Doerr (mdoerr [3]) as new > > Project Lead. > > > > Martin is a true PowerPC/Itanium expert and a real memory model > > wizard. He's a long term member of the SAP JVM team, an OpenJDK > > Reviewer and a member of the OpenJDK HotSpot and Members Groups [3]. > > > > In the end, and according to the OpenJDK Bylaws, the Lead of the > > sponsoring group (Dalibor Topic from the Porters Group) needs to > > assign a new Project Lead [4]. I for myself can't think of any better > > candidate and warmly recommend Martin for this position. > > > > Thank you and best regards, > > Volker > > > > [1] https://wiki.openjdk.java.net/display/PPCAIXPort > > > [2] http://mail.openjdk.java.net/pipermail/announce/2012- > > > May/000125.html > > [3] http://openjdk.java.net/census#mdoerr > > > [4] http://openjdk.java.net/bylaws#project-lead > > -- 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 roger.riggs at oracle.com Wed May 12 17:45:50 2021 From: roger.riggs at oracle.com (Roger Riggs) Date: Wed, 12 May 2021 13:45:50 -0400 Subject: CFV: New JDK Reviewer: Alexander Matveev In-Reply-To: References: Message-ID: <335aa6d5-3c10-dc79-e169-fe899c8584a5@oracle.com> Vote: Yes On 5/5/21 3:24 PM, Philip Race wrote: > I hereby nominate Alexander Matveev (matvee[1]) to the role of JDK > Project Reviewer. From mark.reinhold at oracle.com Thu May 13 00:13:18 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 12 May 2021 17:13:18 -0700 Subject: JEP proposed to target JDK 17: 409: Sealed Classes In-Reply-To: <20210505221756.55F613E2C15@eggemoggin.niobe.net> References: <20210505221756.55F613E2C15@eggemoggin.niobe.net> Message-ID: <20210512171318.809988801@eggemoggin.niobe.net> 2021/5/5 15:17:56 -0700, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 17: > > 409: Sealed Classes > https://openjdk.java.net/jeps/409 > > Summary: Enhance the Java programming language with sealed classes and > interfaces. Sealed classes and interfaces restrict which other classes > or interfaces may extend or implement them. > > 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, 12 May, 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 17. Hearing no objections, I?ve targeted this JEP to JDK 17. - Mark From ebresie at gmail.com Thu May 13 03:43:37 2021 From: ebresie at gmail.com (Eric Bresie) Date: Wed, 12 May 2021 22:43:37 -0500 Subject: API Deprecated/Removal Process In-Reply-To: 052eb6a2-064f-3843-5a84-c24b78def7ae@zeus.net.au References: 20210326180148.E84233DD70B@eggemoggin.niobe.net b0013f87-4b47-6330-958c-ca861c9df773@zeus.net.au 5ee85ce6-0963-d7a4-44d0-a5547ad938c4@oracle.com 5ee85ce6-0963-d7a4-44d0-a5547ad938c4@oracle.com Message-ID: <4be6b02f-08f2-40e0-bcc7-18a4bb074193@Erics-iPhone-12-Pro-Max> I know the benefits of API / implementation removal accommodates change and efficiency to the platform, which I welcome however the more removals that happen, the more risk this will break existing application code, the risk of additional cost for updating existing developed products (which not everyone may have the budget to do so given much is spent on updating own products and priorities without having to introduce changes like this, which prior to pruning of API was less a concern with Java), and just plain risks leaving a bad taste in developer and user?s mouth which could drive people away, which no one wants. So with that said... What is the process when dealing with deprecated and removed API? Or more specifically use case of alternative implementations? I understand depreciation/removal details are usually document in applicable API content and JEP 277 Enhanced Deprecation (https://openjdk.java.net/jeps/277) provides rational and how to annotate things and denotes the need to utilize new interface if available or to use alternative implementation. So define aspects of handoff activities to include potential donation of deprecated/removed code, forking to the alternative, address licensing concerns, how to handle name-spacing concerns (i.e. is the old namespace available or does new namespace needed), and documenting alternatives (i.e. tracking alternatives via wiki, doc, javadoc/api, etc). Or could some form of dependency injection be used to specify alternatives to ease the transition? Eric Bresie Ebresie at gmail.com (mailto:Ebresie at gmail.com) From dalibor.topic at oracle.com Thu May 13 14:46:25 2021 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Thu, 13 May 2021 16:46:25 +0200 Subject: problematic pkcs11 license In-Reply-To: References: Message-ID: Hi Matthias, I would suggest to bring up licensing concerns about OASIS headers to the OASIS PKCS 11 TC directly, which is co-chaired by Red Hat, afaict from https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=pkcs11 . The issue of concerns seems to come up very rarely on the TC mailing list, as far as I can tell from threads like http://markmail.org/message/4juvugfvj45iyrmp . But I think they would be in a much better position to clarify the aspects Debian has an issue with than I could, for example. cheers, dalibor topic On 27.04.2021 08:33, Matthias Klose wrote: > A Debian issue points out a problematic license for some imported header files, > see https://bugs.debian.org/985765, and also https://bugs.debian.org/952951 > pointing out the issue with the OASIS license. > > The header files currently have > > /* Copyright (c) OASIS Open 2016-2019. All Rights Reserved. > * Distributed under the terms of the OASIS IPR Policy, > * [http://www.oasis-open.org/policies-guidelines/ipr], AS-IS, WITHOUT ANY > * IMPLIED OR EXPRESS WARRANTY; there is no warranty of MERCHANTABILITY, FITNESS > FOR A > * PARTICULAR PURPOSE or NONINFRINGEMENT of the rights of others. > */ > > The proposed alternative headers from NSS (which is already used as a build > dependency for OpenJDK), have: > > /* This Source Code Form is subject to the terms of the Mozilla Public > * License, v. 2.0. If a copy of the MPL was not distributed with this > * file, You can obtain one at http://mozilla.org/MPL/2.0/. */ > /* > * Copyright (C) 1994-1999 RSA Security Inc. Licence to copy this document > * is granted provided that it is identified as "RSA Security In.c Public-Key > * Cryptography Standards (PKCS)" in all material mentioning or referencing > * this document. > * > * The latest version of this header can be found at: > * http://www.rsalabs.com/pkcs/pkcs-11/index.html > */ > > Is this something which could be addressed upstream? Which group to contact? > > Thanks, Matthias > -- 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 alexander.zvegintsev at oracle.com Thu May 13 15:17:45 2021 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Thu, 13 May 2021 17:17:45 +0200 Subject: CFV: New JDK Committer: Alexey Ushakov (avu) In-Reply-To: References: Message-ID: Vote: yes -- Thanks, Alexander. On 29/04/2021 21:02, Philip Race wrote: > I hereby nominate Alexey Ushakov (avu [1]) to JDK Committer > > Alexey is a previous member of the Java 2D team at Sun Microsystems > and contributed > to OpenJDK even before it existed - notably adopting LittleCMS as the > open source > color management engine for OpenJDK as part of Sun's effort to provide > open source > replacements for proprietary code. > > Since returning to work on OpenJDK he has been a major contributor to > JEP 382 [2] (New macOS Rendering Pipeline) and is listed [3] a > co-author of that work, > and additionally has made an additional 9 contributions beyond that, > enumerated below. > > git log --author avu --format='%h %s' > 155da257fd9 8265005: Introduce the new client property for mac: > apple.awt.windowTitleVisible > 3bf4c904fbb 8264317: Lanai: IncorrectUnmanagedImageRotatedClip.java > fails on apple M1 > 714ae54f91d 8258788: incorrect response to change in window insets > [lanai] > a4905bae9b2 8226654: Some swing gtk regression tests fail with > "java.lang.InternalError: Unable to load native GTK librarie > c3b47e556e2 8213292: Input freezes after MacOS key-selector > (press&hold) usage on macOS Mojave > 10ef2cd87ca 8197499: RepaintManager does not increase double buffer > after attaching a device with higher resolution > af683a251d0 8158495: CCE: sun.java2d.NullSurfaceData cannot be cast to > sun.java2d.opengl.OGLSurfaceData > 3476a78bab8 7172749: Xrender: Class cast exception in 2D code running > an AWT regression test > 7f2828e070a 6733501: Apply IcedTea little cms patches > > git log --author alexey.ushakov --format='%h %s' > 164537ebd4b 8147542: ClassCastException when repainting after display > resolution change > > > Votes are due by 2021-05-13 19:05 UTC. > > Only current JDK Committers [4] 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 [5]. > > -phil. > > > > [1] https://openjdk.java.net/census#avu > > [2] http://openjdk.java.net/jeps/382 > > [3] commit 8afec70c283ee549795996031e3a53a3212bf35a > Author: Ajit Ghaisas > Date:?? Mon Mar 15 06:41:44 2021 +0000 > > ??? 8260931: Implement JEP 382: New macOS Rendering Pipeline > ??? ??? Co-authored-by: Jayathirth D V > ??? Co-authored-by: Alexey Ushakov > ??? Co-authored-by: Artem Bochkarev > ??? Co-authored-by: Prasanta Sadhukhan > ??? Co-authored-by: Denis Konoplev > ??? Co-authored-by: Phil Race > ??? Co-authored-by: Kevin Rushforth > ??? Co-authored-by: Magnus Ihse Bursie > ??? Co-authored-by: Ajit Ghaisas > ??? Reviewed-by: ihse, avu, kcr, gziemski, prr, kizune, jdv, > psadhukhan, serb > > [4]https://openjdk.java.net/census#jdk > > [5]https://openjdk.java.net/projects/#committer-vote > From paul.sandoz at oracle.com Thu May 13 15:38:34 2021 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 13 May 2021 15:38:34 +0000 Subject: CFV: New JDK Reviewer: Sandhya Viswanathan Message-ID: <7EDAB0F3-8A7A-45F1-A8E3-6A5069DC2471@oracle.com> I hereby nominate Sandhya Viswanathan (sviswanathan)[0] to JDK Reviewer. Sandhya is a long time contributor to OpenJDK, and has extensive experience of x86 platforms, making numerous improvements to HotSpot's code generation. Overall Sandhya has 32 commits to the mainline JDK [3]. Some of those commits reflect involvement in JEPs (JEP-338, JEP-333 and JEP-254), particularly JEP 338: Vector API (Incubator), where Sandhya is a key participant [4] in the effort to bring SIMD programming to Java. Votes are due by Thursday, the 27th of May, 2021. Only current OpenJDK Reviewers (and above) [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]. Paul. [0] https://openjdk.java.net/census#sviswanathan https://github.com/sviswa7 [1] https://openjdk.java.net/census#jdk [2] http://openjdk.java.net/projects/#reviewer-vote [3] https://github.com/openjdk/jdk/search?o=desc&q=merge%3Afalse+author-name%3A%22Sandhya+Viswanathan%22&s=committer-date&type=commits https://github.com/openjdk/jdk/search?q=merge%3Afalse+%22Sandhya+Viswanathan%22&type=commits [4] https://github.com/openjdk/panama-vector/search?o=desc&q=merge%3Afalse+author-name%3A%22Sandhya+Viswanathan%22&s=committer-date&type=commits http://hg.openjdk.java.net/panama/dev/search/?rev=author%28sviswanathan%29%20and%20branch%28vectorIntrinsics%29%20and%20not%20merge%28%29&revcount=52 From vladimir.kozlov at oracle.com Thu May 13 15:47:46 2021 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 13 May 2021 08:47:46 -0700 Subject: CFV: New JDK Reviewer: Sandhya Viswanathan In-Reply-To: <7EDAB0F3-8A7A-45F1-A8E3-6A5069DC2471@oracle.com> References: <7EDAB0F3-8A7A-45F1-A8E3-6A5069DC2471@oracle.com> Message-ID: <27816b1f-0197-0f83-9c4d-b451a39405ea@oracle.com> Vote, yes Definitely! Sandhya, as member of Intel's Java group, worked with us since Sun Microsystems. She knows HotSpot very well. Thanks, Vladimir K On 5/13/21 8:38 AM, Paul Sandoz wrote: > I hereby nominate Sandhya Viswanathan (sviswanathan)[0] to JDK Reviewer. > > Sandhya is a long time contributor to OpenJDK, and has extensive experience of x86 platforms, making numerous improvements to HotSpot's code generation. > > Overall Sandhya has 32 commits to the mainline JDK [3]. Some of those commits reflect involvement in JEPs (JEP-338, JEP-333 and JEP-254), particularly JEP 338: Vector API (Incubator), where Sandhya is a key participant [4] in the effort to bring SIMD programming to Java. > > Votes are due by Thursday, the 27th of May, 2021. > > Only current OpenJDK Reviewers (and above) [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]. > > Paul. > > > [0] https://openjdk.java.net/census#sviswanathan > https://github.com/sviswa7 > [1] https://openjdk.java.net/census#jdk > [2] http://openjdk.java.net/projects/#reviewer-vote > > [3] > https://github.com/openjdk/jdk/search?o=desc&q=merge%3Afalse+author-name%3A%22Sandhya+Viswanathan%22&s=committer-date&type=commits > https://github.com/openjdk/jdk/search?q=merge%3Afalse+%22Sandhya+Viswanathan%22&type=commits > > [4] > https://github.com/openjdk/panama-vector/search?o=desc&q=merge%3Afalse+author-name%3A%22Sandhya+Viswanathan%22&s=committer-date&type=commits > http://hg.openjdk.java.net/panama/dev/search/?rev=author%28sviswanathan%29%20and%20branch%28vectorIntrinsics%29%20and%20not%20merge%28%29&revcount=52 > From adinn at redhat.com Thu May 13 15:49:56 2021 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 13 May 2021 16:49:56 +0100 Subject: CFV: New JDK Reviewer: Sandhya Viswanathan In-Reply-To: <7EDAB0F3-8A7A-45F1-A8E3-6A5069DC2471@oracle.com> References: <7EDAB0F3-8A7A-45F1-A8E3-6A5069DC2471@oracle.com> Message-ID: <683ba198-b810-77cd-3f4a-4958fec533e5@redhat.com> Vote: yes On 13/05/2021 16:38, Paul Sandoz wrote: > I hereby nominate Sandhya Viswanathan (sviswanathan)[0] to JDK Reviewer. > > Sandhya is a long time contributor to OpenJDK, and has extensive experience of x86 platforms, making numerous improvements to HotSpot's code generation. > > Overall Sandhya has 32 commits to the mainline JDK [3]. Some of those commits reflect involvement in JEPs (JEP-338, JEP-333 and JEP-254), particularly JEP 338: Vector API (Incubator), where Sandhya is a key participant [4] in the effort to bring SIMD programming to Java. > > Votes are due by Thursday, the 27th of May, 2021. > > Only current OpenJDK Reviewers (and above) [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]. > > Paul. > > > [0] https://openjdk.java.net/census#sviswanathan > https://github.com/sviswa7 > [1] https://openjdk.java.net/census#jdk > [2] http://openjdk.java.net/projects/#reviewer-vote > > [3] > https://github.com/openjdk/jdk/search?o=desc&q=merge%3Afalse+author-name%3A%22Sandhya+Viswanathan%22&s=committer-date&type=commits > https://github.com/openjdk/jdk/search?q=merge%3Afalse+%22Sandhya+Viswanathan%22&type=commits > > [4] > https://github.com/openjdk/panama-vector/search?o=desc&q=merge%3Afalse+author-name%3A%22Sandhya+Viswanathan%22&s=committer-date&type=commits > http://hg.openjdk.java.net/panama/dev/search/?rev=author%28sviswanathan%29%20and%20branch%28vectorIntrinsics%29%20and%20not%20merge%28%29&revcount=52 > -- 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 paul.sandoz at oracle.com Thu May 13 15:55:12 2021 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 13 May 2021 15:55:12 +0000 Subject: CFV: New JDK Reviewer: Sandhya Viswanathan In-Reply-To: <7EDAB0F3-8A7A-45F1-A8E3-6A5069DC2471@oracle.com> References: <7EDAB0F3-8A7A-45F1-A8E3-6A5069DC2471@oracle.com> Message-ID: Vote: yes Paul. From hohensee at amazon.com Thu May 13 15:57:28 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 13 May 2021 15:57:28 +0000 Subject: CFV: New JDK Reviewer: Sandhya Viswanathan Message-ID: Vote: yes ?-----Original Message----- From: jdk-dev on behalf of Paul Sandoz Date: Thursday, May 13, 2021 at 8:39 AM To: jdk-dev Subject: CFV: New JDK Reviewer: Sandhya Viswanathan I hereby nominate Sandhya Viswanathan (sviswanathan)[0] to JDK Reviewer. Sandhya is a long time contributor to OpenJDK, and has extensive experience of x86 platforms, making numerous improvements to HotSpot's code generation. Overall Sandhya has 32 commits to the mainline JDK [3]. Some of those commits reflect involvement in JEPs (JEP-338, JEP-333 and JEP-254), particularly JEP 338: Vector API (Incubator), where Sandhya is a key participant [4] in the effort to bring SIMD programming to Java. Votes are due by Thursday, the 27th of May, 2021. Only current OpenJDK Reviewers (and above) [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]. Paul. [0] https://openjdk.java.net/census#sviswanathan https://github.com/sviswa7 [1] https://openjdk.java.net/census#jdk [2] http://openjdk.java.net/projects/#reviewer-vote [3] https://github.com/openjdk/jdk/search?o=desc&q=merge%3Afalse+author-name%3A%22Sandhya+Viswanathan%22&s=committer-date&type=commits https://github.com/openjdk/jdk/search?q=merge%3Afalse+%22Sandhya+Viswanathan%22&type=commits [4] https://github.com/openjdk/panama-vector/search?o=desc&q=merge%3Afalse+author-name%3A%22Sandhya+Viswanathan%22&s=committer-date&type=commits http://hg.openjdk.java.net/panama/dev/search/?rev=author%28sviswanathan%29%20and%20branch%28vectorIntrinsics%29%20and%20not%20merge%28%29&revcount=52 From adinn at redhat.com Thu May 13 09:32:17 2021 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 13 May 2021 10:32:17 +0100 Subject: [External] : AW: Resigning as PowerPC/AIX Port Project Lead In-Reply-To: <5addb455-5353-e833-c8f7-f35e72f319dc@oracle.com> References: <5addb455-5353-e833-c8f7-f35e72f319dc@oracle.com> Message-ID: Hi Volker, Dalibor et al, I'd very much like to second and amplify Dalibor's message. Integration of the PowerPC/AIX Port into OpenJDK paved the way for subsequent merging of the AArch64 port. The smoothness of that latter integration is clear evidence of how good and how thorough a job Volker and his team did. Many thanks for all your hard work, Volker! 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 On 12/05/2021 16:03, Dalibor Topic wrote: > Hi Volker & team, > > Thank you all for your efforts on the port, and in particular to Volker > for having stepped up as Project Lead and having contributed a lot of > effort to make the PowerPC/AIX Port the exemplary porting Project within > the Porters Group in terms of its documentation, JEP, and integration > into mainline that all the subsequent ports could and did heavily > benefit from. > > In my capacity as the Porters Group Lead, I'll be happy to appoint > Martin as the new Project Lead, and to wish him ongoing success. > > I'll send a separate e-mail to that effect to the ppc-aix-port-dev > mailing list, and let the Registrar know about the change. > > cheers, > dalibor topic > > On 12.05.2021 16:00, Doerr, Martin wrote: >> Hi Volker and G?tz, >> >> thank you for all the work you have done regarding the PowerPC/AIX Port! >> >> The job was often tough, but you never gave up. It was a great >> achievement which I?d like to emphasize again. >> >> I appreciate the nomination as new lead and I?ll be glad to accept. >> I?m looking forward to continue the collaboration with IBM/RedHat and >> Oracle. >> >> Best regards, >> >> Martin >> >> *Von: *Lindenmaier, Goetz >> *Datum: *Mittwoch, 12. Mai 2021 um 15:40 >> *An: *Volker Simonis , ppc-aix-port-dev >> , porters-dev at openjdk.java.net >> , discuss at openjdk.java.net >> , Doerr, Martin , >> jdk-dev , jdk-updates-dev at openjdk.java.net >> , jdk8u-dev at openjdk.java.net >> >> *Cc: *Dalibor Topic , 'Tim Ellison' >> >> *Betreff: *RE: Resigning as PowerPC/AIX Port Project Lead >> >> Hi >> >> Volker, many thanks for initiating and driving the ppc/aix >> port up to now! >> >> And yes, SAP proposes Martin Doerr[1] as new lead of the >> PowerPC/AIX Port Project [2][3][4]. >> >> In the future, SAP will concentrate on supporting >> linuxppc64le (little endian) in jdk/jdk, jdk17 and jdk11. I.e., SAP >> will assure best quality by continuously building and testing these >> repositories.? IBM will take the responsibility of the AIX port. >> >> The linuxppc64 (big endian) port will be discontinued [5] as it >> is nowadays superseded by the little endian port. SAP will also >> terminate its testing efforts of the ppc platforms in OpenJDK 8u [6]. >> IBM will continue the support of linuxppc64 (le, be) in 8 and 11. >> >> Naturally, SAP will always respond to issues raised against the >> linuxppc64, linuxppc64le or aixppc64 ports in any jdk version >> with appropriate effort. >> >> Best regards, >> Goetz and Tim >> >> [1] http://openjdk.java.net/census#mdoerr >> >> [2] http://openjdk.java.net/census#ppc-aix-port >> >> [3] http://openjdk.java.net/projects/ppc-aix-port/ >> >> [4] https://wiki.openjdk.java.net/display/PPCAIXPort >> >> [5] The last releases where SAP tests linuxppc64 will be 11.0.12 and 17. >> [6] The last release of 8 where SAP tests linuxppc64 and aix will be >> ???? the July 2021 security update. >> >> >> >> >> ?> -----Original Message----- >> ?> From: Volker Simonis >> ?> Sent: Wednesday, May 12, 2021 3:26 PM >> ?> To: ppc-aix-port-dev ; porters- >> ?> dev at openjdk.java.net; discuss at openjdk.java.net >> ?> Cc: Dalibor Topic ; Lindenmaier, Goetz >> ?> >> ?> Subject: Resigning as PowerPC/AIX Port Project Lead >> ?> >> ?> I hereby resign as PowerPC/AIX Port Project Lead. >> ?> >> ?> The PowerPC/AIX Port [1] was proposed almost exactly 9 years ago [2]. >> ?> It was the first externally contributed, full OpenJDK port and paved >> ?> the way for subsequent porting projects like aarch64 and s390. It was >> ?> also the beginning of a fruitful cooperation between SAP, IBM and >> ?> Oracle who have all contributed to the success of this project. >> ?> >> ?> While PowerPC and especially AIX can still be seen as "niche" >> ?> platforms, the presence of the PowerPC/AIX Port in the OpenJDK main >> ?> line has helped to considerably improve and streamline the whole code >> ?> base. I hope this mutually beneficial collaboration will continue in >> ?> the future and would like to propose Martin Doerr (mdoerr [3]) as new >> ?> Project Lead. >> ?> >> ?> Martin is a true PowerPC/Itanium expert and a real memory model >> ?> wizard. He's a long term member of the SAP JVM team, an OpenJDK >> ?> Reviewer and a member of the OpenJDK HotSpot and Members Groups [3]. >> ?> >> ?> In the end, and according to the OpenJDK Bylaws, the Lead of the >> ?> sponsoring group (Dalibor Topic from the Porters Group) needs to >> ?> assign a new Project Lead [4]. I for myself can't think of any better >> ?> candidate and warmly recommend Martin for this position. >> ?> >> ?> Thank you and best regards, >> ?> Volker >> ?> >> ?> [1] https://wiki.openjdk.java.net/display/PPCAIXPort >> >> ?> [2] http://mail.openjdk.java.net/pipermail/announce/2012- >> >> ?> May/000125.html >> ?> [3] http://openjdk.java.net/census#mdoerr >> >> ?> [4] http://openjdk.java.net/bylaws#project-lead >> >> > From jesper.wilhelmsson at oracle.com Thu May 13 16:33:45 2021 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 13 May 2021 18:33:45 +0200 Subject: CFV: New JDK Reviewer: Sandhya Viswanathan In-Reply-To: <7EDAB0F3-8A7A-45F1-A8E3-6A5069DC2471@oracle.com> References: <7EDAB0F3-8A7A-45F1-A8E3-6A5069DC2471@oracle.com> Message-ID: <4B1DBAF6-F000-4B6A-93D4-97CC022395BA@oracle.com> Vote: Yes /Jesper > On 13 May 2021, at 17:38, Paul Sandoz wrote: > > I hereby nominate Sandhya Viswanathan (sviswanathan)[0] to JDK Reviewer. > > Sandhya is a long time contributor to OpenJDK, and has extensive experience of x86 platforms, making numerous improvements to HotSpot's code generation. > > Overall Sandhya has 32 commits to the mainline JDK [3]. Some of those commits reflect involvement in JEPs (JEP-338, JEP-333 and JEP-254), particularly JEP 338: Vector API (Incubator), where Sandhya is a key participant [4] in the effort to bring SIMD programming to Java. > > Votes are due by Thursday, the 27th of May, 2021. > > Only current OpenJDK Reviewers (and above) [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]. > > Paul. > > > [0] https://openjdk.java.net/census#sviswanathan > https://github.com/sviswa7 > [1] https://openjdk.java.net/census#jdk > [2] http://openjdk.java.net/projects/#reviewer-vote > > [3] > https://github.com/openjdk/jdk/search?o=desc&q=merge%3Afalse+author-name%3A%22Sandhya+Viswanathan%22&s=committer-date&type=commits > https://github.com/openjdk/jdk/search?q=merge%3Afalse+%22Sandhya+Viswanathan%22&type=commits > > [4] > https://github.com/openjdk/panama-vector/search?o=desc&q=merge%3Afalse+author-name%3A%22Sandhya+Viswanathan%22&s=committer-date&type=commits > http://hg.openjdk.java.net/panama/dev/search/?rev=author%28sviswanathan%29%20and%20branch%28vectorIntrinsics%29%20and%20not%20merge%28%29&revcount=52 From chris.hegarty at oracle.com Thu May 13 16:40:52 2021 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 13 May 2021 16:40:52 +0000 Subject: CFV: New JDK Reviewer: Sandhya Viswanathan In-Reply-To: <7EDAB0F3-8A7A-45F1-A8E3-6A5069DC2471@oracle.com> References: <7EDAB0F3-8A7A-45F1-A8E3-6A5069DC2471@oracle.com> Message-ID: Vote: YES -Chris. > On 13 May 2021, at 16:38, Paul Sandoz wrote: > > I hereby nominate Sandhya Viswanathan (sviswanathan)[0] to JDK Reviewer. From lois.foltan at oracle.com Thu May 13 17:00:29 2021 From: lois.foltan at oracle.com (Lois Foltan) Date: Thu, 13 May 2021 13:00:29 -0400 Subject: CFV: New JDK Reviewer: Sandhya Viswanathan In-Reply-To: <7EDAB0F3-8A7A-45F1-A8E3-6A5069DC2471@oracle.com> References: <7EDAB0F3-8A7A-45F1-A8E3-6A5069DC2471@oracle.com> Message-ID: <7f94c4c7-b6dc-42b6-9b10-814ea050c184@oracle.com> Vote: yes Lois On 5/13/2021 11:38 AM, Paul Sandoz wrote: > I hereby nominate Sandhya Viswanathan (sviswanathan)[0] to JDK Reviewer. > > Sandhya is a long time contributor to OpenJDK, and has extensive experience of x86 platforms, making numerous improvements to HotSpot's code generation. > > Overall Sandhya has 32 commits to the mainline JDK [3]. Some of those commits reflect involvement in JEPs (JEP-338, JEP-333 and JEP-254), particularly JEP 338: Vector API (Incubator), where Sandhya is a key participant [4] in the effort to bring SIMD programming to Java. > > Votes are due by Thursday, the 27th of May, 2021. > > Only current OpenJDK Reviewers (and above) [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]. > > Paul. > > > [0] https://openjdk.java.net/census#sviswanathan > https://github.com/sviswa7 > [1] https://openjdk.java.net/census#jdk > [2] http://openjdk.java.net/projects/#reviewer-vote > > [3] > https://github.com/openjdk/jdk/search?o=desc&q=merge%3Afalse+author-name%3A%22Sandhya+Viswanathan%22&s=committer-date&type=commits > https://github.com/openjdk/jdk/search?q=merge%3Afalse+%22Sandhya+Viswanathan%22&type=commits > > [4] > https://github.com/openjdk/panama-vector/search?o=desc&q=merge%3Afalse+author-name%3A%22Sandhya+Viswanathan%22&s=committer-date&type=commits > http://hg.openjdk.java.net/panama/dev/search/?rev=author%28sviswanathan%29%20and%20branch%28vectorIntrinsics%29%20and%20not%20merge%28%29&revcount=52 From vladimir.x.ivanov at oracle.com Thu May 13 17:08:22 2021 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 13 May 2021 20:08:22 +0300 Subject: CFV: New JDK Reviewer: Sandhya Viswanathan In-Reply-To: <7EDAB0F3-8A7A-45F1-A8E3-6A5069DC2471@oracle.com> References: <7EDAB0F3-8A7A-45F1-A8E3-6A5069DC2471@oracle.com> Message-ID: <47f3a9b0-e45b-0d48-ef95-ee8768226cf5@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 13.05.2021 18:38, Paul Sandoz wrote: > I hereby nominate Sandhya Viswanathan (sviswanathan)[0] to JDK Reviewer. From daniel.fuchs at oracle.com Thu May 13 17:17:50 2021 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 13 May 2021 18:17:50 +0100 Subject: CFV: New JDK Reviewer: Sandhya Viswanathan In-Reply-To: <7EDAB0F3-8A7A-45F1-A8E3-6A5069DC2471@oracle.com> References: <7EDAB0F3-8A7A-45F1-A8E3-6A5069DC2471@oracle.com> Message-ID: Vote: yes best regards, -- daniel On 13/05/2021 16:38, Paul Sandoz wrote: > I hereby nominate Sandhya Viswanathan (sviswanathan)[0] to JDK Reviewer. From brian.goetz at oracle.com Thu May 13 17:32:48 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 13 May 2021 13:32:48 -0400 Subject: CFV: New JDK Reviewer: Sandhya Viswanathan In-Reply-To: <7EDAB0F3-8A7A-45F1-A8E3-6A5069DC2471@oracle.com> References: <7EDAB0F3-8A7A-45F1-A8E3-6A5069DC2471@oracle.com> Message-ID: <1df324ee-0c5d-2aeb-5a13-fdad1089536d@oracle.com> Vote: Yes On 5/13/2021 11:38 AM, Paul Sandoz wrote: > I hereby nominate Sandhya Viswanathan (sviswanathan)[0] to JDK Reviewer. > > Sandhya is a long time contributor to OpenJDK, and has extensive experience of x86 platforms, making numerous improvements to HotSpot's code generation. > > Overall Sandhya has 32 commits to the mainline JDK [3]. Some of those commits reflect involvement in JEPs (JEP-338, JEP-333 and JEP-254), particularly JEP 338: Vector API (Incubator), where Sandhya is a key participant [4] in the effort to bring SIMD programming to Java. > > Votes are due by Thursday, the 27th of May, 2021. > > Only current OpenJDK Reviewers (and above) [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]. > > Paul. > > > [0] https://openjdk.java.net/census#sviswanathan > https://github.com/sviswa7 > [1] https://openjdk.java.net/census#jdk > [2] http://openjdk.java.net/projects/#reviewer-vote > > [3] > https://github.com/openjdk/jdk/search?o=desc&q=merge%3Afalse+author-name%3A%22Sandhya+Viswanathan%22&s=committer-date&type=commits > https://github.com/openjdk/jdk/search?q=merge%3Afalse+%22Sandhya+Viswanathan%22&type=commits > > [4] > https://github.com/openjdk/panama-vector/search?o=desc&q=merge%3Afalse+author-name%3A%22Sandhya+Viswanathan%22&s=committer-date&type=commits > http://hg.openjdk.java.net/panama/dev/search/?rev=author%28sviswanathan%29%20and%20branch%28vectorIntrinsics%29%20and%20not%20merge%28%29&revcount=52 From harold.seigel at oracle.com Thu May 13 17:38:29 2021 From: harold.seigel at oracle.com (Harold Seigel) Date: Thu, 13 May 2021 13:38:29 -0400 Subject: CFV: New JDK Reviewer: Sandhya Viswanathan In-Reply-To: <7EDAB0F3-8A7A-45F1-A8E3-6A5069DC2471@oracle.com> References: <7EDAB0F3-8A7A-45F1-A8E3-6A5069DC2471@oracle.com> Message-ID: Vote: yes Harold On 5/13/2021 11:38 AM, Paul Sandoz wrote: > I hereby nominate Sandhya Viswanathan (sviswanathan)[0] to JDK Reviewer. > > Sandhya is a long time contributor to OpenJDK, and has extensive experience of x86 platforms, making numerous improvements to HotSpot's code generation. > > Overall Sandhya has 32 commits to the mainline JDK [3]. Some of those commits reflect involvement in JEPs (JEP-338, JEP-333 and JEP-254), particularly JEP 338: Vector API (Incubator), where Sandhya is a key participant [4] in the effort to bring SIMD programming to Java. > > Votes are due by Thursday, the 27th of May, 2021. > > Only current OpenJDK Reviewers (and above) [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]. > > Paul. > > > [0] https://openjdk.java.net/census#sviswanathan > https://github.com/sviswa7 > [1] https://openjdk.java.net/census#jdk > [2] http://openjdk.java.net/projects/#reviewer-vote > > [3] > https://github.com/openjdk/jdk/search?o=desc&q=merge%3Afalse+author-name%3A%22Sandhya+Viswanathan%22&s=committer-date&type=commits > https://github.com/openjdk/jdk/search?q=merge%3Afalse+%22Sandhya+Viswanathan%22&type=commits > > [4] > https://github.com/openjdk/panama-vector/search?o=desc&q=merge%3Afalse+author-name%3A%22Sandhya+Viswanathan%22&s=committer-date&type=commits > http://hg.openjdk.java.net/panama/dev/search/?rev=author%28sviswanathan%29%20and%20branch%28vectorIntrinsics%29%20and%20not%20merge%28%29&revcount=52 From anthony.scarpino at oracle.com Thu May 13 21:30:22 2021 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 13 May 2021 14:30:22 -0700 Subject: CFV: New JDK Reviewer: Sandhya Viswanathan In-Reply-To: <7EDAB0F3-8A7A-45F1-A8E3-6A5069DC2471@oracle.com> References: <7EDAB0F3-8A7A-45F1-A8E3-6A5069DC2471@oracle.com> Message-ID: <9c73497b-d27a-3174-18ba-ffc4719f256a@oracle.com> Vote: yes Tony On 5/13/21 8:38 AM, Paul Sandoz wrote: > I hereby nominate Sandhya Viswanathan (sviswanathan)[0] to JDK Reviewer. > > Sandhya is a long time contributor to OpenJDK, and has extensive experience of x86 platforms, making numerous improvements to HotSpot's code generation. > > Overall Sandhya has 32 commits to the mainline JDK [3]. Some of those commits reflect involvement in JEPs (JEP-338, JEP-333 and JEP-254), particularly JEP 338: Vector API (Incubator), where Sandhya is a key participant [4] in the effort to bring SIMD programming to Java. > > Votes are due by Thursday, the 27th of May, 2021. > > Only current OpenJDK Reviewers (and above) [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]. > > Paul. > > > [0] https://openjdk.java.net/census#sviswanathan > https://github.com/sviswa7 > [1] https://openjdk.java.net/census#jdk > [2] http://openjdk.java.net/projects/#reviewer-vote > > [3] > https://github.com/openjdk/jdk/search?o=desc&q=merge%3Afalse+author-name%3A%22Sandhya+Viswanathan%22&s=committer-date&type=commits > https://github.com/openjdk/jdk/search?q=merge%3Afalse+%22Sandhya+Viswanathan%22&type=commits > > [4] > https://github.com/openjdk/panama-vector/search?o=desc&q=merge%3Afalse+author-name%3A%22Sandhya+Viswanathan%22&s=committer-date&type=commits > http://hg.openjdk.java.net/panama/dev/search/?rev=author%28sviswanathan%29%20and%20branch%28vectorIntrinsics%29%20and%20not%20merge%28%29&revcount=52 > From philip.race at oracle.com Thu May 13 22:04:18 2021 From: philip.race at oracle.com (Philip Race) Date: Thu, 13 May 2021 15:04:18 -0700 Subject: Result: new JDK Committer: Alexey Ushakov Message-ID: Voting for Alexey Ushakov [1] is now closed: Yes: 18 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus [2], this is sufficient to approve the nomination. -phil. [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2021-April/005431.html [2] http://openjdk.java.net/bylaws#lazy-consensus From mark.reinhold at oracle.com Thu May 13 22:37:16 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 13 May 2021 15:37:16 -0700 Subject: The meaning, or not, of =?utf-8?B?4oCcTFRT4oCd?= Message-ID: <20210513153716.883107515@eggemoggin.niobe.net> I?ve heard a few contributors report that they?ve received advice along the lines of, ?since JDK 17 is an LTS we should focus on stability, and avoid doing major enhancements.? This suggests that the stability of non-LTS releases is not important, but nothing is further from the truth. We should focus on stability in every JDK release, since every JDK release is meant to be ready for production use. That a release is designated an LTS release is no reason to hold back on innovation. If you have an enhancement that will preserve stability and is ready to integrate then, by all means, please proceed with the usual high level of care and consideration. Whether the target release is an LTS or not is, in almost all ways, completely irrelevant. - Mark From mark.reinhold at oracle.com Thu May 13 23:09:39 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 13 May 2021 16:09:39 -0700 (PDT) Subject: JEP proposed to target JDK 17: 412: Foreign Function & Memory API (Incubator) Message-ID: <20210513230939.49A733E3B9D@eggemoggin.niobe.net> The following JEP is proposed to target JDK 17: 412: Foreign Function & Memory API (Incubator) https://openjdk.java.net/jeps/412 Summary: Introduce an API by which Java programs can interoperate with code and data outside of the Java runtime. By efficiently invoking foreign functions (i.e., code outside the JVM), and by safely accessing foreign memory (i.e., memory not managed by the JVM), the API enables Java programs to call native libraries and process native data without the brittleness and danger of JNI. 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 Thursday, 20 May, 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 17. - Mark [1] https://openjdk.java.net/census#jdk [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From Alan.Bateman at oracle.com Fri May 14 12:21:48 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 14 May 2021 13:21:48 +0100 Subject: CFV: New JDK Reviewer: Sandhya Viswanathan In-Reply-To: <7EDAB0F3-8A7A-45F1-A8E3-6A5069DC2471@oracle.com> References: <7EDAB0F3-8A7A-45F1-A8E3-6A5069DC2471@oracle.com> Message-ID: <924e649d-0537-55a0-30c1-f532e4fd097b@oracle.com> Vote: yes From aph at redhat.com Fri May 14 13:17:54 2021 From: aph at redhat.com (Andrew Haley) Date: Fri, 14 May 2021 14:17:54 +0100 Subject: =?UTF-8?B?UmU6IFRoZSBtZWFuaW5nLCBvciBub3QsIG9mIOKAnExUU+KAnQ==?= In-Reply-To: <20210513153716.883107515@eggemoggin.niobe.net> References: <20210513153716.883107515@eggemoggin.niobe.net> Message-ID: <73a3a594-3970-2bde-b76e-1878228ee2c8@redhat.com> On 5/13/21 11:37 PM, mark.reinhold at oracle.com wrote: > I?ve heard a few contributors report that they?ve received advice along > the lines of, ?since JDK 17 is an LTS we should focus on stability, and > avoid doing major enhancements.? > > This suggests that the stability of non-LTS releases is not important, > but nothing is further from the truth. We should focus on stability > in every JDK release, since every JDK release is meant to be ready for > production use. That a release is designated an LTS release is no > reason to hold back on innovation. I agree, but this coin has a flipside that should also be mentioned: That JDK 17 may be treated as an LTS is not a reason to rush anything in order to "get it done in time for the release." -- 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 mark.reinhold at oracle.com Fri May 14 16:05:51 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 14 May 2021 09:05:51 -0700 Subject: The meaning, or not, of =?utf-8?B?4oCcTFRT4oCd?= In-Reply-To: <73a3a594-3970-2bde-b76e-1878228ee2c8@redhat.com> References: <20210513153716.883107515@eggemoggin.niobe.net> <73a3a594-3970-2bde-b76e-1878228ee2c8@redhat.com> Message-ID: <20210514090551.888225439@eggemoggin.niobe.net> 2021/5/14 6:17:54 -0700, Andrew Haley : > On 5/13/21 11:37 PM, mark.reinhold at oracle.com wrote: >> I?ve heard a few contributors report that they?ve received advice along >> the lines of, ?since JDK 17 is an LTS we should focus on stability, and >> avoid doing major enhancements.? >> >> This suggests that the stability of non-LTS releases is not important, >> but nothing is further from the truth. We should focus on stability >> in every JDK release, since every JDK release is meant to be ready for >> production use. That a release is designated an LTS release is no >> reason to hold back on innovation. > > I agree, but this coin has a flipside that should also be mentioned: > > That JDK 17 may be treated as an LTS is not a reason to rush anything > in order to "get it done in time for the release." Absolutely! Hence my exhortation to ?please proceed with the usual high level of care and consideration.? - Mark From mikael.vidstedt at oracle.com Fri May 14 22:23:40 2021 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 14 May 2021 22:23:40 +0000 Subject: CFV: New JDK Reviewer: Sandhya Viswanathan In-Reply-To: <7EDAB0F3-8A7A-45F1-A8E3-6A5069DC2471@oracle.com> References: <7EDAB0F3-8A7A-45F1-A8E3-6A5069DC2471@oracle.com> Message-ID: <8EA79C92-EE41-4BC6-BE5C-C6B06C0E92C6@oracle.com> Vote: yes Cheers, Mikael > On May 13, 2021, at 8:38 AM, Paul Sandoz wrote: > > I hereby nominate Sandhya Viswanathan (sviswanathan)[0] to JDK Reviewer. > > Sandhya is a long time contributor to OpenJDK, and has extensive experience of x86 platforms, making numerous improvements to HotSpot's code generation. > > Overall Sandhya has 32 commits to the mainline JDK [3]. Some of those commits reflect involvement in JEPs (JEP-338, JEP-333 and JEP-254), particularly JEP 338: Vector API (Incubator), where Sandhya is a key participant [4] in the effort to bring SIMD programming to Java. > > Votes are due by Thursday, the 27th of May, 2021. > > Only current OpenJDK Reviewers (and above) [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]. > > Paul. > > > [0] https://openjdk.java.net/census#sviswanathan > https://github.com/sviswa7 > [1] https://openjdk.java.net/census#jdk > [2] http://openjdk.java.net/projects/#reviewer-vote > > [3] > https://github.com/openjdk/jdk/search?o=desc&q=merge%3Afalse+author-name%3A%22Sandhya+Viswanathan%22&s=committer-date&type=commits > https://github.com/openjdk/jdk/search?q=merge%3Afalse+%22Sandhya+Viswanathan%22&type=commits > > [4] > https://github.com/openjdk/panama-vector/search?o=desc&q=merge%3Afalse+author-name%3A%22Sandhya+Viswanathan%22&s=committer-date&type=commits > http://hg.openjdk.java.net/panama/dev/search/?rev=author%28sviswanathan%29%20and%20branch%28vectorIntrinsics%29%20and%20not%20merge%28%29&revcount=52 From ebresie at gmail.com Sat May 15 13:48:12 2021 From: ebresie at gmail.com (Eric Bresie) Date: Sat, 15 May 2021 08:48:12 -0500 Subject: Life of a Bug - Next Generation Message-ID: As I try to better understand the openjdk development process I stumble across a very helpful informative (older) blog entry. https://blogs.oracle.com/java/a-bugs-life:-java-7-updates With the migration to git and it?s applicable features, and the build changes can anyone clarify some more on this? If this has been documented already elsewhere (i.e. https://openjdk.java.net/guide/) I apologize up front but still was interested in how things have further changed I assume the changes mainly involve things like: - Code migration from Mercurial to github for configuration control - Bug Tracking (may have some different methods in tracking) - Branch/release management (i.e. git commit/branches/master vs development, and build/release cadence, etc.) in git - Review (leveraging ?Pull Requests? in git including applicable flags involved in PRs [like the OCA, milestones, review requests, etc.) Eric Bresie ebresie at gmail.com -- Eric Bresie ebresie at gmail.com From Sergey.Bylokhov at oracle.com Sun May 16 07:19:57 2021 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sun, 16 May 2021 00:19:57 -0700 Subject: CFV: New JDK Reviewer: Alexander Matveev In-Reply-To: References: Message-ID: Vote: Yes -- Best regards, Sergey. From cay.horstmann at gmail.com Sun May 16 12:37:21 2021 From: cay.horstmann at gmail.com (Cay Horstmann) Date: Sun, 16 May 2021 14:37:21 +0200 Subject: =?UTF-8?B?UmU6IFRoZSBtZWFuaW5nLCBvciBub3QsIG9mIOKAnExUU+KAnQ==?= In-Reply-To: <20210513153716.883107515@eggemoggin.niobe.net> References: <20210513153716.883107515@eggemoggin.niobe.net> Message-ID: <28f73897-ff65-0572-54f3-b78dc05ba000@gmail.com> What happens with experimental, preview, and incubator features that are introduced in an LTS and subsequently modified? Are providers of an LTS obligated to keep the feature in its unmodified form, or may they drop it or replace it with a later version? I am just wondering about the effort of keeping an obsolete feature version alive for many years. Thanks, Cay On 14/05/2021 00:37, mark.reinhold at oracle.com wrote: > I?ve heard a few contributors report that they?ve received advice along > the lines of, ?since JDK 17 is an LTS we should focus on stability, and > avoid doing major enhancements.? > > This suggests that the stability of non-LTS releases is not important, > but nothing is further from the truth. We should focus on stability > in every JDK release, since every JDK release is meant to be ready for > production use. That a release is designated an LTS release is no > reason to hold back on innovation. > > If you have an enhancement that will preserve stability and is ready to > integrate then, by all means, please proceed with the usual high level > of care and consideration. Whether the target release is an LTS or not > is, in almost all ways, completely irrelevant. > > - Mark > -- Cay S. Horstmann | http://horstmann.com | mailto:cay at horstmann.com From dev at anthonyv.be Sun May 16 13:41:54 2021 From: dev at anthonyv.be (Anthony Vanelverdinghe) Date: Sun, 16 May 2021 15:41:54 +0200 Subject: =?utf-8?q?Re=3A?= The =?utf-8?q?meaning=2C?= or =?utf-8?q?not=2C?= of =?utf-8?q?=E2=80=9CLTS=E2=80=9D?= In-Reply-To: <28f73897-ff65-0572-54f3-b78dc05ba000@gmail.com> Message-ID: <298b-60a12100-41b-66041980@150997417> Preview features are specified in the Java SE Platform JSRs, hence tested in their accompanying TCKs, and thus must remain unaltered. On the other hand, incubator modules are not, so I believe vendors are allowed to ship upgraded versions (though I don't readily see the value in doing so: developers using incubator modules are likely to upgrade to subsequent JDKs anyway), or not ship them at all. Kind regards, Anthony On Sunday, May 16, 2021 14:37 CEST, Cay Horstmann wrote: > What happens with experimental, preview, and incubator features that are > introduced in an LTS and subsequently modified? Are providers of an LTS > obligated to keep the feature in its unmodified form, or may they drop > it or replace it with a later version? I am just wondering about the > effort of keeping an obsolete feature version alive for many years. > > Thanks, > > Cay > > On 14/05/2021 00:37, mark.reinhold at oracle.com wrote: > > I?ve heard a few contributors report that they?ve received advice along > > the lines of, ?since JDK 17 is an LTS we should focus on stability, and > > avoid doing major enhancements.? > > > > This suggests that the stability of non-LTS releases is not important, > > but nothing is further from the truth. We should focus on stability > > in every JDK release, since every JDK release is meant to be ready for > > production use. That a release is designated an LTS release is no > > reason to hold back on innovation. > > > > If you have an enhancement that will preserve stability and is ready to > > integrate then, by all means, please proceed with the usual high level > > of care and consideration. Whether the target release is an LTS or not > > is, in almost all ways, completely irrelevant. > > > > - Mark > > > > -- > > Cay S. Horstmann | http://horstmann.com | mailto:cay at horstmann.com From brian.goetz at oracle.com Sun May 16 14:29:31 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Sun, 16 May 2021 14:29:31 +0000 Subject: =?utf-8?B?UmU6IFRoZSBtZWFuaW5nLCBvciBub3QsIG9mIOKAnExUU+KAnQ==?= In-Reply-To: <28f73897-ff65-0572-54f3-b78dc05ba000@gmail.com> References: <20210513153716.883107515@eggemoggin.niobe.net>, <28f73897-ff65-0572-54f3-b78dc05ba000@gmail.com> Message-ID: <198F6FF2-FD75-4F60-BB3C-D78BF837EDBC@oracle.com> The obvious thing happens. The spec is versioned, so if the 17 spec calls for preview features, those features in that state are part of the 17 spec forever. We don?t anticipate running MRs to remove them, though we also expect their use to decline after the first 6-12 months as the bleeding edge users will have moved on to the new hotness. In terms of ?keeping them alive?, since it is risky to run with preview features in production ? which is what attracts most users to LTS ? we expect the maintenance load in practice to be low. Sent from my iPad > On May 16, 2021, at 8:37 AM, Cay Horstmann wrote: > > ?What happens with experimental, preview, and incubator features that are introduced in an LTS and subsequently modified? Are providers of an LTS obligated to keep the feature in its unmodified form, or may they drop it or replace it with a later version? I am just wondering about the effort of keeping an obsolete feature version alive for many years. > > Thanks, > > Cay > >> On 14/05/2021 00:37, mark.reinhold at oracle.com wrote: >> I?ve heard a few contributors report that they?ve received advice along >> the lines of, ?since JDK 17 is an LTS we should focus on stability, and >> avoid doing major enhancements.? >> This suggests that the stability of non-LTS releases is not important, >> but nothing is further from the truth. We should focus on stability >> in every JDK release, since every JDK release is meant to be ready for >> production use. That a release is designated an LTS release is no >> reason to hold back on innovation. >> If you have an enhancement that will preserve stability and is ready to >> integrate then, by all means, please proceed with the usual high level >> of care and consideration. Whether the target release is an LTS or not >> is, in almost all ways, completely irrelevant. >> - Mark > > -- > > Cay S. Horstmann | http://horstmann.com | mailto:cay at horstmann.com From forax at univ-mlv.fr Sun May 16 14:54:43 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 16 May 2021 16:54:43 +0200 (CEST) Subject: =?utf-8?Q?Re:_The_meaning,_or_not,_of_=E2=80=9CLTS=E2=80=9D?= In-Reply-To: <298b-60a12100-41b-66041980@150997417> References: <298b-60a12100-41b-66041980@150997417> Message-ID: <1138094174.87883.1621176883949.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Anthony Vanelverdinghe" > ?: "cay" > Cc: "jdk-dev" > Envoy?: Dimanche 16 Mai 2021 15:41:54 > Objet: Re: The meaning, or not, of ?LTS? > Preview features are specified in the Java SE Platform JSRs, hence tested in > their accompanying TCKs, and thus must remain unaltered. On the other hand, > incubator modules are not, so I believe vendors are allowed to ship upgraded > versions (though I don't readily see the value in doing so: developers using > incubator modules are likely to upgrade to subsequent JDKs anyway), or not ship > them at all. Given that for incubator modules, each new versions is incompatible with the previous one (it's not mandatory but it's what's appear in practice), shipping a new version of an incubator module in a LTS updates seems to have no value, you need to do more work to release something which is not compatible with the previous update. > > Kind regards, > Anthony R?mi > > On Sunday, May 16, 2021 14:37 CEST, Cay Horstmann > wrote: > >> What happens with experimental, preview, and incubator features that are >> introduced in an LTS and subsequently modified? Are providers of an LTS >> obligated to keep the feature in its unmodified form, or may they drop >> it or replace it with a later version? I am just wondering about the >> effort of keeping an obsolete feature version alive for many years. >> >> Thanks, >> >> Cay >> >> On 14/05/2021 00:37, mark.reinhold at oracle.com wrote: >> > I?ve heard a few contributors report that they?ve received advice along >> > the lines of, ?since JDK 17 is an LTS we should focus on stability, and >> > avoid doing major enhancements.? >> > >> > This suggests that the stability of non-LTS releases is not important, >> > but nothing is further from the truth. We should focus on stability >> > in every JDK release, since every JDK release is meant to be ready for >> > production use. That a release is designated an LTS release is no >> > reason to hold back on innovation. >> > >> > If you have an enhancement that will preserve stability and is ready to >> > integrate then, by all means, please proceed with the usual high level >> > of care and consideration. Whether the target release is an LTS or not >> > is, in almost all ways, completely irrelevant. >> > >> > - Mark >> > >> >> -- >> > > Cay S. Horstmann | http://horstmann.com | mailto:cay at horstmann.com From forax at univ-mlv.fr Sun May 16 14:57:21 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 16 May 2021 16:57:21 +0200 (CEST) Subject: =?utf-8?Q?Re:_The_meaning,_or_not,_of_=E2=80=9CLTS=E2=80=9D?= In-Reply-To: <198F6FF2-FD75-4F60-BB3C-D78BF837EDBC@oracle.com> References: <20210513153716.883107515@eggemoggin.niobe.net> <28f73897-ff65-0572-54f3-b78dc05ba000@gmail.com> <198F6FF2-FD75-4F60-BB3C-D78BF837EDBC@oracle.com> Message-ID: <1430846912.88627.1621177041020.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Brian Goetz" > ?: "cay" > Cc: "jdk-dev" > Envoy?: Dimanche 16 Mai 2021 16:29:31 > Objet: Re: The meaning, or not, of ?LTS? > The obvious thing happens. The spec is versioned, so if the 17 spec calls for > preview features, those features in that state are part of the 17 spec forever. > We don?t anticipate running MRs to remove them, though we also expect their > use to decline after the first 6-12 months as the bleeding edge users will have > moved on to the new hotness. > > In terms of ?keeping them alive?, since it is risky to run with preview features > in production ? which is what attracts most users to LTS ? we expect the > maintenance load in practice to be low. Apart the security issue that will still need to be patched even if very few people use incubator modules after the first 6 months, i agree/hope that the maintenance should be low. R?mi > > > > > > Sent from my iPad > >> On May 16, 2021, at 8:37 AM, Cay Horstmann wrote: >> >> ?What happens with experimental, preview, and incubator features that are >> ?introduced in an LTS and subsequently modified? Are providers of an LTS >> ?obligated to keep the feature in its unmodified form, or may they drop it or >> ?replace it with a later version? I am just wondering about the effort of >> ?keeping an obsolete feature version alive for many years. >> >> Thanks, >> >> Cay >> >>> On 14/05/2021 00:37, mark.reinhold at oracle.com wrote: >>> I?ve heard a few contributors report that they?ve received advice along >>> the lines of, ?since JDK 17 is an LTS we should focus on stability, and >>> avoid doing major enhancements.? >>> This suggests that the stability of non-LTS releases is not important, >>> but nothing is further from the truth. We should focus on stability >>> in every JDK release, since every JDK release is meant to be ready for >>> production use. That a release is designated an LTS release is no >>> reason to hold back on innovation. >>> If you have an enhancement that will preserve stability and is ready to >>> integrate then, by all means, please proceed with the usual high level >>> of care and consideration. Whether the target release is an LTS or not >>> is, in almost all ways, completely irrelevant. >>> - Mark >> >> -- >> > > Cay S. Horstmann | http://horstmann.com | mailto:cay at horstmann.com From jesper.wilhelmsson at oracle.com Mon May 17 00:53:10 2021 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 17 May 2021 02:53:10 +0200 Subject: Life of a Bug - Next Generation In-Reply-To: References: Message-ID: Hi Eric, It's unclear to me exactly what you want clarified, but I'll give it a try. Please be more specific in your questions if you don't get the answer you are looking for. > As I try to better understand the openjdk development process I stumble > across a very helpful informative (older) blog entry. > > https://blogs.oracle.com/java/a-bugs-life:-java-7-updates This is a very old post but some of it is still relevant. The process of bug triage, a bug's priority, and a bug's state hasn't changed. The WebBugs team still triage bugs filed through the bug report tool (https://bugreport.java.com/ ). The blog post recommends that someone new to the project should pick a p4 or p5 bug to get started. While choosing a bug with lower priority may be a good idea as there is less urgency around fixing it, there is no correlation between a bug's priority and how difficult it is to fix it. A p5 bug can be just as hard or even harder to fix (especially if it's intermittent) as a p1. In many cases it's actually quite the opposite - a crash that happens often (like during JVM startup) or a change that breaks the build is often quite easy to fix but would clearly be a p1 bug. > With the migration to git and it?s applicable features, and the build > changes can anyone clarify some more on this? > > If this has been documented already elsewhere (i.e. > https://openjdk.java.net/guide/) I apologize up front but still was > interested in how things have further changed The Developers' Guide is where you would ideally find these answers, yes. The parts that explains how to work with git hasn't been completed yet unfortunately. Many other parts of the development process is described there though. > I assume the changes mainly involve things like: > - Code migration from Mercurial to github for configuration control The move to GitHub means that we now use git for revision control of the source code instead of mercurial and that the source mirrors are hosted by GitHub instead of Oracle. That's the main change, and depending on how you choose to work it could even be the only change. > - Bug Tracking (may have some different methods in tracking) No changes has been made to the bug database or the bug report tool. > - Branch/release management (i.e. git commit/branches/master vs > development, and build/release cadence, etc.) in git No changes has been made to branch/release management (yet). The release cadence is unrelated to what tools we use for development. > - Review (leveraging ?Pull Requests? in git including applicable flags > involved in PRs [like the OCA, milestones, review requests, etc.) The move to GitHub enabled the use of their infrastructure for code review. This is really nice and a lot of OpenJDK developers use it frequently. There is no requirement to use it though. You can still review all changes using the old webrev format and the main channel for ALL review comments and discussions around a bug is still the mailing list. The Skara tooling developed to accommodate the move to git simplifies and automates a lot, for instance the OCA check, but process wise nothing has changed in this area. Hth, /Jesper > > Eric Bresie > ebresie at gmail.com > -- > Eric Bresie > ebresie at gmail.com From tobias.hartmann at oracle.com Mon May 17 09:12:05 2021 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 17 May 2021 11:12:05 +0200 Subject: CFV: New JDK Reviewer: Sandhya Viswanathan In-Reply-To: <7EDAB0F3-8A7A-45F1-A8E3-6A5069DC2471@oracle.com> References: <7EDAB0F3-8A7A-45F1-A8E3-6A5069DC2471@oracle.com> Message-ID: Vote: yes Best regards, Tobias On 13.05.21 17:38, Paul Sandoz wrote: > I hereby nominate Sandhya Viswanathan (sviswanathan)[0] to JDK Reviewer. > > Sandhya is a long time contributor to OpenJDK, and has extensive experience of x86 platforms, making numerous improvements to HotSpot's code generation. > > Overall Sandhya has 32 commits to the mainline JDK [3]. Some of those commits reflect involvement in JEPs (JEP-338, JEP-333 and JEP-254), particularly JEP 338: Vector API (Incubator), where Sandhya is a key participant [4] in the effort to bring SIMD programming to Java. > > Votes are due by Thursday, the 27th of May, 2021. > > Only current OpenJDK Reviewers (and above) [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]. > > Paul. > > > [0] https://openjdk.java.net/census#sviswanathan > https://github.com/sviswa7 > [1] https://openjdk.java.net/census#jdk > [2] http://openjdk.java.net/projects/#reviewer-vote > > [3] > https://github.com/openjdk/jdk/search?o=desc&q=merge%3Afalse+author-name%3A%22Sandhya+Viswanathan%22&s=committer-date&type=commits > https://github.com/openjdk/jdk/search?q=merge%3Afalse+%22Sandhya+Viswanathan%22&type=commits > > [4] > https://github.com/openjdk/panama-vector/search?o=desc&q=merge%3Afalse+author-name%3A%22Sandhya+Viswanathan%22&s=committer-date&type=commits > http://hg.openjdk.java.net/panama/dev/search/?rev=author%28sviswanathan%29%20and%20branch%28vectorIntrinsics%29%20and%20not%20merge%28%29&revcount=52 > From mark.reinhold at oracle.com Mon May 17 22:52:58 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 17 May 2021 15:52:58 -0700 (PDT) Subject: JEP proposed to target JDK 17: 407: Remove RMI Activation Message-ID: <20210517225259.1938A3E412F@eggemoggin.niobe.net> The following JEP is proposed to target JDK 17: 407: Remove RMI Activation https://openjdk.java.net/jeps/407 Summary: Remove the Remote Method Invocation (RMI) Activation mechanism, while preserving the rest of RMI. 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, 24 May, 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 17. - Mark [1] https://openjdk.java.net/census#jdk [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From ioi.lam at oracle.com Tue May 18 05:09:11 2021 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 17 May 2021 22:09:11 -0700 Subject: Result: New jdk Reviewer: Jie Fu Message-ID: Voting for Jie Fu (jiefu) [1] is now closed. Yes:???? 15 Veto:???? 0 Abstain:? 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. Thanks! - Ioi [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2021-May/005457.html From shade at openjdk.java.net Tue May 18 12:28:49 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 18 May 2021 12:28:49 GMT Subject: RFR: 8267304: Bump global JTReg memory limit to 768m Message-ID: <9n1WI3NnCxt7iG-PVkTKmEP5hyJjR0CNwn576AYj30Q=.f8269bff-92e7-450c-b4dc-332e9c8d6ffc@github.com> See the rationale in the RFE. Additional testing: - [x] Linux x86_64 fastdebug `java/time/format/TestZoneTextPrinterParser.java` with aggressive GC options - [x] Linux x86_64 fastdebug `jdk:tier1` - [x] Linux x86_64 fastdebug `tier1` - [x] Linux x86_64 fastdebug `tier2` - [x] Linux x86_32 fastdebug `tier1` - [x] Linux x86_32 fastdebug `tier2` ------------- Commit messages: - 8267304: Bump global JTReg memory limit to 768m Changes: https://git.openjdk.java.net/jdk/pull/4087/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4087&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267304 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4087.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4087/head:pull/4087 PR: https://git.openjdk.java.net/jdk/pull/4087 From lmesnik at openjdk.java.net Tue May 18 18:27:41 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Tue, 18 May 2021 18:27:41 GMT Subject: RFR: 8267304: Bump global JTReg memory limit to 768m In-Reply-To: <9n1WI3NnCxt7iG-PVkTKmEP5hyJjR0CNwn576AYj30Q=.f8269bff-92e7-450c-b4dc-332e9c8d6ffc@github.com> References: <9n1WI3NnCxt7iG-PVkTKmEP5hyJjR0CNwn576AYj30Q=.f8269bff-92e7-450c-b4dc-332e9c8d6ffc@github.com> Message-ID: On Tue, 18 May 2021 09:51:09 GMT, Aleksey Shipilev wrote: > See the rationale in the RFE. > > Additional testing: > - [x] Linux x86_64 fastdebug `java/time/format/TestZoneTextPrinterParser.java` with aggressive GC options > - [x] Linux x86_64 fastdebug `jdk:tier1` > - [x] Linux x86_64 fastdebug `tier1` > - [x] Linux x86_64 fastdebug `tier2` > - [x] Linux x86_32 fastdebug `tier1` > - [x] Linux x86_32 fastdebug `tier2` Shouldn't affect VM testing. Fine with core-svc setting. ------------- Marked as reviewed by lmesnik (Committer). PR: https://git.openjdk.java.net/jdk/pull/4087 From iignatyev at openjdk.java.net Tue May 18 19:08:48 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Tue, 18 May 2021 19:08:48 GMT Subject: RFR: 8267304: Bump global JTReg memory limit to 768m In-Reply-To: <9n1WI3NnCxt7iG-PVkTKmEP5hyJjR0CNwn576AYj30Q=.f8269bff-92e7-450c-b4dc-332e9c8d6ffc@github.com> References: <9n1WI3NnCxt7iG-PVkTKmEP5hyJjR0CNwn576AYj30Q=.f8269bff-92e7-450c-b4dc-332e9c8d6ffc@github.com> Message-ID: On Tue, 18 May 2021 09:51:09 GMT, Aleksey Shipilev wrote: > See the rationale in the RFE. > > Additional testing: > - [x] Linux x86_64 fastdebug `java/time/format/TestZoneTextPrinterParser.java` with aggressive GC options > - [x] Linux x86_64 fastdebug `jdk:tier1` > - [x] Linux x86_64 fastdebug `tier1` > - [x] Linux x86_64 fastdebug `tier2` > - [x] Linux x86_32 fastdebug `tier1` > - [x] Linux x86_32 fastdebug `tier2` LGTM ------------- Marked as reviewed by iignatyev (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4087 From tobias.hartmann at oracle.com Wed May 19 09:51:41 2021 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 19 May 2021 11:51:41 +0200 Subject: CFV: New JDK Committer: Yi Yang Message-ID: I hereby nominate Yi Yang (yyang) to JDK Committer. Description by himself: "I'm working at Alibaba JVM Team for a year, mainly focus on runtime and tool. In runtime, my work includes making java start up faster and occupies less memory for serverless applications. In tool, we are trying to deploy JFR and EclipseJIFA in a cloud environment and help users diagnose their problems. Besides, I'm also very interested in jit compilers, that is what really attracts me among HotSpot VM. In my spare time, I wrote a JVMCI based C1-like JIT compiler, though, incomplete." Yang has contributed 24 patches to JDK [3] and 10 to Valhalla [4], many of which are non-trivial. Votes are due by Wednesday, 2 June 2021 at 10: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, Tobias [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%22Yi+Yang%22&type=commits [4] https://github.com/search?q=is%3Apr+author%3Akelthuzadx+repo%3Aopenjdk%2Fvalhalla+state%3Aclosed From jiefu at tencent.com Wed May 19 10:40:32 2021 From: jiefu at tencent.com (=?utf-8?B?amllZnUo5YKF5p2wKQ==?=) Date: Wed, 19 May 2021 10:40:32 +0000 Subject: New JDK Committer: Yi Yang(Internet mail) In-Reply-To: References: Message-ID: Vote: Yes. Congratulations! Best regards, Jie ?On 2021/5/19, 5:53 PM, "jdk-dev on behalf of Tobias Hartmann" wrote: I hereby nominate Yi Yang (yyang) to JDK Committer. Description by himself: "I'm working at Alibaba JVM Team for a year, mainly focus on runtime and tool. In runtime, my work includes making java start up faster and occupies less memory for serverless applications. In tool, we are trying to deploy JFR and EclipseJIFA in a cloud environment and help users diagnose their problems. Besides, I'm also very interested in jit compilers, that is what really attracts me among HotSpot VM. In my spare time, I wrote a JVMCI based C1-like JIT compiler, though, incomplete." Yang has contributed 24 patches to JDK [3] and 10 to Valhalla [4], many of which are non-trivial. Votes are due by Wednesday, 2 June 2021 at 10: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, Tobias [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%22Yi+Yang%22&type=commits [4] https://github.com/search?q=is%3Apr+author%3Akelthuzadx+repo%3Aopenjdk%2Fvalhalla+state%3Aclosed From yan at azul.com Wed May 19 10:59:14 2021 From: yan at azul.com (Yuri Nesterenko) Date: Wed, 19 May 2021 13:59:14 +0300 Subject: CFV: New JDK Committer: Yi Yang In-Reply-To: References: Message-ID: <03365d92-6748-dddb-29bf-6bdb98399c73@azul.com> Vote: yes --yan On 19.05.2021 12:51, Tobias Hartmann wrote: > I hereby nominate Yi Yang (yyang) to JDK Committer. > > Description by himself: > "I'm working at Alibaba JVM Team for a year, mainly focus on runtime and tool. In runtime, my work > includes making java start up faster and occupies less memory for serverless applications. In tool, > we are trying to deploy JFR and EclipseJIFA in a cloud environment and help users diagnose their > problems. Besides, I'm also very interested in jit compilers, that is what really attracts me among > HotSpot VM. In my spare time, I wrote a JVMCI based C1-like JIT compiler, though, incomplete." > > Yang has contributed 24 patches to JDK [3] and 10 to Valhalla [4], many of which are non-trivial. > > Votes are due by Wednesday, 2 June 2021 at 10: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, > Tobias > > [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%22Yi+Yang%22&type=commits > [4] https://github.com/search?q=is%3Apr+author%3Akelthuzadx+repo%3Aopenjdk%2Fvalhalla+state%3Aclosed > From tobias.hartmann at oracle.com Wed May 19 11:59:42 2021 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 19 May 2021 13:59:42 +0200 Subject: CFV: New JDK Committer: Yi Yang In-Reply-To: References: Message-ID: <87b91d52-83c8-6e28-832e-d0e2679d0ef3@oracle.com> Vote: yes Best regards, Tobias On 19.05.21 11:51, Tobias Hartmann wrote: > I hereby nominate Yi Yang (yyang) to JDK Committer. > > Description by himself: > "I'm working at Alibaba JVM Team for a year, mainly focus on runtime and tool. In runtime, my work > includes making java start up faster and occupies less memory for serverless applications. In tool, > we are trying to deploy JFR and EclipseJIFA in a cloud environment and help users diagnose their > problems. Besides, I'm also very interested in jit compilers, that is what really attracts me among > HotSpot VM. In my spare time, I wrote a JVMCI based C1-like JIT compiler, though, incomplete." > > Yang has contributed 24 patches to JDK [3] and 10 to Valhalla [4], many of which are non-trivial. > > Votes are due by Wednesday, 2 June 2021 at 10: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, > Tobias > > [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%22Yi+Yang%22&type=commits > [4] https://github.com/search?q=is%3Apr+author%3Akelthuzadx+repo%3Aopenjdk%2Fvalhalla+state%3Aclosed > From shade at openjdk.java.net Wed May 19 13:02:42 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 19 May 2021 13:02:42 GMT Subject: Integrated: 8267304: Bump global JTReg memory limit to 768m In-Reply-To: <9n1WI3NnCxt7iG-PVkTKmEP5hyJjR0CNwn576AYj30Q=.f8269bff-92e7-450c-b4dc-332e9c8d6ffc@github.com> References: <9n1WI3NnCxt7iG-PVkTKmEP5hyJjR0CNwn576AYj30Q=.f8269bff-92e7-450c-b4dc-332e9c8d6ffc@github.com> Message-ID: <9rMOOvcY8sfJ1agArP8yPZ3OaonsyotFjjKu25lOiPU=.0998f084-b235-4fb3-bf2c-72a2922cd97c@github.com> On Tue, 18 May 2021 09:51:09 GMT, Aleksey Shipilev wrote: > See the rationale in the RFE. > > Additional testing: > - [x] Linux x86_64 fastdebug `java/time/format/TestZoneTextPrinterParser.java` with aggressive GC options > - [x] Linux x86_64 fastdebug `jdk:tier1` > - [x] Linux x86_64 fastdebug `tier1` > - [x] Linux x86_64 fastdebug `tier2` > - [x] Linux x86_32 fastdebug `tier1` > - [x] Linux x86_32 fastdebug `tier2` This pull request has now been integrated. Changeset: e749f75d Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/e749f75de015fd9ef47f7a962f232e2ea677aba5 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod 8267304: Bump global JTReg memory limit to 768m Reviewed-by: lmesnik, iignatyev ------------- PR: https://git.openjdk.java.net/jdk/pull/4087 From zgu at redhat.com Wed May 19 13:06:14 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 19 May 2021 09:06:14 -0400 Subject: CFV: New JDK Committer: Yi Yang In-Reply-To: References: Message-ID: Vote: yes. -Zhengyu On 5/19/21 5:51 AM, Tobias Hartmann wrote: > I hereby nominate Yi Yang (yyang) to JDK Committer. > > Description by himself: > "I'm working at Alibaba JVM Team for a year, mainly focus on runtime and tool. In runtime, my work > includes making java start up faster and occupies less memory for serverless applications. In tool, > we are trying to deploy JFR and EclipseJIFA in a cloud environment and help users diagnose their > problems. Besides, I'm also very interested in jit compilers, that is what really attracts me among > HotSpot VM. In my spare time, I wrote a JVMCI based C1-like JIT compiler, though, incomplete." > > Yang has contributed 24 patches to JDK [3] and 10 to Valhalla [4], many of which are non-trivial. > > Votes are due by Wednesday, 2 June 2021 at 10: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, > Tobias > > [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%22Yi+Yang%22&type=commits > [4] https://github.com/search?q=is%3Apr+author%3Akelthuzadx+repo%3Aopenjdk%2Fvalhalla+state%3Aclosed > From sean.mullan at oracle.com Wed May 19 13:48:35 2021 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 19 May 2021 09:48:35 -0400 Subject: Updates to JEP 411: Deprecate the Security Manager for Removal Message-ID: <9272f796-4268-a674-b648-49ff26ad3bc6@oracle.com> Thanks for those that have taken the time to review JEP 411 [1]. The JEP has been updated today with a few changes, the most significant which is the addition of a new section titled "Future Work" [2] which lists related potential enhancements and works in progress. Other smaller changes have been made throughout the JEP, including: - The "Alternate JAAS APIs" section has been removed and replaced with a smaller section in the Description section with a pointer to a JBS issue with more details. - Changes have been made to the Motivation section to improve some of the wording and add more details. - A new item named "Preserve the Security Manager API for extension by custom Security Managers that wish to intercept, log, and veto access to resources" has been added to the Alternatives section, as this has been a topic of discussion since the JEP has been published. - RMISecurityException has been removed from the list of APIs to be deprecated for removal, and java.util.concurrent.Executors::{privilegedCallable, privilegedCallableUsingCurrentClassLoader, privilegedThreadFactory} have been added. Thanks, Sean [1] https://openjdk.java.net/jeps/411 [2] https://openjdk.java.net/jeps/411#Future-Work From vladimir.x.ivanov at oracle.com Wed May 19 14:54:14 2021 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 19 May 2021 17:54:14 +0300 Subject: CFV: New JDK Committer: Yi Yang In-Reply-To: References: Message-ID: <14317eae-942c-6238-ab33-11e2eb2b34a4@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 19.05.2021 12:51, Tobias Hartmann wrote: > I hereby nominate Yi Yang (yyang) to JDK Committer. From mark.reinhold at oracle.com Tue May 18 23:47:17 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 18 May 2021 16:47:17 -0700 (PDT) Subject: JEP proposed to target JDK 17: 403: Strongly Encapsulate JDK Internals Message-ID: <20210518234717.566DE3E4392@eggemoggin.niobe.net> The following JEP is proposed to target JDK 17: 403: Strongly Encapsulate JDK Internals https://openjdk.java.net/jeps/403 Summary: Strongly encapsulate all internal elements of the JDK, except for critical internal APIs such as sun.misc.Unsafe. It will no longer be possible to relax the strong encapsulation of internal elements via a single command-line option, as was possible in JDK?9 through JDK?16. 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 Tuesday, 25 May, 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 17. - Mark [1] https://openjdk.java.net/census#jdk [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From mark.reinhold at oracle.com Wed May 19 00:00:55 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 18 May 2021 17:00:55 -0700 Subject: JEP proposed to target JDK 17: 414: Vector API (Second Incubator) In-Reply-To: <20210511165359.046CE3E36AA@eggemoggin.niobe.net> References: <20210511165359.046CE3E36AA@eggemoggin.niobe.net> Message-ID: <20210518170055.594346463@eggemoggin.niobe.net> 2021/5/11 9:53:59 -0700, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 17: > > 414: Vector API (Second Incubator) > https://openjdk.java.net/jeps/414 > > 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. > > 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 Tuesday, 18 May, 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 17. Hearing no objections, I?ve targeted this JEP to JDK 17. - Mark From felixxfyang at tencent.com Wed May 19 15:25:31 2021 From: felixxfyang at tencent.com (=?utf-8?B?ZmVsaXh4Znlhbmco5p2o5pmT5bOwKQ==?=) Date: Wed, 19 May 2021 15:25:31 +0000 Subject: New JDK Committer: Yi Yang Message-ID: <566D1B8D-6D45-4F35-90F2-3E333E046D10@tencent.com> Vote: yes -Felix Yang ?? 2021/5/19 ??5:52??jdk-dev ?? Tobias Hartmann? ??: I hereby nominate Yi Yang (yyang) to JDK Committer. Description by himself: "I'm working at Alibaba JVM Team for a year, mainly focus on runtime and tool. In runtime, my work includes making java start up faster and occupies less memory for serverless applications. In tool, we are trying to deploy JFR and EclipseJIFA in a cloud environment and help users diagnose their problems. Besides, I'm also very interested in jit compilers, that is what really attracts me among HotSpot VM. In my spare time, I wrote a JVMCI based C1-like JIT compiler, though, incomplete." Yang has contributed 24 patches to JDK [3] and 10 to Valhalla [4], many of which are non-trivial. Votes are due by Wednesday, 2 June 2021 at 10: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, Tobias [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%22Yi+Yang%22&type=commits [4] https://github.com/search?q=is%3Apr+author%3Akelthuzadx+repo%3Aopenjdk%2Fvalhalla+state%3Aclosed From vladimir.kozlov at oracle.com Wed May 19 15:30:54 2021 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 19 May 2021 08:30:54 -0700 Subject: CFV: New JDK Committer: Yi Yang In-Reply-To: References: Message-ID: <41dd3318-0e00-c374-d5df-eae4a3eceaf3@oracle.com> Vote: yes Thanks, Vladimir K On 5/19/21 2:51 AM, Tobias Hartmann wrote: > I hereby nominate Yi Yang (yyang) to JDK Committer. > > Description by himself: > "I'm working at Alibaba JVM Team for a year, mainly focus on runtime and tool. In runtime, my work > includes making java start up faster and occupies less memory for serverless applications. In tool, > we are trying to deploy JFR and EclipseJIFA in a cloud environment and help users diagnose their > problems. Besides, I'm also very interested in jit compilers, that is what really attracts me among > HotSpot VM. In my spare time, I wrote a JVMCI based C1-like JIT compiler, though, incomplete." > > Yang has contributed 24 patches to JDK [3] and 10 to Valhalla [4], many of which are non-trivial. > > Votes are due by Wednesday, 2 June 2021 at 10: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, > Tobias > > [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%22Yi+Yang%22&type=commits > [4] https://github.com/search?q=is%3Apr+author%3Akelthuzadx+repo%3Aopenjdk%2Fvalhalla+state%3Aclosed > From jonathan.gibbons at oracle.com Wed May 19 16:37:04 2021 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 19 May 2021 09:37:04 -0700 Subject: Coming Soon: jtreg 6 Message-ID: JDK folk, This is a general heads-up that jtreg 6 is ready for use and that we should soon update JDK to use it.? There are not many changes to the jtreg tool itself; the most significant change in jtreg 6 is the updated versions of the TestNG and JUnit libraries, which in turn have some new dependencies of their own. There is a new, improved script to drive the Makefile, for those that want to build jtreg themselves. The new build script (make/build.sh) separates the specification of the dependencies from the code used to download the dependencies. The script can also be configured to download from non-default locations, which may be useful for those behind corporate firewalls. And, as always, for those that want to control the downloads themselves, you can still drive the Makefile directly. In its simplest form, you can use the new script as follows: ??? sh make/build.sh --jdk /path/to/JDK8 jtreg is also adopting the JDK version-numbering scheme, as defined in "JEP 223: New Version-String Scheme"[1], so the days of using the build number as a significant part of the version string are finally over.? This version of jtreg is "6"; subsequent versions will be "6.1", "6.2", ... "7", ... etc. As before, we will tag the jtreg repo to mark the commit used for each version. jtreg uses TestNG 7.3.0 and JUnit 4.13.2, as defined in make/build-support/version-numbers. This version of TestNG depends on Google Guice, and JUnit depends on Hamcrest. Suitable version numbers for those libraries are also defined in that file. TestNG 7.3.0 has a number of incompatibilities compared to the version we were previously using, including: 1. The module name is now set explicitly to `org.testng` instead of allowing the default name `testng` to be used. This affects modular tests that explicitly `require` the TestNG jar as an automatic module and/or export packages to that module. This will require a small number of tests to be updated when we switch to the new version. 2. It is no longer possible to declare static methods as test methods with the `@Test` annotation. 3. The behavior of `@BeforeGroups` has changed and should generally be avoided in jtreg tests. 4. TestNG checks a number of new system properties. This needs to be taken into account in tests that need to grant permission to access those properties. All JDK tests affected by #2, #3, #4 have already been updated. Tests affected by #1 will be updated as part of the Pull Request to switch to using jtreg 6. We have done internal test runs of most test tiers and do not believe there are any more test failures related to the upgrade. These incompatibilities mean that it will not be possible to use jtreg 6 for older/update releases unless/until the changes to the affected tests are also backported. That decision is left to those managing those releases. NOTE: Users building jtreg should NOT use TestNG 7.4.0 to run JDK tests. There is a bug[2] in TestNG 7.4.0 that breaks a number of JDK tests. Finally, thanks to everyone who has helped thus far, including Mikael Vidstedt for initiating work on the new build script and other related improvements, and to the developers who have helped analyze and fix the issues cause by the TestNG upgrade. -- Jon [1] https://openjdk.java.net/jeps/223 [2] https://github.com/cbeust/testng/issues/2527 ??? https://github.com/cbeust/testng/issues/2540 From calvin.cheung at oracle.com Wed May 19 17:48:31 2021 From: calvin.cheung at oracle.com (calvin.cheung at oracle.com) Date: Wed, 19 May 2021 10:48:31 -0700 Subject: CFV: New JDK Committer: Yi Yang In-Reply-To: References: Message-ID: Vote: yes On 5/19/21 2:51 AM, Tobias Hartmann wrote: > I hereby nominate Yi Yang (yyang) to JDK Committer. > > Description by himself: > "I'm working at Alibaba JVM Team for a year, mainly focus on runtime and tool. In runtime, my work > includes making java start up faster and occupies less memory for serverless applications. In tool, > we are trying to deploy JFR and EclipseJIFA in a cloud environment and help users diagnose their > problems. Besides, I'm also very interested in jit compilers, that is what really attracts me among > HotSpot VM. In my spare time, I wrote a JVMCI based C1-like JIT compiler, though, incomplete." > > Yang has contributed 24 patches to JDK [3] and 10 to Valhalla [4], many of which are non-trivial. > > Votes are due by Wednesday, 2 June 2021 at 10: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, > Tobias > > [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%22Yi+Yang%22&type=commits > [4] https://github.com/search?q=is%3Apr+author%3Akelthuzadx+repo%3Aopenjdk%2Fvalhalla+state%3Aclosed From jianglizhou at google.com Wed May 19 18:04:45 2021 From: jianglizhou at google.com (Jiangli Zhou) Date: Wed, 19 May 2021 11:04:45 -0700 Subject: CFV: New JDK Committer: Yi Yang In-Reply-To: References: Message-ID: Vote: yes Best, Jiangli On Wed, May 19, 2021 at 2:52 AM Tobias Hartmann wrote: > I hereby nominate Yi Yang (yyang) to JDK Committer. > > Description by himself: > "I'm working at Alibaba JVM Team for a year, mainly focus on runtime and > tool. In runtime, my work > includes making java start up faster and occupies less memory for > serverless applications. In tool, > we are trying to deploy JFR and EclipseJIFA in a cloud environment and > help users diagnose their > problems. Besides, I'm also very interested in jit compilers, that is what > really attracts me among > HotSpot VM. In my spare time, I wrote a JVMCI based C1-like JIT compiler, > though, incomplete." > > Yang has contributed 24 patches to JDK [3] and 10 to Valhalla [4], many of > which are non-trivial. > > Votes are due by Wednesday, 2 June 2021 at 10: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, > Tobias > > [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%22Yi+Yang%22&type=commits > [4] > https://github.com/search?q=is%3Apr+author%3Akelthuzadx+repo%3Aopenjdk%2Fvalhalla+state%3Aclosed > From philip.race at oracle.com Wed May 19 20:24:46 2021 From: philip.race at oracle.com (Philip Race) Date: Wed, 19 May 2021 13:24:46 -0700 Subject: Result: New JDK Reviewer: Alexander Matveev Message-ID: <6cc0943a-42bd-161d-e0ef-bfec2b0af7c0@oracle.com> Voting for Alexander Matveev [1] has now closed. Yes: 12 Veto: 0 Abstain: 0 According to the Bylaws definition of Three Vote Consensus [2], this is sufficient to approve the nomination. -phil. [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2021-May/005495.html [2] https://openjdk.java.net/projects/#reviewer-vote From mark.reinhold at oracle.com Wed May 19 23:14:03 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 19 May 2021 16:14:03 -0700 (PDT) Subject: JEP proposed to target JDK 17: 406: Pattern Matching for switch (Preview) Message-ID: <20210519231403.A132F3E46CB@eggemoggin.niobe.net> The following JEP is proposed to target JDK 17: 406: Pattern Matching for switch (Preview) https://openjdk.java.net/jeps/406 Summary: Enhance the Java programming language with pattern matching for switch expressions and statements, along with extensions to the language of patterns. Extending pattern matching to switch allows an expression to be tested against a number of patterns, each with a specific action, so that complex data-oriented queries can be expressed concisely and safely. 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, 26 May, 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 17. - Mark [1] https://openjdk.java.net/census#jdk [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From david.holmes at oracle.com Thu May 20 01:00:15 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 20 May 2021 11:00:15 +1000 Subject: CFV: New JDK Committer: Yi Yang In-Reply-To: References: Message-ID: <86a71f91-f21b-0123-4f69-8301c64846ae@oracle.com> Vote: yes David On 19/05/2021 7:51 pm, Tobias Hartmann wrote: > I hereby nominate Yi Yang (yyang) to JDK Committer. > > Description by himself: > "I'm working at Alibaba JVM Team for a year, mainly focus on runtime and tool. In runtime, my work > includes making java start up faster and occupies less memory for serverless applications. In tool, > we are trying to deploy JFR and EclipseJIFA in a cloud environment and help users diagnose their > problems. Besides, I'm also very interested in jit compilers, that is what really attracts me among > HotSpot VM. In my spare time, I wrote a JVMCI based C1-like JIT compiler, though, incomplete." > > Yang has contributed 24 patches to JDK [3] and 10 to Valhalla [4], many of which are non-trivial. > > Votes are due by Wednesday, 2 June 2021 at 10: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, > Tobias > > [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%22Yi+Yang%22&type=commits > [4] https://github.com/search?q=is%3Apr+author%3Akelthuzadx+repo%3Aopenjdk%2Fvalhalla+state%3Aclosed > From mikael.vidstedt at oracle.com Thu May 20 06:15:02 2021 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 20 May 2021 06:15:02 +0000 Subject: CFV: New JDK Committer: Yi Yang In-Reply-To: References: Message-ID: Vote: yes Cheers, Mikael > On May 19, 2021, at 2:51 AM, Tobias Hartmann wrote: > > I hereby nominate Yi Yang (yyang) to JDK Committer. > > Description by himself: > "I'm working at Alibaba JVM Team for a year, mainly focus on runtime and tool. In runtime, my work > includes making java start up faster and occupies less memory for serverless applications. In tool, > we are trying to deploy JFR and EclipseJIFA in a cloud environment and help users diagnose their > problems. Besides, I'm also very interested in jit compilers, that is what really attracts me among > HotSpot VM. In my spare time, I wrote a JVMCI based C1-like JIT compiler, though, incomplete." > > Yang has contributed 24 patches to JDK [3] and 10 to Valhalla [4], many of which are non-trivial. > > Votes are due by Wednesday, 2 June 2021 at 10: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, > Tobias > > [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%22Yi+Yang%22&type=commits > [4] https://github.com/search?q=is%3Apr+author%3Akelthuzadx+repo%3Aopenjdk%2Fvalhalla+state%3Aclosed From adinn at redhat.com Thu May 20 11:15:03 2021 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 20 May 2021 12:15:03 +0100 Subject: CFV: New JDK Committer: Yi Yang In-Reply-To: References: Message-ID: <239bfa99-9201-124c-fb84-9d0adf77963e@redhat.com> Vote: yes On 19/05/2021 10:51, Tobias Hartmann wrote: > I hereby nominate Yi Yang (yyang) to JDK Committer. > > Description by himself: > "I'm working at Alibaba JVM Team for a year, mainly focus on runtime and tool. In runtime, my work > includes making java start up faster and occupies less memory for serverless applications. In tool, > we are trying to deploy JFR and EclipseJIFA in a cloud environment and help users diagnose their > problems. Besides, I'm also very interested in jit compilers, that is what really attracts me among > HotSpot VM. In my spare time, I wrote a JVMCI based C1-like JIT compiler, though, incomplete." > > Yang has contributed 24 patches to JDK [3] and 10 to Valhalla [4], many of which are non-trivial. > > Votes are due by Wednesday, 2 June 2021 at 10: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, > Tobias > > [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%22Yi+Yang%22&type=commits > [4] https://github.com/search?q=is%3Apr+author%3Akelthuzadx+repo%3Aopenjdk%2Fvalhalla+state%3Aclosed > -- 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 felix.yang at huawei.com Thu May 20 12:14:14 2021 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Thu, 20 May 2021 12:14:14 +0000 Subject: New JDK Committer: Yi Yang In-Reply-To: References: Message-ID: <09a944ea823845a2b9abbcab40e9a68b@huawei.com> Vote: yes > -----Original Message----- > From: jdk-dev [mailto:jdk-dev-retn at openjdk.java.net] On Behalf Of Tobias > Hartmann > Sent: Wednesday, May 19, 2021 5:52 PM > To: jdk-dev > Subject: CFV: New JDK Committer: Yi Yang > > I hereby nominate Yi Yang (yyang) to JDK Committer. > > Description by himself: > "I'm working at Alibaba JVM Team for a year, mainly focus on runtime and > tool. In runtime, my work includes making java start up faster and occupies > less memory for serverless applications. In tool, we are trying to deploy JFR > and EclipseJIFA in a cloud environment and help users diagnose their > problems. Besides, I'm also very interested in jit compilers, that is what really > attracts me among HotSpot VM. In my spare time, I wrote a JVMCI based C1- > like JIT compiler, though, incomplete." > > Yang has contributed 24 patches to JDK [3] and 10 to Valhalla [4], many of > which are non-trivial. > > Votes are due by Wednesday, 2 June 2021 at 10: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, > Tobias > > [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%22Yi+Yang%22&type=commits > [4] > https://github.com/search?q=is%3Apr+author%3Akelthuzadx+repo%3Aope > njdk%2Fvalhalla+state%3Aclosed From neugens at redhat.com Thu May 20 12:19:56 2021 From: neugens at redhat.com (Mario Torre) Date: Thu, 20 May 2021 14:19:56 +0200 Subject: CFV: New JDK Committer: Yi Yang In-Reply-To: References: Message-ID: Vote: Yes, Cheers, Mario On Wed, May 19, 2021 at 11:52 AM Tobias Hartmann wrote: > > I hereby nominate Yi Yang (yyang) to JDK Committer. > > Description by himself: > "I'm working at Alibaba JVM Team for a year, mainly focus on runtime and tool. In runtime, my work > includes making java start up faster and occupies less memory for serverless applications. In tool, > we are trying to deploy JFR and EclipseJIFA in a cloud environment and help users diagnose their > problems. Besides, I'm also very interested in jit compilers, that is what really attracts me among > HotSpot VM. In my spare time, I wrote a JVMCI based C1-like JIT compiler, though, incomplete." > > Yang has contributed 24 patches to JDK [3] and 10 to Valhalla [4], many of which are non-trivial. > > Votes are due by Wednesday, 2 June 2021 at 10: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, > Tobias > > [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%22Yi+Yang%22&type=commits > [4] https://github.com/search?q=is%3Apr+author%3Akelthuzadx+repo%3Aopenjdk%2Fvalhalla+state%3Aclosed > -- Mario Torre Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From eric.caspole at oracle.com Thu May 20 14:42:41 2021 From: eric.caspole at oracle.com (eric.caspole at oracle.com) Date: Thu, 20 May 2021 10:42:41 -0400 Subject: CFV: New JDK Committer: Yi Yang In-Reply-To: References: Message-ID: <39f561df-c450-98c8-ff70-4fda7252d5f5@oracle.com> Vote: yes Eric On 5/19/21 5:51 AM, Tobias Hartmann wrote: > I hereby nominate Yi Yang (yyang) to JDK Committer. > > Description by himself: > "I'm working at Alibaba JVM Team for a year, mainly focus on runtime and tool. In runtime, my work > includes making java start up faster and occupies less memory for serverless applications. In tool, > we are trying to deploy JFR and EclipseJIFA in a cloud environment and help users diagnose their > problems. Besides, I'm also very interested in jit compilers, that is what really attracts me among > HotSpot VM. In my spare time, I wrote a JVMCI based C1-like JIT compiler, though, incomplete." > > Yang has contributed 24 patches to JDK [3] and 10 to Valhalla [4], many of which are non-trivial. > > Votes are due by Wednesday, 2 June 2021 at 10: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, > Tobias > > [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%22Yi+Yang%22&type=commits > [4] https://github.com/search?q=is%3Apr+author%3Akelthuzadx+repo%3Aopenjdk%2Fvalhalla+state%3Aclosed From stuart.marks at oracle.com Thu May 20 20:26:28 2021 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 20 May 2021 13:26:28 -0700 Subject: API Deprecated/Removal Process In-Reply-To: <4be6b02f-08f2-40e0-bcc7-18a4bb074193@Erics-iPhone-12-Pro-Max> References: <4be6b02f-08f2-40e0-bcc7-18a4bb074193@Erics-iPhone-12-Pro-Max> Message-ID: <6910d402-f4d2-0cf2-a10b-464f39be264e@oracle.com> On 5/12/21 8:43 PM, Eric Bresie wrote: > I know the benefits of API / implementation removal accommodates change and efficiency to the platform, which I welcome however the more removals that happen, the more risk this will break existing application code, the risk of additional cost for updating existing developed products (which not everyone may have the budget to do so given much is spent on updating own products and priorities without having to introduce changes like this, which prior to pruning of API was less a concern with Java), and just plain risks leaving a bad taste in developer and user?s mouth which could drive people away, which no one wants. So with that said... > > What is the process when dealing with deprecated and removed API? Or more specifically use case of alternative implementations? We try to remove only things that are old and obsolete and that have very little usage (e.g., RMI Activation) or things that have little usage but are very expensive to maintain (e.g., Security Manager). There's certainly a risk of breaking projects that use these things, and there are undoubtedly costs imposed on such projects. You also have to account for the cost of having these things in OpenJDK. Costs are imposed not only on the maintainers of OpenJDK but also all of its users. Software doesn't just sit there passively; it requires active maintenance and effort to keep running. These costs aren't always visible. I'll take RMI Activation as an example since it's something that I've worked on. Since RMI Activation involves multiple processes and networking, you shouldn't be surprised to learn that the tests for it are fragile. In a CI environment, there are lots of intermittent failures. Over the years I've put some effort into fixing some of these tests to be more robust. Fixing the tests requires effort, but assessing intermittent failures is also an effort, so either way there are costs. It turns out that the JDK 8-update project is also interested in improving test reliablity, so they're backporting some of these test fixes: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-April/013761.html I'm a bit surprised, but then again, maybe I shouldn't be. The costs of intermittent failures are larger than one might think, so it justified the effort of fixing the tests and even backporting those test fixes. There are also costs on users, but they're more indirect. Users might ask, "Why can't you add feature X?" Part of the answer might be, "Feature X seems useful, but we haven't yet figured out how to make it work with the security manager." Or sometimes it's pure opportunity cost. For example, I might have wanted to get feature Y into this release, but I didn't have time because I was fixing security vulnerabilities in RMI Activation. Thus, feature Y got pushed to the next release, or it got dropped altogether. When these costs get out of balance with the value a feature is providing, then we consider removing it. > I understand depreciation/removal details are usually document in applicable API content and JEP 277 Enhanced Deprecation (https://openjdk.java.net/jeps/277) provides rational and how to annotate things and denotes the need to utilize new interface if available or to use alternative implementation. > > So define aspects of handoff activities to include potential donation of deprecated/removed code, forking to the alternative, address licensing concerns, how to handle name-spacing concerns (i.e. is the old namespace available or does new namespace needed), and documenting alternatives (i.e. tracking alternatives via wiki, doc, javadoc/api, etc). > > Or could some form of dependency injection be used to specify alternatives to ease the transition? I'm not entirely sure what you're asking here. If OpenJDK removes some feature, and some project depends on that feature, then that project has to deal with it somehow. There's not much that OpenJDK can do about this, because the range of possible actions a project can take is too broad. A project might decide to stay on JDK 11 indefinitely. It will have a long service lifetime, so that might be sufficient for some projects. Even after its support lifetime ends, a project can move to a self-support model. Of course, this incurs greater costs and risks. At some point they will outweigh the cost of migrating to a newer JDK or even rewriting the project, so one of those will get done. Or perhaps those costs outweigh the benefit the project is providing, which means the project is just abandoned. Some of the stuff that's been removed has an easy technical solution, like JAXB, which has always been available as a separate jar. Other things, like the security manager, are too pervasive to be packaged separately. In that case, something depending on the security manager will need to be rethought. Undoubtedly these changes will cause somebody somewhere some pain. But our primary task here is to look after the whole project, on behalf of all the maintainers and consumers, and try to balance things out. s'marks From mike.rettig at gmail.com Thu May 20 22:48:18 2021 From: mike.rettig at gmail.com (Mike Rettig) Date: Thu, 20 May 2021 17:48:18 -0500 Subject: JEP proposed to target JDK 17: 406: Pattern Matching for switch (Preview) Message-ID: Will non-expression switches be exhaustive? I know that this has been discussed but I wanted to confirm the behavior for jdk 17. https://mail.openjdk.java.net/pipermail/amber-spec-experts/2021-April/002959.html Sealed classes will be far more useful with exhaustiveness. Thanks, Mike From forax at univ-mlv.fr Fri May 21 07:07:34 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 21 May 2021 09:07:34 +0200 (CEST) Subject: JEP proposed to target JDK 17: 406: Pattern Matching for switch (Preview) In-Reply-To: References: Message-ID: <836273750.803875.1621580854520.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Mike Rettig" > ?: "jdk-dev" > Envoy?: Vendredi 21 Mai 2021 00:48:18 > Objet: Re: JEP proposed to target JDK 17: 406: Pattern Matching for switch (Preview) > Will non-expression switches be exhaustive? I know that this has been > discussed but I wanted to confirm the behavior for jdk 17. > > https://mail.openjdk.java.net/pipermail/amber-spec-experts/2021-April/002959.html > > Sealed classes will be far more useful with exhaustiveness. yes, see 15.28.1 of the current spec [1]. > > Thanks, > > Mike regards, R?mi [1] https://cr.openjdk.java.net/~gbierman/jep406/jep406-20210514/specs/patterns-switch-jls.html From mike.rettig at gmail.com Fri May 21 13:22:37 2021 From: mike.rettig at gmail.com (Mike Rettig) Date: Fri, 21 May 2021 08:22:37 -0500 Subject: JEP proposed to target JDK 17: 406: Pattern Matching for switch (Preview) In-Reply-To: <836273750.803875.1621580854520.JavaMail.zimbra@u-pem.fr> References: <836273750.803875.1621580854520.JavaMail.zimbra@u-pem.fr> Message-ID: On Fri, May 21, 2021 at 2:07 AM Remi Forax wrote: > ----- Mail original ----- > > De: "Mike Rettig" > > Will non-expression switches be exhaustive? I know that this has been > > discussed but I wanted to confirm the behavior for jdk 17. > > > > > https://mail.openjdk.java.net/pipermail/amber-spec-experts/2021-April/002959.html > > > > Sealed classes will be far more useful with exhaustiveness. > > yes, > see 15.28.1 of the current spec [1]. 15.28.1 is specifically referring to switch expressions. I am asking about the non-expression form. Will this switch compile even though it is not exhaustive? abstract sealed class Shape {...} ... class Circle extends Shape {...} ... class Rectangle extends Shape {...} Shape s = .... switch(s){ case Circle c ->{handleCircle(c);} //no case for Rectangle or default } From forax at univ-mlv.fr Fri May 21 13:44:13 2021 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Fri, 21 May 2021 15:44:13 +0200 (CEST) Subject: JEP proposed to target JDK 17: 406: Pattern Matching for switch (Preview) In-Reply-To: References: <836273750.803875.1621580854520.JavaMail.zimbra@u-pem.fr> Message-ID: <477029027.1402020.1621604653841.JavaMail.zimbra@u-pem.fr> > De: "Mike Rettig" > ?: "Remi Forax" > Cc: "jdk-dev" > Envoy?: Vendredi 21 Mai 2021 15:22:37 > Objet: Re: JEP proposed to target JDK 17: 406: Pattern Matching for switch > (Preview) > On Fri, May 21, 2021 at 2:07 AM Remi Forax < [ mailto:forax at univ-mlv.fr | > forax at univ-mlv.fr ] > wrote: >> ----- Mail original ----- >> > De: "Mike Rettig" < [ mailto:mike.rettig at gmail.com | mike.rettig at gmail.com ] > >> > Will non-expression switches be exhaustive? I know that this has been >> > discussed but I wanted to confirm the behavior for jdk 17. >>> [ >>> https://mail.openjdk.java.net/pipermail/amber-spec-experts/2021-April/002959.html >>> | >>> https://mail.openjdk.java.net/pipermail/amber-spec-experts/2021-April/002959.html >> > ] >> > Sealed classes will be far more useful with exhaustiveness. >> yes, >> see 15.28.1 of the current spec [1]. > 15.28.1 is specifically referring to switch expressions. I am asking about the > non-expression form. > Will this switch compile even though it is not exhaustive? my bad, in the changelog: A switch statement that uses the new features of this JEP is now required to be complete (the same notion that all switch expressions require) The rule for completness is in 14.11.1 the three rules after "A switch block is complete for a selector expression if the following are true:" > abstract sealed class Shape {...} > ... class Circle extends Shape {...} > ... class Rectangle extends Shape {...} > Shape s = .... > switch(s){ > case Circle c ->{handleCircle(c);} > //no case for Rectangle or default > } It's a sealed type so this specific rule applies: If the type of the selector expression, T , names a sealed interface or a sealed class that is abstract then at least one of the following is true: 1. All of the permitted subtypes of T are covered by the switch block. Rectangle is a permitted subtype but there is no case for it, so the switch statement is not complete. R?mi From mike.rettig at gmail.com Fri May 21 14:09:31 2021 From: mike.rettig at gmail.com (Mike Rettig) Date: Fri, 21 May 2021 09:09:31 -0500 Subject: JEP proposed to target JDK 17: 406: Pattern Matching for switch (Preview) In-Reply-To: <477029027.1402020.1621604653841.JavaMail.zimbra@u-pem.fr> References: <836273750.803875.1621580854520.JavaMail.zimbra@u-pem.fr> <477029027.1402020.1621604653841.JavaMail.zimbra@u-pem.fr> Message-ID: On Fri, May 21, 2021 at 8:44 AM wrote: > It's a sealed type so this specific rule applies: > > If the type of the selector expression, *T*, names a sealed interface > or a sealed class that is abstract then at least one of the following is > true: > > 1. > > All of the permitted subtypes of *T* are covered by the switch block. > > Rectangle is a permitted subtype but there is no case for it, so the > switch statement is not complete. > > R?mi > Thanks for the clarification. So enums and sealed types behave differently with switch? This compiles just fine with jdk 16. enum Shape { Circle, Rectangle } Shape s = ...; switch (s){ case Circle -> { System.out.println("Circle"); } } It's not consistent, but I guess it's better than the alternatives. Sealed types without exhaustiveness aren't very useful. Mike From alex.buckley at oracle.com Fri May 21 17:23:24 2021 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 21 May 2021 10:23:24 -0700 Subject: Updates to JEP 411: Deprecate the Security Manager for Removal In-Reply-To: <9272f796-4268-a674-b648-49ff26ad3bc6@oracle.com> References: <9272f796-4268-a674-b648-49ff26ad3bc6@oracle.com> Message-ID: <56ee1652-9d5e-4bde-b14f-b861e9ea2987@oracle.com> A further point is that `-Djava.security.manager=allow` has been special-cased since JDK 12: - RFE: https://bugs.openjdk.java.net/browse/JDK-8191053 - Compatibility review: https://bugs.openjdk.java.net/browse/JDK-8203316 - Release note: https://www.oracle.com/java/technologies/javase/12-relnote-issues.html#JDK-8191053 (I saw that Netbeans has run into trouble under JEP 411 because some code does not recognize `allow`, and treats it as a class name: https://issues.apache.org/jira/browse/NETBEANS-5703) Alex On 5/19/2021 6:48 AM, Sean Mullan wrote: > Thanks for those that have taken the time to review JEP 411 [1]. The JEP > has been updated today with a few changes, the most significant which is > the addition of a new section titled "Future Work" [2] which lists > related potential enhancements and works in progress. > > Other smaller changes have been made throughout the JEP, including: > > ?- The "Alternate JAAS APIs" section has been removed and replaced with > a smaller section in the Description section with a pointer to a JBS > issue with more details. > > ?- Changes have been made to the Motivation section to improve some of > the wording and add more details. > > ?- A new item named "Preserve the Security Manager API for extension by > custom Security Managers that wish to intercept, log, and veto access to > resources" has been added to the Alternatives section, as this has been > a topic of discussion since the JEP has been published. > > ?- RMISecurityException has been removed from the list of APIs to be > deprecated for removal, and > java.util.concurrent.Executors::{privilegedCallable, > privilegedCallableUsingCurrentClassLoader, privilegedThreadFactory} have > been added. > > Thanks, > Sean > > [1] https://openjdk.java.net/jeps/411 > [2] https://openjdk.java.net/jeps/411#Future-Work From sandhya.viswanathan at intel.com Fri May 21 20:18:30 2021 From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya) Date: Fri, 21 May 2021 20:18:30 +0000 Subject: CFV: New JDK Committer: Yi Yang In-Reply-To: References: Message-ID: Vote: yes Best Regards, Sandhya -----Original Message----- From: jdk-dev On Behalf Of Tobias Hartmann Sent: Wednesday, May 19, 2021 2:52 AM To: jdk-dev Subject: CFV: New JDK Committer: Yi Yang I hereby nominate Yi Yang (yyang) to JDK Committer. Description by himself: "I'm working at Alibaba JVM Team for a year, mainly focus on runtime and tool. In runtime, my work includes making java start up faster and occupies less memory for serverless applications. In tool, we are trying to deploy JFR and EclipseJIFA in a cloud environment and help users diagnose their problems. Besides, I'm also very interested in jit compilers, that is what really attracts me among HotSpot VM. In my spare time, I wrote a JVMCI based C1-like JIT compiler, though, incomplete." Yang has contributed 24 patches to JDK [3] and 10 to Valhalla [4], many of which are non-trivial. Votes are due by Wednesday, 2 June 2021 at 10: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, Tobias [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%22Yi+Yang%22&type=commits [4] https://github.com/search?q=is%3Apr+author%3Akelthuzadx+repo%3Aopenjdk%2Fvalhalla+state%3Aclosed From mark.reinhold at oracle.com Fri May 21 22:40:56 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 21 May 2021 15:40:56 -0700 Subject: JEP proposed to target JDK 17: 412: Foreign Function & Memory API (Incubator) Message-ID: <20210521154056.888292555@eggemoggin.niobe.net> 2021/5/13 16:09:39 -0700, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 17: > > 412: Foreign Function & Memory API (Incubator) > https://openjdk.java.net/jeps/412 > > Summary: Introduce an API by which Java programs can interoperate with > code and data outside of the Java runtime. By efficiently invoking > foreign functions (i.e., code outside the JVM), and by safely accessing > foreign memory (i.e., memory not managed by the JVM), the API enables > Java programs to call native libraries and process native data without > the brittleness and danger of JNI. > > 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 Thursday, 20 May, 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 17. Hearing no objections, I?ve targeted this JEP to JDK 17. - Mark From mark.reinhold at oracle.com Fri May 21 23:03:47 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 21 May 2021 16:03:47 -0700 (PDT) Subject: JEP proposed to target JDK 17: 411: Deprecate the Security Manager for Removal Message-ID: <20210521230347.78ACB3E4C33@eggemoggin.niobe.net> The following JEP is proposed to target JDK 17: 411: Deprecate the Security Manager for Removal https://openjdk.java.net/jeps/411 Summary: Deprecate the Security Manager for removal in a future release. The Security Manager dates from Java 1.0. It has not been the primary means of securing client-side Java code for many years, and it has rarely been used to secure server-side code. To move Java forward, we intend to deprecate the Security Manager for removal in concert with the legacy Applet API (JEP 398). 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 Friday, 28 May, 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 17. - Mark [1] https://openjdk.java.net/census#jdk [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From mark.reinhold at oracle.com Fri May 21 23:03:46 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 21 May 2021 16:03:46 -0700 (PDT) Subject: JEP proposed to target JDK 17: 306: Restore Always-Strict Floating-Point Semantics Message-ID: <20210521230346.5C6693E4C31@eggemoggin.niobe.net> The following JEP is proposed to target JDK 17: 306: Restore Always-Strict Floating-Point Semantics https://openjdk.java.net/jeps/306 Summary: Make floating-point operations consistently strict, rather than have both strict floating-point semantics (strictfp) and subtly different default floating-point semantics. This will restore the original floating-point semantics to the language and VM, matching the semantics before the introduction of strict and default floating-point modes in Java SE 1.2. 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 Friday, 28 May, 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 17. - Mark [1] https://openjdk.java.net/census#jdk [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From liangchenblue at gmail.com Sat May 22 01:50:15 2021 From: liangchenblue at gmail.com (-) Date: Fri, 21 May 2021 20:50:15 -0500 Subject: invokeinterface on sealed interfaces Message-ID: Greetings all, I have heard of a myth against using interfaces, namely on how invokeinterface is slower than invokevirtual since concrete class methods to call, with known indices in the method table, can be found more easily than interface methods, which always require a lookup by name. Another myth I've heard is that JVM may decide to construct a temporary table for interface dispatches as well, but the table would be discarded once another class is discovered in the interface hierarchy and the performance would slow back down. I wonder if these two claims are right; unfortunately, I am no good at the VM internals and can't verify them. But if they are true, I wonder if invokeinterface calls on sealed interface methods would enjoy a performance boost and have its performance brought closer to that of invokevirtual calls. It seems that the sealed class design not only provides clearer apis, but also allow the VM to better optimize code. Best From david.holmes at oracle.com Sat May 22 02:38:43 2021 From: david.holmes at oracle.com (David Holmes) Date: Sat, 22 May 2021 12:38:43 +1000 Subject: invokeinterface on sealed interfaces In-Reply-To: References: Message-ID: Hi, Probably something best discussed on hotspot-dev (cc'd) or perhaps hotspot-compiler-dev. Disclaimer: I'm not a JIT expert. :) On 22/05/2021 11:50 am, - wrote: > Greetings all, > I have heard of a myth against using interfaces, namely on how > invokeinterface is slower than invokevirtual since concrete class methods > to call, with known indices in the method table, can be found more easily > than interface methods, which always require a lookup by name. Not sure about that part. > Another myth I've heard is that JVM may decide to construct a temporary > table for interface dispatches as well, but the table would be discarded > once another class is discovered in the interface hierarchy and the > performance would slow back down. This happens for classes and virtual methods too. Class Hierarchy Analysis (CHA) can be used to devirtualise a call-site if we know there can't be subclasses to distinguish. If a subclass is subsequently loaded then that analysis has to be discarded and the code deoptimised so the call site is virtualised again. > I wonder if these two claims are right; unfortunately, I am no good at the > VM internals and can't verify them. But if they are true, I wonder if > invokeinterface calls on sealed interface methods would enjoy a performance > boost and have its performance brought closer to that of invokevirtual > calls. It seems that the sealed class design not only provides clearer > apis, but also allow the VM to better optimize code. I'm not sure if there is much scope for additional optimisation beyond the fact that if all subclasses are known when CHA is applied then we know it can't be invalidated later. JIT compiler folk may be able to say more. Cheers, David > Best > From vitalyd at gmail.com Sat May 22 03:08:39 2021 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 21 May 2021 23:08:39 -0400 Subject: invokeinterface on sealed interfaces In-Reply-To: References: Message-ID: https://wiki.openjdk.java.net/display/HotSpot/InterfaceCalls is an old but (I believe) still accurate description of how invokeinterface is dispatched (if not monomorphized by the JIT). In short, it doesn?t look up the method by name but it does walk the receiver (ie object on which method is being invoked) class?s list of interfaces to ensure it implements the interface in question. Once found, there?s an itable (similar in concept to vtable) associated with that class?s implementation of the interface. As for the more general question around dispatch performance, https://shipilev.net/blog/2015/black-magic-method-dispatch/ is a good writeup by Aleksey. While some things may look expensive (eg invokeinterface), the high tier JITs typically do a good job of making them more efficient, leveraging runtime callsite type profiling. Hope that helps. On Fri, May 21, 2021 at 10:39 PM David Holmes wrote: > Hi, > > Probably something best discussed on hotspot-dev (cc'd) or perhaps > hotspot-compiler-dev. > > Disclaimer: I'm not a JIT expert. :) > > On 22/05/2021 11:50 am, - wrote: > > Greetings all, > > I have heard of a myth against using interfaces, namely on how > > invokeinterface is slower than invokevirtual since concrete class methods > > to call, with known indices in the method table, can be found more easily > > than interface methods, which always require a lookup by name. > > Not sure about that part. > > > Another myth I've heard is that JVM may decide to construct a temporary > > table for interface dispatches as well, but the table would be discarded > > once another class is discovered in the interface hierarchy and the > > performance would slow back down. > > This happens for classes and virtual methods too. Class Hierarchy > Analysis (CHA) can be used to devirtualise a call-site if we know there > can't be subclasses to distinguish. If a subclass is subsequently loaded > then that analysis has to be discarded and the code deoptimised so the > call site is virtualised again. > > > I wonder if these two claims are right; unfortunately, I am no good at > the > > VM internals and can't verify them. But if they are true, I wonder if > > invokeinterface calls on sealed interface methods would enjoy a > performance > > boost and have its performance brought closer to that of invokevirtual > > calls. It seems that the sealed class design not only provides clearer > > apis, but also allow the VM to better optimize code. > > I'm not sure if there is much scope for additional optimisation beyond > the fact that if all subclasses are known when CHA is applied then we > know it can't be invalidated later. JIT compiler folk may be able to say > more. > > Cheers, > David > > > Best > > > -- Sent from my phone From mark.yagnatinsky at barclays.com Sat May 22 05:39:00 2021 From: mark.yagnatinsky at barclays.com (mark.yagnatinsky at barclays.com) Date: Sat, 22 May 2021 05:39:00 +0000 Subject: invokeinterface on sealed interfaces In-Reply-To: References: Message-ID: I'm usually just a lurker on this list, and there are plenty of real experts here who can give you a more detailed answer, but let me try anyway. This will be a two-part answer. In part 1, I will try to answer your question. In part 2 I'll try to convince you that it's the wrong question: the secret to fast method calls lies elsewhere. Actually, let me give a sneak preview of part 2, and then I'll begin part 1, and eventually return to part 2. The sneak preview is just 3 lines: Ask not how Java can make interface calls as fast as virtual calls, for virtual calls are too slow. Nor ask how to make virtual calls as fast as static calls, for even static calls are too slow. Instead, ask how to make interface calls as fast as no calls at all. Okay, that's it for the sneak preview. Time for part 1. An old but probably still accurate description of invoking through an interface is here: https://wiki.openjdk.java.net/display/HotSpot/InterfaceCalls I don't see anything about discarding tables if another class is found. (Maybe I missed it; I only skimmed it superficially.) I haven't thought about it too much, but it seems sealing doesn't help much here. What makes virtual calls so cheap is that each class has only one base class, but may implement many interfaces. Sealed doesn't change this. (Again, I haven't thought too much; there may be a really neat trick that can make good use of sealed-ness.) This concludes part 1 of my answer. Now we begin part 2. There are two kinds of methods: big/expensive, and fast/cheap. For example, if a method merely increments an integer field, it is fast and cheap. If it makes an SQL query to a database halfway around the world, it is slow. If a method is slow, then method invocation overhead doesn't matter: it's counting a few nanoseconds when many milliseconds are at stake. On the other hand, for cheap methods, it matters a lot. And here, even a virtual call is too slow, let alone an interface call. In fact, even a static call (using invokestatic or invokespecial) is still too slow! And calling cheap methods through an interface is common in Java! For instance, suppose you have an ArrayList, and you want to loop through it using a for-each loop. This involves getting the iterator from the list, and then calling next() and hasNext() and bunch of times. Now obviously, Iterator is an interface that will never be sealed: that would defeat its point. But we still want this loop to run fast. And note that we have a classic example of two very cheap methods: next() is basically "i++" and hasNext() is basically "i < n". Call overhead should matter a lot here! Luckily, there's a trick that works quite well. The JVM eventually notices "I've called next() on line 123 a few hundred times already, and every time it turned out to be a method on ArrayList.Itr". It then makes a bet with itself: I bet that line 123 will keep acting the same way in the future, so I'm going to fire up the JIT compiler, and have it emit code like this: If(iterator.getClass() == ArrayList.Iter.class) call the method directly Else do the usual slow thing If the class is what we expected, we pay only the price of a static call, not a virtual call. But this is still too much. But now the solution is easy: since we have a static call, we can just inline it! And once we do, that brings in more benefits! It allows the JIT compiler to treat the loop body as one unified whole. Whereas before, it would have to worry "who knows what this mysterious hasNext() method might do? Maybe it does I/O. Maybe it starts new threads. Maybe it writes to global variables. I'd better be careful to make sure the code I generate works no matter what crazy stuff this method does." Whereas as after hasNext() is inlined directly into the loop, life is simpler: "this is just a simple test with no side-effects at all. I can optimize this aggressively with no fear." And that's why the price of virtual calls doesn't matter too much: Java tries to make sure that you rarely have to pay for them if it matters. -----Original Message----- From: liangchenblue at gmail.com Sent: Friday, May 21, 2021 9:50 PM To: jdk-dev at openjdk.java.net Subject: invokeinterface on sealed interfaces Greetings all, I have heard of a myth against using interfaces, namely on how invokeinterface is slower than invokevirtual since concrete class methods to call, with known indices in the method table, can be found more easily than interface methods, which always require a lookup by name. Another myth I've heard is that JVM may decide to construct a temporary table for interface dispatches as well, but the table would be discarded once another class is discovered in the interface hierarchy and the performance would slow back down. I wonder if these two claims are right; unfortunately, I am no good at the VM internals and can't verify them. But if they are true, I wonder if invokeinterface calls on sealed interface methods would enjoy a performance boost and have its performance brought closer to that of invokevirtual calls. It seems that the sealed class design not only provides clearer apis, but also allow the VM to better optimize code. Best _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ ?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 david.lloyd at redhat.com Sat May 22 14:11:32 2021 From: david.lloyd at redhat.com (David Lloyd) Date: Sat, 22 May 2021 09:11:32 -0500 Subject: JEP proposed to target JDK 17: 411: Deprecate the Security Manager for Removal In-Reply-To: <20210521230347.78ACB3E4C33@eggemoggin.niobe.net> References: <20210521230347.78ACB3E4C33@eggemoggin.niobe.net> Message-ID: On Fri, May 21, 2021 at 6:04 PM wrote: > The following JEP is proposed to target JDK 17: > > 411: Deprecate the Security Manager for Removal > https://openjdk.java.net/jeps/411 I'm not a committer or reviewer, so perhaps my feedback is unwelcome - but one can't help but note the amount of heated discussion on this topic, and the determination of whether or not the problematic points have been addressed satisfactorily is probably pretty subjective. I have a bit of experience in this area, having either designed or having had a major part of the design of the authentication and authorization APIs presently in use in WildFly [1], as well as the WildFly security manager [2] (and a significant number of other security-related APIs), so I thought I'd give some feedback and also offer a possible compromise. The security manager defines a variety of behaviors. Some of these have clearly been supplanted by other APIs (like getClassContext() vs StackWalker) or security mechanisms (checkPackageAccess() and friends vs the new encapsulation protections). There are also however other APIs on the security manager which clearly have no replacement. These include socket and file access checking APIs, and of course the general permission check methods. In addition, the JEP proposes deprecation of the access controller and policy classes which are the mechanism of stack-based access checking, and finally unavoidably bumps against JAAS, which itself is a very difficult and problematic API which also uses the same stack-based access mechanism (and which we here at Red Hat have for the most part long since abandoned). A large part of this deprecated machinery relates to the stack-based access controller (not to mention, I believe, a nontrivial number of CVEs). The idea, of course, was that one can authenticate untrusted or semi-trusted code. It is definitely clear through years of experience on all sides though that one cannot truly rely on this mechanism to protect against malicious code; it is as easy as an infinite loop to cause massive undesired CPU usage (and, in this modern $/cpu world, cost) for example. However, one other undeniably useful function of the security manager is to authorize basic native operations *not* in the context of what code is executing, but what person or principal is executing it. In other words, the use case of *trusted* code running on behalf of one of many potentially untrusted users - probably the widest application of server-side Java in existence today. It cannot be argued that removing all of the above security checks does not weaken security of such users, when they could have a narrower authorization applied to them to limit the possibility of impact of server exploitation. On the other hand, the cost of the SecurityManager mechanism as it stands is undeniably too high; there is absolutely no point in arguing otherwise, in my view. Leaving aside the substantial CVE load, the access controller and policy APIs are very difficult to use correctly by containers and frameworks, for one thing, and are cumbersome for users as well. Many users and frameworks get doPrivileged() wrong, and combining JAAS subjects into the same mechanism historically doesn't even work consistently between otherwise-compliant JDK implementations. What I would propose then is a compromise aimed at maximizing the amount of value retained and minimizing the amount of cost incurred, by *only* retaining permission checks that specifically pertain to or are useful for user authorization, while *also* deprecating (for removal) the existing problem-prone stack-based access checking mechanism, policy, and security manager implementation. Thus I would suggest not deprecating all of SecurityManager, rather just the following: * java.lang.SecurityManager#getClassContext - it is replaced by StackWalker * java.lang.SecurityManager#getSecurityContext * java.lang.SecurityManager#checkCreateClassLoader * java.lang.SecurityManager#checkPermission(java.security.Permission, java.lang.Object) - the overload which accepts a "security context" * java.lang.SecurityManager#checkPackageAccess * java.lang.SecurityManager#checkPackageDefinition * java.lang.SecurityManager#checkSecurityAccess * java.lang.SecurityManager#getThreadGroup ...as well as their dependent methods and security checks. These checks generally pertain to determining whether the application or its frameworks are trusted to perform certain operations, but are far less useful for user authorization, as far as I can determine. I would probably even include the system property access methods as well - though I saw Peter arguing that those in particular were useful, I have my doubts, but that could obviously be worked out. Further I would recommend the following change: make java.lang.SecurityManager#checkPermission(java.security.Permission) either a no-op or throw UnsupportedOperationException. Ideally, SecurityManager and checkPermission() would be made abstract (and, for completeness, the SecurityManager constructor); perhaps after the deprecation period, such a change could be made. It's a bit tricky here, because the deprecation policy doesn't seem to cover the case of making a concrete class or method abstract. The remaining proposal would need slight modification in certain ways: for example, the security manager allow/forbid flags would still make sense and need to be retained, and the permission checks in socket and file system code would need to be retained. After this change, SecurityManager would be decoupled from the stack-based access controller. This means that any implementation of authorization would be the responsibility of third-party libraries. The remaining JDK authorization checks would then be easily testable - much more so than today, because the contract becomes substantially simpler in the absence of AccessController - and still usable by third party security managers to perform user authorization checks on these native operations. And, it would still be possible for third parties to provide stack-based access control checks using StackWalker for an extra level of security with absolutely zero additional cost to JDK maintenance (and the burden of coping with the lack of doPrivileged would reside squarely on the third party). As for JAAS, nobody would be happier than us to see it just go away, though that may be beyond the scope of this change. The proposed scope locals give what is potentially a very good opportunity to employ a vastly superior means of propagating security context between tasks. Under this proposal, a third-party security manager which uses a scope local security context for authorization would not only be a useful and measurable security improvement over an "unsecured" JDK, but would also likely be substantially more performant (and, if I may say so, reliable) than anything using JAAS today. It should even be possible, in the future, to standardize on a new authentication and authorization identity propagation API using these mechanisms - at least in Jakarta EE and/or MicroProfile, if not in the JDK itself. Essentially what I propose is only slightly departed from the current JEP 411 proposal, by introducing the exception of retaining certain permission checks and the security manager class itself. Please give this compromise some consideration. Thanks! [1] https://github.com/wildfly-security/wildfly-elytron [2] originally: https://github.com/wildfly-security/security-manager/blob/master/src/main/java/org/wildfly/security/manager/WildFlySecurityManager.java - which is now: https://github.com/wildfly-security/wildfly-elytron/blob/1.x/manager/base/src/main/java/org/wildfly/security/manager/WildFlySecurityManager.java -- - DML ? he/him From jini at zeus.net.au Mon May 24 01:09:30 2021 From: jini at zeus.net.au (jini at zeus.net.au) Date: Mon, 24 May 2021 11:09:30 +1000 Subject: Java 2.0 migration planning. JEP's for removal. Message-ID: Will RMI and the RMI registry be put up for removal soon? Just seeing the writing on the wall here, with other components being removed, I was wondering when will RMI be proposed for removal. We still use some RMI interfaces and exceptions in our API's but don't use the RMI implementation (except for the RMI registry that occurs over TLS sockets on the local machine), same for Activation. I'm guessing if we need to make a breaking release of our software, we might as well get all the breaking code out of the way in one go, rather than make multiple breaking releases as Java removes parts of its API's. Betting Serialization will be removed at some point too, we will also want to remove all Java Serialization as well. Can we get an indication on what's on the chopping block so we can start to consider how to handle it? Thinking we are going to need to maintain two separate forks of our software to support both Java 2.0 and Java 1.8 to 1.17. We could bundle all the insecure code, such as TCP connections into one release without any dependencies on JAAS or SecurityManager, and remove all AccessController.doPrivileged etc, to be used on private networks, which will later utilise the new security features in later versions of Java 2.0 that are yet to be determined, we would also remove all Permissions and policy, and remove the ability to transfer a calling subject from one JVM to another, so this would be designed to be used on local networks behind a firewall, this will have no migration cost for users moving to Java 2.0.? Rather than attempt to duplicate current security functionality, we would simply remove it. We would make the other release our secure release, for use on untrusted networks, including the internet, which would include our implementation of Activation, used as a service watchdog, TLS and Kerberos connections that depend on JAAS and SecurityManager and AccessController and principles of least privilege.? This won't work on Java 2.0, but people who require security would need to continue to use it for the foreseeable future, until it becomes clearer what the new best practices will be to lock down Java securely, it's possible we may never migrate this version to Java 2.0. This way we could serve both Java markets. -- Regards, Peter Firmstone Zeus Project Services Pty Ltd. From ningsheng.jian at arm.com Mon May 24 02:15:31 2021 From: ningsheng.jian at arm.com (Ningsheng Jian) Date: Mon, 24 May 2021 10:15:31 +0800 Subject: CFV: New JDK Committer: Yi Yang In-Reply-To: References: Message-ID: <11b88ad1-5555-f16c-ca0e-57723ff640ae@arm.com> Vote: yes Regards, Ningsheng On 5/19/21 5:51 PM, Tobias Hartmann wrote: > I hereby nominate Yi Yang (yyang) to JDK Committer. > > Description by himself: > "I'm working at Alibaba JVM Team for a year, mainly focus on runtime and tool. In runtime, my work > includes making java start up faster and occupies less memory for serverless applications. In tool, > we are trying to deploy JFR and EclipseJIFA in a cloud environment and help users diagnose their > problems. Besides, I'm also very interested in jit compilers, that is what really attracts me among > HotSpot VM. In my spare time, I wrote a JVMCI based C1-like JIT compiler, though, incomplete." > > Yang has contributed 24 patches to JDK [3] and 10 to Valhalla [4], many of which are non-trivial. > > Votes are due by Wednesday, 2 June 2021 at 10: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, > Tobias > > [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%22Yi+Yang%22&type=commits > [4] https://github.com/search?q=is%3Apr+author%3Akelthuzadx+repo%3Aopenjdk%2Fvalhalla+state%3Aclosed > From fw at deneb.enyo.de Mon May 24 13:02:47 2021 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 24 May 2021 15:02:47 +0200 Subject: JEP proposed to target JDK 17: 409: Sealed Classes In-Reply-To: <20210505221756.55F613E2C15@eggemoggin.niobe.net> (mark reinhold's message of "Wed, 5 May 2021 15:17:56 -0700 (PDT)") References: <20210505221756.55F613E2C15@eggemoggin.niobe.net> Message-ID: <87k0nouvwo.fsf@mid.deneb.enyo.de> * mark reinhold: > The following JEP is proposed to target JDK 17: > > 409: Sealed Classes > https://openjdk.java.net/jeps/409 > > Summary: Enhance the Java programming language with sealed classes and > interfaces. Sealed classes and interfaces restrict which other classes > or interfaces may extend or implement them. > > 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, 12 May, 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 17. I've got a question regarding this example from the JEP: | Sealing a class restricts its subclasses. User code can inspect an | instance of a sealed class with an if-else chain of instanceof tests, | one test per subclass; no catch-all else clause is needed. For | example, the following code looks for the three permitted subclasses | of Shape: | | Shape rotate(Shape shape, double angle) { | if (shape instanceof Circle) return shape; | else if (shape instanceof Rectangle) return shape.rotate(angle); | else if (shape instanceof Square) return shape.rotate(angle); | // no else needed! | } With JEP 409, there is no way to make this actually compile with suitable definitions for Shape/Circle/Rectangle/Square, right? I looked at the JLS changes, and I don't see a way they could enable anything like this. I expect functionality like this will be delived as part of JEP 406, but with different syntax. From fw at deneb.enyo.de Mon May 24 13:04:31 2021 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 24 May 2021 15:04:31 +0200 Subject: JEP proposed to target JDK 17: 406: Pattern Matching for switch (Preview) In-Reply-To: <20210519231403.A132F3E46CB@eggemoggin.niobe.net> (mark reinhold's message of "Wed, 19 May 2021 16:14:03 -0700 (PDT)") References: <20210519231403.A132F3E46CB@eggemoggin.niobe.net> Message-ID: <87fsycuvts.fsf@mid.deneb.enyo.de> * mark reinhold: > The following JEP is proposed to target JDK 17: > > 406: Pattern Matching for switch (Preview) > https://openjdk.java.net/jeps/406 > > Summary: Enhance the Java programming language with pattern matching > for switch expressions and statements, along with extensions to the > language of patterns. Extending pattern matching to switch allows > an expression to be tested against a number of patterns, each with a > specific action, so that complex data-oriented queries can be expressed > concisely and safely. I think the formatter(Object) and formatterPatternSwitch(Object) example implementations should be aligned ("unknown" vs o.String()). From sean.mullan at oracle.com Mon May 24 15:29:11 2021 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 24 May 2021 11:29:11 -0400 Subject: JEP proposed to target JDK 17: 411: Deprecate the Security Manager for Removal In-Reply-To: References: <20210521230347.78ACB3E4C33@eggemoggin.niobe.net> Message-ID: <0ba7b17f-a967-214c-4149-8627c7bac801@oracle.com> Comments inline ... On 5/22/21 10:11 AM, David Lloyd wrote: > On Fri, May 21, 2021 at 6:04 PM wrote: > >> The following JEP is proposed to target JDK 17: >> >> 411: Deprecate the Security Manager for Removal >> https://openjdk.java.net/jeps/411 > > > I'm not a committer or reviewer, so perhaps my feedback is unwelcome - but > one can't help but note the amount of heated discussion on this topic, and > the determination of whether or not the problematic points have been > addressed satisfactorily is probably pretty subjective. I have a bit of > experience in this area, having either designed or having had a major part > of the design of the authentication and authorization APIs presently in use > in WildFly [1], as well as the WildFly security manager [2] (and a > significant number of other security-related APIs), so I thought I'd give > some feedback and also offer a possible compromise. > > The security manager defines a variety of behaviors. Some of these have > clearly been supplanted by other APIs (like getClassContext() vs > StackWalker) or security mechanisms (checkPackageAccess() and friends vs > the new encapsulation protections). There are also however other APIs on > the security manager which clearly have no replacement. These include > socket and file access checking APIs, and of course the general permission > check methods. In addition, the JEP proposes deprecation of the access > controller and policy classes which are the mechanism of stack-based access > checking, and finally unavoidably bumps against JAAS, which itself is a > very difficult and problematic API which also uses the same stack-based > access mechanism (and which we here at Red Hat have for the most part long > since abandoned). Has Red Hat mostly abandoned JAAS entirely or more specifically the stack-based JAAS authorization mechanism that depends on the Security Manager? I'm just curious why this proposal is important to you - is it on behalf of Red Hat or just your personal preferences? > A large part of this deprecated machinery relates to the stack-based access > controller (not to mention, I believe, a nontrivial number of CVEs). The > idea, of course, was that one can authenticate untrusted or semi-trusted > code. It is definitely clear through years of experience on all sides > though that one cannot truly rely on this mechanism to protect against > malicious code; it is as easy as an infinite loop to cause massive > undesired CPU usage (and, in this modern $/cpu world, cost) for example. > > However, one other undeniably useful function of the security manager is to > authorize basic native operations *not* in the context of what code is > executing, but what person or principal is executing it. In other words, > the use case of *trusted* code running on behalf of one of many potentially > untrusted users - probably the widest application of server-side Java in > existence today. It cannot be argued that removing all of the above > security checks does not weaken security of such users, when they could > have a narrower authorization applied to them to limit the possibility of > impact of server exploitation. But I assume that in these cases, it is due to a vulnerability in some trusted code that the user exploited or a weakness in some higher level authorization mechanism that the user was able to subvert. In practice, I don't think the Security Manager can or should take the place of a user-based Authorization provider. It is too low-level and too difficult to use and deploy, for the reasons mentioned in the JEP. But I think you agree with a lot of that anyway. > On the other hand, the cost of the SecurityManager mechanism as it stands > is undeniably too high; there is absolutely no point in arguing > otherwise, in my view. Leaving aside the substantial CVE load, the access > controller and policy APIs are very difficult to use correctly by > containers and frameworks, for one thing, and are cumbersome for users as > well. Many users and frameworks get doPrivileged() wrong, and combining > JAAS subjects into the same mechanism historically doesn't even work > consistently between otherwise-compliant JDK implementations. > > What I would propose then is a compromise aimed at maximizing the amount of > value retained and minimizing the amount of cost incurred, by *only* > retaining permission checks that specifically pertain to or are useful for > user authorization, while *also* deprecating (for removal) the existing > problem-prone stack-based access checking mechanism, policy, and security > manager implementation. > > Thus I would suggest not deprecating all of SecurityManager, rather just > the following: > > * java.lang.SecurityManager#getClassContext - it is replaced by StackWalker > * java.lang.SecurityManager#getSecurityContext > * java.lang.SecurityManager#checkCreateClassLoader > * java.lang.SecurityManager#checkPermission(java.security.Permission, > java.lang.Object) - the overload which accepts a "security context" > * java.lang.SecurityManager#checkPackageAccess > * java.lang.SecurityManager#checkPackageDefinition > * java.lang.SecurityManager#checkSecurityAccess > * java.lang.SecurityManager#getThreadGroup > > ...as well as their dependent methods and security checks. These checks > generally pertain to determining whether the application or its frameworks > are trusted to perform certain operations, but are far less useful for user > authorization, as far as I can determine. I would probably even include > the system property access methods as well - though I saw Peter arguing > that those in particular were useful, I have my doubts, but that could > obviously be worked out. Right, and I think this becomes a slipperly slope and would result in long and endless debates about which permissions people think are important. What about RuntimePermission "exitVM.*"? That is typically not an issue for server applications, but if you include that, then one could say that is useful for sandboxing against untrusted code so why not RuntimePermission "createClassLoader", and all the other permissions? I think it is better to make a clean break from it. > Further I would recommend the following change: make > java.lang.SecurityManager#checkPermission(java.security.Permission) either > a no-op or throw UnsupportedOperationException. Ideally, SecurityManager > and checkPermission() would be made abstract (and, for completeness, the > SecurityManager constructor); perhaps after the deprecation period, such a > change could be made. It's a bit tricky here, because the deprecation > policy doesn't seem to cover the case of making a concrete class or method > abstract. > > The remaining proposal would need slight modification in certain ways: for > example, the security manager allow/forbid flags would still make sense and > need to be retained, and the permission checks in socket and file system > code would need to be retained. > > After this change, SecurityManager would be decoupled from the stack-based > access controller. This means that any implementation of authorization > would be the responsibility of third-party libraries. The remaining JDK > authorization checks would then be easily testable - much more so than > today, because the contract becomes substantially simpler in the absence of > AccessController - and still usable by third party security managers to > perform user authorization checks on these native operations. And, it would > still be possible for third parties to provide stack-based access control > checks using StackWalker for an extra level of security with absolutely > zero additional cost to JDK maintenance (and the burden of coping with the > lack of doPrivileged would reside squarely on the third party). > > As for JAAS, nobody would be happier than us to see it just go away, though > that may be beyond the scope of this change. The proposed scope locals > give what is potentially a very good opportunity to employ a vastly > superior means of propagating security context between tasks. Under this > proposal, a third-party security manager which uses a scope local security > context for authorization would not only be a useful and measurable > security improvement over an "unsecured" JDK, but would also likely be > substantially more performant (and, if I may say so, reliable) than > anything using JAAS today. It should even be possible, in the future, to > standardize on a new authentication and authorization identity propagation > API using these mechanisms - at least in Jakarta EE and/or MicroProfile, if > not in the JDK itself. Note that we have already filed two follow-on issues to enhance JAAS and decouple it from the Security Manager: https://bugs.openjdk.java.net/browse/JDK-8266592 https://bugs.openjdk.java.net/browse/JDK-8267108 > > Essentially what I propose is only slightly departed from the current JEP > 411 proposal, by introducing the exception of retaining certain permission > checks and the security manager class itself. > > Please give this compromise some consideration. Thanks! I think if we are to consider this path (and that is something that would involve more discussion), it would be much cleaner to define a completely new API, say "ResourceManager" and make a clean break from the Security Manager. I think this idea can be explored more in later JDK releases to see if there is merit to this approach. I think it would be much harder, and confusing to keep the Security Manager around but for a much more limited functionality, and decide which permissions are ok, which are not, etc. We would have to define what is the "old" vs "new" Security Manager. Let's move Java forward rather than keeping one foot in the past. --Sean > > [1] https://github.com/wildfly-security/wildfly-elytron > [2] originally: > https://github.com/wildfly-security/security-manager/blob/master/src/main/java/org/wildfly/security/manager/WildFlySecurityManager.java > - which is now: > https://github.com/wildfly-security/wildfly-elytron/blob/1.x/manager/base/src/main/java/org/wildfly/security/manager/WildFlySecurityManager.java > From mark.reinhold at oracle.com Tue May 25 00:05:48 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 24 May 2021 17:05:48 -0700 Subject: JEP proposed to target JDK 17: 407: Remove RMI Activation In-Reply-To: <20210517225259.1938A3E412F@eggemoggin.niobe.net> References: <20210517225259.1938A3E412F@eggemoggin.niobe.net> Message-ID: <20210524170548.258331793@eggemoggin.niobe.net> 2021/5/17 15:52:58 -0700, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 17: > > 407: Remove RMI Activation > https://openjdk.java.net/jeps/407 > > Summary: Remove the Remote Method Invocation (RMI) Activation > mechanism, while preserving the rest of RMI. > > 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, 24 May, 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 17. Hearing no objections, I?ve targeted this JEP to JDK 17. - Mark From jini at zeus.net.au Tue May 25 08:14:25 2021 From: jini at zeus.net.au (jini at zeus.net.au) Date: Tue, 25 May 2021 18:14:25 +1000 Subject: JEP proposed to target JDK 17: 411: Deprecate the Security Manager for Removal In-Reply-To: <20210521230347.78ACB3E4C33@eggemoggin.niobe.net> References: <20210521230347.78ACB3E4C33@eggemoggin.niobe.net> Message-ID: <9469d8ef-3532-46fc-a247-173a0a0830bd@zeus.net.au> The new property change is already causing breakages downstream, as this is a LTS release can we target 18 please. Of course I realise it will target 17, so please don't waste time making arguments against this request, there's no harm asking, that's all. On 22/05/2021 9:03 am, mark.reinhold at oracle.com wrote: > The following JEP is proposed to target JDK 17: > > 411: Deprecate the Security Manager for Removal > https://openjdk.java.net/jeps/411 > > Summary: Deprecate the Security Manager for removal in a future > release. The Security Manager dates from Java 1.0. It has not been the > primary means of securing client-side Java code for many years, and it > has rarely been used to secure server-side code. To move Java forward, > we intend to deprecate the Security Manager for removal in concert with > the legacy Applet API (JEP 398). > > 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 Friday, 28 May, 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 17. > > - Mark > > > [1] https://openjdk.java.net/census#jdk > [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html -- Regards, Peter From Alan.Bateman at oracle.com Tue May 25 08:21:08 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 25 May 2021 09:21:08 +0100 Subject: JEP proposed to target JDK 17: 411: Deprecate the Security Manager for Removal In-Reply-To: <9469d8ef-3532-46fc-a247-173a0a0830bd@zeus.net.au> References: <20210521230347.78ACB3E4C33@eggemoggin.niobe.net> <9469d8ef-3532-46fc-a247-173a0a0830bd@zeus.net.au> Message-ID: <8434a78c-3bae-c222-5f06-f323eb61428e@oracle.com> On 25/05/2021 09:14, jini at zeus.net.au wrote: > The new property change is already causing breakages downstream This JEP hasn't been integrated so there isn't any "property change" in the main line or EA builds. Can you clarify what you mean by "downstream" here? -Alan From jini at zeus.net.au Tue May 25 08:27:40 2021 From: jini at zeus.net.au (jini at zeus.net.au) Date: Tue, 25 May 2021 18:27:40 +1000 Subject: JEP proposed to target JDK 17: 411: Deprecate the Security Manager for Removal In-Reply-To: <8434a78c-3bae-c222-5f06-f323eb61428e@oracle.com> References: <20210521230347.78ACB3E4C33@eggemoggin.niobe.net> <9469d8ef-3532-46fc-a247-173a0a0830bd@zeus.net.au> <8434a78c-3bae-c222-5f06-f323eb61428e@oracle.com> Message-ID: https://blogs.apache.org/netbeans/entry/jep-411-deprecate-the-security1 On 25/05/2021 6:21 pm, Alan Bateman wrote: > On 25/05/2021 09:14, jini at zeus.net.au wrote: >> The new property change is already causing breakages downstream > > This JEP hasn't been integrated so there isn't any "property change" > in the main line or EA builds. Can you clarify what you mean by > "downstream" here? > > -Alan -- Regards, Peter From Alan.Bateman at oracle.com Tue May 25 08:53:18 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 25 May 2021 09:53:18 +0100 Subject: JEP proposed to target JDK 17: 411: Deprecate the Security Manager for Removal In-Reply-To: References: <20210521230347.78ACB3E4C33@eggemoggin.niobe.net> <9469d8ef-3532-46fc-a247-173a0a0830bd@zeus.net.au> <8434a78c-3bae-c222-5f06-f323eb61428e@oracle.com> Message-ID: <87af5740-4628-a7b5-d866-403d4ed3f454@oracle.com> On 25/05/2021 09:27, jini at zeus.net.au wrote: > https://blogs.apache.org/netbeans/entry/jep-411-deprecate-the-security1 The JEP is just currently in the "proposed to target" state. The PR with the changes is work-in-progress so I guess Geertjan must have grabbed the PR and did some testing. Early testing is good and well constructed bug reports are always welcome. In this case, there seems to be a fix to Eclipse Equinox in the works [1] as it didn't support the "allow" and "disallow" values that were added in JDK 12. There is an argument that the placeholder values ("default", "allow", ..) should be dropped at startup and before user code executes as there may be code reading the value of java.security.manager (as Equinox seems to be doing). So that may be resolved soon. -Alan [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=573731 From david.lloyd at redhat.com Tue May 25 13:29:28 2021 From: david.lloyd at redhat.com (David Lloyd) Date: Tue, 25 May 2021 08:29:28 -0500 Subject: JEP proposed to target JDK 17: 411: Deprecate the Security Manager for Removal In-Reply-To: <0ba7b17f-a967-214c-4149-8627c7bac801@oracle.com> References: <20210521230347.78ACB3E4C33@eggemoggin.niobe.net> <0ba7b17f-a967-214c-4149-8627c7bac801@oracle.com> Message-ID: On Mon, May 24, 2021 at 11:17 AM Sean Mullan wrote: > Comments inline ... > > On 5/22/21 10:11 AM, David Lloyd wrote: > > ... In addition, the JEP proposes deprecation of the access > > controller and policy classes which are the mechanism of stack-based > access > > checking, and finally unavoidably bumps against JAAS, which itself is a > > very difficult and problematic API which also uses the same stack-based > > access mechanism (and which we here at Red Hat have for the most part > long > > since abandoned). > > Has Red Hat mostly abandoned JAAS entirely or more specifically the > stack-based JAAS authorization mechanism that depends on the Security > Manager? I'm just curious why this proposal is important to you - is it > on behalf of Red Hat or just your personal preferences? > Yes, we have mostly abandoned JAAS other than in a few specific cases where it is baked into, say, a certain JDBC driver or Kerberos implementation or something like that. Our replacement mechanism relies on immutable security identity carriers which are locked into lexical scopes to prevent accidental identity or authorization leakage, but still relies on `Principal` for identity and permissions for authorization. I'm thinking on behalf of Red Hat customers, but really on behalf of *all* users who currently rely on SecurityManager (or more specifically, on the ability to restrict permissions for certain services). In many cases, it is a requirement for certain security certifications that certain customers may require as a matter of course. The idea here is to largely move the cost burden of security from the JDK to the specific vendor(s) who wish to provide that additional service, without making it substantially more difficult than it is today to provide that service. > > However, one other undeniably useful function of the security manager is > to > > authorize basic native operations *not* in the context of what code is > > executing, but what person or principal is executing it. In other words, > > the use case of *trusted* code running on behalf of one of many > potentially > > untrusted users - probably the widest application of server-side Java in > > existence today. It cannot be argued that removing all of the above > > security checks does not weaken security of such users, when they could > > have a narrower authorization applied to them to limit the possibility of > > impact of server exploitation. > > But I assume that in these cases, it is due to a vulnerability in some > trusted code that the user exploited or a weakness in some higher level > authorization mechanism that the user was able to subvert. > Right; a security manager is not proof against implementation error, nor is simple rigor, ultimately. But every layer of protection helps. > In practice, I don't think the Security Manager can or should take the > place of a user-based Authorization provider. It is too low-level and > too difficult to use and deploy, for the reasons mentioned in the JEP. > But I think you agree with a lot of that anyway. > Right, the mechanisms in place today are not really ideal for providing these kinds of protections for reasons that I think have been well-established. > > ...as well as their dependent methods and security checks. These checks > > generally pertain to determining whether the application or its > frameworks > > are trusted to perform certain operations, but are far less useful for > user > > authorization, as far as I can determine. I would probably even include > > the system property access methods as well - though I saw Peter arguing > > that those in particular were useful, I have my doubts, but that could > > obviously be worked out. > > Right, and I think this becomes a slipperly slope and would result in > long and endless debates about which permissions people think are > important. What about RuntimePermission "exitVM.*"? That is typically > not an issue for server applications, but if you include that, then one > could say that is useful for sandboxing against untrusted code so why > not RuntimePermission "createClassLoader", and all the other permissions? > I think exitVM is a bit of a unique case, and thus is probably not the best example to support this argument. It is completely possible to trust a library (potentially one that may not be modified) but note that it does call exit - and having a mechanism to block that isn't really about trust or any other higher principle; it's simply a pragmatic way to make life somewhat easier. Also, in this case, the cost of this check is very small. > > Essentially what I propose is only slightly departed from the current JEP > > 411 proposal, by introducing the exception of retaining certain > permission > > checks and the security manager class itself. > > > > Please give this compromise some consideration. Thanks! > > I think if we are to consider this path (and that is something that > would involve more discussion), it would be much cleaner to define a > completely new API, say "ResourceManager" and make a clean break from > the Security Manager. I think this idea can be explored more in later > JDK releases to see if there is merit to this approach. I think it would > be much harder, and confusing to keep the Security Manager around but > for a much more limited functionality, and decide which permissions are > ok, which are not, etc. We would have to define what is the "old" vs > "new" Security Manager. > I can understand this point of view. The fact that the Security Manager *is* historical however does not invalidate its utility or its potential, and (odd as it feels to be saying this) there are some nice elements to its design. Any new API that one might propose to perform this function would have to make the same evaluations in terms of permission checks, and would likely have the same general code shapes. I think it would be more palatable to "step down" the implementation as I described - after all, the remaining parts can still be deprecated and removed later if it turns out to be a bad idea. > Let's move Java forward rather than keeping one foot in the past. > Look, nobody is more surprised than I am that I'm arguing against completely removing this thing! :-) But I don't think that keeping the base API can fairly be characterized as keeping a foot in the past. Some of the APIs didn't age well - like ProtectionDomain, which is a bit awkward (using URL, rather than say URI) or the old package-sealing or JAR-signing mechanisms, for example. That's where a lot of the complexity lies, and AccessController is where a lot of the liability lies. I think it's OK to start aging these things out. However, the basic Permission system may have a few minor rough edges but it's basically a sound system that is still in use by modern APIs. And retaining strategically placed permission checks seems like a great way to offer a more open end to security without taking on the liabilities. -- - DML ? he/him From Alan.Bateman at oracle.com Wed May 26 07:05:51 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 26 May 2021 08:05:51 +0100 Subject: JEP proposed to target JDK 17: 411: Deprecate the Security Manager for Removal In-Reply-To: <87af5740-4628-a7b5-d866-403d4ed3f454@oracle.com> References: <20210521230347.78ACB3E4C33@eggemoggin.niobe.net> <9469d8ef-3532-46fc-a247-173a0a0830bd@zeus.net.au> <8434a78c-3bae-c222-5f06-f323eb61428e@oracle.com> <87af5740-4628-a7b5-d866-403d4ed3f454@oracle.com> Message-ID: <90ca5887-6c89-cdb8-c379-6b9f80ca98ba@oracle.com> On 25/05/2021 09:53, Alan Bateman wrote: > The PR with the changes is work-in-progress so I guess Geertjan must > have grabbed the PR and did some testing. Early testing is good and > well constructed bug reports are always welcome. In this case, there > seems to be a fix to Eclipse Equinox in the works [1] as it didn't > support the "allow" and "disallow" values that were added in JDK 12. Just to follow-up on this. Max Wang from the security group dug into the NB usages of this Eclipse library. It turns out NB patches this code already and Max only needed to change one line to get it to handle the "allow" value added in JDK 12. With that fix, NB starts okay with -Djava.security.manager=allow as expected. Hopefully the NB maintainers will be able to include the fix in their next release. The upstream Eclipse project have committed a fix too. So I think all good on this issue. Hopefully there will wider testing with the EA builds when the changes are integrated. -Alan. From mark.reinhold at oracle.com Wed May 26 14:58:39 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 26 May 2021 07:58:39 -0700 Subject: JEP proposed to target JDK 17: 403: Strongly Encapsulate JDK Internals In-Reply-To: <20210518234717.566DE3E4392@eggemoggin.niobe.net> References: <20210518234717.566DE3E4392@eggemoggin.niobe.net> Message-ID: <20210526075839.733078090@eggemoggin.niobe.net> 2021/5/18 16:47:17 -0700, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 17: > > 403: Strongly Encapsulate JDK Internals > https://openjdk.java.net/jeps/403 > > Summary: Strongly encapsulate all internal elements of the JDK, except > for critical internal APIs such as sun.misc.Unsafe. It will no longer > be possible to relax the strong encapsulation of internal elements > via a single command-line option, as was possible in JDK9 through > JDK16. > > 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 Tuesday, 25 May, 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 17. Hearing no objections, I?ve targeted this JEP to JDK 17. - Mark From stuart.marks at oracle.com Wed May 26 18:38:59 2021 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 26 May 2021 11:38:59 -0700 Subject: Java 2.0 migration planning. JEP's for removal. In-Reply-To: References: Message-ID: <9e4b588d-0e48-f971-a43b-b9db16ba3d86@oracle.com> On 5/23/21 6:09 PM, jini at zeus.net.au wrote: > Will RMI and the RMI registry be put up for removal soon? > > Just seeing the writing on the wall here, with other components being removed, I was > wondering when will RMI be proposed for removal. > > We still use some RMI interfaces and exceptions in our API's but don't use the RMI > implementation (except for the RMI registry that occurs over TLS sockets on the > local machine), same for Activation. There are no plans for removing "core" RMI at present (as opposed to RMI Activation), but if you wanted to make a case for their removal, be my guest. Note that even though RMI Activation is "newer" than core RMI, Activation never got much traction, and so has seen extremely little use. It also has a larger maintenance overhead than core RMI. These combined made it a candidate for removal. There is still some use of core RMI by legacy applications, so we're leaving it in the platform for the time being. As we've discussed earlier, all of this stuff is essentially obsolete. Maybe at some point there will be so little use of any part of RMI that it will eventually be removed. I don't think we're at that point quite yet though. > I'm guessing if we need to make a breaking release of our software, we might as well > get all the breaking code out of the way in one go, rather than make multiple > breaking releases as Java removes parts of its API's. I'll just observe that there are mechanism such as multi-release jars that might help with this situation. > Betting Serialization will be removed at some point too, we will also want to remove > all Java Serialization as well. There are many reasons we'd like to get rid of serialization, but in fact it's heavily used today, so it won't be deprecated or removed anytime soon. (I'm talking specifically about the serialization mechanism in the JDK, as in java.io.Serializable.) Serialization as a general concept is very important and is likely never going to go away. To this end we're thinking of a long-term path to upgrading the platform to provide better language support for serialization in general, which we hope will eventually produce a mechanism that supersedes the existing Java serialization mechanism. Some of our thoughts are here: https://cr.openjdk.java.net/~briangoetz/amber/serialization.html You can also see that some of this thinking is embodied in current JDK releases: https://inside.java/2021/03/12/simpler-serilization-with-records/ > Can we get an indication on what's on the chopping block so we can start to consider > how to handle it? In general, deprecation-for-removal is the indication of what's on the chopping block. Currently deprecated stuff *might* be upgraded to for-removal at some point, though that doesn't apply to everything. In general, we don't provide advance notice of deprecation-for-removal, because deprecation-for-removal is already advance notice. s'marks From sean.mullan at oracle.com Fri May 28 22:52:45 2021 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 28 May 2021 18:52:45 -0400 Subject: JEP proposed to target JDK 17: 411: Deprecate the Security Manager for Removal In-Reply-To: <20210521230347.78ACB3E4C33@eggemoggin.niobe.net> References: <20210521230347.78ACB3E4C33@eggemoggin.niobe.net> Message-ID: <6c02ae7c-eb5c-0e1d-eb44-169c7a2db166@oracle.com> We have updated the JEP with a few changes to the "Issue Warnings" section [1], summarized as follows: If the Java runtime is started without setting the system property 'java.security.manager' then a custom Security Manager can be installed dynamically by calling System::setSecurityManager, just as in Java 16. No UnsupportedOperationException will be thrown. This call will, however, issue a warning message explaining that the Security Manager is deprecated and will be removed in a future release. We plan to change the default value of the 'java.security.manager' system property to "disallow" in the next release, i.e., Java 18. That will cause System::setSecurityManager to throw an UnsupportedOperationException in Java 18. With these changes, the process of deprecating and eventually removing the Security Manager will be consistent with our treatment of past breaking changes such as, e.g., the strong encapsulation of internal APIs. Maintainers of libraries and applications will be given fair warning before any existing code is broken. --Sean [1] https://openjdk.java.net/jeps/411#Issue-warnings On 5/21/21 7:03 PM, mark.reinhold at oracle.com wrote: > The following JEP is proposed to target JDK 17: > > 411: Deprecate the Security Manager for Removal > https://openjdk.java.net/jeps/411 > > Summary: Deprecate the Security Manager for removal in a future > release. The Security Manager dates from Java 1.0. It has not been the > primary means of securing client-side Java code for many years, and it > has rarely been used to secure server-side code. To move Java forward, > we intend to deprecate the Security Manager for removal in concert with > the legacy Applet API (JEP 398). > > 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 Friday, 28 May, 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 17. > > - Mark > > > [1] https://openjdk.java.net/census#jdk > [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html > From paul.sandoz at oracle.com Sat May 29 00:55:14 2021 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Sat, 29 May 2021 00:55:14 +0000 Subject: Result: New JDK Reviewer: Sandhya Viswanathan Message-ID: Voting for Sandhya Viswanathan [1] has now closed. Yes: 15 Veto: 0 Abstain: 0 According to the Bylaws definition of Three Vote Consensus [2], this is sufficient to approve the nomination. Paul. [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2021-May/005528.html [2] https://openjdk.java.net/projects/#reviewer-vote