Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rating 26 years of Java changes

neilmadden.blog

Post reply on HN
Print view View original

121–130 of 327 posts

Re: Rating 26 years of Java changes

#121

Post by dcminter »

b_e_n_t_o_n wrote: post #44

I haven't written much Java but I am learning Kotlin and I really appreciate the language and the whole JVM ecosystem. Yeah yeah, Gradle is complicated but it's waaaaay easier to figure out than my adventures with Cmake, and when I read Java code there is a certain comfort I feel that I don't get with other languages, even ones I'm experienced with like Go. Java feels a bit like a stranger I've known my whole life, s…

Maven was peak Java build tool. I detest Gradle. Some people just hate XML enough to doom us all.

Re: Rating 26 years of Java changes

#122

Post by malfist »

__float wrote: post #117
nine_k wrote: post #68

Earlier quoted context omitted.

Absolutely. It seems that the author never touched Spring, for instance, or a dependency-injection framework of any kind. Annotations allow to do things in a completely different way, removing tons of boilerplate. I'd give annotations 9/10 at least. (And I lost the interest in the rest of the article, given such a level of familiarity with the subject matter.)

My experience using Dagger (2) was so unpleasant that it really soured me on the possible uses of this feature. I understand the benefits of dependency injection, but to be totally honest I'm more likely to take the Go-style approach of wiring it all up manually, even if it's a bit of extra boilerplate. The indirection and abstractions built up in DI frameworks is rarely worth it IMO.

Dagger is an absolutely pain in the ass. Its also damn good. Once you understand the archane syntax of their error messages its a lot easier (but still not easy) to use.

Harder than spring, but less magic than spring

Re: Rating 26 years of Java changes

#123

Post by hashmash »

brap wrote: post #82
marginalia_nu wrote: post #17

I think the author is sleeping on Java assertions. I really like the feature, and it's really one of the features I feel Java got right. The syntax is very expressive, and they can easily be made to generate meaningful exceptions when they fail. It's also neat that it gives the language a canonical way of adding invariant checks that can be removed in production but run in tests or during testing or debugging (with -…

What are the pros of making this a keyword vs just a standard function?

At the time the feature was added, there was no way to make a parameter to a function be lazily evaluated. Something like `assert(condition, "error: " + stuff)` would eagerly concatenate the string even when the condition is always true (which it should be). Nowadays, the error parameter can be specified as a lambda, which can potentially be optimized to be just as cheap as the existing assert feature.

Re: Rating 26 years of Java changes

#124

Post by dcminter »

brap wrote: post #78

Wow I can’t believe try with resources is so old! I’ve been working with Java for years and only learned this exists recently, I thought it must be relatively new. 14 years!

It was such a lifesaver for doing raw database stuff. The boilerplate for making sure Connection, PreparedStatement, ResultSet and so on were all released properly was a huge pain before that.

Re: Rating 26 years of Java changes

#125

Post by marginalia_nu »

brap wrote: post #82
marginalia_nu wrote: post #17

I think the author is sleeping on Java assertions. I really like the feature, and it's really one of the features I feel Java got right. The syntax is very expressive, and they can easily be made to generate meaningful exceptions when they fail. It's also neat that it gives the language a canonical way of adding invariant checks that can be removed in production but run in tests or during testing or debugging (with -…

What are the pros of making this a keyword vs just a standard function?

The pros are that it can generate better error messages, without putting that responsibility on the programmer. Something that would otherwise require a preprocessor or some form of metaprogramming.

Re: Rating 26 years of Java changes

#128

Post by hocuspocus »

agos wrote: post #63
marginalia_nu wrote: post #35

Earlier quoted context omitted.

Yeah that's very much an explicit design philosophy of Java, dating way back. Let other languages experiment, and adapt what proves useful. It hasn't worked out in terms of delivering perfect language design, but it has worked out in the sense that Java has an almost absurd degree of backward compatibility. There are libraries that have had more breaking changes this year than the Java programming language has had in…

What other language made them think checked exceptions were a good idea?

I assume it was the other way around, a slight twist to exceptions, only enforced by the compiler (the JVM doesn't care about checked/unchecked) probably seemed a cheap and reasonable way to implement explicit error handling. Given that Java ergonomics of the time didn't offer any convenient and performant way to return multiple values instead.

Re: Rating 26 years of Java changes

#129

Post by sothatsit »

alex_smart wrote: post #98
haunter wrote: post #7

I'm sorry, please don't hate me (I'm tired and don't have anything better to do) https://files.catbox.moe/ge4el3.png

Why so much hate for modules? They seem to be almost universally disliked by everyone on this thread and I don't understand why.

They are only useful for a small group of people, and their addition broke/complicated lots of people's builds in non-trivial ways.

Re: Rating 26 years of Java changes

#130

Post by hashmash »

dcminter wrote: post #66
sedro wrote: post #37

Autoboxing's evil twin, auto-unboxing should knock the score down a few points. Integer a = null; int b = 42; if (a == b) {} // throws NullPointerException

Or my favourite... Short w = 42; Short x = 42; out.println(w == x); // true Short y = 1042; Short z = 1042; out.println(y == z); // false

If JEP 401 is ever delivered (Value Classes and Objects), then this sort of problem should go away.
Post reply on HN