Re: RFR: JDK-8266797: Fix for 8266610 breaks the build on macos

On Mon, 10 May 2021 08:46:15 GMT, Vyom Tewari wrote: >> Hi Vyom, >> >> That fixes the include file problem but as this was obviously not tested on >> non-Linux have you checked that the rest of the fix for 8266610 works okay >> on non-Linux? >> >> Thanks, >> David > >> Hi Vyom, >> >> That fi

Integrated: 8265961: Fix comments in logging.properties

On Mon, 26 Apr 2021 09:33:03 GMT, Pavel Rappo wrote: > I had been looking for an example of a "properties" file when spotted a typo > in `logging.properties`. I decided to proofread the file. That resulted in > finding a few other issues. This pull request has now been int

Re: RFR: 8265961: Fix comments in logging.properties [v2]

On Mon, 26 Apr 2021 15:48:18 GMT, Mark Reinhold wrote: >> Pavel Rappo has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Rollback "in" -> "with"; remove more trailing whitespace > >

Re: RFR: 8265961: Fix comments in logging.properties [v2]

> I had been looking for an example of a "properties" file when spotted a typo > in `logging.properties`. I decided to proofread the file. That resulted in > finding a few other issues. Pavel Rappo has updated the pull request incrementally with one additional commit sinc

Re: RFR: 8265961: Fix comments in logging.properties

On Mon, 26 Apr 2021 09:33:03 GMT, Pavel Rappo wrote: > I had been looking for an example of a "properties" file when spotted a typo > in `logging.properties`. I decided to proofread the file. That resulted in > finding a few other issues. Thanks, Daniel. Let's maybe wa

RFR: 8265961: Fix comments in logging.properties

I had been looking for an example of a "properties" file when spotted a typo in `logging.properties`. I decided to proofread the file. That resulted in finding a few other issues. - Commit messages: - Initial commit Changes: https://git.openjdk.java.net/jdk/pull/3688/files Webrev

Re: Enhancement proposal regarding bufferization of InputStream

> On 15 Apr 2021, at 08:33, Сергей Цыпанов wrote: > > Hello, > > buffering with j.i.BufferedInputStream is a handy way to improve performance > of IO operations. > However in many cases buffering is redundant. Consider this code snippet from > Spring Framework: > > static ClassReader getClas

Re: 8214761: Bug in parallel Kahan summation implementation

Hey Chris, I don't know exactly what triggers removal of the "oca" and "oca-verify" labels. The only OCA entry for Chris Dennis I could find [1] had a different GitHub username. Did you mistype it or it belongs to another person? Mind you, that person's GitHub page is 404. -Pavel [1] https://

Re: RFR: 8264029: Replace uses of StringBuffer with StringBuilder in java.base

On Tue, 23 Mar 2021 20:44:17 GMT, Andrey Turbanov wrote: >> src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 1954: >> >>> 1952: for (int i = 0; i < 4; ++i) { >>> 1953: if (i > 0) { >>> 1954: sb.append(" "); >> >> Cons

Re: RFR: 8264029: Replace uses of StringBuffer with StringBuilder in java.base

On Wed, 10 Mar 2021 19:47:00 GMT, Andrey Turbanov wrote: > Found by IntelliJ IDEA inspection `Java | Java language level migration aids > | Java 5 | 'StringBuffer' may be 'StringBuilder'` > As suggested in > https://github.com/openjdk/jdk/pull/1507#issuecomment-757369003 I've created > separa

Re: RFR: 8263358: Update java.lang to use instanceof pattern variable [v5]

On Mon, 15 Mar 2021 13:34:45 GMT, Rémi Forax wrote: >> I don't think that cast from `Object` to a raw type is unchecked, so as >> error does not seem warranted to me. >> >> However, I agree javac should produce the rawtype warning for rawtypes in >> pattern matching instanceof, because we are

Re: RFR: 8263358: Update java.lang to use instanceof pattern variable [v5]

On Mon, 15 Mar 2021 10:47:10 GMT, Rémi Forax wrote: > I think it's a bug in javac, it should not even raise a warning but an error. > But the spec is not fully clear. If you think that it's a bug, consider providing feedback to authors of JEP 394: > Other refinements may be incorporated based

Re: RFR: 8263358: Update java.lang to use instanceof pattern variable [v5]

On Mon, 15 Mar 2021 09:32:33 GMT, Rémi Forax wrote: >> Patrick Concannon has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8263358: Refactored missed equals method > > src/java.base/share/classes/java/lang/constant/DynamicConstantDesc.jav

Re: RFR: 8247373: ArraysSupport.newLength doc, test, and exception message [v5]

On Tue, 2 Mar 2021 06:29:07 GMT, Stuart Marks wrote: >> This rewrites the doc of ArraysSupport.newLength, adds detail to the >> exception message, and adds a test. In addition to some renaming and a bit >> of refactoring of the actual code, I also made two changes of substance to >> the code:

Re: Monitoring wrapped ThreadPoolExecutor returned from Executors

Questions related to the contents of java.util.concurrent.** should generally be asked on the "Concurrency-interest" mailing list: http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest -Pavel > On 6 Jan 2021, at 03:11, Tommy Ludwig wrote: > > Hello, > > In the Micrometer project,

Re: RFR: 8193031: Collections.addAll is likely to perform worse than Collection.addAll

On Mon, 21 Dec 2020 14:26:45 GMT, Сергей Цыпанов wrote: >> This message is purely informational: I may have found a JBS comment that >> provides historical context for that "this method is likely to run >> significantly faster under most implementations" phrase. Here: >> https://bugs.openjdk.

Re: RFR: 8193031: Collections.addAll is likely to perform worse than Collection.addAll

On Sat, 19 Dec 2020 09:09:50 GMT, Guoxiong Li wrote: >> Apart from the @SuppressWarnings, this looks good to me. >> And i like the irony of this. > > Hi all, > > According to the document of > [SafeVarargs](https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/SafeVarargs.html

Re: Optimization potential in Reader#read(CharBuffer)

I found this relevant issue created 17 years ago: https://bugs.openjdk.java.net/browse/JDK-4926314 > On 10 Dec 2020, at 20:23, Brian Burkhalter > wrote: > > Hi Philippe, > >> On Dec 10, 2020, at 12:03 PM, Philippe Marschall >> wrote: >> >> I recently came across Reader#read(CharBuffer) and

Re: RFR: 8247402: Documentation for Map::compute contains confusing implementation requirements [v2]

On Sat, 28 Nov 2020 08:35:20 GMT, John Lin wrote: >> This is from the mailing list: >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-June/067190.html >> >> - >> ### Progress >> - [x] Change must not contain extraneous whitespace >> - [x] Commit message must refer to an issu

Re: RFR: 8247402: Documentation for Map::compute contains confusing implementation requirements

On Wed, 25 Nov 2020 20:22:21 GMT, Daniel Fuchs wrote: >> @pavelrappo >> >>> What is the required level of fidelity particular (pseudo-) code has to >>> have? >> >> It's potentially a large discussion, one that could be had in the context of >> my JEP draft http://openjdk.java.net/jeps/806856

Re: RFR: 8234131: Miscellaneous changes imported from jsr166 CVS 2020-12 [v3]

On Tue, 8 Dec 2020 21:15:48 GMT, Martin Buchholz wrote: >> 8234131: Miscellaneous changes imported from jsr166 CVS 2020-12 > > Martin Buchholz has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains one commit: > > JDK-8234131 The chang

Re: RFR: 8234131: Miscellaneous changes imported from jsr166 CVS 2020-12 [v2]

On Tue, 8 Dec 2020 08:53:38 GMT, Alan Bateman wrote: >> Martin Buchholz has refreshed the contents of this pull request, and >> previous commits have been removed. The incremental views will show >> differences compared to the previous content of the PR. > > src/java.base/share/classes/java/uti

Re: RFR: 8247402: Documentation for Map::compute contains confusing implementation requirements

On Sat, 28 Nov 2020 08:42:52 GMT, John Lin wrote: >> @johnlinp In any case, you'd also need to update the surrounding prose; we >> need to remove this: >> returning the current value or {@code null} if absent:``` > > @pavelrappo Please see my updated CSR below. Thanks. > > # Map::compute shou

Re: RFR: 8247402: Documentation for Map::compute contains confusing implementation requirements

On Mon, 30 Nov 2020 15:08:51 GMT, Pavel Rappo wrote: >> @johnlinp, thanks for updating the CSR draft; it is much better now. >> >> @stuart-marks, I think we could further improve this snippet. This `if` >> statement seems to use an optimization: >> >> if

Re: RFR: 8247402: Documentation for Map::compute contains confusing implementation requirements

On Mon, 30 Nov 2020 13:52:17 GMT, Pavel Rappo wrote: >> @pavelrappo Please see my updated CSR below. Thanks. >> >> # Map::compute should have the implementation requirement match its default >> implementation >> >> ## Summary >> >> The imp

Re: RFR: 8247402: Documentation for Map::compute contains confusing implementation requirements

On Sat, 28 Nov 2020 08:42:52 GMT, John Lin wrote: >> @johnlinp In any case, you'd also need to update the surrounding prose; we >> need to remove this: >> returning the current value or {@code null} if absent:``` > > @pavelrappo Please see my updated CSR below. Thanks. > > # Map::compute shou

Re: RFR: 8247402: Documentation for Map::compute contains confusing implementation requirements

On Sat, 21 Nov 2020 09:21:06 GMT, John Lin wrote: >> @johnlinp, you cannot create a CSR by yourself at the moment. Someone else >> will have to do that for you. Might as well be me. So here's my proposal: >> come up with the meat, then I'll help you with the paperwork. >> >> For starters, ha

Re: RFR: 8247402: Documentation for Map::compute contains confusing implementation requirements

On Wed, 25 Nov 2020 06:19:04 GMT, Stuart Marks wrote: >>> The proposed CSR has a few problems that we need to resolve. >>> >>> 1. The **Specification** pseudo-code behaves differently from both the old >>> pseudo-code and the actual implementation when `newValue == null && >>> oldValue == null

Re: RFR: 8247402: Documentation for Map::compute contains confusing implementation requirements

On Mon, 23 Nov 2020 14:35:37 GMT, Pavel Rappo wrote: > The proposed CSR has a few problems that we need to resolve. > > 1. The **Specification** pseudo-code behaves differently from both the old > pseudo-code and the actual implementation when `newValue == null && oldV

Re: RFR: 8247402: Documentation for Map::compute contains confusing implementation requirements

On Sat, 21 Nov 2020 09:21:06 GMT, John Lin wrote: >> @johnlinp, you cannot create a CSR by yourself at the moment. Someone else >> will have to do that for you. Might as well be me. So here's my proposal: >> come up with the meat, then I'll help you with the paperwork. >> >> For starters, ha

Re: RFR: 8247402: Documentation for Map::compute contains confusing implementation requirements

On Wed, 21 Oct 2020 00:11:42 GMT, John Lin wrote: >> Hi Jon, >> >> Can you explain what this change is about: e.g. something like: >> >>> Updates the documentation of `Map::compute` to match its default >>> implementation: >>> The documentation of the default implementation of `Map::compute`

Integrated: 8255989: Remove explicitly unascribed authorship from Java source files

On Fri, 6 Nov 2020 20:11:24 GMT, Pavel Rappo wrote: > This PR proposes to remove > 1. JavaDoc `@author` tags with unclear semantics: `@author > unascribed|unattributed|unknown` > 2. A couple of astray Form Feed (a.k.a. FF, `\f`, `0xC`, or `^L`) characters This pull request

Re: RFR: 8255989: Remove explicitly unascribed authorship from Java source files [v2]

On Sat, 7 Nov 2020 09:05:29 GMT, Sergey Bylokhov wrote: >> Pavel Rappo has updated the pull request with a new target base due to a >> merge or a rebase. The incremental webrev excludes the unrelated changes >> brought in by the merge/rebase. The pull request conta

Re: RFR: 8255989: Remove explicitly unascribed authorship from Java source files [v2]

> This PR proposes to remove > 1. JavaDoc `@author` tags with unclear semantics: `@author > unascribed|unattributed|unknown` > 2. A couple of astray Form Feed (a.k.a. FF, `\f`, `0xC`, or `^L`) characters Pavel Rappo has updated the pull request with a new target base due to a merge

RFR: 8255989: Remove explicitly unascribed authorship from Java source files

This PR proposes to remove 1. JavaDoc `@author` tags with unclear semantics: `@author unascribed|unattributed|unknown` 2. A couple of astray Form Feed (a.k.a. FF, `\f`, `0xC`, or `^L`) characters - Commit messages: - Initial commit Changes: https://git.openjdk.java.net/jdk/pull/11

Integrated: 8253342: Fix typos in String.transform

On Fri, 18 Sep 2020 08:27:44 GMT, Pavel Rappo wrote: > To confirm that this would not require a CSR I asked Joe Darcy. Joe replied > that this would NOT require a CSR. This pull request has now been integrated. Changeset: 83b2411f Author: Pavel Rappo URL:

Re: RFR: 8253342: Fix typos in String.transform

On Fri, 18 Sep 2020 08:46:45 GMT, Aleksey Shipilev wrote: >> To confirm that this would not require a CSR I asked Joe Darcy. Joe replied >> that this would NOT require a CSR. > > src/java.base/share/classes/java/lang/String.java line 3186: > >> 3184: * caller. >> 3185: * >> 3186:

RFR: 8253342: Fix typos in String.transform

To confirm that this would not require a CSR I asked Joe Darcy. Joe replied that this would NOT require a CSR. - Commit messages: - Initial commit Changes: https://git.openjdk.java.net/jdk/pull/238/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=238&range=00 Issue: h

Re: [BUG] Java 15: DecimalFormatSymbols overrides equals but not hashCode

> On 15 Sep 2020, at 21:50, Rob Spoor wrote: > > On 15/09/2020 22:02, Pavel Rappo wrote: >>> On 15 Sep 2020, at 20:50, Brian Burkhalter >>> wrote: >>> >>>> On Sep 15, 2020, at 12:38 PM, Kevin Rushforth >>&

Re: [BUG] Java 15: DecimalFormatSymbols overrides equals but not hashCode

> On 15 Sep 2020, at 20:50, Brian Burkhalter > wrote: > >> On Sep 15, 2020, at 12:38 PM, Kevin Rushforth >> wrote: >> >> I see this in DecimalFormatSymbols: >> >> >> /** >> * Override hashCode. >> */ > private volatile int hashCode; >> @Override >> public int has

Re: RFR 8252537: Replace @exception with @throws for core-libs

> On 4 Sep 2020, at 21:32, Vipin Sharma wrote: > > > I have generated Javadoc for all updated packages and compared html files, > before and after changes. Since effects can be nonlocal (e.g. {@inheritDoc}), you should always compare everything. >> There are ~ 1.5K lines, 86 files changed in

Re: RFR 8252537: Replace @exception with @throws for core-libs

Oops, wrong issue number. Here's the correct one: JDK-8157682. > On 4 Sep 2020, at 09:52, Pavel Rappo wrote: > > It would be nice to compare documentation HTML files generated before and > after that patch: there's a possibility of non-local consequences, see >

Re: RFR 8252537: Replace @exception with @throws for core-libs

It would be nice to compare documentation HTML files generated before and after that patch: there's a possibility of non-local consequences, see JDK-6509045. -Pavel > On 3 Sep 2020, at 20:33, Vipin Sharma wrote: > > Hi, > > Please review and sponsor the fix for replacing @exception with @thro

Re: RFR 8252538: Replace @exception with @throws java.rmi package

> On 3 Sep 2020, at 18:51, Vipin Sharma wrote: > > I agree. In the next patch, I will include all remaining occurrences of > @exception in the core-libs > area. > > Also, I noticed that those files still use the markup. >> Converting them to use {@c

Re: RFR of JDK-8245620: Improve Annotation.annotationType() documentation

Looks good. > On 11 Jun 2020, at 18:11, Joe Darcy wrote: > > Hi Pavel, > > On 6/11/2020 2:54 AM, Pavel Rappo wrote: >> Joe, >> >> There is a typo: >> >> *appropriate overloading of {@lin

Re: RFR of JDK-8245620: Improve Annotation.annotationType() documentation

Joe, There is a typo: *appropriate overloading of {@link java.util.Arrays#equals Arrays.hashCode}. ^ ~~~^ Since we are in this area, is it possible to rephrase (or at least re-punctuate) the doc comment for java.lang.annotatio

Re: RFR [15] 8247212: Use assistant markup in java.lang.module.ModuleDescriptor

Thanks, Alan. Here's the updated webrev: http://cr.openjdk.java.net/~prappo/8247212/webrev.01/ > On 9 Jun 2020, at 13:33, Alan Bateman wrote: > > On 09/06/2020 13:15, Pavel Rappo wrote: >> Hello, >> >> Please review the change for https://bugs.ope

Re: RFR [15] 8247115: Fix typos in java.lang.invoke and java.lang

t;> On Jun 9, 2020, at 6:42 AM, Pavel Rappo wrote: >> >> Hello, >> >> Please review the change for https://bugs.openjdk.java.net/browse/JDK-8247115 >> >> http://cr.openjdk.java.net/~prappo/8247115/webrev.00/ >> >> The patch fixes 11 typos in

RFR [15] 8247212: Use assistant markup in java.lang.module.ModuleDescriptor

Hello, Please review the change for https://bugs.openjdk.java.net/browse/JDK-8247212 http://cr.openjdk.java.net/~prappo/8247212/webrev.00/ The patch adds markup that makes it easier to read documentation in cases where code and prose are mixed. The patch also fixes a few typos. -Pavel

RFR [15] 8247115: Fix typos in java.lang.invoke and java.lang

Hello, Please review the change for https://bugs.openjdk.java.net/browse/JDK-8247115 http://cr.openjdk.java.net/~prappo/8247115/webrev.00/ The patch fixes 11 typos in doc comments and 2 typos in code. The typos in code are in exception messages. Testing results are pending. -Pavel

Re: RFR[8243655]: 'Map.replace javadoc code snippet typo'

Extra points would be to substitute the resulting snippet for the actual implementation to see if it compiles and satisfies the tests. For example, like this: default boolean replace(K key, V oldValue, V newValue) { Map map = this; // synthetic line if (map.containsKey(key) && Objects.

Re: [PATCH] Typo in java.util.regex.Pattern

I'm holding a copy in my hands right now. I can see "ISBN: 978-0-596-52812-6" written on the back of the book. Searching that number in the database yields the following record: Mastering Regular Expressions ISBN-13: 9780596528126 ISBN-10: 0596528124 Author: Friedl, Jeffrey E. F.

Re: [PATCH] Typo in java.util.regex.Pattern

Looks good. I can see that Lance has offered to sponsor that for you. (I was writing this message when I saw his reply.) I researched history a bit. That happened as one might guess quite trivially in November 2006: 2c2 < * @(#)Pattern.java 1.124 06/11/09 --- > * @(#)Pattern.java 1.125

Re: RFR(xs): 8242281: IntStream.html#reduce doc should not mention average

Daniel, have you considered that comment from Paul Sandoz to that CSR? > IMHO removing the @see is not necessary in this respect, it's useful to point > to related reduction methods. https://bugs.openjdk.java.net/browse/JDK-8245970?focusedCommentId=14341561&page=com.atlassian.jira.plugin.system.

Re: RFR[8245658]: 'Arrays.java has two occurrences of bad unicode constants in Javadoc.'

There were two issues with this sequence in the resulting HTML pages. The first one, which you mentioned and fixed, was a missing zero. The second one, which you fixed but didn't mention, was an extra slash symbol. Looks good to me. P.S. There seem to be more cases where authors assumed the con

Re: RFR [15] 8245111: Update doc comments for improved processing by the Standard Doclet

n improvement. > But its a slippery slope beyond what you originally observed and wanted to > fix. > > Thanks, Roger > > > On 5/15/20 11:59 AM, Pavel Rappo wrote: >>> On 15 May 2020, at 16:53, Roger Riggs wrote: >>> >>> Hi Pavel, >>> >

Re: RFR [15] 8245111: Update doc comments for improved processing by the Standard Doclet

me is obsolete, the extension mechanism is no longer supported." > > $.02, Roger > > > On 5/15/20 10:00 AM, Daniel Fuchs wrote: >> Hi Pavel, >> >> This looks good to me - but English is not my native language ;-) >> >> cheers, >> >&g

RFR [15] 8245111: Update doc comments for improved processing by the Standard Doclet

Hello, Please review this trivial change for https://bugs.openjdk.java.net/browse/JDK-8245111: http://cr.openjdk.java.net/~prappo/8245111/webrev.00/ In addition to fixing the main issue, this includes a blanket change from "followed with" to "followed by" as the latter seemed idiomatic to me

Re: RFR 15: 8243010: Test support: Customizable Hex Printer

> On 17 Apr 2020, at 15:11, Roger Riggs wrote: > > Hi Pavel, > > On 4/17/20 8:27 AM, Pavel Rappo wrote: >> Hi Roger, >> >> First of all, many thanks for doing this. After skimming through that webrev >> I have two comments. >> >> 1. It mig

Re: RFR 15: 8243010: Test support: Customizable Hex Printer

Hi Roger, First of all, many thanks for doing this. After skimming through that webrev I have two comments. 1. It might make sense to beef this up with more retrofitted tests, so people could more clearly see how applicable this API is. If you'd like I could help you with looking for those acr

Re: Need sponsor to fix Javadoc warnings

those changes, you may want to ask ICU4J [^1] folk to incorporate them. If they agree, one day those changes may show up in the OpenJDK. -- [^1]: https://github.com/unicode-org/icu/tree/master/icu4j > On 15 Apr 2020, at 12:06, Pavel Rappo wrote: > > Vipin, > > I saw that

Re: Need sponsor to fix Javadoc warnings

Here's the cumulative webrev: http://cr.openjdk.java.net/~prappo/8242366/webrev.01/ -Pavel > On 11 Apr 2020, at 20:23, Vipin Sharma wrote: > > Hi Pavel, > >> On Apr 9, 2020, at 2:45 AM, Pavel Rappo wrote: >> >> If your new patch addresses a similar ty

Re: JDK 15 RFR of JDK-8225540: In core reflection note whether returned annotations are declaration or type annotations

> http://cr.openjdk.java.net/~darcy/8225540.1/ I'm not an expert in this area, but AFAIK this looks good. A couple of nits. 1. The newly added text in the top-level doc comment for AnnotatedElement is missing some tags. It looks nice in source, but it won't be like that in the output. (For be

Re: Need sponsor to fix Javadoc warnings

If your new patch addresses a similar type of problem, please send it in reply to this email, so that I could merge it with the existing patch. Let's try to minimize process overhead if possible. > On 8 Apr 2020, at 17:35, Vipin Sharma wrote: > > > >> On Apr 8, 2020,

Re: Need sponsor to fix Javadoc warnings

Why assume something that sophisticated where it can be adequately explained by a simpler thing? :) I bet it was an IDE inspection. -Pavel > On 8 Apr 2020, at 14:14, Alan Bateman wrote: > > On 08/04/2020 14:07, Daniel Fuchs wrote: >> Hi Pavel, >> >> On 08/04/2020 13:56, David Holmes wrote: >>>

Re: Need sponsor to fix Javadoc warnings

prone that can be, I still wouldn't do it in this changeset. -Pavel > On 8 Apr 2020, at 13:56, David Holmes wrote: > > Hi Pavel, > > Not a review ... > > On 8/04/2020 9:50 pm, Pavel Rappo wrote: >> Vipin, here you go: >> https://bugs.open

Re: Need sponsor to fix Javadoc warnings

t. -Pavel > On 7 Apr 2020, at 19:50, Vipin Sharma wrote: > > Hi Pavel, > >> On Apr 7, 2020, at 11:11 PM, Pavel Rappo wrote: >> >> I assume you have signed the OCA [1]. If not and you want to continue, >> please do it. If you've already done so, whi

Re: RFR [15] 8242230: Whitespace typos, relaxed javadoc, formatting

sted we'll never have to think about that ever again. > On 7 Apr 2020, at 20:23, Joe Darcy wrote: > > Hi Pavel, > > Looks fine in general, assuming the change to Class.java renders correctly in > output. > > Thanks, > > -Joe > > On 4/7/2020 8:28 AM, Pavel

Re: Need sponsor to fix Javadoc warnings

I assume you have signed the OCA [1]. If not and you want to continue, please do it. If you've already done so, which is probably the case [2], please attach your patch as text to this thread with the next email. Do not use zip or the like. I will take it from there and sponsor that for you. -P

Re: RFR [15] 8242230: Whitespace typos, relaxed javadoc, formatting

--- [1] https://en.wikipedia.org/wiki/Line_wrap_and_word_wrap [2] https://docs.oracle.com/en/java/javase/14/docs/specs/javadoc/doc-comment-spec.html > With kind regards, > > Ivan > > [1] > https://docs.oracle.com/en/java/javase/14/docs/api/java.base/

RFR [15] 8242230: Whitespace typos, relaxed javadoc, formatting

Hello, Please review the change for https://bugs.openjdk.java.net/browse/JDK-8242230: http://cr.openjdk.java.net/~prappo/8242230/webrev.00/ This is a documentation cleanup. There are no code changes involved, and the changes in documentation are mostly trivial. The following packages are affe

Re: [15] RFR 8241727 : Typos: empty lines in javadoc, inconsistent indents, etc. (core-libs only)

140 a successful * query to a constant will always remain successful. Made me pause and read a bit of the surrounding context to make sure there's no "*" type of query. Looks good to me. Thanks for doing this. -Pavel > On 27 Mar 2020, at 10:26, Ivan Gerasimov wrote: > > Hello! > > This

Re: RFR [15] 8241014: Miscellaneous typos in documentation comments

>> >> The former is easier just delete the ’s’. >> >> Other bits look good. >> >> Paul. >> >>> On Mar 13, 2020, at 7:03 PM, Ivan Gerasimov >>> wrote: >>> >>> Hi Pavel! >>> >>> Can this please be combi

Re: RFR [15] 8241014: Miscellaneous typos in documentation comments

java.net/~igerasim/XXX-typos/00/webrev/ > > Just to save cycles on reviewing :) > > With kind regards, > > Ivan > > > On 3/13/20 8:42 AM, Pavel Rappo wrote: >> Hello, >> >> Please review the change for >> https://bugs.openjdk.java.net/brow

Re: RFR: [small, docs] JDK-8240971 Fix CSS styles in some doc comments

This is really nice. Incidentally, it also makes https://bugs.openjdk.java.net/browse/JDK-8234395 less relevant. -Pavel > On 12 Mar 2020, at 20:50, Jonathan Gibbons > wrote: > > Please review a simple fix regarding the non-standard use of some CSS in some > doc comments. > > From the JBS

RFR [15] 8241014: Miscellaneous typos in documentation comments

Hello, Please review the change for https://bugs.openjdk.java.net/browse/JDK-8241014: http://cr.openjdk.java.net/~prappo/8241014/webrev.00/ This is a documentation cleanup. There are no code changes involved, and the changes in documentation are mostly trivial. The following packages are affe

Re: JDK 15 RFR of JDK-8237805: Use inline @jls @jvms in core libs where appropriate

@Joe, I noticed you changed "section" to the § entity in one place. In other places it is still in prose, i.e. "section" and "sections". I think whatever we choose we should try to use it consistently. I built the API docs and checked that everything renders as expected. (Links are 404, obviously,

Re: [14] 8215361 (doc) Cleanup package-info markup - smartcardio, java.sql, java.sql.rowset

Yes, I can see those too. That suggests that the change was not performed automatically. Which makes sense, since sometimes nested tags need to be "turned inside out", e.g. ... -> {@code ...}. {@code     java.net.URL url = rowset.getURL(1);} Will it be rendered as intended? Otherwise looks

Re: 8237186: Fix typo in copyright header of java/io/Reader/TransferTo.java

:%s/in /source /g (or similar) I guess. > On 15 Jan 2020, at 02:03, Mandy Chung wrote: > > Looks okay. I wonder how the word "source" got creeped in :-) > > Mandy > > On 1/14/20 5:51 PM, Brian Burkhalter wrote: >> Oops: correction. >> >> --- a/test/jdk/java/io/Reader/TransferTo.java >> +++

Re: Note bulk methods in Javadocs for Collections.synchronizedXxx()

t; > On Sat, 28 Dec 2019, 18:23 Pavel Rappo, wrote: > If we were to add something like that to the documentation, it would probably > go > under @apiNote (section "pitfalls", hehe). > > As you said, the spec says just enough to infer that. So, strictly speaking, >

Re: Note bulk methods in Javadocs for Collections.synchronizedXxx()

If we were to add something like that to the documentation, it would probably go under @apiNote (section "pitfalls", hehe). As you said, the spec says just enough to infer that. So, strictly speaking, there's no need to add that note. After all, there are infinite ways to use these, synchronized,

Re: RFR: 8235730: Incorrect javadoc in MatchKind

Looks good to me. Trivially, update the copyright years before pushing. This is one of those changes that decrease the entropy, but have little visible effects on the outside world. Neither MatchOps nor MatchOps.MatchKind type should be visible in the online API docs. P.S. I'm not a Reviewer.

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

gt; Pavel, > > Deal. Handling early returns too: > http://cr.openjdk.java.net/~mmimica/8228580/webrev.05/ > I will ask there about socket timeout semantics. > > On Tue, 24 Sep 2019 at 12:51, Pavel Rappo wrote: >> >> Milan, >> >> Thanks for looking

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

much different. > > If the above is correct, should I just add a tolerance for the lower bound? > > [1] http://man7.org/linux/man-pages/man2/poll.2.html > [2] > https://docs.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-select > [3] > https://docs.oracle.com

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

https://bugs.openjdk.java.net/browse/JDK-8230965 > On 23 Sep 2019, at 14:20, Milan Mimica wrote: > > Got it. Thanks Pavel! > > > On Mon, 23 Sep 2019 at 13:37, Pavel Rappo wrote: >> >> Milan, >> >> How do you check which tests

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

vel, > > Here it is: http://cr.openjdk.java.net/~mmimica/8228580/webrev.04/ > I don't see the test is run twice when I execute "make test > TEST=jtreg:test/jdk/com/sun/jndi/dns/ConfigTests/TcpTimeout.java". Am > I missing something? > > On Thu, 19 Sep 2019 at 13

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

oblems to users. I think, at least, we should have a way > to tell the user that the response is truncated, and the payload is > partial/invalid. > > > On Tue, 17 Sep 2019 at 15:09, Pavel Rappo wrote: >> >> Milan, >> >> While the CSR is being processed, could

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

ng if you could propose some way of testing that. > On 17 Sep 2019, at 09:55, Pavel Rappo wrote: > > I have filed the CSR: > >https://bugs.openjdk.java.net/browse/JDK-8230965 > >> On 13 Sep 2019, at 11:21, Pavel Rappo wrote: >> >> Here's the latest we

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

I have filed the CSR: https://bugs.openjdk.java.net/browse/JDK-8230965 > On 13 Sep 2019, at 11:21, Pavel Rappo wrote: > > Here's the latest webrev accumulating all the changes we've discussed so far: > >http://cr.openjdk.java.net/~prappo/8228580/webrev.03/ >

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

Here's the latest webrev accumulating all the changes we've discussed so far: http://cr.openjdk.java.net/~prappo/8228580/webrev.03/ If people are okay with that I will proceed to creating a CSR. > On 12 Sep 2019, at 20:06, Alan Bateman wrote: > > On 12/09/2019 12:41, Chris Hegarty wrote: >

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

Martin, May I add you to the list of people who reviewed this change? I mean the concurrency-related portion of the change, specifically in the test. Not the LDAP part. > On 12 Sep 2019, at 16:21, Martin Buchholz wrote: > > > > On Thu, Sep 12, 2019 at 4:36 AM Pavel Rappo

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

this property has not been set, the > + * default number of retries is 4. > + * > * @provides javax.naming.spi.InitialContextFactory > + * > * @moduleGraph > * @since 9 > */ > > -Chris. > > [1] https://docs.oracle.com/javase/6/docs/technotes/guides/jndi/jndi-d

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

> On 12 Sep 2019, at 03:54, Martin Buchholz wrote: > > We're mostly in agreement. Good to hear and I agree! > On Wed, Sep 11, 2019 at 11:02 AM Pavel Rappo <mailto:pavel.ra...@oracle.com>> wrote: > > > a. is not using any synchronization aid to make sure

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

Martin, > On 10 Sep 2019, at 17:40, Martin Buchholz wrote: > > Here's a canonical example of an "expected timeout" test that seems natural > and readable to me. > timeoutMillis() returns 12ms, adjusted by timeout factor. Ldap might need a > bigger value. > > > /** > * timed await t

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

> On 11 Sep 2019, at 16:55, Alan Bateman wrote: > > I don't think the jndi-dns docs page is in the jdk repo. Could you kindly point me to the location of the current jndi-dns docs page? I can't seem to be able to even find anything related to that on the web. You might want to try to use your

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

> On 11 Sep 2019, at 16:10, Alan Bateman wrote: > > I assume extending the timeout to TCP will require at least some minimal > updates to the descriptions. Which descriptions do you have in mind? I cannot seem to find that text anywhere in the current repo (jdk/jdk) $ hg tip changeset:

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

ies is 4." I cannot seem to find a newer version of that document though. > On 11 Sep 2019, at 14:58, Alan Bateman wrote: > > On 11/09/2019 13:26, Pavel Rappo wrote: >> I'm happy with the overall changeset. I have (once again) made some tiny >> changes, you can se

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

, I'm not really happy with how we used the DNSTestBase/TestBase infrastructure, however I'm totally fine with the retrying logic. Test results are pending. -Pavel > On 10 Sep 2019, at 16:33, Milan Mimica wrote: > >>> On 5 Sep 2019, at 16:02, Pavel Rappo wrote: >&g

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

modates for a given timeout once, not many times. Yes, I agree I can't stop a thread suspension at line 387 or anywhere else for that matter, but I shouldn't account for it either. Maybe just once -- in the value of the timeout. Again, many thanks for looking at it! Thoughts? &

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

Milan, ping? > On 5 Sep 2019, at 16:02, Pavel Rappo wrote: > > 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 cou

<    1   2   3   4   5   >