Re: RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached

On Wed, 10 Feb 2021 14:08:22 GMT, PROgrm_JARvis wrote: >>> Hi Claes, >>> Would flattening the state of MD5 bring any further improvements? >>> [plevart@92bf48f](https://github.com/plevart/jdk/commit/92bf48ff58f0ce9648e49466dbf1befebbf49083) >> >> I think it might, marginally, but it seemed to m

Re: RFR: JDK-8261601: free memory in early return in Java_sun_nio_ch_sctp_SctpChannelImpl_receive0

On Fri, 12 Feb 2021 08:50:14 GMT, Matthias Baesken wrote: > Btw. while adjusting Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 , I > started to wonder what happens to the allocated memory in the same file in > handleSendFailed ( if ((addressP = malloc(dataLength)) == NULL) ) in early > return

Re: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v8]

On Sat, 13 Feb 2021 10:56:32 GMT, Andrey Turbanov wrote: >> This fours tests pass without problems, when I run them separately. >> >> ## sun/security/tools/jarsigner/TimestampCheck.java >> ## sun/security/tools/keytool/DefaultOptions.java >> ## sanity/client/SwingSet/src/ColorChooserDemoTest.ja

Re: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v10]

On Mon, 15 Feb 2021 18:33:00 GMT, Andrey Turbanov wrote: >> 8080272 Refactor I/O stream copying to use >> InputStream.transferTo/readAllBytes and Files.copy > > Andrey Turbanov has updated the pull request incrementally with one > additional commit since the last revision: > > 8080272: Ref

Re: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v11]

On Mon, 15 Feb 2021 19:47:00 GMT, Andrey Turbanov wrote: >> 8080272 Refactor I/O stream copying to use >> InputStream.transferTo/readAllBytes and Files.copy > > Andrey Turbanov has updated the pull request incrementally with one > additional commit since the last revision: > > 8080272: Ref

Re: RFR: JDK-8261601: free memory in early return in Java_sun_nio_ch_sctp_SctpChannelImpl_receive0

On Sat, 13 Feb 2021 17:27:47 GMT, Alan Bateman wrote: >> There seems to be an early return in >> Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 that misses freeing memory. >> >> Sonar reports : >> https://sonarcloud.io/project/issues?id=shipilev_jdk&lan

Re: RFR: JDK-8261791: handleSendFailed in SctpChannelImpl.c potential leaks

On Tue, 16 Feb 2021 12:26:54 GMT, Matthias Baesken wrote: > In another bug this question from me was answered by Alan Bateman : > > Btw. while adjusting Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 , I > started to wonder what happens to the allocated memory in the

Re: RFR: JDK-8261791:(sctp) handleSendFailed in SctpChannelImpl.c potential leaks

On Wed, 17 Feb 2021 13:27:13 GMT, Matthias Baesken wrote: >> Hi Alan and Chris, thanks for the reviews. > > Looks like I cannot integrate it, even after changing the title!? > Is this a bug? Here's the jcheck failure: https://github.com/openjdk/jdk/pull/2586/checks?check_run_id=1918880270 -

Re: RFR: 8261880: Change nested classes in java.base to static nested classes where possible [v2]

On Wed, 17 Feb 2021 16:38:03 GMT, Сергей Цыпанов wrote: >> Non-static classes hold a link to their parent classes, which in many cases >> can be avoided. > > Сергей Цыпанов has updated the pull request incrementally with one additional > commit since the last revision: > > 8261880: Remove s

Re: RFR: JDK-8262875: doccheck: empty paragraphs, etc in java.base module

On Tue, 2 Mar 2021 19:35:47 GMT, Jonathan Gibbons wrote: > Please review some minor doc fixes, for issues found by _doccheck_.There > are two kinds of errors that are addressed. > > 1. Incorrect use of ``. In HTML, `` marks the *beginning* of a > paragraph. It is not a terminator, to mark

Re: RFR: JDK-8263104: fix warnings for empty paragraphs

On Fri, 5 Mar 2021 19:36:13 GMT, Jonathan Gibbons wrote: > Please review some simple cleanup for empty `` tags. > > Two of the tags are completely redundant, and simply deleted. > > The other three, in _package.html_ files are generally undesirable. Although > the presumed intent of the `id` d

Re: RFR: 8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI

On Fri, 9 Apr 2021 13:15:16 GMT, Conor Cleary wrote: > ### Description > This fix is part of a previous effort to both cleanup/modernise JNDI code, > the details of which can be seen in > [JDK-8048091](https://bugs.openjdk.java.net/browse/JDK-8048091). A number > JNDI methods under `java.namin

Re: RFR: 8264208: Console charset API [v2]

On Fri, 9 Apr 2021 21:06:00 GMT, Naoto Sato wrote: >> Please review the changes for the subject issue. This has been suggested in >> a recent discussion thread for the JEP 400 >> [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. >> A CSR has also been drafte

Re: RFR: 8264208: Console charset API [v4]

On Tue, 13 Apr 2021 12:54:51 GMT, Ichiroh Takiguchi wrote: > 1. I think method name "charset()" is too short. It's not called frequently. > This method name should explain functionality. > 2. Sometimes stderr may be redirected to stdout by shell. Why do we need to > set different encodings for

Re: RFR: 8264208: Console charset API [v6]

On Tue, 13 Apr 2021 19:59:30 GMT, Naoto Sato wrote: >> Please review the changes for the subject issue. This has been suggested in >> a recent discussion thread for the JEP 400 >> [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. >> A CSR has also been draft

Re: RFR: 8264208: Console charset API [v8]

On Wed, 14 Apr 2021 17:17:03 GMT, Naoto Sato wrote: >> Please review the changes for the subject issue. This has been suggested in >> a recent discussion thread for the JEP 400 >> [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. >> A CSR has also been draft

Re: JEP411: Missing use-case: Monitoring / restricting libraries

On 16/04/2021 02:29, Reinier Zwitserloot wrote: : * An XML parser library may make network calls or open files on disk due to e.g. XXE shenanigans: See https://owasp.org/www-community/vulnerabilities/XML_External_Entity_(XXE)_Processing

Re: JEP411: Restricting/logging library usages using a SecurityManager

On 15/04/2021 22:10, Roel Spilker wrote: : But on my server application, we use libraries. And I'm very interested on how they behave. I would like to log or restrict the following actions: - Spawning new processes - Unexpected file access - Unexpected network traffic Currently, our applicat

Re: RFR: 8264208: Console charset API [v12]

On Thu, 22 Apr 2021 17:38:43 GMT, Naoto Sato wrote: >> Please review the changes for the subject issue. This has been suggested in >> a recent discussion thread for the JEP 400 >> [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. >> A CSR has also been draft

Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator)

On Mon, 26 Apr 2021 17:10:13 GMT, Maurizio Cimadamore wrote: > This PR contains the API and implementation changes for JEP-412 [1]. A more > detailed description of such changes, to avoid repetitions during the review > process, is included as a separate comment. > > [1] - https://openjdk.jav

Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v2]

On Wed, 28 Apr 2021 13:47:43 GMT, Maurizio Cimadamore wrote: >> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java >> line 270: >> >>> 268: >>> 269: /** >>> 270: * Converts a Java string into a null-terminated C string, using >>> the platform's default charse

Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v7]

On Fri, 30 Apr 2021 15:20:42 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-412 [1]. A more >> detailed description of such changes, to avoid repetitions during the review >> process, is included as a separate comment. >> >> [1] - https://openjd

Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v7]

On Tue, 4 May 2021 12:01:44 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/jdk/internal/module/IllegalNativeAccessChecker.java >> line 34: >> >>> 32: import java.util.Set; >>> 33: >>> 34: public final class IllegalNativeAccessChecker { >> >> Are you sure about the name of the

Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v10]

On Tue, 4 May 2021 12:05:15 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-412 [1]. A more >> detailed description of such changes, to avoid repetitions during the review >> process, is included as a separate comment. >> >> [1] - https://openjdk

Re: JEP411: Missing use-case: Monitoring / restricting libraries

On 06/05/2021 11:26, Peter Firmstone wrote: OpenJDK seems to have assumed that no one was using SecurityManager based on one research report. I don't think this is right. Instead I would say that many of us have rarely encountered deployments on the server-side that are using a SecurityMana

Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v12]

On Thu, 6 May 2021 14:23:27 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-412 [1]. A more >> detailed description of such changes, to avoid repetitions during the review >> process, is included as a separate comment. >> >> [1] - https://openjdk

Re: Performance differences between Java 8,, 11, 14 and 16

On 12/05/2021 07:18, Peter Firmstone wrote: https://github.com/pfirmstone/JGDMS/blob/trunk/qa/src/org/apache/river/test/impl/mahalo/RandomStressTest.java https://github.com/pfirmstone/JGDMS/blob/trunk/qa/src/org/apache/river/test/impl/mahalo/RandomStressTest.td It would be great if there wer

Re: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests calling System.setSecurityManager

On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang wrote: > Please review the test changes for [JEP > 411](https://openjdk.java.net/jeps/411). > > With JEP 411 and the default value of `-Djava.security.manager` becoming > `disallow`, tests calling `System.setSecurityManager()` need > `-Djava.secu

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

On 18/05/2021 03:39, Peter Firmstone wrote: : Yes, I realize that, it is my understanding that because this is a security concern, it is not something the community is allowed to provide support for at OpenJDK, hence my suggestion to Alan, to make it possible for this to happen by changing t

Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote: > Please review this implementation of [JEP > 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. > https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

On 18/05/2021 08:36, Peter Firmstone wrote: : It's a perception issue, I understand, but we can fix that far less painfully. With respect, I don't see a viable route here. SM/AccessController and most of that security architecture has been an albatross around our necks for years. This JE

Re: RFR: 8267110: Update java.util to use instanceof pattern variable

On Tue, 18 May 2021 10:37:21 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.util` > package to make use of the `instanceof` pattern variable? > > Kind regards, > Patrick You may need to coordinate with @DougLea on the changes to

Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal

On Tue, 18 May 2021 12:42:08 GMT, Sean Mullan wrote: >> src/java.base/share/classes/java/lang/SecurityManager.java line 315: >> >>> 313: * >>> 314: * @since 1.0 >>> 315: * @deprecated The Security Manager is deprecated and subject to >>> removal in a >> >> Javadoc will prefix, in bold, "D

Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote: > Please review this implementation of [JEP > 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. > https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28

Re: RFR: 8266936: Add a finalization JFR event [v2]

On Wed, 19 May 2021 06:20:59 GMT, Erik Gahlin wrote: > This looks useful, but I am worried about the performance impact: > > * The added allocation for every object that is finalized. > * The event being enabled in the default configuration. > > The default configuration must be safe to use eve

Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3]

On Thu, 20 May 2021 04:22:32 GMT, Phil Race wrote: >> That is unfortunate, but nonetheless I think required to be done. >> We have acknowledeged this can't reasonably be called an RFE, so the JEP is >> introducing bugs/technical debt/call it what you will. This should generally >> be part of a

Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v24]

On Wed, 28 Apr 2021 08:20:05 GMT, Chris Hegarty wrote: >> src/java.base/share/classes/sun/nio/ch/IOUtil.java line 466: >> >>> 464: } >>> 465: >>> 466: private static final JavaNioAccess NIO_ACCESS = >>> SharedSecrets.getJavaNioAccess(); >> >> It might be cleaner to move to acquire/rel

Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3]

On Fri, 21 May 2021 18:00:13 GMT, Phil Race wrote: > Are you suggesting that the patch doesn't need testing as it is ? It should > be the same either way. > It is very straight forward to run the automated tests across all platforms > these days. > I get the impression that no one is guaranteei

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

On 22/05/2021 11:58, Bernd Eckenfels wrote: : This whole discussion about using only secure libraries really makes me wonder if you know the realities of modern applications with hundreds of dependencies and the state of those, like there is still no easy way to limit XXE in upstream xerces.

Re: RFR: 8267123: Remove RMI Activation

On Tue, 25 May 2021 18:04:45 GMT, Stuart Marks wrote: > This is the implementation of [JEP 407](https://openjdk.java.net/jeps/407). > > This is a fairly straightforward removal of this component. > - Activation implementation classes removed > - Activation tests removed > - adjustments to var

Re: RFR: 8267123: Remove RMI Activation

On Tue, 25 May 2021 18:04:45 GMT, Stuart Marks wrote: > This is the implementation of [JEP 407](https://openjdk.java.net/jeps/407). > > This is a fairly straightforward removal of this component. > - Activation implementation classes removed > - Activation tests removed > - adjustments to var

Re: JEP411: Missing use-case: Monitoring / restricting libraries

On 31/05/2021 08:11, Peter Firmstone wrote: : I think also that many more people are using SecurityManager than OpenJDK realises, and they're not using it how OpenJDK recommends either, (AllPermission granted to trusted code, and sandbox untrusted code model of Applets is not how we use it) p

Re: JEP411: Missing use-case: Monitoring / restricting libraries

On 01/06/2021 01:11, Chapman Flack wrote: On 05/31/21 03:59, Alan Bateman wrote: The SM survey in 2018 showed that there was some usage too. Out of curiosity, where can I learn more about this survey? Was it the kind of survey that, if I had been hanging around in the right places in 2018, I

Re: JEP 411: Disable warning message with flag?

On 31/05/2021 22:53, Chapman Flack wrote: : Thank you for that. One question I have been wondering about: do you have any internally-tracked metrics that you can share about how many uses of doPrivileged there are in the JDK codebase, and perhaps even a histogram of the stack depth from the doPri

Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v6]

On Mon, 31 May 2021 15:02:57 GMT, Weijun Wang wrote: >> Please review this implementation of [JEP >> 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. >> https://github.com/openjdk/jdk/commit/576161d15423f58281e38

Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v8]

On Tue, 1 Jun 2021 15:21:33 GMT, Weijun Wang wrote: >> Please review this implementation of [JEP >> 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. >> https://github.com/openjdk/jdk/commit/576161d15423f58281e384

Re: Authorization Layer post JEP 411

On 03/06/2021 01:04, Chapman Flack wrote: On 06/02/21 19:41, Peter Firmstone wrote: We need the power of AccessController's stack walk, StackWalker doesn't work with compiled code, only bytecode. Is this correct? I have not tried it, but the apidocs had led me to understand it did not distin

Re: JEP 411: Documentation on the new way to establish TLS connections

On 04/06/2021 05:22, Peter Firmstone wrote: Could someone please advise the recommended way now to preserve the Subject in Executors to establish a TLS connection? I think the primitive you are looking for is scope local variables. It's still in the exploration phase but there is a draft JEP

Re: RFR: 8268349: Provide more detail in JEP 411 warning messages

On Mon, 7 Jun 2021 20:42:53 GMT, Weijun Wang wrote: > More loudly and precise warning messages when a security manager is either > enabled at startup or installed at runtime. Changes requested by alanb (Reviewer). src/java.base/share/classes/java/lang/System.java line 331: > 329: > 330:

Re: RFR: 8268349: Provide more detail in JEP 411 warning messages

On Tue, 8 Jun 2021 06:30:00 GMT, David Holmes wrote: > You might want to make your "WARNING" consistent with the VM's "Warning" so > that OutputAnalyzer's logic to ignore warnings will automatically ignore > these too. The uppercase "WARNING" is intentional here, it was the same with illegal

Re: RFR: 8268349: Provide more detail in JEP 411 warning messages

On Tue, 8 Jun 2021 12:22:52 GMT, Weijun Wang wrote: > I thought about that but not sure of performance impact. Is the worst problem > that more than one warnings will be printed for a single caller? It's not > really harmless. > > As for the frame, if the warning message only contain the calle

Re: RFR: 8268349: Provide more detail in JEP 411 warning messages

On Tue, 8 Jun 2021 18:22:55 GMT, Weijun Wang wrote: >>> I thought about that but not sure of performance impact. Is the worst >>> problem that more than one warnings will be printed for a single caller? >>> It's not really harmless. >>> >>> As for the frame, if the warning message only contain

Re: Low level hooks in JDK for instrumentation of permission checks.

On 10/06/2021 03:49, Peter Firmstone wrote: Hi Sean, Sorry I've confused you. What I should have said is a ProtectionDomain with a null CodeSource. What I mean to ask is, where ProtectionDomain is created with a null CodeSource, in Class::getProtectionDomain() can we have CodeSource's that r

Re: Low level hooks in JDK for instrumentation of permission checks.

On 10/06/2021 07:40, Peter Firmstone wrote: Just a quick question, would it be possible that some JFR hooks might also be useable for an authorisation layer? JFR events can't be used to intercept/veto operations, assuming that is what you are asking. However, it might be that JFR events are

Re: JEP 411: Deprecation with removal would break most existing Java libraries

cc'ing security-dev as that is the mailing list to use for this JEP. This JEP is the first of several in a multi-release/multi-year effort. It's way too early to give any guess as to when the APIs will be removed. As the JEP says, future releases may degrade the SM APIs so that System.getSM re

Re: JEP 411: Deprecation with removal would break most existing Java libraries

On 14/06/2021 08:35, Peter Firmstone wrote: I wouldn't want to see SecurityManager and Policy be neutralized, it's better to remove it and fail early so people update their software, there's a risk they may update without realizing it's no longer fully functional.   Get rid of the baggage so

Re: blizzard of deprecation warnings related to JEP 411

On 15/06/2021 15:10, Rick Hillegas wrote: : When I tried to build Derby with the Rampdown Phase One build of open JDK 17 (17-ea+26-2439), I saw many warnings related to the deprecation of Security Manager classes and methods, undoubtedly the consequence of JEP 411 (https://openjdk.java.net/je

Re: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible

On Wed, 16 Jun 2021 08:08:47 GMT, Yi Yang wrote: > After JDK-8265518(#3615), it's possible to replace all variants of checkIndex > by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in > the whole JDK codebase. I looked through the changes in java.base and only spotted o

Re: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible

On Thu, 17 Jun 2021 05:16:14 GMT, David Holmes wrote: > There are a lot more tests than just tier1. :) I don't expect many, if any, > tests to be looking for a specific IOOBE message, and I can't see an easy way > to find such tests without running them. If core-libs folk are okay with this >

Re: blizzard of deprecation warnings related to JEP 411

On 17/06/2021 00:30, Rick Hillegas wrote: Thanks for that advice, Alan. I have rototilled @SuppressWarnings("removal") annotations across the Derby codebase and thrown more memory at javadoc so that it won't crash on JDK 11. When I run Derby's test suites, I see a blizzard of the following diag

Re: [jdk17] RFR: 8268349: Provide clear run-time warnings about Security Manager deprecation [v4]

On Thu, 17 Jun 2021 14:55:02 GMT, Weijun Wang wrote: >> More loudly and precise warning messages when a security manager is either >> enabled at startup or installed at runtime. >> >> This is new PR for the `openjdk/jdk17` repo copied from >> https://github.com/openjdk/jdk/pull/4400. A new com

Re: [jdk17] RFR: 8268349: Provide clear run-time warnings about Security Manager deprecation [v5]

On 18/06/2021 03:51, Jaikiran Pai wrote: : Given all that, do you think that we should be printing the jar file paths in this WARNING message by default? I read the linked CSR, but I didn't see why the location of the jar or the name of the jar would be useful in this warning message. As long

Re: [jdk17] RFR: 8269034: AccessControlException for SunPKCS11 daemon threads [v2]

On Tue, 22 Jun 2021 20:08:03 GMT, Sean Coffey wrote: >> Sufficient permissions missing if this code was ever to run with >> SecurityManager. >> >> Cleanest approach appears to be use of InnocuousThread to create the >> cleaner/poller threads. >> Test case coverage extended to cover the Securi

Re: Authorization layer API and low level access checks.

On 23/06/2021 04:02, Peter Firmstone wrote: Note: I'm not sure how to replace an inherited AccessControlContext (with a new implementation based on StackWalker functionality) at thread creation time, as it must be created when threads are created, possibly by using ThreadFactory everywhere, b

Re: [jdk17] RFR: 8269409: Post JEP 411 refactoring: core-libs with maximum covering > 10K [v2]

On Fri, 25 Jun 2021 23:40:27 GMT, Weijun Wang wrote: >> More refactoring to limit the scope of `@SuppressWarnings` annotations. >> >> Sometimes I introduce new methods. Please feel free to suggest method names >> you like to use. > > Weijun Wang has updated the pull request incrementally with o

Re: Initial feedback from Apache Ant users on recent security manager warning messages

On 28/06/2021 18:16, Jaikiran Pai wrote: On a slightly related note, I was wondering why we decided to go with what appears to be a bit more aggressive approach to these warning messages as compared to what was done with the illegal reflective access warnings? I would have thought that the il

Re: Initial feedback from Apache Ant users on recent security manager warning messages

On 29/06/2021 08:04, Jaikiran Pai wrote: Thank you Alan. I see that https://bugs.openjdk.java.net/browse/JDK-8269543 has been created for this. I'll keep a watch on that one. Yes, that was the original intention but had to dropped because it wasn't thread safe. BTW: I'm puzzled as to w

Re: [jdk17] RFR: 8269543: The warning for System::setSecurityManager should only appear once for each caller

On Tue, 29 Jun 2021 21:18:35 GMT, Weijun Wang wrote: >> Using a synchronized WeakHashMap with the class as the key would not prevent >> class unloading. >> Using a non-weak set or map to strings would keep the strings around for the >> life of the runtime. > > I hope this is uncommon but if tha

Re: Initial feedback from Apache Ant users on recent security manager warning messages

On 30/06/2021 05:51, Jaikiran Pai wrote: In the case we are dealing with, the class is always "org.apache.tools.ant.types.Permissions". It will always be loaded by one single classloader (so classloaded just once). However, multiple different instances of this class will get created during th

Re: [jdk17] RFR: 8269543: The warning for System::setSecurityManager should only appear once for each caller

On 30/06/2021 08:19, Bernd Eckenfels wrote: Hello, sorry for being unpopular, but I just hate it to waste developer resources, I realy think this deprecation message should be re-considered, it broke a lot of things, the amount of work to implement a caching solution feels like a waste of tim

Re: [jdk17] RFR: 8269543: The warning for System::setSecurityManager should only appear once for each caller [v2]

On Wed, 30 Jun 2021 15:45:25 GMT, Weijun Wang wrote: >> Add a cache to record which sources have called `System::setSecurityManager` >> and only print out warning lines once for each. > > Weijun Wang has updated the pull request incrementally with one additional > commit since the last revision

Re: JEP 411 Headaches: Instrumenting private methods in the JDK for authorization checkpoints.

On 23/07/2021 11:48, Peter Firmstone wrote: Perhaps the solution is to replace the entire class, instead of instrumenting one method? Compile a patched copy of the JVM, with modified class files, then replace the existing classes in the JVM with the modified classes? Kinda like maintaining

Re: RFR: 8268873: Unnecessary Vector usage in java.base

On Fri, 18 Jun 2021 18:28:26 GMT, Sean Mullan wrote: >> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to >> use `ArrayList` if a thread-safe implementation is not needed. In >> post-BiasedLocking times, this is gets worse, as every access is >> synchronized. >> I ch

Re: JEP 411 Headaches: Instrumenting private methods in the JDK for authorization checkpoints.

On 23/07/2021 23:33, Peter Firmstone wrote: I think it's worth noting that there isn't a way to securely run code with malicious intent now, so I'm surprised that at this late stage you were still providing support for sand boxing (whack a mole). It's just for us many assumptions have been mad

Re: JEP 411, removal of finalizers, a path forward.

On 31/07/2021 04:04, Peter Firmstone wrote: Allan has advised when finalizers are removed, it will be practical to use Agents to instrument public API to implement an authorization layer, this is try, so can it be coordinated with JEP 411 et al? Our exchange was about instrumenting construct

Re: JEP 411, removal of finalizers, a path forward.

On 01/08/2021 15:28, Uwe Schindler wrote: : What I figured out: You intend to remove SecurityManager because it does not fit your latest ideas how Java threads should behave. I know the main problem is not "SecurityManager is too complex / too slow / wrongly used /..." -- the main problem of so

Re: RFR: 8272120: Avoid looking for standard encodings in "java." modules

On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov wrote: > This is the continuation of JDK-8233884 and JDK-8271456. This change affects > fewer cases so I fix all "java." modules at once. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("U

Re: RFR: 8272120: Avoid looking for standard encodings in "java." modules

On Tue, 10 Aug 2021 18:41:04 GMT, Claes Redestad wrote: > Yes, while I don't know exactly which changes resolved JDK-6764325, it's > clear from the microbenchmarks added for #2102 that it's no longer an issue - > at least not in the mainline. Thanks for checking and for closing that issue. --

Re: RFR: 8272120: Avoid looking for standard encodings in "java." modules

On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov wrote: > This is the continuation of JDK-8233884 and JDK-8271456. This change affects > fewer cases so I fix all "java." modules at once. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("U

Re: RFR: 8272626: Avoid C-style array declarations in java.*

On Wed, 18 Aug 2021 10:07:35 GMT, Claes Redestad wrote: > C-style array declarations generate noisy warnings in IDEs, et.c. This patch > cleans up all java.* packages. > > (Copyrights intentionally not updated due the triviality of most changes) Marked as reviewed by alanb (Reviewer). ---

Re: RFR: 8270380: Change the default value of the java.security.manager system property to disallow

On Sat, 21 Aug 2021 11:23:54 GMT, Weijun Wang wrote: >> src/java.base/share/classes/java/lang/SecurityManager.java line 128: >> >>> 126: * null >>> 127: * None >>> 128: * Always throws {@code UnsupportedOperationException} >> >> Not sure "Always" is needed, could just be "Throws UOE" >

Re: RFR: 8272805: Avoid looking up standard charsets

On Sun, 22 Aug 2021 02:53:44 GMT, Sergey Bylokhov wrote: > This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("UTF-8"); > > This could be done more efficiently(up to x20

Re: RFR: 8270380: Change the default value of the java.security.manager system property to disallow

On 23/08/2021 05:45, David Holmes wrote: : @wangweij there are many tests that can call setSecurityManager() and will presumably need to be fixed before this switch can be applied. And all testing will need to be updated to require jtreg 6.1 (which no longer uses the SM) once it is released.

Re: System.exit(...) without SecurityManager - implications for Apache Ant project

On 23/08/2021 07:46, Jaikiran Pai wrote: : So if any of the upcoming Java 18 EA builds introduce the "disallow" by default, then if Ant has to test against those EA builds (not just for SecurityManager but any other changes), then Ant project will have to start setting the "java.security.mana

Re: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the java.util.logging

On Wed, 1 Sep 2021 06:31:16 GMT, Sergey Bylokhov wrote: > The "java.util.logging.LogManager" class uses the "threadgroup sandboxing" > via an AppContext to support "applet logging isolation". The AppContext class > became useless since the plugin and webstart are no longer supported and > remo

Re: RFR: 8273401: Remove JarIndex support in URLClassPath

On Tue, 7 Sep 2021 03:34:27 GMT, wxiang wrote: > There is a bug for URLClassPath.findResources with JarIndex. > With some discussions about the bug, the current priority is to remove the > JAR index support in URLClassPath, > and don’t need to do anything to the jar tool in the short term, exc

Re: RFR: 8273401: Remove JarIndex support in URLClassPath [v2]

On Wed, 8 Sep 2021 06:30:34 GMT, wxiang wrote: > Create CSR: https://bugs.openjdk.java.net/browse/JDK-8273473 Thanks. I've updated the CSR to make it clearer what this change is about. There is still some TDB for the JAR file spec. - PR: https://git.openjdk.java.net/jdk/pull/5383

Re: RFR: 8273401: Remove JarIndex support in URLClassPath [v2]

On Wed, 8 Sep 2021 06:30:34 GMT, wxiang wrote: >> wxiang has updated the pull request incrementally with one additional commit >> since the last revision: >> >> Some minor changes >> >> Include: >> 1. remove public for INDEX_NAME in JarFile >> 2. recover the definition for INDEX_NAM

Re: RFR: 8273401: Remove JarIndex support in URLClassPath [v2]

On Wed, 15 Sep 2021 01:45:49 GMT, wxiang wrote: > Yes, I will take care of it. Need I create a new PR? Up to you, it's okay to continue with this one if you want, we would just need to change the description here and in JBS. - PR: https://git.openjdk.java.net/jdk/pull/5383

Re: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v3]

On Sun, 17 Oct 2021 15:55:59 GMT, Aleksei Efimov wrote: > * `InetAddressResolverProvider.Configuration` interface API might evolve, > e.g. there might be a need to pass additional configuration items. > * local hostname is a dynamic information, therefore it cannot be passed as > string paramet

Re: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v5]

On Wed, 20 Oct 2021 11:52:38 GMT, Aleksei Efimov wrote: >> This change implements a new service provider interface for host name and >> address resolution, so that java.net.InetAddress API can make use of >> resolvers other than the platform's built-in resolver. >> >> The following API classes

Re: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v5]

On Wed, 20 Oct 2021 11:52:38 GMT, Aleksei Efimov wrote: >> This change implements a new service provider interface for host name and >> address resolution, so that java.net.InetAddress API can make use of >> resolvers other than the platform's built-in resolver. >> >> The following API classes

Re: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v5]

On Wed, 20 Oct 2021 18:25:24 GMT, Alan Bateman wrote: >> Aleksei Efimov has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Change InetAddressResolver method names > > src/java.b

Re: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v7]

On Fri, 22 Oct 2021 14:27:41 GMT, Aleksei Efimov wrote: >> This change implements a new service provider interface for host name and >> address resolution, so that java.net.InetAddress API can make use of >> resolvers other than the platform's built-in resolver. >> >> The following API classes

Re: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v8]

On Tue, 26 Oct 2021 12:52:58 GMT, Aleksei Efimov wrote: >> This change implements a new service provider interface for host name and >> address resolution, so that java.net.InetAddress API can make use of >> resolvers other than the platform's built-in resolver. >> >> The following API classes

Re: previously prevented exploit now possible with JDK 18

On 28/10/2021 20:14, Rick Hillegas wrote: As a canary in the mineshaft, I built and tested Apache Derby with the recent build 18-ea+20-1248 of Open JDK 18. I tripped across the following issue when running Derby's regression tests. The problem is explained in more detail at https://issues.apac

Re: RFR: 8276348: Use blessed modifier order in java.base

On Tue, 2 Nov 2021 17:13:47 GMT, Roger Riggs wrote: > In comments, I think the 'synchronized static 'reads better, the conventional > order is for the code. I think Roger is right and maybe the change to the javadoc could be dropped from this patch. - PR: https://git.openjdk.java

Re: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v13]

On Tue, 2 Nov 2021 19:35:29 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-419 [1]. A more >> detailed description of such changes, to avoid repetitions during the review >> process, is included as a separate comment. >> >> [1] - https://openjdk

Re: RFR: JDK-8276447 Deprecate finalization-related methods for removal

On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian wrote: > Here are the code changes for the "Deprecate finalizers in the standard Java > API" portion of JEP 421 ("Deprecate Finalization for Removal") for code > review. > > This change makes the indicated deprecations, and updates the API spec

Re: RFR: 8277932: Subject:callAs() not throwing NPE when action is null

On Mon, 6 Dec 2021 22:22:14 GMT, Weijun Wang wrote: > Add null check. I must have thought the NPE will be thrown anyway but the > `catch Exception` block swallows it. > > I added a noreg-trivial label. If you think differently can add one. Is there a test for this? (I see noreg-trivial is adde

<    4   5   6   7   8   9   10   >