> if you've programmed a game in a functional programming language you know it also requires the code to become more complex in various situations
Irrelevant. A game is not a web application. A game has a claim to require mutability for performance concerns, but mutable state is generally safer in such a use case. A game is likely to have a few threads, each with a dedicated task or set of tasks, whereas a web application is not so constrained and any request may effectively duplicate another. Web applications that are cavalier about mutable state literally-literally invariably decompose to "synchronized blocks for all the things!" and, seriously, who wants to have anything to do with that?
> I can also find lots literature about following java bean convention as good practise. Your just cherry picking literature.
I'm not "cherry-picking" a Goddamned thing: I'm referring to one of the major, canonical sources of Java convention. You may find shitty Apress books that say "sure, use JavaBeans everywhere!", but that's why they're shitty Apress books. Effective Java is the book that literally-literally every competent Java programmer I have ever met has read and fully digested. There are areas of style where not everyone I've met agrees with Bloch, but immutable-by-default is very widely accepted except in areas (such as game development, though that is, again, irrelevant to the topic at hand) where performance becomes a legitimate concern.
But, except for those edge cases (and they really are edge cases, they certainly don't apply to web development) you are not going to find someone of significant credibility and stature in the Java community who is going to say "follow JavaBean convention". You just aren't.
Indeed, I too implement web apps
in a immutable manor when I can. Most of my ejbs are immutable, since they just add and return stuff. I don't like web servers relying on state. I also keep my ejbs mostly stateless using stateless ejbs funnily enough.
However when choosing JPA or JDBC - thus relying on boilderplate code loading data into java object constructors manually then I choose jpa.
It is a trade off for me. Boilerplate or keeping immutable data classes. For me that is a situation when adding immutability makes things more difficult.
And besides most well supported modern web frameworks like Django or rails also do it that way. So it is not really trade off when choosing EE / rails / Django. You have to have in most of those frameworks unless you rip out the orm.
I'm not really in a position to choose some obscure framework.
Irrelevant. A game is not a web application. A game has a claim to require mutability for performance concerns, but mutable state is generally safer in such a use case. A game is likely to have a few threads, each with a dedicated task or set of tasks, whereas a web application is not so constrained and any request may effectively duplicate another. Web applications that are cavalier about mutable state literally-literally invariably decompose to "synchronized blocks for all the things!" and, seriously, who wants to have anything to do with that?
> I can also find lots literature about following java bean convention as good practise. Your just cherry picking literature.
I'm not "cherry-picking" a Goddamned thing: I'm referring to one of the major, canonical sources of Java convention. You may find shitty Apress books that say "sure, use JavaBeans everywhere!", but that's why they're shitty Apress books. Effective Java is the book that literally-literally every competent Java programmer I have ever met has read and fully digested. There are areas of style where not everyone I've met agrees with Bloch, but immutable-by-default is very widely accepted except in areas (such as game development, though that is, again, irrelevant to the topic at hand) where performance becomes a legitimate concern.
But, except for those edge cases (and they really are edge cases, they certainly don't apply to web development) you are not going to find someone of significant credibility and stature in the Java community who is going to say "follow JavaBean convention". You just aren't.
(If you were, you already would have.)