Re: RFR [14] 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect

ons and error handling in one place. Unless there's a good reason I wouldn't change it. > Timeouts should be adjusted via Utils.adjustTimeout That makes perfect sense. I never knew this method existed. Thanks! > On Fri, Sep 6, 2019 at 4:31 AM Pavel Rappo wrote: > Martin, thanks for having

Re: RFR(s): 8228580: DnsClient TCP socket timeout

Milan, In order to simulate the "Address already in use" scenario I did this: TcpDnsServer(int port) { try { * new ServerSocket(port, 0, InetAddress.getLoopbackAddress()); serverSocket = new ServerSocket(port, 0, InetAddress.getLoopbackAddress()); } catch

Re: RFR: 8230648: Replace @exception tag with @throws in java.base

If you ran the specdiff and saw nothing, I'm fine with that. Looks good. > On 5 Sep 2019, at 19:28, Julia Boes wrote: > > Hi, > > Thanks for your comments, Lance and Pavel. > > The copyright will be updated before pushing, as Daniel suggested. > > To address the tag alignment, I adjusted the

Re: RFR [14] 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect

ction ... actions) { > ExecutorService pool = Executors.newCachedThreadPool(); > try (PoolCleaner cleaner = cleaner(pool)) { > > On Fri, Aug 30, 2019 at 6:23 AM Daniel Fuchs wrote: > On 30/08/2019 13:54, Pavel Rappo wrote: > > Updated, > > > > http://c

Re: RFR(s): 8228580: DnsClient TCP socket timeout

I think we are almost there. What do you think of the following incremental (i.e. on top of your latest webrev) change? http://cr.openjdk.java.net/~prappo/8228580/webrev.01/ I fixed a couple of trivial typos and addressed the socket relinquishing issue. Initializing a socket is not an

Re: RFR: 8230648: Replace @exception tag with @throws in java.base

Julia, Trivially update the copyright years and pay attention to not-so-trivial things like: 8157682: @inheritDoc doesn't work with @exception I'd suggest comparing "before" and "after" javadoc visually to make sure no funny business is going on. -Pavel > On 5 Sep 2019, at 11:40, Julia

Re: RFR(s): 8228580: DnsClient TCP socket timeout

> On 4 Sep 2019, at 18:54, Florian Weimer wrote: > > You should use a larger timeout than the initial UDP timeout, > though. Could you elaborate on that?

Re: RFR(s): 8228580: DnsClient TCP socket timeout

> On 4 Sep 2019, at 18:38, Florian Weimer wrote: > > > > Maybe I'm mistaken, but I think this: > > 692 Tcp(InetAddress server, int port, int timeout) throws IOException { > 693 sock = new Socket(server, port); > 694 sock.setTcpNoDelay(true); > 695 out = new

Re: RFR(s): 8228580: DnsClient TCP socket timeout

> On 4 Sep 2019, at 17:35, Florian Weimer wrote: > > * Milan Mimica: > >> Continuing in a new thread with a RFR of my own: >> http://cr.openjdk.java.net/~mmimica/8228580/webrev.00/ > > I would add a comment why there's no explicit TCP connection timeout in > the code. I assume you rely on the

Re: RFR(s): 8228580: DnsClient TCP socket timeout

> On 4 Sep 2019, at 13:26, Milan Mimica wrote: > > Hello > > Continuing in a new thread with a RFR of my own: > http://cr.openjdk.java.net/~mmimica/8228580/webrev.00/ Here's the link to the previous discussion: https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/061918.html

Re: [PATCH] JDK-8228580 DnsClient TCP socket timeout

of solutions for this issue. One would be to make the test run inapplicable by throwing jtreg.SkippedException. 3. L34, typo: UDH DNS server; L57, typo: the reponse is -Pavel > On 2 Sep 2019, at 18:58, Milan Mimica wrote: > > On Mon, 2 Sep 2019 at 17:45, Pavel Rappo wrote: >> >>

Re: [PATCH] JDK-8228580 DnsClient TCP socket timeout

> On 22 Aug 2019, at 08:20, Milan Mimica wrote: > > Hi > > Indeed I have forgotten. Re-attached, with aesthetic fixes to the test. Milan, it seems that there is more work than we might've imagined initially. So as to proceed efficiently I would recommend you create a proper RFR [1] based on

Re: [PATCH] JDK-8228580 DnsClient TCP socket timeout

> On 21 Aug 2019, at 09:27, Milan Mimica wrote: > > I don't know why main/timeout=20 does not work for me. What do you mean exactly by "does not work for me"? Are there any associated traces/logs from jtreg? Can you post them?

Re: RFR [14] 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect

resolve to the same > address than that returned by InetAddess.getLoopbackAddress(), > so it may be better to use the literal address (which may be > an IPv6 literal requiring enclosing "[" "]") rather than > the hostname when building the LDAP URL. > >

RFR [14] 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect

// // Dear maintainer: // // Once you are done trying to 'optimize' this routine, // and have realized what a terrible mistake that was, // please

Re: [PATCH] JDK-8228580 DnsClient TCP socket timeout

Thanks for doing that. I've only skimmed through the patch and I’d recommend that no matter if the changes are adequate or not there should be a test [1]: "...A unit test, written for the jtreg test harness, that validates your change. The test should fail when run against a build without the

Re: RFR [14] 8217606: LdapContext#reconnect always opens a new connection

> On 13 Aug 2019, at 16:58, Roger Riggs wrote: > > > > The Semaphore implementation is the least complex. Looks fine to me. Updated: http://cr.openjdk.java.net/~prappo/8217606/webrev.01/ -Pavel

Re: RFR [14] 8217606: LdapContext#reconnect always opens a new connection

Comments are inline. > On 8 Aug 2019, at 18:59, Roger Riggs wrote: > > Hi Pavel, > > To your questions... > > > On 8/8/19 11:07 AM, Pavel Rappo wrote: > ... >>> 109: "template method" doesn't describe the method well, the method is >>>

Re: RFR [14] 8217606: LdapContext#reconnect always opens a new connection

Roger, answers are inline. > On 7 Aug 2019, at 16:52, Roger Riggs wrote: > > > > BaseLdapServer: > > 100: The new exception should have a message "Unexpected exception" or > "server should no be running"... Fixed. > 158: Is printing the stack trace diagnostic or an error?, the exception

Re: RFR [14] 8217606: LdapContext#reconnect always opens a new connection

> On 7 Aug 2019, at 18:49, Roger Riggs wrote: > > > > It seemed unnecessary/redundant since except for isRunning it is updated > inside a synchronize(lock). Pardon, what seemed unnecessary? > The synchronized(socketList) is also unnecessary since it is already > synchronized on lock. You

Re: RFR [14] 8217606: LdapContext#reconnect always opens a new connection

Roger, thank you for looking at this. While we might hear (on some of your questions) from Chris soon, I just have to ask about this one > On 7 Aug 2019, at 16:52, Roger Riggs wrote: > > 238: isRunning should be synchronized(lock) to make sure each Thread sees the > same value threads that

RFR [14] 8217606: LdapContext#reconnect always opens a new connection

Hello, Please review the following change: http://cr.openjdk.java.net/~prappo/8217606/webrev.00/ The original issue seems to be an unintended consequence of JDK-8059009 [1]. The proposed change is based on the private patch by Chris Yin. I skimmed through the history of the

Re: 8078891: java.io.SequenceInputStream.close is not atomic and not idempotent

> On 26 Jul 2019, at 19:36, Alan Bateman wrote: > > > > In any case, the change looks okay but it might be simpler to restructure to > use: > > while (in != null) { > try { in.close() } catch (IOException e) { ... } > peekNextStream(); > } > > to simplify the error handling and

Re: 8078891: java.io.SequenceInputStream.close is not atomic and not idempotent

> On 26 Jul 2019, at 19:36, Alan Bateman wrote: > > The bug summary might be a big misleading as SequenceInputStream isn't thread > safe and close isn't atomic. The changes are really to attempt to close all > the remaining streams rather than bailing out when closing one of them fails. I'm

Re: 8078891: java.io.SequenceInputStream.close is not atomic and not idempotent

> On 25 Jul 2019, at 21:01, Brian Burkhalter > wrote: > This concern would be fixed by changing the proposed patch as > > --- a/src/java.base/share/classes/java/io/SequenceInputStream.java > +++ b/src/java.base/share/classes/java/io/SequenceInputStream.java > @@ -91,13 +91,10 @@ > *

Re: 8078891: java.io.SequenceInputStream.close is not atomic and not idempotent

Brian, Thanks a lot for picking up a bug I filled back in 2015. This looks like a good cleanup! I'm a bit concerned though with the added `finally` block in L98. Could that lead to a subtle behavioral change for (an unlikely) case where a `read` method exhausts the current stream, then tries to

Re: DnsClient TCP socket timeout

I have created an issue to track this: https://bugs.openjdk.java.net/browse/JDK-8228580 > Hello list > > Have you ever considered the problem reported here: > > https://stackoverflow.com/questions/14603553/dns-query-freezes-with-dnscontextfactory-in-java > > > A DNS query gets stuck

Re: RFR [14] 8226303: Examine the HttpRequest.BodyPublishers for exception handling

it * @bug 8226303 Is that okay? 2) Done. Thanks. > On 18 Jun 2019, at 16:07, Chris Hegarty wrote: > > [ adding net-dev ] > > Pavel, > >> On 18 Jun 2019, at 14:22, Pavel Rappo wrote: >> >> Hello, >> >> Please review the following change: &

RFR [14] 8226303: Examine the HttpRequest.BodyPublishers for exception handling

Hello, Please review the following change: http://cr.openjdk.java.net/~prappo/8226303/webrev.00 This change increases robustness of convenience BodyPublishers by going the extra mile and ensuring unlikely thrown exceptions are relayed downstream. Thanks, -Pavel

Re: Slightly faster java.util.Arrays.byteSort(byte[])

I'm not an expert, however, while your OCA (see below) is being processed I would recommend to provide more comprehensive stats. Different lengths of an array, different flavours of data: sorted, sorted in the reverse order, random, typical expected case(s), etc. It seems that this particular

Re: Slightly faster java.util.Arrays.byteSort(byte[])

Hi Rodion, A more appropriate place for your email would be the core-libs-dev mailing list, so CC'ing that list. > On 14 Jun 2019, at 16:34, Rodion Efremov wrote: > > Good evening! > > I managed to improve the JDK 8 java.util.Arrays.sort(byte[]) > performance-wise [1]. The (warmed up)

Re: [RFR] 8223727: com/sun/jndi/ldap/privconn/RunTest.java failed due to hang in LdapRequest.getReplyBer

Hi Rob, As per our offline conversation, there's indeed a race condition between the cleanup actions performed by LDAP connection (com.sun.jndi.ldap.Connection.cleanup) and reading from LdapRequest (com.sun.jndi.ldap.LdapRequest.getReplyBer). There are 3 activities of interest to us. Adding a

Re: RFR (M): JDK-6394757: rev1: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

Would you care to elaborate on that? As far as I understand Stuart was simply working around javadoc's bug in the "Copying of Method Comments" algorithm. > On 26 May 2019, at 17:25, Martin Buchholz wrote: > > This is yet another symptom of Java's fundamental design mistake of being > unable to

Re: RFR 8223730 : URLClassLoader.findClass() can throw IndexOutOfBoundsException

Ivan, This change looks good to me. It's a pity we can't use 3-args InputStream.readNBytes here. Unrelated to your change: it looks a bit wasteful to create a zero-length byte array only to throw it away later. We could probably pre-size it or at least make it a `private static final`? -Pavel

Re: RFR 8223593 : Refactor code for reallocating storage

Thanks for updating your patch. The updated code seems fine. -Pavel > On 11 May 2019, at 05:01, Ivan Gerasimov wrote: > > Hello! > > Please help review the updated fix. > > This new webrev includes changes suggested by Pavel, Peter and Roger. > > BUGURL:

Re: RFR 8223593 : Refactor code for reallocating storage

> On 10 May 2019, at 15:41, Roger Riggs wrote: > > 98: I think you've dropped the normal doubling of the buffer size that comes > from old line 115. > The buffer should be doubling in size, but at least minsize. I thought about it too initially. But then I reproduced that function. It

Re: RFR 8223593 : Refactor code for reallocating storage

Ivan, There seem to be more places that use a somewhat similar pattern. I was wondering if you have seen them and decided not to include them in your patch for some reason (e.g. they really are quite different)? Here are some of them: java.io.BufferedInputStream java.io.InputStream

Re: RFR 8223593 : Refactor code for reallocating storage

> On 10 May 2019, at 09:52, Peter Levart wrote: > > > > Is there a case where returning > MAX_ARRAY_SIZE will not lead to OOME? > > If this utility method is meant for re-sizing arrays only (currently it is > only used for that), then perhaps the method could throw OOME explicitly in > this

Re: RFR 8223593 : Refactor code for reallocating storage

Ivan, Many thanks for doing this! This code is both error-prone and abundant in the JDK, which indeed makes it a perfect candidate for refactoring. Since that particular change touches quite a few foundational parts of the libraries I felt the urge to make sure the change doesn't introduce any

Re: inconsistency between ArrayList.modCount and logic of ArrayList::addAll

We will certainly hear from Stuart on this very soon. Meanwhile, I have to say that the situation you've described is not that clear-cut in my opinion. I understand there might be a discrepancy between how the `modCount` field is described and how it is actually used. Incrementing `modCount`

Re: RFR (M): JDK-6394757: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

Stuart, That looks good. A tiny note on your FIXME comment [1]: 68 // FIXME: the first paragraph below is copied from Set.equals, because 69 // {@inheritDoc} will include text from Object.equals. You might want to check if it is the same as [2] or [3]. If it is the same, consider

Re: 8218280: LineNumberReader throws "Mark invalid" exception if CRLF straddles buffer.

> On 26 Apr 2019, at 02:20, Brian Burkhalter > wrote: > > For issue [1] please review the patch [2]. Looks good to me.

Re: RFR: 8221723: Avoid storing zero to String.hash

> On 1 Apr 2019, at 13:36, Claes Redestad wrote: > > Makes sense? It does, thanks. I wonder though what portion of strings in a typical app has a calculated `hash` of 0? My naive estimate would be 1E-9. Unless I'm mistaken, is that really of concern?

Re: RFR: 8221723: Avoid storing zero to String.hash

Hi Claes, > To make String objects more amenable to storage in shared read-only memory, > e.g., CDS archives, we should avoid this redundant store. Could you please elaborate on that?

Re: RFR 8220684 : Process.waitFor(long, TimeUnit) can return false for a process that exited within the timeout

> > > On 3/14/19 2:02 PM, Pavel Rappo wrote: >> I have to look at this patch in more detail, however here's what jumped out >> at >> me straight away: >> >> long deadline = System.nanoTime() + remainingNanos; >> >> It seems like a possibil

Re: RFR: 8219197: ThreadGroup.enumerate() may return wrong value

. Thanks for doing this. -Pavel > On 13 Mar 2019, at 14:41, Pavel Rappo wrote: > > I'm reading the test. Still trying to figure out how it works in detail. Give > me > some more time to get comfortable with it and I will reply to the list. At the > very least I would (suggestion) c

Re: RFR: 8219197: ThreadGroup.enumerate() may return wrong value

> On 13 Mar 2019, at 14:22, Daniel Fuchs wrote: > > I don't think there is another bug in the 3-args enumerate > methods. I might not have expressed myself clearly. I'm not saying there is an extra bug with the fix applied. What I'm saying is that without the fix, not only was the value wrong

Re: RFR: 8219197: ThreadGroup.enumerate() may return wrong value

Hi Daniel, First of all, the change looks good to me. The broken if (destroyed) { return n; } part looks like a "copy and paste" from some other method in the ThreadGroup class. They use recursion a lot. Might it be the case that not only the returned value is wrong, but also the

RFR [13] 8218022: Repeated words typos in java.base (was: Duplicate words typos in comments/javadoc/strings)

Alan, Lance, I have created a webrev with the change: http://cr.openjdk.java.net/~prappo/8218022/webrev.00/ I added bonus fixes and updated the copyright years. If everybody is fine with this change, I'm pushing it. List of locations of additional fixes added to Andrey's patch:

Re: Duplicate words typos in comments/javadoc/strings

> On 28 Jan 2019, at 22:23, Andrey Turbanov wrote: > > Thanks to review. Patch updated. I'm not really sure what to do next. > I should find someone who can create issue and commit my patch to > repository, right? Andrey, Could you please re-generate your patch? The reason I'm asking is that

Re: Duplicate words typos in comments/javadoc/strings

> On 29 Jan 2019, at 08:50, David Holmes wrote: > > Hi Pavel, > > I don't think this kind of trivial change needs the OCA to be signed. > > "A Participant may post messages to a list, submit simple patches, and make > other kinds of small contributions." [1] Hi David, That is true. However,

Re: Duplicate words typos in comments/javadoc/strings

> On 28 Jan 2019, at 22:23, Andrey Turbanov wrote: > > Thanks to review. Patch updated. I'm not really sure what to do next. > I should find someone who can create issue and commit my patch to > repository, right? Have you signed the OCA [1]? The full process is described here [2]. If you have

Re: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words

Sweet! Learning English with the OpenJDK community. You sir, probably, have a degree in public relations and/or marketing. This was *the best* way to draw attention to those swear words. Had these words stayed unexposed, no one would have been bothered by them. I guess... On a serious note, I

Re: RFR 8214971 : Replace use of string.equals("") with isEmpty()

Roger, changes look good. On a side note, it's impressive how many cases we have when we check for string not being null and empty. We should have had something for that *internally* in the JDK. And it's a pity that `String.trim().isEmpty()` not equivalent to `String.isBlank`. Seems to be a

Re: RFR 8214971 : Replace use of string.equals("") with isEmpty()

> On 6 Dec 2018, at 20:27, Jim Laskey wrote: > > I assume you automated this change, might be worthwhile to automate a > verification (compare the -+ pairs.) Eyeballing the patch it seems complete, > one comment changed as well. > > Question: Is it probably that vm optimizes .equals(“”) to

Re: RFR: XXS: JDK-8213910: Invalid HTML in java.net.http.HttpClient

Looks fine to me. P.S. Looks like your doccheck has already started to pay off. > On 15 Nov 2018, at 00:01, Jonathan Gibbons > wrote: > > Please review the removal of two extraneous in HttpClient.java. > > $ hg diff -R open > diff -r 40098289d580 >

Re: PipedInputStream improvement

tributing > code. > > See https://openjdk.java.net/contribute/ > > -- Jon > > > On 11/01/2018 01:04 PM, Pavel Rappo wrote: >>> On 29 Oct 2018, at 19:33, Ilya Gazman wrote: >>> >>> Hey guys, >>> >>> I created a more efficient ve

Re: PipedInputStream improvement

> On 29 Oct 2018, at 19:33, Ilya Gazman wrote: > > Hey guys, > > I created a more efficient version of java.io.PipedStream. I would like to > have a conversation with you about my implementation and how we can test > and benched marked it and eventually maybe even submit it for the next Java >

Re: Looking for guidness

General info on contributing can be found here: https://openjdk.java.net/contribute/ > On 30 Oct 2018, at 17:26, Ilya Gazman wrote: > > Hey guys, > > I would like to contribute to OpenJDK changes that I made to java.io. > PipedInput/Output/Stream. > > What would be the best way for me to

RFR [12] 8212001: Verify exported symbols in java.base (libjava)

Hello, Please review the following change: http://cr.openjdk.java.net/~prappo/8212001/webrev.00 This is yet another clean-up kind of change. It seals unnecessarily exported functions. This time from libjava. Also couldn't help fixing a typo. Not only does it soothe aesthetic discomfort, it

Re: Reactive Streams utility API

> On 26 Sep 2018, at 02:41, James Roper wrote: > > Sounds good to me, I'll ping Viktor to make sure he sees it too. The "Synchronization primitives in Reactive Streams implementations" thread on concurrency-interest mailing list:

Re: Reactive Streams utility API

> On 25 Sep 2018, at 05:33, James Roper wrote: > > Hi Pavel, > > > > As for the MutexExecutor itself, that was mostly written by Viktor Klang, and > I believe he wrote it based on his experience implementing similar constructs > for Akka mailboxes. There is one major problem with it that

Re: Reactive Streams utility API

Hi James, It sounds like the project is being very active. Glad to hear that! No matter how good a mailing list is, in practice, it cannot be the best mailing list for every topic there is. core-libs-dev is no exception. It's good to see you've found another way to make progress on the project.

Re: Reactive Streams utility API

Hi James, What's the status of the project? Has it been abandoned? -Pavel > On 22 Mar 2018, at 00:09, James Roper wrote: > > Hi all, > > We've created a reference implementation. It's been done in such a way that > implementation of new features (stages) is quite straight forward, there is >

Re: RFR 4358774: Add null InputStream and OutputStream

> On Dec 6, 2017, at 11:11 AM, Jonathan Gibbons > wrote: > >> "null" is a significant term in the Java ecosystem, and the relationship >> here, to /dev/null or NUL seems somewhat tenuous. >> >> Have any other names been considered? At least for the InputStream,

Re: 9 (test only) RFR: 8180279: java/net/httpclient/whitebox/Driver.java failed due to timeout

Daniel, thanks for taking care of this! Looks good. > On 24 May 2017, at 12:14, Daniel Fuchs wrote: > > Hi, > > Please find below a test-only fix for: > > 8180279: java/net/httpclient/whitebox/Driver.java failed due to timeout >

Re: [concurrency-interest] curious if there is a Local.java in the works for CompletableFutures like scala has

Heya Josh, I only want this question to be discussed on ci rather on core-libs-dev :-) I'm not the OP. > On 22 May 2017, at 23:01, Josh Humphries wrote: > > Pavel, > It sounds like you want [...]

Re: curious if there is a Local.java in the works for CompletableFutures like scala has

General questions on concurrency in Java should be asked here: http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest > On 18 May 2017, at 21:57, Dean Hiller wrote: > > Way more detail here... > >

Re: RFR [9] 8179021: Latest bugfixes to WebSocket/HPACK from the sandbox repo

This thread has just moved to net-dev mailing list: http://mail.openjdk.java.net/pipermail/net-dev/2017-May/010785.html Sorry for the noise, thanks. > On 20 Apr 2017, at 17:08, Pavel Rappo <pavel.ra...@oracle.com> wrote: > > Hello, > > Please review the followin

Re: JDK 9 RFR of JDK-8023897: Replace/update/rename executeAndCatch in various tests to assertThrows

> On 2 May 2017, at 22:02, Roger Riggs wrote: > > If the test was being written new I would advocate to add messages that > reflect the semantics of > the test case, not the exception message. > > But ": Must throw ClassCastException for parameter which is not

Re: JDK 9 RFR of JDK-8023897: Replace/update/rename executeAndCatch in various tests to assertThrows

I'm not sure I fully understand the points mentioned by Roger, Daniel and Paul. Nevertheless I will kindly disagree with all of them, just for the sake of having a constructive discussion :-) My understanding is that org.testng.Assert.assertThrows provides a rich message explaining what has

Re: JDK 9 RFR of JDK-8023897: Replace/update/rename executeAndCatch in various tests to assertThrows

Hi Amy, Thanks a lot for doing this! I personally think it's a beginning of a very valuable refactoring to our test base. It turns out this little piece of functionality, namely, checking that a particular exception is thrown from code is error-prone. I have seen many buggy implementations

RFR [9] 8179021: Latest bugfixes to WebSocket/HPACK from the sandbox repo

Hello, Please review the following change: http://cr.openjdk.java.net/~prappo/8179021/webrev.00/ Along with refactoring this change contains a number of critical fixes for WebSocket. Critical fixes are applied to Receiver and OpeningHandshake. Also this change removes 2 convenience methods

Re: RFR [9] 8177738: Runtime.Version must be a value-based class

> On 3 Apr 2017, at 20:39, Paul Sandoz wrote: > > Hi, > > 962 * [1-9][0-9]*((\.0)*\.[1-9][0-9]*)* > > You removed the initial “^” which is still mentioned in JDK-8148822 > > < `^[1-9][0-9]*(((\.0)*\.[1-9][0-9]*)*)*$`. The sequence may be of arbitrary > --- >>

RFR [9] 8177738: Runtime.Version must be a value-based class

Hello, Please review the following change: http://cr.openjdk.java.net/~prappo/8177738/webrev.00/ This is an attempt to resolve a group of issues related to Version-String API and its implementation: 8177738: Runtime.Version must be a value-based class 8148822: (spec) Regex in

A couple of questions on 8160954: (spec) Runtime.Version regex and $PRE/$OPT issues

[This is not an RFR] I’ve been investigating JDK-8160954 [1] which mentions two separate problems within the specification of the Runtime.Version class. The first is about boundary matchers (^ and $) in the regular expression that defines the version number ($VNUM):

Runtime.Version spec

I have a couple of questions on the spec wording. 1. * {@code $BUILD}, matching {@code * (0|[1-9][0-9]*)} --- The build number, incremented for each promoted * build. {@code $BUILD} is reset to {@code 1} when any portion of {@code * $VNUM} is incremented. If the build number

Re: RFR[9] 8160956: Runtime.Version.compareTo/compareToIgnoreOpt problem

Exactly: * * This is a value-based * class; use of identity-sensitive operations (including reference equality * ({@code ==}), identity hash code, or synchronization) on instances of * {@code Optional} may have unpredictable results and should be avoided. * > On 16 Mar 2017, at 20:41, Paul

RFR[9] 8176882: Incorrect integer comparison in version numbers

Hello, Please review the following trivial change for [1]: http://cr.openjdk.java.net/~prappo/8176882/webrev.00/ Thanks, -Pavel [1] https://bugs.openjdk.java.net/browse/JDK-8176882

RFR[9] 8160956: Runtime.Version.compareTo/compareToIgnoreOpt problem

Hello, Please review the following trivial change for [1]: http://cr.openjdk.java.net/~prappo/8160956/webrev.00/ The code change fixes the implementation and makes it adhere to the specification for Version comparison: /** * Compares this version to another. * ...

Re: SubmissionPublisher - Subscriber#onComplete() not invoked when publisher is closed

Only if you want an answer from the concurrency uber geeks :-) > On 21 Feb 2017, at 11:32, Pavel Bucek wrote: > > Thanks for the link to the other mailing list - do I understand it correctly > that I should move this thread there?

Re: SubmissionPublisher - Subscriber#onComplete() not invoked when publisher is closed

I believe, the most appropriate place for concurrency-related questions is http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest As for the question itself. I don't think this behaviour is a bug. SubmissionPublisher.close() seems to be a graceful way of shutting down (in contrast

Re: ByteBuffer to CharBuffer

Hi Jay, 1. I don't know if you've forgotten to attach the patch you mentioned or it has been stripped by the mail list. In any case, if it's not too big, please inline it in your next email. 2. A more appropriate place for this discussion would be another list: nio-dev at openjdk dot java

RFR 8170116: Remove qualified exports from java.base to java.corba

Hello, Could you please review the following change for [1]? http://cr.openjdk.java.net/~prappo/8170116/webrev.00/ Thanks, -Pavel [1] https://bugs.openjdk.java.net/browse/JDK-8170116

RFR 8164907: Eliminate dependency on java.naming/com.sun.jndi.toolkit.url

Hello, Could you please review the following change for [1]? For convenience I split the otherwise monolithic change into 4 separate webrevs. The first webrev addresses the first part of the task. Which is elimination of undesirable inter-modular dependencies. There were dependencies on 3

Re: Request/discussion: BufferedReader reading using async API while providing sync API

eadBuffer > That's the gaining part against the plain old Buffered classes. > > > Did that make sense to you? Feel free to ask anything else you need. > > On 25/10/2016 20:52, Pavel Rappo wrote: >> I've skimmed through the code and I'm not sure I can see any asynchronicity >&g

Re: Request/discussion: BufferedReader reading using async API while providing sync API

:59, Brunoais <brunoa...@gmail.com> wrote: > > Attached and sending! > > > On 24/10/2016 13:48, Pavel Rappo wrote: >> Could you please send a new email on this list with the source attached as a >> text file? >> >>> On 23 Oct 2016, at 19:14, Brunoais

Re: Request/discussion: BufferedReader reading using async API while providing sync API

wondering about the file size; it is both to avoid OS cache and > to make the reading at the main use-case these objects are for (large streams > of bytes). > > @Pavel, are you open for discussion now ;)? Need anything else? > > On 21/10/2016 19:21, Pavel Rappo wrote: >&

Re: Request/discussion: BufferedReader reading using async API while providing sync API

separate thread and the necessary synchronization. >> >> Though I think the formal interface semantics could be maintained, I have >> doubts >> about compatibility and its unintended consequences on existing subclasses, >> applications and libraries. >> >&

Re: Request/discussion: BufferedReader reading using async API while providing sync API

Off the top of my head, I would say it's not possible to change the design of an _extensible_ type that has been out there for 20 or so years. All these I/O streams from java.io were designed for simple synchronous use case. It's not that their design is flawed in some way, it's that they doesn't

Re: [concurrency-interest] We need to add blocking methods to CompletionStage!

On Wed, Sep 21, 2016 at 9:43 PM, Martin Buchholz wrote: > What is happening instead is API providers not using CompletionStage as > return values in public APIs because of the lack of convenient blocking, and > instead returning CompletableFuture, which is a tragic software

Re: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK

gt;> I'm not sure I like the replacement of Collections.emptyList() >> by List.of(); >> I find emptyList() more expressive (+ it always returns >> the same instance). >> >> best regards, >> >> -- daniel >> >> On 15/09/16 11:46, Pavel Rappo wrote: &g

Re: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK

Daniel, if you're referring to 388 List getValidOffsets() { 389 if (isGap()) { > 390 return List.of(); 391 } 392 return List.of(getOffsetBefore(), getOffsetAfter()); 393 } I think in this particular case, List.of is more consistent. > On 15

Re: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK

Hi, I have had a look at the change. It looks good. Retrofitting Collections.unmodifiableXXX/Arrays.asList with Convenience Factory Methods requires extra carefulness as the factory methods are stricter than any of those. Not only do they provide unconditional non-modifiability [0], they also do

Re: java.io.Writer uses CharSequence.toString()

Once again, while I agree in some places it could have been done a bit better probably, I would say it's good to a have a look at benchmarks first. If they show there's indeed a big difference between char[] copy = new chars[charSequence.length()]; String s = charSequence.toString();

Re: java.io.Writer uses CharSequence.toString()

> On 29 Jul 2016, at 09:23, Fabian Lange wrote: > > This is especially sad because after having mad the String, write() > will then copy out the chars of the string and then iterate over the > chars individually. As far as I can see no one iterates over chars

Re: RFR JDK-7031075: GZIPInputStream's available() reports 1, but read() gives -1.

rrectly". > > Thanks, > Sherman > > On 07/13/2016 02:55 AM, Pavel Rappo wrote: >>> On 13 Jul 2016, at 00:12, Xueming Shen<xueming.s...@oracle.com> wrote: >>> >>> (as I commented in the bug report) >> Sorry, I didn't see th

Re: RFR - 8141148: LDAP "follow" throws ClassCastException with Java 8

It looks like it was a defect in the original generification done in 7072353. Looks okay to me. Thanks. > On 12 Jul 2016, at 22:13, Rob McKenna wrote: > > Hi folks, > > Looking for a review for this change: > > https://bugs.openjdk.java.net/browse/JDK-8141148 >

Re: RFR JDK-7031075: GZIPInputStream's available() reports 1, but read() gives -1.

> On 13 Jul 2016, at 00:12, Xueming Shen wrote: > > (as I commented in the bug report) Sorry, I didn't see this. I should've been more careful. On other topics. 1. Original bug refers to GZIPInputStream's behaviour, not InflaterInputStream's. That said, I think

Re: RFR JDK-7031075: GZIPInputStream's available() reports 1, but read() gives -1.

> On 12 Jul 2016, at 23:38, Pavel Rappo <pavel.ra...@oracle.com> wrote: > > Hi Sherman, > > A quick question. Is "inf.finished()" the only condition that needs to be > checked in order to determine reachEOF? In read(), for instance, they use

<    1   2   3   4   5   >