# io.github.libtmux.query.FilterExpr.FilterExpr.negate

- **Module:** io.github.libtmux.query.FilterExpr.FilterExpr
- **Package:** io.github.libtmux:libtmux
- **Language:** Java
- **Kind:** method
- **Source:** https://github.com/libtmux/libtmux-java/blob/c3517519ee799428a809ce6deb1708c8be289cd1/libtmux/src/main/java/io/github/libtmux/query/FilterExpr.java#L53
- **Page:** https://libtmux.org/reference/java/io-github-libtmux-query-filterexpr-filterexpr-negate/

```
io.github.libtmux.query.FilterExpr.FilterExpr.negate() -> FilterExpr<T>
```

Negation, narrowed to an expression.

<p>{@code and} and {@code or} below are deliberately <em>overloads</em> of the inherited
{@link Predicate} methods rather than overrides: their parameter is a {@code FilterExpr}, so
combining two expressions stays an expression, while passing a bare lambda selects the
inherited method and yields a plain predicate. That is the intended boundary — a lambda cannot
be printed or serialized, so an expression built from one must not claim to be inspectable.