Skip to content

1.1.0 release train - #3307

Draft
pivovarit wants to merge 28 commits into
vavr_1.0.1from
vavr_1.1.0
Draft

1.1.0 release train#3307
pivovarit wants to merge 28 commits into
vavr_1.0.1from
vavr_1.1.0

Conversation

@pivovarit

Copy link
Copy Markdown
Member

No description provided.

pivovarit and others added 23 commits June 20, 2026 13:54
While the comment is correct, it's way more pragmatic to explicitly mark the field as _volatile_

(cherry picked from commit 6d3be22)
fixes: #3267
(cherry picked from commit e4dd6c0)
The old implementation independently called replace on both front and rear, causing up to two replacements instead of one.

(cherry picked from commit e50089d)
Queue#flatMap produced incorrectly ordered results when the queue had elements in its internal rear list

(cherry picked from commit 1b22db5)
- stop cancellation from dispatching queued or newly registered
completion callbacks
- make `andThen` use a cancellable result future so cancelling the
chained future prevents the delayed side-effect action
- add regression coverage for direct callbacks and cancelled `andThen`
chains

Fixes #2552

-
`JAVA_HOME=/opt/homebrew/Cellar/openjdk/25.0.2/libexec/openjdk.jdk/Contents/Home
PATH=/opt/homebrew/Cellar/openjdk/25.0.2/libexec/openjdk.jdk/Contents/Home/bin:$PATH
./mvnw -pl vavr -DskipCheckstyle -DskipCoverage
-Dmaven.repo.local=$PWD/.m2/repository
-Dtest=io.vavr.concurrent.FutureTest test`
- `git diff --check`

---------

Co-authored-by: Puneet Dixit <236133619+puneetdixit200@users.noreply.github.com>
Co-authored-by: Deepak kudi <deepakkudi23@adsl-172-10-9-116.dsl.sndg02.sbcglobal.net>
(cherry picked from commit dffe169)
…r()/valuesIterator() (#3294)

(cherry picked from commit ce168ec)
(cherry picked from commit 1d1f3a2)
@pivovarit
pivovarit changed the base branch from main to vavr_1.0.1 June 20, 2026 12:26
before:

```
distinct=66000 total=900000  ->  size=66000  in 178172 ms
```

after:
```
distinct=66000 total=900000  ->  size=66000  in 232 ms
```

reproducer:
```
static void shakespeareStyleWorkload() {
    int distinct = 66_000, total = 900_000;
    int[] corpus = new int[total];
    for (int i = 0; i < total; i++) {
        corpus[i] = i % distinct;
    }

    long t0 = System.nanoTime();
    LinkedHashMap<Integer, Integer> m = LinkedHashMap.empty();
    for (int word : corpus) {
        m = m.put(word, m.get(word).getOrElse(0) + 1);
    }
    long t1 = System.nanoTime();
    System.out.printf("distinct=%d total=%d  ->  size=%d  in %.0f ms%n",
      distinct, total, m.size(), (t1 - t0) / 1_000_000.0);
}
```
Queue and Vector make very different tradeoffs, and Queue's tradeoffs are wrong for this job.

`LinkedHashMap` doesn't use it like a queue. It uses it as an insertion-ordered sequence it reads many times without consuming. That breaks the amortization.

Vector keeps everything already in the correct order. Nothing is stored backwards, so nothing ever has to be flipped before reading. Getting the first element is instant. It uses slightly more memory, but it sounds like a reasonable trade-off.

Before:
```
size       per-call (us)    ratio vs prev
20000      95,305           -         
40000      186,741          1,96x     
80000      295,748          1,58x     
160000     1153,626         3,90x     
320000     1878,587         1,63x     
```

After:
```
size       per-call (us)    ratio vs prev
20000      0,278            -         
40000      0,299            1,07x     
80000      0,134            0,45x     
160000     0,108            0,80x     
320000     0,122            1,13x  
```

----

reproducer:
```
private static double measureFirstElementNanos(LinkedHashSet<Integer> set, int reps) {
    int sink = 0;
    long t0 = System.nanoTime();
    for (int r = 0; r < reps; r++) {
        sink ^= set.iterator().next();
    }
    long t1 = System.nanoTime();
    if (sink == 0xDEADBEEF) {
        System.out.print("");
    }
    return (t1 - t0) / (double) reps;
}
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants