RFR: 8252996: Thread safety problem in java.net.ProxySelector
8252996: Thread safety problem in java.net.ProxySelector - Commit messages: - 8252996: Fix visibility issue in ProxySelector Changes: https://git.openjdk.java.net/jdk/pull/184/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=184&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252996 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/184.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/184/head:pull/184 PR: https://git.openjdk.java.net/jdk/pull/184
Re: RFR: 8252996: Thread safety problem in java.net.ProxySelector
On Tue, 15 Sep 2020 13:54:14 GMT, David M. Lloyd wrote: > 8252996: Thread safety problem in java.net.ProxySelector Seems like an oversight when proxy selector was added - Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/184
Re: RFR: 8252996: Thread safety problem in java.net.ProxySelector
On Thu, 17 Sep 2020 12:07:06 GMT, Alan Bateman wrote: >> 8252996: Thread safety problem in java.net.ProxySelector > > Seems like an oversight when proxy selector was added Hi David, I can sponsor this for you - unless you already have a sponsor? best regards, -- daniel - PR: https://git.openjdk.java.net/jdk/pull/184
Re: RFR: 8252996: Thread safety problem in java.net.ProxySelector
On Thu, 17 Sep 2020 13:04:28 GMT, Daniel Fuchs wrote: >> Seems like an oversight when proxy selector was added > > Hi David, > > I can sponsor this for you - unless you already have a sponsor? > > best regards, > -- daniel No, I do not (though @ChrisHegarty did take a peek at my original ML post). - PR: https://git.openjdk.java.net/jdk/pull/184
Integrated: 8252996: Thread safety problem in java.net.ProxySelector
On Tue, 15 Sep 2020 13:54:14 GMT, David M. Lloyd wrote: > 8252996: Thread safety problem in java.net.ProxySelector This pull request has now been integrated. Changeset: cca3a26e Author:David M. Lloyd Committer: Daniel Fuchs URL: https://git.openjdk.java.net/jdk/commit/cca3a26e Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8252996: Thread safety problem in java.net.ProxySelector Reviewed-by: alanb - PR: https://git.openjdk.java.net/jdk/pull/184
Re: RFR: 8252996: Thread safety problem in java.net.ProxySelector
On Thu, 17 Sep 2020 13:16:41 GMT, David M. Lloyd wrote: >> Hi David, >> >> I can sponsor this for you - unless you already have a sponsor? >> >> best regards, >> -- daniel > > No, I do not (though @ChrisHegarty did take a peek at my original ML post). Done. - PR: https://git.openjdk.java.net/jdk/pull/184
Re: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase
On Fri, 11 Sep 2020 15:17:58 GMT, Bradford Wetmore wrote: >> Ok, sorry for the distraction. > > Our local Santuario maintainer says: > > In general, changes to Apache Santuario should also be made at Apache so we > stay in sync. Hi @doom369, I hope we didn't end up wasting too much of your time with this. I wanted to respond to a comment you made earlier in this PR, > I have in mind dozens of improvements all over the code like this one. It's hard to see, but as you discovered, the JDK has different groups of people maintaining different areas, and sometimes there are hidden constraints on those different areas, for example, to avoid divergence with upstream source bases. And as you discovered, sometimes those source bases might need to maintain compatibility with an older JDK ... so we don't want to update this code even though it's IN the JDK. Those kind of constraints generally don't apply to code in the java.base module, since there's nothing upstream of it, and by definition it cannot depend on anything outside the JDK. Generally -- though there are exceptions -- we're more receptive to keeping stuff in java.base (and sometimes related modules close to the core) on the latest and greatest stuff. There are some constraints, however. There are some things we can't use too early during initialization of the JDK, such as lambdas. Also, there is some code lurking around that is sometimes executed by the boot JDK, which is typically one release behind. (This is definitely the case for tools like javac, but I think it might also apply to some things in base.) Anyway, if you'd like to pursue some of these improvements, drop a note to core-libs-dev@openjdk and we can talk about it. Thanks. - PR: https://git.openjdk.java.net/jdk/pull/29
