Why does Appium's java-client still ship helpers the Appium 3 server no longer answers?

## Two artefacts, two clocks `java-client` is published independently of the Appium server and of every driver. A client release can therefore be older or newer than the server it talks to, and — crucially — the client keeps old public symbols around far longer than the server keeps the behaviour behind them. The asymmetry is deliberate. Deleting a public class breaks every consumer's build at once, so client maintainers deprecate rather than delete. A server dropping an endpoint breaks only the calls that actually reach it, so servers can and do cull routes at a major line. Different people make those two decisions on different schedules, and the result is that the client's symbol table slowly becomes a partial museum of Appium's past. Two measured examples make this concrete. ## Case one: the touch helpers `io.appium.java_client.TouchAction` is still in the library and carries `@Deprecated`. `MultiTouchAction` is in the same position, and the client's own CHANGELOG records the deprecation of the obsolete touch helpers. The W3C Actions API is the supported route, and the Appium 3 server no longer answers the old `POST /session/:sessionId/touch/perform` and `/touch/multi/perform` endpoints those helpers encoded. Two precise statements are worth keeping straight, because interviews routinely get one of them backwards: - **The classes still exist in the client** and still compile. "TouchAction was removed from `java-client`" is simply false. - **The server endpoints they targeted are gone from the Appium 3 server.** "TouchAction still works, it is only deprecated" is equally false. There is a wrinkle underneath, and it is a good example of why flat claims are risky here: Android's Espresso driver still registers touch-action routes on its own on-device server. So "that route exists nowhere" is a stronger claim than the evidence supports. The safe formulation is the careful one: deprecated in the client, replaced by the W3C Actions API, and gone from the Appium 3 server's own route table. ## Case two: the server-flag museum The same client also ships a `GeneralServerFlag` enum, intended as a convenience for launching a server from test code. It still offers `--shell`, `--show-config`, `--async-trace` and `--enable-heapdump`. None of those four appears in the Appium 3 server's configuration schema, which is the actual authority on what the server accepts. Your IDE will autocomplete a flag the server you are launching has never heard of, and nothing in the build will object. ## Why "it compiles" proves nothing The failure mode is identical in both cases, and it is worth stating as a rule: - A client symbol proves the **library** defines it. - It does not prove the **server** implements the endpoint behind it. - It does not prove the **driver** in your session supports the behaviour. - A green build therefore says nothing about whether the request will be accepted. - The evidence lives on the far side of the connection. | Claim | What actually backs it | |---|---| | "The method exists" | the client library's own source | | "The server answers it" | the server's route table and migration notes | | "The driver supports it" | that driver's own command surface | | "The flag is accepted" | the server's configuration schema | There is a second trap that catches careful people. A CHANGELOG entry is not evidence that a feature exists, because removals are announced in CHANGELOGs too. A search that finds a name in release notes has found the announcement of its death about as often as its birth. ## What to do about it 1. Treat every deprecation warning from `java-client` as a scheduled failure rather than noise, and book the fix instead of suppressing the warning. 2. Verify a server flag against the server's configuration schema, never against the client's enum. 3. When a call that compiles fails at run time, read the Appium server log first: the message and the W3C error code come from there. 4. Pin the client, the server and the driver explicitly, so an environment difference is a version diff you can read rather than a mystery. 5. Move to the supported route as soon as it exists, even if the deprecated one still passes today — the client will keep compiling long after the server stops answering. ## The wider lesson This is not really a story about touch gestures or server flags. It is a story about what a thin, separately versioned client can and cannot tell you. The client is an encoder, so its symbol table describes what it is willing to write down, not what anyone on the other end is willing to read. In a physiotherapy exercise app suite that means a refactor which "builds clean" can still be entirely broken at run time, and the only honest verification is a run against the server and driver versions you actually deploy against.