Is This Messenger Server Too Large, or Should I Split It Up?

The code isn’t necessarily massive, but the main method is doing too many unrelated jobs. Separate responsibilities into smaller methods or classes—for example, one component for loading credentials, one for authentication, one for accepting connections, and one for handling individual clients. That will make the program much easier to test and maintain. Also, consistent indentation and formatting will make the size feel more manageable.

You don’t need to switch languages just because the Java version looks long. Splitting the code into small, clearly named methods will help regardless of language. Start with straightforward boundaries such as loadUsers(), acceptConnections(), authenticateUser(), and handleClient(), then create separate classes when those methods need their own data or behavior.

Before expanding the project, fix a few design issues as well. The server appears to keep stream and socket state in instance fields even though each connection should have its own state, and the login check seems to compare against the stored value instead of clearly separating usernames and passwords. Passwords should not be stored as plain text; use a password-hashing approach when you get to authentication. Also reset per-connection variables such as the user-exists flag for every new client.

Java tends to require more boilerplate than some other languages, so the same program may look longer. Still, language verbosity isn’t the main issue here. A server that reads files, authenticates users, manages sockets, and starts threads should usually be divided into logical components rather than kept in one large method.