Hacker News Reader

Comment by kabes | Hacker News Reader

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?

View on HN

> 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.

> 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”

Having worked with maven for about 15 years… it’s largely not a problem anymore. Unless you publish snapshots and depend on them.

If “it’s just a cache,” you should never be able to fix a build problem by nuking your cache. But I frequently can.

Might want to enable strict checksumming on. I think that’s still a thing. Or are you depending on release artifacts that change?

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.)

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.

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".

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.

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.

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://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.

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.

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?

> 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.

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.

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.

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.

Also Groovy kinda sucks

They should just make the right decision and deprecate all Groovy in favor of Kotlin.

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.

You hit the nail on its head. Deprecate Groovy and allocate all resources to make Kotlin more viable.

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.

Well, that’s on them — were they developers in any language they could have also made a mess there. I have seen my fair share of random custom maven plugins as well, which have more bugs than features.

Perl programmers have been making that same argument for literally decades.

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.

Reply on news.ycombinator.com