Java – Any disadvantage to using websockets for non-web client apps

Web Sockets are the better choice

The problem with constant polling is that, much like sending small bursts of data (which it pretty much amounts to), your device goes into an 'idle' state that it has to 'wake up' from in between polls. There is a high cost associated with making the initial connection and this cost is repeated for every poll you perform. And this adds up. For a chat application where you would need to poll every few seconds to keep it responsive you'd drain the battery in no time.

See also this answer on android.SE

Web sockets are not that hard anyway. There are plenty of libraries out there that can help you, and take care of the issues you list for you.

You will not see a huge difference.

Well, the polling will consume a lot more bandwidth simply from request headers unless you use techniques like long-polling, where the server doesn't respond to requests immediately but waits until either new data is available, or some timeout expires (in which case the client starts the next request). This allows for instantaneous updates, just like Websockets.

The difference is that websockets can push multiple messages in both directions using the same connection, whereas with long-polling the server can only provide one response per connection. Connection here means HTTP-request, even though the underlying TCP and TLS connections might be reused. Long-polling is trivial to implement if your web server is based on an event loop, but is problematic in one-thread-per-request web servers.

But aside from that, there really isn't a huge difference. In both cases, your server will have to handle a large number of concurrent open connections. In the case of polling without long-polling, you will have fewer concurrent connections but will spend more time responding to all the requests – which still won't be a lot if the events can be cached.

The cache can likely be a normal in-memory data structure that persists between requests. It doesn't have to be an external cache server.

So simply build the simplest thing that works for you. Both Java and C# have a very mature library ecosystem so you are likely to have good implementations available. When there is a problem, consider refactoring to use a more elaborate, more performant solution. My guess is that long-polling will be fine, unless clients typically receive multiple messages per minute, or unless you have more connections than your main webserver can comfortably handle.