Re: On Period and DateTimeFormatter

Period is like Duration - they are both "lengths of time", just using different units (so they are both a TemporalAmount). Similar to how LocalDateTime vs. Instant are both "points in time", just using different units (so they are both a Temporal). But you bring up a good point - perhaps Calendar

Re: Best Practice for Busy Waiting in Java

Just MHO... This is kind of like asking "What's the best way to waste electricity?" It's a nebulous question until you specify what "best" means in this odd scenario -Archie On Sun, Jun 15, 2025 at 11:09 AM Markus KARG wrote: > Recently I was asked by a programmer, what to do if there sim

Re: RFR: 8357531: The `SegmentBulkOperations::fill` method can be improved using overlaps [v5]

.wikipedia.org/wiki/Automatic_vectorization > [2] https://youtu.be/rXv2-lN5Xgk?t=1518 > -- > *From:* core-libs-dev on behalf of > Archie Cobbs > *Sent:* Thursday, May 22, 2025 10:58 PM > *To:* John R Rose > *Cc:* core-libs-dev@openjdk.org > *Subject:* Re: RFR: 8357531: The `

Re: RFR: 8357531: The `SegmentBulkOperations::fill` method can be improved using overlaps [v5]

On Thu, May 22, 2025 at 3:31 PM John R Rose wrote: > > Update benchmark to reflect new fill method > > Related discussion at the hardware level: > > https://github.com/openjdk/jdk/pull/25147#issuecomment-2902463076 > This discussion spurred me to ask a dumb question. Apologies in advance, just

Re: Towards a JSON API for the JDK

On Wed, May 21, 2025 at 11:30 AM Paul Sandoz wrote: > I consider this a “known unknown” (in the words of Mr. Rumsfeld). We would > need to explore this area throughly, which includes the interconnection > with Serialization 2.0, before we really know what we can and should do in > the near and lo

Re: RFR: 8356995: Provide default methods min(T, T) and max(T, T) in Comparator interface

On Mon, 19 May 2025 07:25:17 GMT, Tagir F. Valeev wrote: > I'm not sure whether we should specify exactly the behavior in case if the > comparator returns 0. I feel that it could be a useful invariant that > `Comparator.min(a, b)` and `Comparator.max(a, b)` always return different > argument,

Withdrawn: 8356993: ArrayDeque should use Arrays.fill() instead of for() loops

On Wed, 14 May 2025 19:37:37 GMT, Archie Cobbs wrote: > Please review this small performance tweak `ArrayDeque`. > > `ArrayDeque` has an invariant in which any unused elements in the array must > be null. In a couple of places, the code is setting contiguous ranges of > element

Re: RFR: 8356993: ArrayDeque should use Arrays.fill() instead of for() loops [v3]

On Thu, 15 May 2025 21:04:40 GMT, Archie Cobbs wrote: >> Please review this small performance tweak `ArrayDeque`. >> >> `ArrayDeque` has an invariant in which any unused elements in the array must >> be null. In a couple of places, the code is setting contiguous ranges

Re: RFR: 8356993: ArrayDeque should use Arrays.fill() instead of for() loops [v2]

On Thu, 15 May 2025 18:33:22 GMT, Raffaello Giulietti wrote: > Here are many > [exmaples](https://github.com/openjdk/jmh/tree/master/jmh-samples/src/main/java/org/openjdk/jmh/samples) > on how to correctly use JMH. > > A > [blackhole](https://github.com/openjdk/jmh/blob/master/jmh-samples/sr

Re: RFR: 8356993: ArrayDeque should use Arrays.fill() instead of for() loops [v3]

ied and sped up > by using `Arrays.fill()` instead. Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: Blackhole ArrayDeque to ensure it's not ignored by the compiler. - Changes: - all: https://git.openjdk.o

Re: RFR: 8356993: ArrayDeque should use Arrays.fill() instead of for() loops [v2]

On Thu, 15 May 2025 19:53:03 GMT, ExE Boss wrote: > Note that `Arrays.fill(…)` is simply a `for(…)` loop with an additional range > check Interesting... I was assuming that most of the "bulk" methods in `Arrays` were being hand-optimized with special hardware magic (e.g., vector instructions),

Re: RFR: 8356993: ArrayDeque should use Arrays.fill() instead of for() loops [v2]

On Thu, 15 May 2025 17:50:30 GMT, Rémi Forax wrote: > I think you need to return the collection or send it to a BlackHole I'm fairly new to the benchmark game so I would not be surprised if this is broken. Previously I was adding them to a list but that caused OOMs. Can you clarify what you m

Re: RFR: 8356993: ArrayDeque should use Arrays.fill() instead of for() loops

On Wed, 14 May 2025 19:37:37 GMT, Archie Cobbs wrote: > Please review this small performance tweak `ArrayDeque`. > > `ArrayDeque` has an invariant in which any unused elements in the array must > be null. In a couple of places, the code is setting contiguous ranges of > element

Re: RFR: 8356993: ArrayDeque should use Arrays.fill() instead of for() loops [v2]

ied and sped up > by using `Arrays.fill()` instead. Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: Add benchmark for ArrayDeque.clear(). - Changes: - all: https://git.openjdk.org/jdk/pull/25237/files - new: https

Re: RFR: 8356993: ArrayDeque should use Arrays.fill() instead of for() loops

On Thu, 15 May 2025 06:07:06 GMT, Alan Bateman wrote: > Are you planning to add some JMH benchmarks to go with this? I wasn't planning to, but I'm inferring from your question that you'd prefer to see one. Which also makes me curious. I'd be shocked if this were slower, but even if not, I won

Re: JDK-8352891 Performance improvements to ByteArrayOutputStream

On Thu, May 15, 2025 at 2:02 AM Peter Levart wrote: > On 4/11/25 6:19 PM, Archie Cobbs wrote: > > Sorry if that wasn't clear - I didn't mean power-of-two exponential > > growth, I meant all segments were literally fixed size, like 256 or > > something (or maybe

RFR: 8356993: ArrayDeque should use Arrays.fill() instead of for() loops

Please review this small performance tweak `ArrayDeque`. `ArrayDeque` has an invariant in which any unused elements in the array must be null. In a couple of places, the code is setting contiguous ranges of elements to null using `for()` loops. This can be both simplified and sped up by using `

Withdrawn: 8143850: Add indexed get() and set() methods to ArrayDeque

On Mon, 12 May 2025 18:24:27 GMT, Archie Cobbs wrote: > Because it is backed by an array, the `ArrayDeque` class has the ability to > get and replace any element in the list (accessed by index) in constant time. > However, this capability is not exposed in the API. > > Please

Re: RFR: 8143850: Add indexed get() and set() methods to ArrayDeque

On Mon, 12 May 2025 18:24:27 GMT, Archie Cobbs wrote: > Because it is backed by an array, the `ArrayDeque` class has the ability to > get and replace any element in the list (accessed by index) in constant time. > However, this capability is not exposed in the API. > > Please

Re: Proposal: Add new methods get(int) and set(int, E) to ArrayDeque

On Mon, May 12, 2025 at 12:00 PM Archie Cobbs wrote: > I would like to offer to do the following: > >- Change the title of this bug from "retrofit ArrayDeque to implement >List" to "Add indexed get() and set() methods to ArrayDeque" > > >-

Re: RFR: 8143850: Add indexed get() and set() methods to ArrayDeque

On Tue, 13 May 2025 08:58:28 GMT, ExE Boss wrote: >> Because it is backed by an array, the `ArrayDeque` class has the ability to >> get and replace any element in the list (accessed by index) in constant >> time. However, this capability is not exposed in the API. >> >> Please review this PR w

RFR: 8143850: Add indexed get() and set() methods to ArrayDeque

Because it is backed by an array, the `ArrayDeque` class has the ability to get and replace any element in the list (accessed by index) in constant time. However, this capability is not exposed in the API. Please review this PR which adds the following two new methods to `ArrayDeque`: * `public

Proposal: Add new methods get(int) and set(int, E) to ArrayDeque

I was wondering for the n'th time why ArrayDeque does not have get(int) and set(int, E) methods and eventually came across JDK-8143850 which was created 10 years ago... This comment exactly describes my own experience: People write code, they need an

Re: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v12]

On Sat, 10 May 2025 20:28:39 GMT, Vicente Romero wrote: >> This PR is defining a new internal annotation, >> `@jdk.internal.RequiresIdentity`, with target types PARAMETER and >> TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation >> that an argument to a given method or

Re: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v11]

On Sat, 10 May 2025 19:32:16 GMT, Chen Liang wrote: >> Vicente Romero has updated the pull request incrementally with two >> additional commits since the last revision: >> >> - additional changes from Archie >> - removing dead code > > src/jdk.compiler/share/classes/com/sun/tools/javac/code/L

Re: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v9]

On Sat, 10 May 2025 15:31:17 GMT, Chen Liang wrote: > Thanks. Looks good, but the Lint to all option names streaming can be > replaced by the static map lookup/iteration. Good point... I prototyped that in commit be160a3261b. - PR Comment: https://git.openjdk.org/jdk/pull/24746#is

Re: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v9]

On Sat, 10 May 2025 15:35:16 GMT, Vicente Romero wrote: > heh, I was doing the same, thanks anyway :) Awesome, thanks! Apologies for the mid-air collision :) I've merged your latest merge into my merge, leaving just a few minor fixes. - PR Comment: https://git.openjdk.org/jdk/pul

Re: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v6]

On Fri, 9 May 2025 22:39:19 GMT, Chen Liang wrote: > Sure, I think vicente is open to patches and PRs to his fork. And I can help > review; just remember to @liach. OK thanks. I've rebased my changes on @vicente-romero-oracle's branch to simply any evaluation. [Here's the diff](https://github

Re: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v6]

On Fri, 9 May 2025 21:09:46 GMT, Chen Liang wrote: > I think if we do that, we should encapsulate `option` and move all access, > such as `option.isSet`, to dedicated methods on `LintCategory`. We are a bit > short on time for this, so IMO our best approach is to open a followup issue > that w

Re: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v6]

On Fri, 9 May 2025 20:25:40 GMT, Vicente Romero wrote: > I was working on something in this line too, just pushed the patch Looks reasonable, a couple of comments... Can't `LintCategory.alias` be `final`? If so I think this obviates the patch to `DetectMutableStaticFields.java`. This is not a

Re: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v6]

On Thu, 8 May 2025 18:55:34 GMT, Vicente Romero wrote: >> Vicente Romero has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 26 commits: >> >> - Merge branch 'master' into JDK-8354556 >> - addressing review comment >> - changes to

Re: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v7]

On Fri, 9 May 2025 14:35:38 GMT, Vicente Romero wrote: >> This PR is defining a new internal annotation, >> `@jdk.internal.RequiresIdentity`, with target types PARAMETER and >> TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation >> that an argument to a given method or c

Re: RFR: 8354724: BufferedReader readAllLines and readString methods [v14]

On Fri, May 2, 2025 at 2:04 PM Stuart Marks wrote: > There was a back-and-forth a while ago -- I think @bplb was involved -- > where there was similar wording about something being "equivalent to" or > "as if" foo() was called, and the person was insistent that this meant that > foo() should actu

Re: JavaDoc fix in java.util.Date

On Wed, Apr 30, 2025 at 3:38 PM Steffen Nießing wrote: > However, the docs should match the expression used in the implementation > when explicitly naming the returned expression. Should we update both to > Long.hashCode(this.getTime())? > I think that's a little too strong of a statement. Rathe

Re: Runtime.exec and SIGPIPE + SIG_IGN

On Tue, Apr 29, 2025 at 9:55 AM Thomas Stüfe wrote: > 1) In a scenario like the one I described we start java, it installs the > SIGPIPE handler, which then gets preplaced by the third-party lib with > SIG_IGN, resulting in child processes running with SIG_IGN for SIGPIPE. > 2) If, however,r the

Re: Runtime.exec and SIGPIPE + SIG_IGN

This reminds me of a bug I saw once decades ago: the JVM was not setting the close-on-exec flag on new file descriptors, so child processes were receiving copies of "leaked" file descriptors and keeping them open indefinitely, causing the system to eventually running out of file descriptors and cra

Re: JDK-8352891 Performance improvements to ByteArrayOutputStream

On Fri, Apr 11, 2025 at 10:50 AM Engebretson, John wrote: > I would like to see JDK standard "array builders" for primitive types and > reference types that use fixed sized (power-of-two) segments internally. > > > > I want to caution on the power-of-two idea – it leads to large objects > faster

Re: JDK-8352891 Performance improvements to ByteArrayOutputStream

d (power-of-two) segments internally. These can be internal classes for now. Then the faster ByteArrayOutputStream becomes just a wrapper around "ByteArrayBuilder" or whatever we call it. This is all just my opinion, I'm curious if others perceive the same gap that I do? -Archie On

Re: JDK-8352891 Performance improvements to ByteArrayOutputStream

On Fri, Apr 11, 2025 at 8:11 AM Engebretson, John wrote: > It seems like a good general-purpose list but I wouldn’t recommend it as a > direct replacement for either ArrayList or LinkedList; in the former case > the risk is slower random accesses, and in the latter the risk is to head > modificat

Re: JDK-8352891 Performance improvements to ByteArrayOutputStream

At the risk of repeating my previous comment , I agree with Chen. That is to say, there is a separate, more fundamental unsolved problem lurking underneath this discussion, and the two problem "layers" are perhaps better addr

Re: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v40]

On Thu, 3 Apr 2025 14:00:00 GMT, Per Minborg wrote: >> Implement JEP 502. >> >> The PR passes tier1-tier3 tests. > > Per Minborg has updated the pull request incrementally with one additional > commit since the last revision: > > Make the sqrt example different src/java.base/share/classes/j

Re: RFR: 8066583: DeflaterInput/OutputStream and InflaterInput/OutputStream should explain responsibility for freeing resources [v6]

On Tue, 1 Apr 2025 17:10:08 GMT, Alan Bateman wrote: >> My opinion is that: if it is possible for another implementation to share >> the backing in/deflator (such as via thread-local instances) that does not >> always need to be closed when an in/output stream is closed, then we should >> not

Re: JDK-8352891 Performance improvements to ByteArrayOutputStream

lternative. > Just a quick thought, I haven’t looked at any proposed code. > > Scott > > On Mar 28, 2025, at 6:09 PM, Archie Cobbs wrote: > >  > This is just a drive-by, opinion-saturated comment, so feel free to > ignore... > > I think the missing puzzle piece here is

Re: JDK-8352891 Performance improvements to ByteArrayOutputStream

This is just a drive-by, opinion-saturated comment, so feel free to ignore... I think the missing puzzle piece here is slightly different/more general than "OutputStream into memory". IMHO what's really missing from the standard toolbox provided by the JDK is the byte equivalent of StringBuilder+S

Integrated: 8351897: Extra closing curly brace typos in Javadoc

On Thu, 13 Mar 2025 01:21:54 GMT, Archie Cobbs wrote: > This PR fixes minor Javadoc typos in a few `java.base` classes. Extra curly > braces have been sneaking in. This pull request has now been integrated. Changeset: fe03e2ec Author:Archie Cobbs URL: https://git.openjdk.o

Re: RFR: 8351897: Extra closing curly brace typos in Javadoc [v3]

> This PR fixes minor Javadoc typos in a few `java.base` classes. Extra curly > braces have been sneaking in. Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: Revert accidental file change. - Changes: - all:

Re: RFR: 8351897: Extra closing curly brace typos in Javadoc [v3]

On Mon, 24 Mar 2025 13:56:21 GMT, Chen Liang wrote: >> Archie Cobbs has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Revert accidental file change. > > Looks good, these locations in the JDK 24 docs indeed

Re: RFR: 8351897: Extra closing curly brace typos in Javadoc [v2]

On Mon, 24 Mar 2025 05:23:58 GMT, Chen Liang wrote: > Shouldn't this closing `)` be wrapped in `{@code}` like `{@code )}` to match > with the code format in `{@code (getLocale()}`? Yes it should - thanks. The two rows above also have the same problem, i.e., I was just making this row consisten

Re: RFR: 8351897: Extra closing curly brace typos in Javadoc [v2]

> This PR fixes minor Javadoc typos in a few `java.base` classes. Extra curly > braces have been sneaking in. Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: Apply font fixes per review suggestion. - Changes:

Re: RFR: 8351897: Extra closing curly brace typos in Javadoc

On Thu, 13 Mar 2025 01:46:53 GMT, Iris Clark wrote: > Where's the matching `(`? I'm guessing that the IDE thinks it's the one > immediately before the `getLocale()`, but I suspect that javadoc won't agree > with that. You are correct - the matching `(` is the one preceding `getLocale()`. I'm

RFR: 8351897: Extra closing curly brace typos in Javadoc

This PR fixes minor Javadoc typos in a few `java.base` classes. Extra curly braces have been sneaking in. - Commit messages: - Fix minor Javadoc typos. Changes: https://git.openjdk.org/jdk/pull/24022/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24022&range=00 Issue: h

Integrated: 8343478: Remove unnecessary @SuppressWarnings annotations (core-libs)

On Sat, 2 Nov 2024 15:40:30 GMT, Archie Cobbs wrote: > Please review this patch which removes unnecessary `@SuppressWarnings` > annotations. This pull request has now been integrated. Changeset: 661bd5bf Author:Archie Cobbs URL: https://git.openjdk.org/jdk/

Re: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations (core-libs) [v12]

On Sat, 15 Feb 2025 21:27:56 GMT, Archie Cobbs wrote: >> Please review this patch which removes unnecessary `@SuppressWarnings` >> annotations. > > Archie Cobbs has updated the pull request with a new target base due to a > merge or a rebase. The pull request no

RFR: 8261669: Add lint warning for widening primitive conversions that lose information

This PR is a prototype to stimulate discussion of [JDK-8261669](https://bugs.openjdk.org/browse/JDK-8261669), which seeks to add more warnings when an implicit cast of a primitive value might lose information. This can possibly happen when converting an `int` to `float`, or when converting a `l

Re: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations (core-libs) [v12]

> Please review this patch which removes unnecessary `@SuppressWarnings` > annotations. Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: - Merge branch 'master' into SuppressWarningsCleanup-

Re: RFR: 8315585: Optimization for decimal to string [v4]

On Tue, Feb 4, 2025 at 5:26 PM Shaojin Wen wrote: > I think you are talking about the problem of PR #23420, which is caused by > the use of thread-unsafe StringBuilder in multi-threaded scenarios. This > problem is very obscure and I didn't consider it before. I have started to > solve this probl

Re: RFR: 8315585: Optimization for decimal to string [v4]

On Tue, Feb 4, 2025 at 2:40 PM Joe Darcy wrote: > Can we please have a pause on the sequence of "make XYZ toString faster" > PRs until there is some wider discussion of goals, etc.? Thanks. > I agree with this sentiment... It was surprising to see how easily a VM crash can sneak in. There is al

Re: RFR: 4452735: Add GZIPOutputStream constructor to specify Deflater [v3]

On Fri, 24 Jan 2025 20:57:15 GMT, Eirik Bjørsnøs wrote: > A tangential concern when allowing a custom deflater / inflater is to > document the resposibility for resource management. I've added a Javadoc blurb to that effect in 3807de16b70. Something similar (once the verbiage is agreed upon) s

Re: RFR: 4452735: Add GZIPOutputStream constructor to specify Deflater [v4]

accepts a custom > `Deflater`, and also adds a basic unit test for it and all of the other > `GZIPOutputStream` constructors, based on the existing test > `BasicGZIPInputStreamTest.java` which does the same thing for > `GZIPInputStream`. Archie Cobbs has updated the pull req

Re: Factory methods for SequencedSet and SequencedMap

On Fri, Jan 17, 2025 at 7:50 PM David Alayachew wrote: > I guess my next question is, there is no bridge method, which is why this > fails. Why not add a bridge method? What is stopping Java from doing this? > In Java class files it's possible to have two methods that differ only in their return

Re: Factory methods for SequencedSet and SequencedMap

On Fri, Jan 17, 2025 at 9:22 AM Ethan McCue wrote: > Just so there are some strawman arguments against: > To pile on... If I go to a restaurant and order a hamburger and they bring me a cheeseburger and also charge me extra for it, I'm going to complain! A Set and a SequencedSet are two differ

Re: RFR: 4452735: Add GZIPOutputStream constructor to specify Deflater

On Fri, 19 Jul 2024 15:16:01 GMT, Lance Andersen wrote: >>> I understand the request here, but is there a current use case for needing >>> a custom Deflater? >> >> I think the primary use case is when you want to set a non-default >> compression level, e.g., "best" or "fast". This is a pretty

Re: RFR: 8347334: JimageDiffGenerator code clean-ups [v2]

On Mon, 13 Jan 2025 10:47:41 GMT, Severin Gehwolf wrote: >> (Getting into marginal returns on comments here, so my apologies for >> nitpicking) >> >> The loop could be simplified even further... >> >> while (true) { >> int bytesRead1 = is1.readNBytes(buf1, 0, buf1.length); >> int bytes

Re: RFR: 8347334: JimageDiffGenerator code clean-ups [v2]

On Thu, 9 Jan 2025 18:25:16 GMT, Severin Gehwolf wrote: >> During code review of >> [JDK-8346239](https://bugs.openjdk.org/browse/JDK-8346239) a few comments >> were made after the PR integrated. This follow-up patch cleans this up and >> adds a unit test for the `JimageDiffGenerator` class. >

Re: RFR: 8347334: JimageDiffGenerator code clean-ups

On Thu, 9 Jan 2025 17:32:39 GMT, Severin Gehwolf wrote: > During code review of > [JDK-8346239](https://bugs.openjdk.org/browse/JDK-8346239) a few comments > were made after the PR integrated. This follow-up patch cleans this up and > adds a unit test for the `JimageDiffGenerator` class. > >

Re: RFR: 8346239: Improve memory efficiency of JimageDiffGenerator

On Thu, 19 Dec 2024 18:14:39 GMT, Severin Gehwolf wrote: > Please review this fairly simple change to improve how the > `JimageDiffGenerator` works. The original implementation is pretty naive and > read all bytes into memory and then compared them. This improved version only > reads bytes on

Re: RFR: 8346239: Improve memory efficiency of JimageDiffGenerator

On Thu, 19 Dec 2024 18:14:39 GMT, Severin Gehwolf wrote: > Please review this fairly simple change to improve how the > `JimageDiffGenerator` works. The original implementation is pretty naive and > read all bytes into memory and then compared them. This improved version only > reads bytes on

Re: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations (core-libs) [v8]

On Mon, 9 Dec 2024 22:18:30 GMT, Joe Darcy wrote: >> Archie Cobbs has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 15 commits: >> >> - Remove more unnecessary suppressions. >> - Merge branch 'm

Re: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations (core-libs) [v10]

On Thu, 2 Jan 2025 19:56:16 GMT, Archie Cobbs wrote: >> Please review this patch which removes unnecessary `@SuppressWarnings` >> annotations. > > Archie Cobbs has updated the pull request incrementally with one additional > commit since the last revision: > >

Re: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations (core-libs) [v11]

> Please review this patch which removes unnecessary `@SuppressWarnings` > annotations. Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: Update @LastModified tags. - Changes: - all: https://git.openjdk.org/jd

Re: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations (core-libs) [v10]

> Please review this patch which removes unnecessary `@SuppressWarnings` > annotations. Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: Revert changes under src/java.desktop (to be moved into a separate PR). - C

Re: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations (core-libs) [v9]

On Thu, 2 Jan 2025 19:16:41 GMT, Naoto Sato wrote: > Looks like some files in java.desktop package are also modified. Just > wondering they may not be seen by client folks as the title mentions > core-libs. Yeah my attempt to split this up was not perfect. I did have a separate, earlier PR (#

Re: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations (core-libs) [v9]

> Please review this patch which removes unnecessary `@SuppressWarnings` > annotations. Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: - Bump copyright year to 2025. - Merge branch 'm

Re: RFR: 4452735: Add GZIPOutputStream constructor to specify Deflater [v3]

accepts a custom > `Deflater`, and also adds a basic unit test for it and all of the other > `GZIPOutputStream` constructors, based on the existing test > `BasicGZIPInputStreamTest.java` which does the same thing for > `GZIPInputStream`. Archie Cobbs has updated the pull req

Re: RFR: 8345668: ZoneOffset.ofTotalSeconds performance regression [v3]

On Thu, 26 Dec 2024 17:25:55 GMT, Andrey Turbanov wrote: > For sure we should use result of `putIfAbsent` Drive-by comment... >From what i can infer, the performance regression being addressed here is >caused in part by the fact that (for example) >`ConcurrentHashMap.computeIfAbsent()` provid

Re: Proposal: jar option to disable compression for selected file extensions

On Mon, Dec 16, 2024 at 5:39 AM Eirik Bjørsnøs wrote: > I propose that we add a new option, tentatively named "--no-compress-ext", > which would take a colon-separated list of file extensions to disable ZIP > compression for: > > jar --create --file archive.jar --no-compress-ext=.jpg:.png:.gz -C

Re: Copyright update tedium

Hi Thomas, On Tue, Dec 10, 2024 at 4:45 AM Thomas Stüfe wrote: > Note that we have a script for that; see > make/scripts/update_copyright_year.sh . I use it a lot. Sonia recently > enhanced it. It even has an option to update copyrights for foreign > companies. > Awesome - thanks for the pointe

Re: Copyright update tedium

further discussion to have Skara actually get into > the business of whether the copyright header should be updated and what the > copyright year(s) should be. I personally think Skara shouldn't do that, > but it is a topic that might be worth discussing for a future Enhancement. > &g

Re: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations (core-libs) [v8]

> Please review this patch which removes unnecessary `@SuppressWarnings` > annotations. Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: - Remove more unnecessary suppressions. - Merge branch 'm

Re: Copyright update tedium

Bleh, ignore my comment. I didn't realize the PR#1702 you referenced is already proposing doing this! -Archie On Mon, Dec 9, 2024 at 10:45 AM Archie Cobbs wrote: > Thanks for working on this... something of a thankless task :) > > I'm sure you've considered this but I

Re: Copyright update tedium

re starting to slowly get there, see > https://github.com/openjdk/skara/pull/1702 for a first step. > > /Magnus > On 2024-12-03 16:45, Archie Cobbs wrote: > > Dumb question... > > It seems like the thing with updating copyright years in source files > could be better automated

Copyright update tedium

Dumb question... It seems like the thing with updating copyright years in source files could be better automated. At least, couldn't there be a test that fails if you forget? FWIW my little updater script says that these files still need to be updated to 2024: .github/actions/config/action.yml .

Re: Deprecate Double.MIN_VALUE?

Having been bitten by this bug myself, I would vote yes on this one. For symmetry's sake, I would think there should be four new constants - for {MIN,MAX}_{POSITIVE,NEGATIVE}_VALUE - and that both of {MIN,MAX}_VALUE should be deprecated. -Archie On Mon, Dec 2, 2024 at 5:18 PM Éamonn McManus wro

Re: RFR: 4452735: Add GZIPOutputStream constructor to specify Deflater

On Wed, 17 Jul 2024 21:07:23 GMT, Archie Cobbs wrote: > The class `GZIPOutputStream` extends `DeflaterOutputStream`, which is logical > because the GZIP encoding is based on ZLIB "deflate" encoding. > > However, while `DeflaterOutputStream` provides constructors that take

Re: RFR: 4452735: Add GZIPOutputStream constructor to specify Deflater [v2]

accepts a custom > `Deflater`, and also adds a basic unit test for it and all of the other > `GZIPOutputStream` constructors, based on the existing test > `BasicGZIPInputStreamTest.java` which does the same thing for > `GZIPInputStream`. Archie Cobbs has updated the pull req

Re: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations (core-libs) [v7]

> Please review this patch which removes unnecessary `@SuppressWarnings` > annotations. Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: - Remove more unnecessary @SuppressWarnings annotations. -

Re: RFR: 8343125: Correct the documentation for TreeMap's getFloorEntry and getCeilingEntry [v3]

On Thu, 14 Nov 2024 03:23:29 GMT, Naman Nigam wrote: >> As the documentation of getCeilingEntry currently reads, the inference is >> misleading as follows: >> >> if no such entry exists, returns the entry for the least key greater than >> the specified key; >> if no such entry exists (i.e., th

Re: RFR: 8343490: Update copyright year for JDK-8341692

On Wed, Nov 13, 2024 at 10:39 PM Phil Race wrote: > On Tue, 5 Nov 2024 01:41:00 GMT, SendaoYan wrote: > > The copyright year of some files which has been changed by > [JDK-8341692](https://bugs.openjdk.org/browse/JDK-8341692) wasn't update > correctly. This PR update the copyright year of [JDK-8

Re: RFR: 8343125: Correct the documentation for TreeMap's getFloorEntry and getCeilingEntry [v2]

On Thu, 14 Nov 2024 03:19:01 GMT, Naman Nigam wrote: >> src/java.base/share/classes/java/util/TreeMap.java line 424: >> >>> 422: /** >>> 423: * Returns the entry for the least key greater than or equal to >>> the specified key; >>> 424: * if no such entry exists (i.e. the specifie

Re: RFR: 8343125: Correct the documentation for TreeMap's getFloorEntry and getCeilingEntry [v2]

On Thu, 14 Nov 2024 02:29:27 GMT, Naman Nigam wrote: >> As the documentation of getCeilingEntry currently reads, the inference is >> misleading as follows: >> >> if no such entry exists, returns the entry for the least key greater than >> the specified key; >> if no such entry exists (i.e., th

Re: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations (core-libs) [v6]

> Please review this patch which removes unnecessary `@SuppressWarnings` > annotations. Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: Remove more unnecessary warning suppressions. - Changes: - all:

Re: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations (core-libs) [v5]

> Please review this patch which removes unnecessary `@SuppressWarnings` > annotations. Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: - Merge branch 'master' into SuppressWarningsCleanup-

Re: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations (core-libs) [v4]

> Please review this patch which removes unnecessary `@SuppressWarnings` > annotations. Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: Put back @SuppressWarnings annotations to be fixed by JDK-8343286. - C

Re: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations (core-libs) [v3]

> Please review this patch which removes unnecessary `@SuppressWarnings` > annotations. Archie Cobbs 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 co

Re: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations (core-libs) [v2]

> Please review this patch which removes unnecessary `@SuppressWarnings` > annotations. Archie Cobbs 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 co

RFR: 8343478: Remove unnecessary @SuppressWarnings annotations (core-libs)

Please review this patch which removes unnecessary `@SuppressWarnings` annotations. - Commit messages: - Remove unnecessary @SuppressWarnings annotations. Changes: https://git.openjdk.org/jdk/pull/21852/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21852&range=00 Issue

Re: RFR: 8233451: (fs) Files.newInputStream() cannot be used with character special files

On Tue, 15 Oct 2024 15:13:06 GMT, Alan Bateman wrote: > FileChannel implements SeekableByteChannel. You'll see exactly the same thing > if you use FileChannel.open to open a special file. Ah... thanks. Also (for example) `FileInputStream.getChannel()` returns a `FileChannel`, so we're stuck wi

Re: RFR: 8233451: (fs) Files.newInputStream() cannot be used with character special files

On Mon, 14 Oct 2024 23:30:06 GMT, Brian Burkhalter wrote: > Add `isOther` and `available` methods to `FileChannelImpl` and the interfaces > to native code and use these in `ChannelInputStream` to work around cases > where a wrapped `FileChannelImpl` is not really seekable. Albeit with my very

Re: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v12]

On Fri, 4 Oct 2024 17:03:38 GMT, fabioromano1 wrote: >> src/java.base/share/classes/java/math/BigDecimal.java line 5238: >> >>> 5236: BigInteger pow = FIVE_TO_2_TO[FIVE_TO_2_TO_LEN - 1]; >>> 5237: for (int i = FIVE_TO_2_TO_LEN; i <= n; i++) >>> 5238: FIVE_

Re: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v12]

On Thu, 3 Oct 2024 17:11:09 GMT, fabioromano1 wrote: >> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses >> repeated squares trick. > > fabioromano1 has updated the pull request incrementally with one additional > commit since the last revision: > > Code simplification

  1   2   3   >