6 ms·

As a language java's not that bad at this point. But it still has cultural issues. Every java project I encounter tends to be overengineered, has tons of usele

by kabes 4y ago

As a language java's not that bad at this point. But it still has cultural issues. Every java project I encounter tends to be overengineered, has tons of useless boilerplate code and ends up throwing mile-long stack traces as a result. Also, somehow maven manages to be even more unreliable than npm as a package manager. I still frequently encounter situations which seem to only get resolved by throwing away my .m2 folder. Furthermore, since the language evolved so much in recent years, it's hard for newcomers to know what the best practices are. There's at least 6 different ways to iterate over map values. Which one should I pick?

Bjartr 4y ago
If it's snapshots causing issues that clearing .m2 is fixing, try adding `-U` to your mvn execution instead, that forces snapshots to be updated. Do you run `mvn install` for your local project under development, or any of its locally built dependent modules? Are all of those at a snapshot version? If not, I think you'd need to delete it from .m2 (or clear all of .m2) to get updates to it into .m2, since even for the local cache I don't think maven will override a cached version during install.
jayd16 4y ago
Don't use ambiguous dependencies and you won't need to flush your cache to get a newer version. I would say the culture is not an issue of Java but of popularity. If Go became the shovelware language of choice, you'd see a lot more bad Go.
vrnvu 4y ago
Completely agree with you. I stopped working with Java not because the language or the ecosystem. I stopped working with Java because Java developers and their culture of over-engineering everything defending it as "clean code" and "good practice". But this seems a taboo topic in a culture infested with "good practice gurus".
- lightbendover 4y ago
  https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris... isn't too far removed from some of what I've seen in big tech, especially architecture-wise. Certainly less costly absurdity.
- dkarl 4y ago
  Theoretically, choosing a JVM language with a good culture seems like a very attractive option. Scala has its own cultural issues, but maybe Kotlin gives you most of the nice parts of Scala without attracting the type astronauts? Maybe Clojure is an option as well, if you're willing to give up static typing? I'm leery of a language with the full power of Lisp macros, but from a distance, the Clojure culture seems to be very pragmatic.
- giantrobot 4y ago
  Is your program really complete if you haven't implemented all of the design patterns in the GoF book? How will it even work without an AbstractFooFactoryFactory? How else can you make stack traces unreadable to the point of being useless?
- marginalia_nu 4y ago
  This seems pretty uncontroversial in the Java space. I think most Java developers will wince at clean code. Clean Code made sense in contrast to the pervading gang-of-four norms that preceded it, but I don't think many people would recommend the style today.
  - giantrobot 4y ago
    In my experience, there's a non-trivial number of "Java developers" stuck in the Clean Code or Design Pattern All The Things modes of development. They want every project to look like a J2EE demo. Those types of Java devs can use a lot of interesting sounding terminology but they overengineer everything and commit ludicrous amounts of code that doesn't tackle the problems at hand.
  - deleted 4y ago
    [deleted]
- diarrhea 4y ago
  Couldn't agree more, and have found people in disagreement with my stance on that [0]. Although my context is C#, I reckon it's similar. 0: https://news.ycombinator.com/item?id=35486983 https://news.ycombinator.com/item?id=35486983
- deleted 4y ago
  [deleted]
kaba0 4y ago
Gradle is a better build tool from a purely architectural point of view (though it is quite disliked, I believe mostly due to the ultra-complex android build system being built on top and giving it a bad name), but the Maven repo system is absolutely better than most contemporary repositories, proved by its comparably rare side-chain attacks.
- btreecat 4y ago
  Also Groovy kinda sucks
  - wiseowise 4y ago
    They should just make the right decision and deprecate all Groovy in favor of Kotlin.
    - ohgodplsno 4y ago
      It's not like the kotlin DSL comes without problems. Configuration time is most of the time about doubled compared to Groovy, type hinting and completion often end up being slower _and_ worse than Groovy, and if you're lucky, your IDE suddenly can't find a random extension in your classpath and your entire build.gradle.kts or plugin becomes a red, squiggly mess. Unfortunately, Gradle is the best build tool I've used for complex systems. And it still fucking sucks.
      - wiseowise 4y ago
        You hit the nail on its head. Deprecate Groovy and allocate all resources to make Kotlin more viable.
- seti0Cha 4y ago
  I dislike it because of the ultra-complex build system that over-ambitious devops engineers ended up building in my shop. Our build system was the hardest part of our code base to reason about, which is pretty screwed up.
brabel 4y ago
> I still frequently encounter situations which seem to only get resolved by throwing away my .m2 folder. I have my own issues with Maven, but never in my 16 years doing Java have I done that. What the heck leads you to believe doing that may fix something at all? .m2 is just a cache, it has pretty much zero impact on whether your stuff will build unless you had installed things there that are not available on a configured repository or something similar, which would of course be your mistake not the tool's.
- dkarl 4y ago
  Depending on what is in your cache, Maven will satisfy dependencies differently. You can go out of your way to nail down your dependencies (analogous to a Javascript lock file) but it goes against the grain of how Maven is designed. Maven encourages pretty sloppy dependency resolution by default, and that's what you'll see if you look inside the artifacts you depend on. There may be other issues as well, because this was an issue that affected Maven throughout my years of using it, in contrast to SBT, which in my experience had this issue much less often (though it definitely did from time to time.)
- whoisthemachine 4y ago
  Can probably happen like it can happen with any dependency management system - if you set wildcard versions (or no version at all?), different systems can have different versions of the dependency cached. Eventually this can lead to surprise build failures.
- afavour 4y ago
  > m2 is just a cache, it has pretty much zero impact on whether your stuff will build Well… the cache can be broken. I’m not a Java dev so have no horse in this race but “it’s just a cache” doesn’t mean “it can’t ever be a problem”
  - i386 4y ago
    Having worked with maven for about 15 years… it’s largely not a problem anymore. Unless you publish snapshots and depend on them.
re-thc 4y ago
> There's at least 6 different ways to iterate over map values. Which one should I pick? Didn't stop people from using Javascript. > I still frequently encounter situations which seem to only get resolved by throwing away my .m2 folder And I frequently encounter issues which seem to only get resolved by throwing away my node_modules folder (and package-lock.json). Point being every language has its issues but Java gets knocked down constantly regardless.
equalsione 4y ago
Pre-java 8 (Java.old) and post-Java.8 (Java++) are philosophically two different languages. Now, 21 is coming and while the changes aren't quite as in your face, the change in philosophy is just as radical. Java would be better regarded if less time was spent on "look at this cool new feature" and more spent on "this is how you should use Java now". Or even, "here's how to safely modernise your codebase". Venkat Subramaniam does some good talks on this but I would prefer if the Java language team were leading it.

by kabes 4y ago

Bjartr 4y ago

If it's snapshots causing issues that clearing .m2 is fixing, try adding `-U` to your mvn execution instead, that forces snapshots to be updated. Do you run `mvn install` for your local project under development, or any of its locally built dependent modules? Are all of those at a snapshot version? If not, I think you'd need to delete it from .m2 (or clear all of .m2) to get updates to it into .m2, since even for the local cache I don't think maven will override a cached version during install.

jayd16 4y ago

Don't use ambiguous dependencies and you won't need to flush your cache to get a newer version. I would say the culture is not an issue of Java but of popularity. If Go became the shovelware language of choice, you'd see a lot more bad Go.

vrnvu 4y ago

Completely agree with you. I stopped working with Java not because the language or the ecosystem. I stopped working with Java because Java developers and their culture of over-engineering everything defending it as "clean code" and "good practice". But this seems a taboo topic in a culture infested with "good practice gurus".

lightbendover 4y ago
https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris... isn't too far removed from some of what I've seen in big tech, especially architecture-wise. Certainly less costly absurdity.
dkarl 4y ago
Theoretically, choosing a JVM language with a good culture seems like a very attractive option. Scala has its own cultural issues, but maybe Kotlin gives you most of the nice parts of Scala without attracting the type astronauts? Maybe Clojure is an option as well, if you're willing to give up static typing? I'm leery of a language with the full power of Lisp macros, but from a distance, the Clojure culture seems to be very pragmatic.
giantrobot 4y ago
Is your program really complete if you haven't implemented all of the design patterns in the GoF book? How will it even work without an AbstractFooFactoryFactory? How else can you make stack traces unreadable to the point of being useless?
marginalia_nu 4y ago
This seems pretty uncontroversial in the Java space. I think most Java developers will wince at clean code. Clean Code made sense in contrast to the pervading gang-of-four norms that preceded it, but I don't think many people would recommend the style today.
- giantrobot 4y ago
  In my experience, there's a non-trivial number of "Java developers" stuck in the Clean Code or Design Pattern All The Things modes of development. They want every project to look like a J2EE demo. Those types of Java devs can use a lot of interesting sounding terminology but they overengineer everything and commit ludicrous amounts of code that doesn't tackle the problems at hand.
- deleted 4y ago
  [deleted]
diarrhea 4y ago
Couldn't agree more, and have found people in disagreement with my stance on that [0]. Although my context is C#, I reckon it's similar. 0: https://news.ycombinator.com/item?id=35486983 https://news.ycombinator.com/item?id=35486983
deleted 4y ago
[deleted]

kaba0 4y ago

Gradle is a better build tool from a purely architectural point of view (though it is quite disliked, I believe mostly due to the ultra-complex android build system being built on top and giving it a bad name), but the Maven repo system is absolutely better than most contemporary repositories, proved by its comparably rare side-chain attacks.

btreecat 4y ago
Also Groovy kinda sucks
- wiseowise 4y ago
  They should just make the right decision and deprecate all Groovy in favor of Kotlin.
  - ohgodplsno 4y ago
    It's not like the kotlin DSL comes without problems. Configuration time is most of the time about doubled compared to Groovy, type hinting and completion often end up being slower _and_ worse than Groovy, and if you're lucky, your IDE suddenly can't find a random extension in your classpath and your entire build.gradle.kts or plugin becomes a red, squiggly mess. Unfortunately, Gradle is the best build tool I've used for complex systems. And it still fucking sucks.
    - wiseowise 4y ago
      You hit the nail on its head. Deprecate Groovy and allocate all resources to make Kotlin more viable.
seti0Cha 4y ago
I dislike it because of the ultra-complex build system that over-ambitious devops engineers ended up building in my shop. Our build system was the hardest part of our code base to reason about, which is pretty screwed up.

brabel 4y ago

> I still frequently encounter situations which seem to only get resolved by throwing away my .m2 folder. I have my own issues with Maven, but never in my 16 years doing Java have I done that. What the heck leads you to believe doing that may fix something at all? .m2 is just a cache, it has pretty much zero impact on whether your stuff will build unless you had installed things there that are not available on a configured repository or something similar, which would of course be your mistake not the tool's.

dkarl 4y ago
Depending on what is in your cache, Maven will satisfy dependencies differently. You can go out of your way to nail down your dependencies (analogous to a Javascript lock file) but it goes against the grain of how Maven is designed. Maven encourages pretty sloppy dependency resolution by default, and that's what you'll see if you look inside the artifacts you depend on. There may be other issues as well, because this was an issue that affected Maven throughout my years of using it, in contrast to SBT, which in my experience had this issue much less often (though it definitely did from time to time.)
whoisthemachine 4y ago
Can probably happen like it can happen with any dependency management system - if you set wildcard versions (or no version at all?), different systems can have different versions of the dependency cached. Eventually this can lead to surprise build failures.
afavour 4y ago
> m2 is just a cache, it has pretty much zero impact on whether your stuff will build Well… the cache can be broken. I’m not a Java dev so have no horse in this race but “it’s just a cache” doesn’t mean “it can’t ever be a problem”
- i386 4y ago
  Having worked with maven for about 15 years… it’s largely not a problem anymore. Unless you publish snapshots and depend on them.

re-thc 4y ago

> There's at least 6 different ways to iterate over map values. Which one should I pick? Didn't stop people from using Javascript. > I still frequently encounter situations which seem to only get resolved by throwing away my .m2 folder And I frequently encounter issues which seem to only get resolved by throwing away my node_modules folder (and package-lock.json). Point being every language has its issues but Java gets knocked down constantly regardless.

equalsione 4y ago

Pre-java 8 (Java.old) and post-Java.8 (Java++) are philosophically two different languages. Now, 21 is coming and while the changes aren't quite as in your face, the change in philosophy is just as radical. Java would be better regarded if less time was spent on "look at this cool new feature" and more spent on "this is how you should use Java now". Or even, "here's how to safely modernise your codebase". Venkat Subramaniam does some good talks on this but I would prefer if the Java language team were leading it.