google / guava Public

RELNOTES=n/a
PiperOrigin-RevId: 417651818

…ax`, `lexicographical`, `emptiesFirst`, `emptiesLast`, `isInOrder`, `isInStrictOrder`.

RELNOTES=`collect`: Removed `@Beta` from the remaining methods in `Comparators`: `min`, `max`, `lexicographical`, `emptiesFirst`, `emptiesLast`, `isInOrder`, `isInStrictOrder`.
PiperOrigin-RevId: 417399872

RELNOTES=n/a
PiperOrigin-RevId: 416878427

RELNOTES=n/a
PiperOrigin-RevId: 416847993

…lExecutor`, and `Monitor`.

RELNOTES=`util.concurrent`: Removed `@Beta` from `ExecutionSequencer`, `MoreExecutors.newSequentialExecutor`, and `Monitor`.
PiperOrigin-RevId: 416833591

… array

RELNOTES=n/a
PiperOrigin-RevId: 416664799

RELNOTES=n/a
PiperOrigin-RevId: 416627986

If we detect a duplicate entry while building the map, we do need to store it in the `entries` array, but we should not update the `table` slot. The under-construction hash table is already correct.

RELNOTES=n/a
PiperOrigin-RevId: 416587035

…` and from the `Duration` overloads in the class.

RELNOTES=`util.concurrent`: Removed `@Beta` from `Uninterruptibles.awaitTerminationUninterruptibly` and from the `Duration` overloads in the class.
PiperOrigin-RevId: 416323424

Fixes #3452

RELNOTES=Several classes in `com.google.common.testing` that were previously marked `@Beta` are now fully supported.
PiperOrigin-RevId: 416320108

Fixes #3052
Fixes #3414
Fixes #3417
Fixes #3423

RELNOTES=`net`: Removed `@Beta` from APIs in net.
PiperOrigin-RevId: 416312524

… `ClosingFuture`.

The former two are simple interfaces. `ClosingFuture` was meant to be `@Beta` for only one release :)

`ListenableScheduledFuture` was particularly silly to have as `@Beta` because it's the return type of `ListeningScheduledExecutorService`, from which we'd already removed `@Beta`.

`AsyncCallable` makes extra sense to remove from `@Beta` at the same time as `Futures.submit`, `submitAsync`, and `scheduleAsync` (CL 416093023).

RELNOTES=`util.concurrent`: Removed `@Beta` from `AsyncCallable`, `ListenableScheduledFuture`, and `ClosingFuture`.
PiperOrigin-RevId: 416302588

- `submit`
- `submitAsync`
- `scheduleAsync`
- `nonCancellationPropagating`
- `inCompletionOrder`

I did also add a TODO to potentially make the return type of `scheduleAsync` more specific in the future. However, to the best of my knowledge, no one has ever asked for this. (That's not surprising: `ScheduledFuture` isn't any more useful than `Future` unless you're implementing a `ScheduledExecutorService`, and even then, access to its timeout is unavoidably racy.) Plus, should we ever need to do it, we can do it compatibly by injecting a bridge method with the old signature.

(I didn't see any discussion of the return type in the API Review doc or the CL review thread. It probably just didn't come up, or maybe we all independently concluded that it wasn't worth the trouble, given that `MoreExecutors.listeningDecorator(ScheduledExecutorService)` is a bit of a pain? But I'm guessing `scheduleAsync` would be easier.)

RELNOTES=`util.concurrent`: Removed `@Beta` from `Futures` methods: `submit`, `submitAsync`, `scheduleAsync`, `nonCancellationPropagating`, `inCompletionOrder`.
PiperOrigin-RevId: 416139691

… `addCallback`.

This leaves `@Beta` only for the methods that remain `@Beta` in `Futures` itself, which I'm hoping to make some effort toward later this week.

This CL is an admission that we're never going to get around to reworking `FluentFuture` to be more of a "builder," as discussed in #3419. Maybe there's still a place for something more builder-like, but there's no chance that we'll try to change `FluentFuture` in place. And probably we'll never do anything.

RELNOTES=`util.concurrent`: Removed `@Beta` from the `FluentFuture` type, its factory methods, and `addCallback`.
PiperOrigin-RevId: 416122526

This method is the same as the existing `.buildOrThrow` method, except when the same key appears more than once. In that case `buildOrThrow` throws an exception, while `buildKeepingLast` uses the last value that was associated with the key.

Relnotes:
  * A new method `ImmutableMap.Builder.buildKeepingLast()` keeps the last value for any given key rather than throwing an exception when a key appears more than once.
  * As a side-effect of the `buildKeepingLast()` change, the idiom `ImmutableList.copyOf(Maps.transformValues(map, function))` may produce different results if `function` has side-effects. (This is not recommended.)
PiperOrigin-RevId: 416035210

Fixes #5793

RELNOTES=n/a
PiperOrigin-RevId: 415104694

Fixes #5788

RELNOTES=n/a
PiperOrigin-RevId: 414547550

PiperOrigin-RevId: 414465058

RELNOTES=Include all services in ServiceManager.startAsync exception message
PiperOrigin-RevId: 414199967

Fixed Javadoc search feature on JDK 11, which is currently used in our
scripts updating snapshot Javadocs on guava.dev and building
Guava releases, by adding `no-module-directories` flag.

This option is not present in javadoc tool from JDK 8 and 13+,
hence we use profiles to conditionally pass this flag on 9-12 only.

Note that on JDK 17 javadoc generation does not work,
as it seems to have changed the warning on LVTI usage in sources
to an error.

Fixes #5457
Fixes #5800

RELNOTES=n/a
PiperOrigin-RevId: 413934851

RELNOTES=n/a
PiperOrigin-RevId: 413462427

Fixes #5795.

RELNOTES=n/a
PiperOrigin-RevId: 413459594

This shouldn't be necessary, but we're seeing some evidence that it may help with a mysterious bug.

(I considered renaming the other `cas*` methods (in which I did not add a loop) to "`weakCas*`" to emphasize that _they_ might fail spuriously. But it's hard to imagine how we could ever rewrite their callers to _not_ use a loop, so I don't think we'd be protecting ourselves from any mistakes. Plus, "weak CAS" carries additional meaning (specifically, lack of ordering guarantees) that may or may not be appropriate here. And anyway, we hope that this is all a short-term hack.)

RELNOTES=n/a
PiperOrigin-RevId: 413130485

`AtomicDouble` and `AtomicDoubleArray`:

* `accumulateAndGet`
* `getAndAccumulate`
* `updateAndGet`
* `getAndUpdate`

Closes #5784.
Fixes #5742.

RELNOTES=Implement accumulate/update methods for `AtomicDouble` and `AtomicDoubleArray`.
PiperOrigin-RevId: 412110543

…ters fields

This should allow use of just one xchg on x86 and swp on arm. On architectures where this intrinsic is implemented, this makes completing a future wait-free.

RELNOTES=n/a
PiperOrigin-RevId: 412104471

RELNOTES=n/a
PiperOrigin-RevId: 412061510

RELNOTES=n/a
PiperOrigin-RevId: 411675632

RELNOTES=n/a
PiperOrigin-RevId: 411621730

RELNOTES=n/a
PiperOrigin-RevId: 410535636

RELNOTES=n/a
PiperOrigin-RevId: 409483439

This is our general policy, so it's misleading to mention it only in these two classes.

RELNOTES=n/a
PiperOrigin-RevId: 409192741

…der, matching the description used in newSequentialExecutor()'s Javadoc. Updated the description to more completely specify what that order is.

RELNOTES=Documented that ExecutionSequencer tasks execute in happens-before order.
PiperOrigin-RevId: 408666760

Closes #5772

RELNOTES=n/a
PiperOrigin-RevId: 407945788

Fixes #5761

RELNOTES=n/a
PiperOrigin-RevId: 407670094

RELNOTES=n/a
PiperOrigin-RevId: 407317240