111–120 of 327 posts
Fast forward a few years later, and I'm actually at a C# shop.
Fast forward a decade, I'm at the same shop. I adore C# and I fondly remember my foray into Java.
I left Java around the time Streams were becoming a thing. I thought it looked like a mess, and then I ran into LINQ in C# land. Swings (pun intended) and roundabouts.
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.
So for most people, the initial impression of modules is negative, and then they just decided to rule the feature out completely. This has created a sea of useless criticism, and any constructive criticism is hardly observed. Improvements to module configuration (combine it with the classpath), would go a long way towards making modules "just work" without the naysayers getting in the way.
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
Are there linters for this sort of thing? I don't write Java much any more.
Earlier quoted context omitted.
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
That's another gotcha-- interning of strings and boxed primitives. Are there linters for this sort of thing? I don't write Java much any more.
Yes and they're pretty good so it's rarely an issue in practice. Using == on object references will indeed usually get you yelled at by the linter.
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?
They exist since v1, which had very different philosophy than Java of 2010s-2020s. 1990s were an interesting time in language design and software engineering. People started reflecting on the previous experiences of building software and trying to figure out how to build better, faster, with higher quality. At that time checked exceptions were untested idea: it felt wrong not to have them based on previous experience with exceptions in C++ codebases, but there were no serious arguments against them.
Earlier quoted context omitted.
Is that strictly bad, though? Being able to run an enterprise service by setting configuration values declaratively, and get all the guarantees of a well-tested framework, seems like a pretty good thing. Yes, it’s weird how that’s still Java, but using standard components and only using code as glue where it’s absolutely necessary seems very similar to other engineering disciplines to me.
I think the general adversity against this specialized configurations is that they often tend to be fairly limited/rigid in what they can do, and if you want to customize anything you have to rewrite the whole thing. They effectively lock you into one black box of doing things, and getting out of it can be very painful.
You can always inject your own implementation if needed right?
Definitely underrates the impact of annotations. I'm personally not a fan of the way annotations are used to implicitly wire together applications, but I have to admit the impact. Maybe 5/10 is fair in light of the wide range of positive and extremely negative ways annotations can be used. So many of these features were adopted after they were proven in other languages. You would expect that since Java took such a sl…
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.)
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.
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?
For some things like requiring arguments to be non-null static checks with annotations have superseded them (in a confusing way inevitably - I think there are three different common non-nullness annotations).
Earlier quoted context omitted.
I used to joke that the direction spring was heading was that you’d have an application be a boilerplate main method with a dozen lines of annotations. Then I actually encountered this in the wild: we had an app that sent updates from db2 to rabbitmq, and the application literally was just configuration via annotations and no actual Java code other than the usual spring main method.
Is that strictly bad, though? Being able to run an enterprise service by setting configuration values declaratively, and get all the guarantees of a well-tested framework, seems like a pretty good thing. Yes, it’s weird how that’s still Java, but using standard components and only using code as glue where it’s absolutely necessary seems very similar to other engineering disciplines to me.
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?
There's Guava and its Preconditions class[0] that is approximately as terse and I find to be more helpful than everything-is-an-AssertionError.
[0] https://guava.dev/releases/14.0/api/docs/com/google/common/b...