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

On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo wrote: > This PR follows up one of the recent PRs, where I used a non-canonical > modifier order. Since the problem was noticed [^1], why not to address it at > mass? > > As far as I remember, the first mass-canonicalization of modifiers took place

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

On Tue, 2 Nov 2021 19:14:23 GMT, Pavel Rappo wrote: >> Pragmatically, fix the script to ignore those keywords on comment lines. >> Learn Perl, its just a regular expression pattern match and replace >> expression. >> >> All of the changes have to be manually reviewed by the author and then

Re: RFR 8237858: PlainSocketImpl.socketAccept() handles EINTR incorrectly

imple test case for this issue but it is getting more > complex. > > Thanks, > Vyom > > On Sat, Jul 4, 2020 at 8:14 PM Martin Buchholz wrote: >> >> On Fri, Jul 3, 2020 at 11:12 PM Alan Bateman wrote: >> >> > - "service" isn't a great name for the Executor

Re: RFR 8237858: PlainSocketImpl.socketAccept() handles EINTR incorrectly

On Fri, Jul 3, 2020 at 11:12 PM Alan Bateman wrote: > - "service" isn't a great name for the Executor. Also you can make use > of try-finally, e.g. > ExecutorService executor = Executors.newFixedThreadPool(1); > try { ... } finally { executor.shutdown(); } If you want to do this

Re: RFR: JDK-8235903: GCC default -fno-common exposes "multiple definition" link errors

forwarded to other teams for review. On Fri, Dec 13, 2019 at 3:14 AM Patrick Zhang OS < patr...@os.amperecomputing.com> wrote: > Hi > > Please review this patch, if it should be reviewed by any group other than > core-libs, please help forward it. Thanks. > > JBS:

Re: RFR: 8232853: AuthenticationFilter.Cache::remove may throw ConcurrentModificationException

in Cache#remove that's easy to fix. Nobody much likes LinkedList, but it does have the advantage of always shrinking to fit its contents. On Mon, Nov 4, 2019 at 7:09 AM Daniel Fuchs wrote: > Hi Martin, > > On 02/11/2019 16:40, Martin Buchholz wrote: > > Hi Julia, > > > >

Re: RFR: 8232853: AuthenticationFilter.Cache::remove may throw ConcurrentModificationException

Hi Julia, I think this is the wrong fix. Looking at the Cache class - all the methods are synchronized, so it looks like any failure is not actually due to concurrent execution, but any bug can be reproduced in a single thread. (please add such a repro to the bug report) It looks like

Re: RFR: 8223553: Fix code constructs that do not compile with the Eclipse Java Compiler

Stuart's cool type system hack is hard for me to grok, but it seems alright to put into ConcurrentSkipListMap.java. We could add it to the current jsr166 integration. *From: *Stuart Marks *Date: *Thu, May 16, 2019 at 3:11 PM *To: *Martin Buchholz, David Holmes, Doug Lea, Langer, Christoph *Cc

Re: RFR: JDK-8224028: loop initial declarations introduced by JDK-8184770 (jdwp)

Maybe you just need to ask gcc to use a more modern -std=... It might reasonably be defaulting to gnu89 https://stackoverflow.com/questions/14737104/what-is-the-default-c-mode-for-the-current-gcc-especially-on-ubuntu On Thu, May 16, 2019 at 3:25 PM David Holmes wrote: > On 16/05/2019 11:41 pm,

Re: RFR: 8223553: Fix code constructs that do not compile with the Eclipse Java Compiler

I feel the same as David - reluctant to change anything. Introducing a raw type makes an ugly cast uglier. *From: *David Holmes > > > src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java > > As you note this should be ok'd by jsr166 folk so I've cc'd Martin > Buccholz. I

Re: [ipv6] Regarding 8220673: Add test library support for determining platform IP support

TIL that we had tests with security policies so fine-grained that test libraries were granted more permissions than other test code. grant codeBase "file:${test.classes}/../../../../test/lib/-" { Given that, I agree with Chris and Daniel that test library code should include the same

Re: [ipv6] Regarding 8220673: Add test library support for determining platform IP support

On Thu, May 2, 2019 at 2:28 AM Daniel Fuchs wrote: > > 1. IPSupport needs to read system properties, attempts > to bind sockets etc... I wonder how that might interact > with tests that use a security manager, as some of these > operations may throw a SecurityException. > Maybe

Re: [RFR]: 8222562: IPv6 only systems fail on setsockopt(IPV6_V6ONLY, 0)

On Wed, Apr 17, 2019 at 10:58 AM Arthur Eubanks wrote: > It turns out these patches only apply to a modified kernel which has > patches to turn off IPv4. This specific patch doesn't make sense to submit > if the kernel patches are not upstream. > I disagree a little. Google may be decades

Re: [ipv6] Issue Tracking

Sorry for never having had the time to finish https://bugs.openjdk.java.net/browse/JDK-8179037 Improve IPv6 support On Mon, Apr 1, 2019 at 6:12 AM Chris Hegarty wrote: > Arthur, others, > > In order to help track the all the IPv6 related work, we have the > following issues: > > Improved IPv6

Re: Regarding 8220575: Correctly format test URI's that contain a retrieved IPv6 address

On Wed, Mar 13, 2019 at 11:24 AM Daniel Fuchs wrote: > > jshell> InetAddress.getLoopbackAddress().getHostName() > $7 ==> "localhost" > > jshell> InetAddress.getAllByName("localhost"); > $8 ==> InetAddress[3] { >localhost/127.0.0.1, >localhost/0:0:0:0:0:0:0:1, >

Re: RFR: 8220083: Use InetAddress.getLoopbackAddress() in place of 127.0.0.1 for some tests

On Wed, Mar 13, 2019 at 11:49 AM Chris Hegarty wrote: > > > At Google, we have our own hacks to test ipv6-only environments, based > > on either LD_PRELOAD or eBPF (but it would take work to share them even > > in minimally functional form) > > Maybe I can produce something similar and publish

Re: RFR: 8220083: Use InetAddress.getLoopbackAddress() in place of 127.0.0.1 for some tests

On Tue, Mar 12, 2019 at 12:21 PM Chris Hegarty wrote: > > > Just curious, what tests did you run and under what environment? > > I ran all java/net, sun/net, com/sun/net/, and some nio. I'm have a bit > of a hacky environment: a JDK build with IPV6_V6ONLY set to 1, and > preferIPv6Addresses

Re: RFR: 8220585: Incorrect code in MulticastSocket sample code

Looks good to me. On Wed, Mar 13, 2019 at 9:34 AM Arthur Eubanks wrote: > Hi, > > A fix for some sample code in MulticastSocket, which assumed that > String.length() == String.getBytes().length, which is not true for > non-ASCII Strings. > >

Re: RFR: 8220083: Use InetAddress.getLoopbackAddress() in place of 127.0.0.1 for some tests

These changes are clean progress and allow tests to pass on any of the 4 (!) combinations of IPV4/IPV6 support available. LGTM. BUT ... in the current multi-protocol world it's probably better to test against all the interfaces available on the host machine. Maybe there should be a

Re: RFR: 8220083: Use InetAddress.getLoopbackAddress() in place of 127.0.0.1 for some tests

Tested with $ make test TEST="test/jdk/com/sun/net/httpserver test/jdk/com/sun/nio/ test/jdk/java/net test/jdk/java/nio/channels test/jdk/java/rmi/transport/ test/jdk/jdk/net/ test/jdk/sun/net/" That's useful information, but unfortunately jcheck will reject it. Please edit the commit metadata

Re: RFR: 8220083: Use InetAddress.getLoopbackAddress() in place of 127.0.0.1 for some tests

On Mon, Mar 11, 2019 at 10:18 AM Daniel Fuchs wrote: > > Also please update the copyright years in the files you're > changing. > > Google policy is to leave Copyright years in source files untouched. Especially another company's!

Re: [13] RFR: 8218554: HttpServer: allow custom handlers to request that the connection be closed after the exchange.

All backports become visible on the master bug https://bugs.openjdk.java.net/browse/JDK-8218554 e.g. https://bugs.openjdk.java.net/browse/JDK-8217319 On Mon, Feb 11, 2019 at 10:26 AM Wenbo Zhu wrote: > Thanks for the fix! > > I am new to this and could you let me know how to find out the target

Re: RFR 8215008: Clear confusion between URL/URI paths and file system paths

Thanks. Looks good. Tangentially ... I see URLClassLoader uses URLClassPath which uses FileURLMapper, which tries to directly convert a URL to a String path. FileURLMapper uses URL#getFile, and TIL that #getFile differs from #getPath in that it also returns a query component where present. Maybe

Re: RFR [12] 8213490: Networking area nano cleanup

See also https://bugs.openjdk.java.net/browse/JDK-8213218 https://bugs.openjdk.java.net/browse/JDK-8213220 On Mon, Nov 12, 2018 at 10:29 AM, Pavel Rappo wrote: > > On 12 Nov 2018, at 18:14, Alan Bateman wrote: > > > > It will need a CSR because it changes Inet6Address to specify that it > can

Re: [PATCH] SOCK_CLOEXEC for opening sockets

I agree with this approach - it parallels the efforts made with O_CLOEXEC in past years. According to https://www.freebsd.org/cgi/man.cgi?query=socket=2 SOCK_CLOEXEC is also available on freebsd. On Tue, Jul 10, 2018 at 1:36 AM, Andrew Luo < andrewluotechnolog...@outlook.com> wrote: > Hi, > > >

Re: RFR: 8193034: Optimize URL.toExternalForm

for the default and assume that multiple String concatenation does in fact get optimized. I'm not planning to check in the benchmark code. On Tue, Dec 5, 2017 at 2:10 AM, Chris Hegarty <chris.hega...@oracle.com> wrote: > > > On 5 Dec 2017, at 04:01, Martin Buchholz <marti...@google.com>

RFR: 8193034: Optimize URL.toExternalForm

http://cr.openjdk.java.net/~martin/webrevs/jdk/URL.toExternalForm/

Re: RFR: 8189366: SocketInputStream.available() should check for eof

Any change that fiddles with "available" is never simple! I confess to not understanding sockets, but intuitively they differ from files in that eof is a murky concept - there may not be any data from the other end of the socket right now, but who knows what's coming soon? What's the difference

Re: Let's improve IPv6 support

On Mon, Mar 20, 2017 at 2:46 PM, Alexander Smundak wrote: > Should this be a patch for JDK9 or JDK10? > It's too late for jdk9 initial release, although we might backport to jdk9.1.

Re: Let's improve IPv6 support

On Mon, Mar 20, 2017 at 7:14 AM, Chris Hegarty wrote: > >> I should point out that the current batch of changes are focused on >> support for systems where 127.0.0.1 doesn't exist, which is relatively >> straightforward and unexciting. >> > > Sorry, what does this mean.

Let's improve IPv6 support

Google cares a lot about IPv6, and not only because Vint Cerf works at Google. We have some local modifications and some networking expertise and intend to port/contribute that to openjdk10. Most of this is the work of my colleagues Alexander Smundak and Paul Marks. We hope we can do most of

Re: RFR: JDK-8175325 - NetworkInterface.getInterfaceAddresses throws NPE when no addresses

It would not have both the never-null property and the check for null. I would probably just leave bindings null in the constructor and check for null whenever reading bindings. On Mon, Mar 6, 2017 at 2:00 PM, Mark Sheppard wrote: > Hi, >please oblige and review

Re: HTTP client API

On Wed, Sep 7, 2016 at 10:15 AM, Michael McMahon < michael.x.mcma...@oracle.com> wrote: > > [1] http://cr.openjdk.java.net/~michaelm/httpclient/api.1/ > > [2] http://cr.openjdk.java.net/~michaelm/httpclient/ > specdiffout.1/package-summary.html > Could we have actual source code for

Re: HTTP client API

I don't know much about http, but I believe those who say that it's very hard to get the API right. Perhaps it would be best to deliver a http client library as an independent beta package for use with jdk 8+ with a final version becoming part of jdk 10? Perhaps there can be a productive

Re: HTTP client API

On Tue, Aug 23, 2016 at 12:57 PM, Wenbo Zhu wrote: > >> We are currently working in the sandbox repository again and will have >> these changes >> in the main JDK9 dev forest soon. >> > Is it possible to access the API code somewhere before then, mainly as a > convenience for

Re: JDK-8148424 Support IPv6-only Unix environments

I'm (slowly) working on getting you more ipv6 stuff... On Thu, May 12, 2016 at 8:32 AM, Chris Hegarty wrote: > Martin, > > Promoted by some other changes that are going on, I stumbled > across your proposal for 8148424: "Support IPv6-only Unix > environments” [1][2][3].

Re: RFR JDK-8087113: Websocket API and implementation

On Sun, Apr 10, 2016 at 10:19 PM, Andrej Golovnin wrote: >> On Sun, Apr 10, 2016 at 2:00 PM, Andrej Golovnin >> wrote: >>> BTW, someone should describe in the JavaDocs of >>> CompletableFuture#orTimeout() >>> what would happen when this

JDK-8148424 Support ipv6-only environments

Are y'all interested in our ipv6-only changes? https://bugs.openjdk.java.net/browse/JDK-8148424 If yes, there will be some work on both sides, mostly for multi-platform testing.

Re: 8008662: Add @jdk.Supported to JDK-specific/supported API

On Thu, Feb 21, 2013 at 6:16 PM, Joe Darcy joe.da...@oracle.com wrote: However, the com.sun.* subpackages are a mix of APIs that are supported as described above as well as APIs that are not supported. I was under the impression that the general rule was that all of com.sun.* fell under the

Re: 8008662: Add @jdk.Supported to JDK-specific/supported API

Hi Joe, On Fri, Feb 22, 2013 at 11:19 AM, Joe Darcy joe.da...@oracle.com wrote: Should third-party vendor extensions that are supported for public use by the third-party use jdk.Supported? No; as I envision it, the jdk.Supported annotation is only meant to convey supported-ness in the

Re: Infinite Loop in KeepAliveStream

Pushed. On Mon, Dec 17, 2012 at 11:18 PM, Chris Hegarty chris.hega...@oracle.comwrote: Thank you Martin, looks good. -Chris On 18 Dec 2012, at 02:45, Martin Buchholz marti...@google.com wrote: I created a webrev http://cr.openjdk.java.net/~martin/webrevs/openjdk8/KeepAliveStream

Re: Infinite Loop in KeepAliveStream

; } I was trying to avoid ever calling skip with a larger argument than available(), trying to obey the comment // Do this ONLY if the skip won't block. So my version feels safer, although again I don't have the full context. -Chris On 12/13/2012 12:49 AM, Martin

Re: Infinite Loop in KeepAliveStream

On Tue, Dec 11, 2012 at 7:40 AM, Chris Hegarty chris.hega...@oracle.comwrote: Hi Martin, Thank you for reporting this issue. I filed 8004863: Infinite Loop in KeepAliveStream, to track it. I put together a small test to reproduce the problem (inline below). It is racey, but shows the

Infinite Loop in KeepAliveStream

Hi sun/net/www maintainers, Here at Google we have observed an infinite loop in jdk/src/share/classes/sun/net/www/http/KeepAliveStream.java 85: if (nskip = available()) { 86: long n = 0; 87: while (n nskip) { 88:

Re: Small improvements to Inet6 implementation (unix)

On Wed, Sep 1, 2010 at 06:27, Michael McMahon michael.x.mcma...@oracle.comwrote: Martin Buchholz wrote: Hi net maintainers, I'd like you to do a code review. I got frustrated with incomplete information from exceptions thrown from java.net http://java.net, so I hacked up some fixes

Re: Small improvements to Inet6 implementation (unix)

) error_string = unknown error; Webrev regenerated. Martin On Wed, Sep 1, 2010 at 10:51, Martin Buchholz marti...@google.com wrote: On Wed, Sep 1, 2010 at 06:27, Michael McMahon michael.x.mcma...@oracle.com wrote: Martin Buchholz wrote: Hi net maintainers, I'd like you to do

Small improvements to Inet6 implementation (unix)

Hi net maintainers, I'd like you to do a code review. I got frustrated with incomplete information from exceptions thrown from java.net, so I hacked up some fixes for them. This is the result. generify; remove compiler warnings, typos, casts; return status information via gai_strerror when

EPollArrayWrapper.release should be O(N), not O(N^2)

Hi Alan, This is a bug report with fix. Please review. webrev: http://cr.openjdk.java.net/~martin/webrevs/openjdk7/EPollArrayWrapper.release/ Synopsis: EPollArrayWrapper.release should be O(N), not O(N^2) Description: In a recent email, I said no one is really using LinkedList in

Re: [concurrency-interest] LinkedBlockingDeque deadlock?

also interested in confirming that this is a sane use of Selectors, SocketChannels, and SelectionKeys. Thanks, Ariel Weisberg On Wed, 15 Jul 2009 14:24 -0700, Martin Buchholz marti...@google.com wrote: In summary, there are two different bugs at work here, and neither of them is in LBD