As a dev that moved into a sysadmin role who has to deploy stuff from our Java and C++ devs. As dev I used to like the language itself, but not the frameworks.
These days I seriously dislike the runtime with all it's tuning it requires, memory bloat, ... The absolute worst however is most Java developer's complete disconnect with and ignorance of the actual deployment environment/target. I actually kept a score-count for a while for "the server is not configured correctly, it works on my laptop" actually being true and not a developer error. Was asked to remove the sign though since 'it didn't improve the working atmosphere'.
A few pointers for Java devs: please don't use hard-coded paths, certainly when you develop on windows and I need to deploy it on a *nix system, Java will not automagically fix that because it's supposed to be 'multi-platform'. No, XML files are not 'easy' or 'practical' to configure stuff, and I certainly don't want to use java cli tools to manipulate them. Oh and don't rewrite your base config files when some misc hardly documented API was used to deploy some application in your web framework. I don't like it that it removes every single comment from that file, and my config management has to do a lot of hacky ugly stuff so it doesn't treat that as a config change from it's pov. Also, I don't 'just' want to use java library org.X.Y to talk to that hardly documented deployment API. No the database isn't slow because it's misconfigured or doesn't have enough resources, it's because some framework you use to access the database generates a monstrous 30-page SQL query with a few hundred JOINS. Oh and please stop using SOAP when you expect me to talk to it.
I can keep on going - this goes on for a while, and that's only partially the language's fault - but sadly, the stdlib and community encourages some of that undesired behavior. You can however write pretty clean and nice stuff when avoiding large enterpricy frameworks with all the FactoryFactoryFactoryFactoryFactoryFactories where XML is king, but in reality, most Java projects end up using them.
The language has its pros and cons, but for me the issue is the culture, I'm not sure I'll get over my 00's experience nightmare of being handed specs or UML diagrams by Information Systems "Architects" who never wrote a line.
Comments
Carmack on Java: "I like the language"
Your move, language hipsters.
As a dev that moved into a sysadmin role who has to deploy stuff from our Java and C++ devs. As dev I used to like the language itself, but not the frameworks.
These days I seriously dislike the runtime with all it's tuning it requires, memory bloat, ... The absolute worst however is most Java developer's complete disconnect with and ignorance of the actual deployment environment/target. I actually kept a score-count for a while for "the server is not configured correctly, it works on my laptop" actually being true and not a developer error. Was asked to remove the sign though since 'it didn't improve the working atmosphere'.
A few pointers for Java devs: please don't use hard-coded paths, certainly when you develop on windows and I need to deploy it on a *nix system, Java will not automagically fix that because it's supposed to be 'multi-platform'. No, XML files are not 'easy' or 'practical' to configure stuff, and I certainly don't want to use java cli tools to manipulate them. Oh and don't rewrite your base config files when some misc hardly documented API was used to deploy some application in your web framework. I don't like it that it removes every single comment from that file, and my config management has to do a lot of hacky ugly stuff so it doesn't treat that as a config change from it's pov. Also, I don't 'just' want to use java library org.X.Y to talk to that hardly documented deployment API. No the database isn't slow because it's misconfigured or doesn't have enough resources, it's because some framework you use to access the database generates a monstrous 30-page SQL query with a few hundred JOINS. Oh and please stop using SOAP when you expect me to talk to it.
I can keep on going - this goes on for a while, and that's only partially the language's fault - but sadly, the stdlib and community encourages some of that undesired behavior. You can however write pretty clean and nice stuff when avoiding large enterpricy frameworks with all the FactoryFactoryFactoryFactoryFactoryFactories where XML is king, but in reality, most Java projects end up using them.
The language has its pros and cons, but for me the issue is the culture, I'm not sure I'll get over my 00's experience nightmare of being handed specs or UML diagrams by Information Systems "Architects" who never wrote a line.