# io.github.libtmux.Window.Window.applyLayout

- **Module:** io.github.libtmux.Window.Window
- **Package:** io.github.libtmux:libtmux
- **Language:** Java
- **Kind:** method
- **Source:** https://github.com/libtmux/libtmux-java/blob/842228310449e879ebcaa3f910597757c9dbffd6/libtmux/src/main/java/io/github/libtmux/Window.java#L307
- **Page:** https://libtmux.org/en/java/latest/reference/io-github-libtmux-window-window-applylayout/

```
io.github.libtmux.Window.Window.applyLayout(layout: WindowLayout) -> void
```

Restores an exact arrangement previously read from {@link #layout()}.

The string is checked here rather than by tmux, because tmux 3.3a does not survive being
handed one it cannot parse: it ends the server and every session on the socket. Every other
supported release answers {@code invalid layout}. The classic form carries tmux's own
checksum, so a wrong one is detectable without asking; since 3.8 tmux may instead hand back
JSON, which carries no checksum, so that shape is only trusted from a server new enough to
have written it.

"Exact" holds in full only for a JSON layout, since that is the one form carrying each
pane's id. A classic string — every release before 3.8, or an older reader against a newer
server — restores the geometry but names no pane, so which process lands in which cell can
differ from where it started; whether it does depends on whether the pane list still happens
to match the order the layout was saved in. Confirmed by hand on 3.2a and 3.7c.

## Raises

- `IllegalArgumentException`: if the string is not a layout tmux wrote
- `UnsupportedTmuxVersionException`: if it is JSON-shaped but this server predates JSON layouts