# io.github.libtmux.query.LegacyFilters.LegacyFilters

- **Module:** io.github.libtmux.query.LegacyFilters
- **Package:** io.github.libtmux:libtmux
- **Language:** Java
- **Kind:** class
- **Source:** https://github.com/libtmux/libtmux-java/blob/c3517519ee799428a809ce6deb1708c8be289cd1/libtmux/src/main/java/io/github/libtmux/query/LegacyFilters.java#L22
- **Page:** https://libtmux.org/reference/java/io-github-libtmux-query-legacyfilters-legacyfilters/

The {@code name__contains=dev} form, confined to the edge.

<p>Python libtmux accepts filters as keyword arguments whose names encode the operator. That shape
cannot survive into the typed API: the field and the operator arrive as untrusted strings, so
nothing about their pairing can be checked before the program runs. This parser exists so callers
carrying such strings — a CLI flag, a config file, a stored query — have one supported way in, and
so the rest of the library never has to accept them.

<p>Everything it rejects is a compile error in the typed form. That is the trade being made
explicit rather than hidden: one place where a wrong field name or a text operator on a number
becomes a runtime failure, and the type system everywhere else.

## Members

- `parse` (method) — Parses {@code field__operator} keys into a conjunction, in the map's iteration order.
- `FieldCatalog` (class) — The fields a legacy caller may name.
