3 ms·

Java is hard to use? Seriously?

by Rhedox 4y ago

mschuster91 4y ago
Tomcat is an archaic goddamn mess with so many pitfalls and difficulties to get it actually performant on a production system it isn't even funny to make memes out of it. Not to mention the crap tooling choices (ant vs gradle vs maven), the tendency of Java applications to eventually bloat in RAM consumption over time due to memory leaks or the fact that Java unlike PHP doesn't punish a developer for wasteful development. With Java apps, startup times of minutes are the norm, the worst thing I ever saw written in it was an "enterprise" CMS (!) that, while definitely more capable than Drupal or Wordpress, takes a 32GB RAM machine to develop on, wants a 64GB or more machine as hosting and takes half a goddamn hour to boot.
- ElectricalUnion 4y ago
  It's so hard to get it configured right that instead of deploying your app to Tomcat, you embed Tomcat in your app and letting the framework deal with the configuration, like in Spring Boot. Of course it means you end up with several dozen/hundred/thousand copies of Tomcat...
  - mschuster91 4y ago
    That's even worse for optimization since now you have to deal with whatever your framework does to get Tomcat up to speed and how to set a configuration option for Tomcat in a way that eventually ends up at the correct place.
  - geodel 4y ago
    And now I have to deal with this supremely crappy Spring Boot which would convert compile time Java errors to runtime exceptions. Turn already verbose 100 lines stack trace from Java into 5000 lines of Spring infested stack trace. I guess I just couldn't praise enough this Spring Boot.
    - ElectricalUnion 4y ago
      The only four things that I remember that ended up with crappy run time errors that totally should be compile time Java errors are none specifically related to Spring Boot, they're all generic "Java things": * people using Win boxes for development and therefore antivirus locking files in innoportune times during compilation/packing; * people using the Eclipse Java Compiler, a IDE compiler designed to be useful with bad Java; * people trusting themselves writting XML annotations instead of Java annotations, and not unit testing the code (this lack of unit tests alone probably means the code literally did not even work on their machine); * people using the existential, compile-on-runtime terror that is Java Server Pages.
  - jayd16 4y ago
    >and letting the framework deal with the configuration You could even say that the frameworks put the config on rails. But seriously, just embed the server. Its not a bad deal at all.
- geodel 4y ago
  I smile not only because you are right but also because tomcat looks like sweet little server compared to next level of crappiness peddled by IBM/RedHat/Oracle etc which I have misfortune to deal with.
- marcosdumay 4y ago
  I have just watched an ops team say "hey there's a security problem with our version of Tomcat, we need to update it", and then nothing works anymore for a few hours until they get every problem. My observed odds of a point version upgrade on a normal web server breaking something is 0%. That includes Microsoft IIS, that is a patently known piece of shit. My observed odds of a point version upgrade on Tomcat breaking something is 100%.
sergiotapia 4y ago
I look at Java and I want to throw up. So much verbosity. Supervising.Supervisor.SupervisorFactory.get_instance(Supervising.Supervisor.SupervisorFactory.Default.init()); No thanks!
tootie 4y ago
Yeah, it has fallen out of fashion, but I still say Java is pretty much always the best option. Java may be less "approachable" than Rails, but 99% of an application's lifetime will be spent in maintenance. And anyone coming in cold to any software written by any human being is going to have an uphill battle. Strict types, rigid structures and verbose syntax are a blessing to anyone coming in from the outside to read your code. The number language features that make Java the best are javadoc and clear stack traces. Anything else is just superfluous. Also, anyone who thinks maven is too complicated while working in a language that requires bash hacks to manage runtime versions and native dependencies is equally nuts. Maven (JDK really) lets you specify language-level compatibility as a configuration flag. And can hold multiple versions of external dependencies at once without fainting.

Java is hard to use? Seriously?

by Rhedox 4y ago

Java is hard to use? Seriously?

Tomcat is an archaic goddamn mess with so many pitfalls and difficulties to get it actually performant on a production system it isn't even funny to make memes out of it. Not to mention the crap tooling choices (ant vs gradle vs maven), the tendency of Java applications to eventually bloat in RAM consumption over time due to memory leaks or the fact that Java unlike PHP doesn't punish a developer for wasteful development. With Java apps, startup times of minutes are the norm, the worst thing I ever saw written in it was an "enterprise" CMS (!) that, while definitely more capable than Drupal or Wordpress, takes a 32GB RAM machine to develop on, wants a 64GB or more machine as hosting and takes half a goddamn hour to boot.

ElectricalUnion 4y ago
It's so hard to get it configured right that instead of deploying your app to Tomcat, you embed Tomcat in your app and letting the framework deal with the configuration, like in Spring Boot. Of course it means you end up with several dozen/hundred/thousand copies of Tomcat...
- mschuster91 4y ago
  That's even worse for optimization since now you have to deal with whatever your framework does to get Tomcat up to speed and how to set a configuration option for Tomcat in a way that eventually ends up at the correct place.
- geodel 4y ago
  And now I have to deal with this supremely crappy Spring Boot which would convert compile time Java errors to runtime exceptions. Turn already verbose 100 lines stack trace from Java into 5000 lines of Spring infested stack trace. I guess I just couldn't praise enough this Spring Boot.
  - ElectricalUnion 4y ago
    The only four things that I remember that ended up with crappy run time errors that totally should be compile time Java errors are none specifically related to Spring Boot, they're all generic "Java things": * people using Win boxes for development and therefore antivirus locking files in innoportune times during compilation/packing; * people using the Eclipse Java Compiler, a IDE compiler designed to be useful with bad Java; * people trusting themselves writting XML annotations instead of Java annotations, and not unit testing the code (this lack of unit tests alone probably means the code literally did not even work on their machine); * people using the existential, compile-on-runtime terror that is Java Server Pages.
- jayd16 4y ago
  >and letting the framework deal with the configuration You could even say that the frameworks put the config on rails. But seriously, just embed the server. Its not a bad deal at all.
geodel 4y ago
I smile not only because you are right but also because tomcat looks like sweet little server compared to next level of crappiness peddled by IBM/RedHat/Oracle etc which I have misfortune to deal with.
marcosdumay 4y ago
I have just watched an ops team say "hey there's a security problem with our version of Tomcat, we need to update it", and then nothing works anymore for a few hours until they get every problem. My observed odds of a point version upgrade on a normal web server breaking something is 0%. That includes Microsoft IIS, that is a patently known piece of shit. My observed odds of a point version upgrade on Tomcat breaking something is 100%.

sergiotapia 4y ago

I look at Java and I want to throw up. So much verbosity. Supervising.Supervisor.SupervisorFactory.get_instance(Supervising.Supervisor.SupervisorFactory.Default.init()); No thanks!

tootie 4y ago

Yeah, it has fallen out of fashion, but I still say Java is pretty much always the best option. Java may be less "approachable" than Rails, but 99% of an application's lifetime will be spent in maintenance. And anyone coming in cold to any software written by any human being is going to have an uphill battle. Strict types, rigid structures and verbose syntax are a blessing to anyone coming in from the outside to read your code. The number language features that make Java the best are javadoc and clear stack traces. Anything else is just superfluous. Also, anyone who thinks maven is too complicated while working in a language that requires bash hacks to manage runtime versions and native dependencies is equally nuts. Maven (JDK really) lets you specify language-level compatibility as a configuration flag. And can hold multiple versions of external dependencies at once without fainting.