core-libs-dev  

Messages by Thread

• Re: RFR: 8266431: Dual-Pivot Quicksort improvements (Radix sort) [v4] Vladimir Yaroslavskiy
• Re: RFR: 8360046: Scalability issue when submitting virtual threads with almost empty tasks [v23] Doug Lea
• Re: RFR: 8366478: BigDecimal roots [v29] fabioromano1
• RFR: 8179918: EnumSet spliterator should report SORTED, ORDERED, NONNULL Patrick Strawderman
  • Re: RFR: 8179918: EnumSet spliterator should report SORTED, ORDERED, NONNULL [v2] Patrick Strawderman
• Question about method references David Alayachew
  • Re: Question about method references David Alayachew
• Re: RFR: 8366478: BigDecimal roots [v28] fabioromano1
• RFR: 8372615: Many container tests fail when running rootless on cgroup v1 Casper Norrbin
• Re: RFR: 8361207: Build native Windows ARM64 MSI packages Chayan
• RFR: 8372710: Update ProcessBuilder/Basic regex Harshit470250
  • Re: RFR: 8372710: Update ProcessBuilder/Basic regex Harshit470250
  • Re: RFR: 8372710: Update ProcessBuilder/Basic regex Aleksey Shipilev
• RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting Chen Liang
  • Re: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting Chen Liang
  • Re: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting Jorn Vernee
  • Re: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting Alan Bateman
  • Re: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting Chen Liang
  • Re: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting Alan Bateman
  • Re: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting Jaikiran Pai
  • Re: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting Jaikiran Pai
  • Re: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting Chen Liang
  • Re: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting Chen Liang
  • Re: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting Alan Bateman
  • Re: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting Per Minborg
  • Re: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting Alan Bateman
  • Re: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting Jaikiran Pai
  • Re: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting Chen Liang
  • Re: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting Jaikiran Pai
  • Re: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v2] Chen Liang
  • Re: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v2] Alan Bateman
  • Re: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v2] Alan Bateman
  • Re: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v2] Chen Liang
  • Re: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v2] Alan Bateman
  • Re: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v2] Chen Liang
  • Re: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v2] Chen Liang
• Re: RFR: 8328821: Map.of() derived view collection mutators should throw UnsupportedOperationException [v15] Liam Miller-Cushon
• RFR: 8371815: API docs for 2-arg StructuredTaskScope.open should say timeout may expire before or while waiting in join Alan Bateman
  • Re: RFR: 8371815: API docs for 2-arg StructuredTaskScope.open should say timeout may expire before or while waiting in join Viktor Klang
  • Integrated: 8371815: API docs for 2-arg StructuredTaskScope.open should say timeout may expire before or while waiting in join Alan Bateman
• Re: RFR: 8328821: Map.of() derived view collection mutators should throw UnsupportedOperationException [v14] Liam Miller-Cushon
  • Re: RFR: 8328821: Map.of() derived view collection mutators should throw UnsupportedOperationException [v14] Liam Miller-Cushon
• RFR: 8372136: VectorAPI: Refactor subword gather load API java implementation Xiaohong Gong
  • Re: RFR: 8372136: VectorAPI: Refactor subword gather load API java implementation Xiaohong Gong
  • Re: RFR: 8372136: VectorAPI: Refactor subword gather load API java implementation Xiaohong Gong
• RFR: 8372385: tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/cli/MainTest.java fails Alexey Semenyuk
  • Re: RFR: 8372385: tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/cli/MainTest.java fails Alexey Semenyuk
  • Re: RFR: 8372385: tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/cli/MainTest.java fails Alexander Matveev
  • Integrated: 8372385: tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/cli/MainTest.java fails Alexey Semenyuk
• RFR: 8321283: Reuse StringLatin1::equals in regionMatches Francesco Nigro
  • Re: RFR: 8321283: Reuse StringLatin1::equals in regionMatches Francesco Nigro
  • Re: RFR: 8321283: Reuse StringLatin1::equals in regionMatches Chen Liang
  • Re: RFR: 8321283: Reuse StringLatin1::equals in regionMatches Claes Redestad
  • Re: RFR: 8321283: Reuse StringLatin1::equals in regionMatches Francesco Nigro
  • Re: RFR: 8321283: Reuse StringLatin1::equals in regionMatches Chen Liang
  • Re: RFR: 8321283: Reuse StringLatin1::equals in regionMatches Francesco Nigro
  • Re: RFR: 8321283: Reuse StringLatin1::equals in regionMatches David Schlosnagle
  • Re: RFR: 8321283: Reuse StringLatin1::equals in regionMatches Francesco Nigro
  • Re: RFR: 8321283: Reuse StringLatin1::equals in regionMatches David Schlosnagle
  • Re: RFR: 8321283: Reuse StringLatin1::equals in regionMatches Claes Redestad
  • Re: RFR: 8321283: Reuse StringLatin1::equals in regionMatches Francesco Nigro
  • Re: RFR: 8321283: Reuse StringLatin1::equals in regionMatches Claes Redestad
  • Re: RFR: 8321283: Reuse StringLatin1::equals in regionMatches Claes Redestad
  • Re: RFR: 8321283: Reuse StringLatin1::equals in regionMatches Francesco Nigro
  • Re: RFR: 8321283: Reuse StringLatin1::equals in regionMatches Francesco Nigro
  • Re: RFR: 8321283: Reuse StringLatin1::equals in regionMatches Roger Riggs
  • Re: RFR: 8321283: Reuse StringLatin1::equals in regionMatches Alan Bateman
• RFR: 8372609: Bug4944439 does not enforce locale correctly Justin Lu
  • Re: RFR: 8372609: Bug4944439 does not enforce locale correctly Chen Liang
  • Re: RFR: 8372609: Bug4944439 does not enforce locale correctly Jaikiran Pai
• Re: RFR: 8360046: Scalability issue when submitting virtual threads with almost empty tasks [v22] Doug Lea
  • Re: RFR: 8360046: Scalability issue when submitting virtual threads with almost empty tasks [v22] Viktor Klang
  • Re: RFR: 8360046: Scalability issue when submitting virtual threads with almost empty tasks [v22] Doug Lea
• Integrated: 8366224: Introduce DecimalDigits.appendPair for efficient two-digit formatting and refactor DateTimeHelper Shaojin Wen
• Re: RFR: 8360046: Scalability issue when submitting virtual threads with almost empty tasks [v21] Doug Lea
• Re: RFR: 8366478: BigDecimal roots [v27] fabioromano1
  • Re: RFR: 8366478: BigDecimal roots [v27] Raffaello Giulietti
• Re: RFR: 8366478: BigDecimal roots [v26] fabioromano1
• RFR: 8372460: Use EnumMap instead of HashMap for DateTimeFormatter parsing to improve performance Shaojin Wen
  • Re: RFR: 8372460: Use EnumMap instead of HashMap for DateTimeFormatter parsing to improve performance Shaojin Wen
  • Re: RFR: 8372460: Use EnumMap instead of HashMap for DateTimeFormatter parsing to improve performance Chen Liang
  • Re: RFR: 8372460: Use EnumMap instead of HashMap for DateTimeFormatter parsing to improve performance Shaojin Wen
  • Re: RFR: 8372460: Use EnumMap instead of HashMap for DateTimeFormatter parsing to improve performance [v2] Shaojin Wen
  • Re: RFR: 8372460: Use EnumMap instead of HashMap for DateTimeFormatter parsing to improve performance [v2] Chen Liang
• Use EnumMap instead of HashMap for DateTimeFormatter parsing to improve performance wenshao
  • Re: Use EnumMap instead of HashMap for DateTimeFormatter parsing to improve performance Chen Liang
• RFR: 8351095: [macos] Add more jpackage tests for --mac-app-store option Alexander Matveev
  • Re: RFR: 8351095: [macos] Add more jpackage tests for --mac-app-store option Alexey Semenyuk
  • Re: RFR: 8351095: [macos] Add more jpackage tests for --mac-app-store option Alexey Semenyuk
  • Re: RFR: 8351095: [macos] Add more jpackage tests for --mac-app-store option Alexey Semenyuk
  • Re: RFR: 8351095: [macos] Add more jpackage tests for --mac-app-store option Alexey Semenyuk
  • Re: RFR: 8351095: [macos] Add more jpackage tests for --mac-app-store option Alexey Semenyuk
  • Re: RFR: 8351095: [macos] Add more jpackage tests for --mac-app-store option Alexander Matveev
  • Re: RFR: 8351095: [macos] Add more jpackage tests for --mac-app-store option Alexey Semenyuk
  • Re: RFR: 8351095: [macos] Add more jpackage tests for --mac-app-store option Alexey Semenyuk
  • Re: RFR: 8351095: [macos] Add more jpackage tests for --mac-app-store option Alexander Matveev
  • Re: RFR: 8351095: [macos] Add more jpackage tests for --mac-app-store option [v2] Alexander Matveev
  • Re: RFR: 8351095: [macos] Add more jpackage tests for --mac-app-store option [v2] Alexey Semenyuk
  • Re: RFR: 8351095: [macos] Add more jpackage tests for --mac-app-store option [v2] Alexander Matveev
  • Re: RFR: 8351095: [macos] Add more jpackage tests for --mac-app-store option [v3] Alexander Matveev
  • Re: RFR: 8351095: [macos] Add more jpackage tests for --mac-app-store option [v3] Alexey Semenyuk
  • Re: RFR: 8351095: [macos] Add more jpackage tests for --mac-app-store option [v3] Alexander Matveev
  • Re: RFR: 8351095: [macos] Add more jpackage tests for --mac-app-store option [v3] Alexey Semenyuk
  • Re: RFR: 8351095: [macos] Add more jpackage tests for --mac-app-store option [v3] Alexander Matveev
  • Re: RFR: 8351095: [macos] Add more jpackage tests for --mac-app-store option [v3] Alexander Matveev
  • Re: RFR: 8351095: [macos] Add more jpackage tests for --mac-app-store option [v3] Alexander Matveev
  • Re: RFR: 8351095: [macos] Add more jpackage tests for --mac-app-store option [v4] Alexander Matveev
  • Re: RFR: 8351095: [macos] Add more jpackage tests for --mac-app-store option [v4] Alexey Semenyuk
  • Integrated: 8351095: [macos] Add more jpackage tests for --mac-app-store option Alexander Matveev
• RFR: 8372134: ThreadLocalRandom no longer overrides nextGaussian James Yuzawa
  • Re: RFR: 8372134: ThreadLocalRandom no longer overrides nextGaussian Viktor Klang
  • Re: RFR: 8372134: ThreadLocalRandom no longer overrides nextGaussian Raffaello Giulietti
  • Re: RFR: 8372134: ThreadLocalRandom no longer overrides nextGaussian Alan Bateman
  • Re: RFR: 8372134: ThreadLocalRandom no longer overrides nextGaussian Alan Bateman
  • Re: RFR: 8372134: ThreadLocalRandom no longer overrides nextGaussian [v2] James Yuzawa
  • Re: RFR: 8372134: ThreadLocalRandom no longer overrides nextGaussian [v2] James Yuzawa
  • Re: RFR: 8372134: ThreadLocalRandom no longer overrides nextGaussian [v2] Alan Bateman
  • Re: RFR: 8372134: ThreadLocalRandom no longer overrides nextGaussian [v2] James Yuzawa
  • Re: RFR: 8372134: ThreadLocalRandom no longer overrides nextGaussian [v3] James Yuzawa
  • Re: RFR: 8372134: ThreadLocalRandom no longer overrides nextGaussian [v3] Alan Bateman
  • Re: RFR: 8372134: ThreadLocalRandom no longer overrides nextGaussian [v4] James Yuzawa
  • Re: RFR: 8372134: ThreadLocalRandom no longer overrides nextGaussian [v3] Raffaello Giulietti
  • Re: RFR: 8372134: ThreadLocalRandom no longer overrides nextGaussian [v4] James Yuzawa
  • Re: RFR: 8372134: ThreadLocalRandom no longer overrides nextGaussian [v4] Viktor Klang
  • Re: RFR: 8372134: ThreadLocalRandom no longer overrides nextGaussian [v4] James Yuzawa
  • Re: RFR: 8372134: ThreadLocalRandom no longer overrides nextGaussian [v5] James Yuzawa
  • Re: RFR: 8372134: ThreadLocalRandom no longer overrides nextGaussian [v5] Raffaello Giulietti
  • Re: RFR: 8372134: ThreadLocalRandom no longer overrides nextGaussian [v5] Alan Bateman
  • Re: RFR: 8372134: ThreadLocalRandom no longer overrides nextGaussian [v5] Viktor Klang
  • Re: RFR: 8372134: ThreadLocalRandom no longer overrides nextGaussian [v5] ExE Boss
  • Re: RFR: 8372134: ThreadLocalRandom no longer overrides nextGaussian [v5] Alan Bateman
  • Re: RFR: 8372134: ThreadLocalRandom no longer overrides nextGaussian [v5] duke
  • Integrated: 8372134: ThreadLocalRandom no longer overrides nextGaussian James Yuzawa
• RFR: 8364544: Extract the checks of AtomicXxxFieldUpdater into a common place Steve Armstrong
  • Re: RFR: 8364544: Extract the checks of AtomicXxxFieldUpdater into a common place ExE Boss
  • Re: RFR: 8364544: Extract the checks of AtomicXxxFieldUpdater into a common place [v2] Steve Armstrong
  • Re: RFR: 8364544: Extract the checks of AtomicXxxFieldUpdater into a common place [v2] Steve Armstrong
  • Re: RFR: 8364544: Extract the checks of AtomicXxxFieldUpdater into a common place [v2] Chen Liang
  • Re: RFR: 8364544: Extract the checks of AtomicXxxFieldUpdater into a common place [v2] Steve Armstrong
  • Re: RFR: 8364544: Extract the checks of AtomicXxxFieldUpdater into a common place [v3] Steve Armstrong
  • Re: RFR: 8364544: Extract the checks of AtomicXxxFieldUpdater into a common place [v3] Chen Liang
  • Re: RFR: 8364544: Extract the checks of AtomicXxxFieldUpdater into a common place [v3] Steve Armstrong
  • Re: RFR: 8364544: Extract the checks of AtomicXxxFieldUpdater into a common place [v4] Steve Armstrong
  • Re: RFR: 8364544: Extract the checks of AtomicXxxFieldUpdater into a common place [v4] Viktor Klang
  • Re: RFR: 8364544: Extract the checks of AtomicXxxFieldUpdater into a common place [v4] Steve Armstrong
  • Re: RFR: 8364544: Extract the checks of AtomicXxxFieldUpdater into a common place [v4] Martin Buchholz
  • Re: RFR: 8364544: Extract the checks of AtomicXxxFieldUpdater into a common place [v4] Alan Bateman
  • Re: RFR: 8364544: Extract the checks of AtomicXxxFieldUpdater into a common place [v4] Rémi Forax
  • Re: RFR: 8364544: Extract the checks of AtomicXxxFieldUpdater into a common place [v4] ExE Boss
  • Re: RFR: 8364544: Extract the checks of AtomicXxxFieldUpdater into a common place [v4] Steve Armstrong
  • Withdrawn: 8364544: Extract the checks of AtomicXxxFieldUpdater into a common place Steve Armstrong
• Add better exception message to FileTreeIterator.hasNext()? David Alayachew
  • Re: Add better exception message to FileTreeIterator.hasNext()? Chen Liang
  • Re: Add better exception message to FileTreeIterator.hasNext()? David Alayachew
• Re: RFR: 8360046: Scalability issue when submitting virtual threads with almost empty tasks [v20] Doug Lea
• RFR: 8371740 : LinkedTransferQueue.poll() returns null even though queue is not empty Viktor Klang
  • Re: RFR: 8371740 : LinkedTransferQueue.poll() returns null even though queue is not empty kabutz
  • Re: RFR: 8371740 : LinkedTransferQueue.poll() returns null even though queue is not empty Alan Bateman
  • Re: RFR: 8371740 : LinkedTransferQueue.poll() returns null even though queue is not empty Viktor Klang
  • Re: RFR: 8371740 : LinkedTransferQueue.poll() returns null even though queue is not empty kabutz
  • Re: RFR: 8371740 : LinkedTransferQueue.poll() returns null even though queue is not empty Viktor Klang
  • Re: RFR: 8371740 : LinkedTransferQueue.poll() returns null even though queue is not empty Viktor Klang
  • Re: RFR: 8371740 : LinkedTransferQueue.poll() returns null even though queue is not empty Doug Lea
  • Re: RFR: 8371740 : LinkedTransferQueue.poll() returns null even though queue is not empty Doug Lea
  • Re: RFR: 8371740 : LinkedTransferQueue.poll() returns null even though queue is not empty Viktor Klang
  • Re: RFR: 8371740 : LinkedTransferQueue.poll() returns null even though queue is not empty Viktor Klang
  • Re: RFR: 8371740 : LinkedTransferQueue.poll() returns null even though queue is not empty [v2] Viktor Klang
  • Re: RFR: 8371740 : LinkedTransferQueue.poll() returns null even though queue is not empty [v2] Viktor Klang
  • Re: RFR: 8371740 : LinkedTransferQueue.poll() returns null even though queue is not empty [v2] Alan Bateman
  • Re: RFR: 8371740 : LinkedTransferQueue.poll() returns null even though queue is not empty [v2] kabutz
  • Re: RFR: 8371740 : LinkedTransferQueue.poll() returns null even though queue is not empty [v2] Viktor Klang
  • Re: RFR: 8371740 : LinkedTransferQueue.poll() returns null even though queue is not empty [v2] kabutz
  • Re: RFR: 8371740 : LinkedTransferQueue.poll() returns null even though queue is not empty [v2] Viktor Klang
  • Integrated: 8371740 : LinkedTransferQueue.poll() returns null even though queue is not empty Viktor Klang
• Re: RFR: 8360046: Scalability issue when submitting virtual threads with almost empty tasks [v19] Doug Lea
  • Re: RFR: 8360046: Scalability issue when submitting virtual threads with almost empty tasks [v19] Viktor Klang
  • Re: RFR: 8360046: Scalability issue when submitting virtual threads with almost empty tasks [v19] Doug Lea
• RFR: 8370887: DelayScheduler.replace method may break the 4-ary heap in certain scenarios Alan Bateman
  • Re: RFR: 8370887: DelayScheduler.replace method may break the 4-ary heap in certain scenarios Viktor Klang
  • Re: RFR: 8370887: DelayScheduler.replace method may break the 4-ary heap in certain scenarios Alan Bateman
  • Re: RFR: 8370887: DelayScheduler.replace method may break the 4-ary heap in certain scenarios Viktor Klang
  • Integrated: 8370887: DelayScheduler.replace method may break the 4-ary heap in certain scenarios Alan Bateman
• RFR: 8372410: VarHandle wrongly uses int parameter on VirtualThread creation Francesco Nigro
  • Re: RFR: 8372410: VarHandle wrongly uses int parameter on VirtualThread creation Alan Bateman
  • Re: RFR: 8372410: VarHandle wrongly uses int parameter on VirtualThread creation Francesco Nigro
  • Re: RFR: 8372410: ThreadFactory used by Thread.Builder::factory should use non-optimal VarHandle Alan Bateman
  • Re: RFR: 8372410: ThreadFactory used by Thread.Builder::factory should use non-optimal VarHandle Francesco Nigro
  • Re: RFR: 8372410: ThreadFactory used by Thread.Builder::factory should use non-optimal VarHandle Viktor Klang
  • Re: RFR: 8372410: ThreadFactory used by Thread.Builder::factory should use non-optimal VarHandle Andrew Dinn
  • Re: RFR: 8372410: ThreadFactory used by Thread.Builder::factory should use non-optimal VarHandle Alan Bateman
  • Re: RFR: 8372410: ThreadFactory used by Thread.Builder::factory should use non-optimal VarHandle Andrew Dinn
  • Re: RFR: 8372410: ThreadFactory used by Thread.Builder::factory should use non-optimal VarHandle Chen Liang
  • Re: RFR: 8372410: ThreadFactory used by Thread.Builder::factory uses non-optimal VarHandle Francesco Nigro
  • Re: RFR: 8372410: ThreadFactory used by Thread.Builder::factory uses non-optimal VarHandle Jorn Vernee
  • Re: RFR: 8372410: ThreadFactory used by Thread.Builder::factory uses non-optimal VarHandle Francesco Nigro
  • Re: RFR: 8372410: ThreadFactory used by Thread.Builder::factory uses non-optimal VarHandle Alan Bateman
  • Re: RFR: 8372410: ThreadFactory used by Thread.Builder::factory uses non-optimal VarHandle Hannes Greule
  • Re: RFR: 8372410: ThreadFactory used by Thread.Builder::factory uses non-optimal VarHandle duke
  • Integrated: 8372410: ThreadFactory used by Thread.Builder::factory uses non-optimal VarHandle Francesco Nigro
• RFR: 8372399: Add missing CPE statements Sorna Sarathi N

• Earlier messages