[stickfigure]

While I think there's a lot to love about Java, the standard library itself is not an especially great role model. Most of it was written a long time ago and has a fairly antiquated style - lots of mutable state, nullability, and checked exceptions. Not that the library isn't an incredible asset - it's luxuriously rich compared to working in Node.js - but if it were written from scratch today, I suspect it would look fairly different. Eg, the collection classes would use Optional and have separate read/write interfaces.

For an example of "modern Java" I would point at something like this (which I wrote, sorry about the hubris):

https://github.com/stickfigure/hattery

[NBJack]

As much of a fan as I am of Java, I have to agree. There are some real bombshells in the library that can either make your coding life or debugging a prod service miserable (sometimes both). Other additions are great, but have hurt readability a bit (i.e. Java lambdas).

Checked exceptions get a bad rep, but I've frequently found taking advantage of their hierarchical nature can be beneficial to at least making them less bad to catch. When I work with languages that have no exception support at all, I sometimes even miss them.

[flashgordon]

As much as "not" a big fan of java, I need to give credit where it is due.. as my (almost) first language almost 25 years ago I learnt heaps by going through the source code. Sure there were bad and (what are now) outdated conventions etc. But as a junior eng learning how layouts worked, how data structures were implemented, how network code was written and tons more, the Java src folder was a huge treasure mine. Did I mention swing?

[pragmatick]

I only looked over your code for a minute but found some stuff I would comment on in a code review.

Comment for a method says "null safe" - why not use an annotation?

A package called "util" is a code smell for me.

UrlUtils only provides two methods for URL encoding so why not name it appropriately?

[Tokumei-no-hito]

I’ve always heard about the “util” package code smell but usually in complex contexts that are hard to discuss.

How would you refactor this to avoid a util package or a UrlUtils class?

[kaba0]

From your repo: Respectfully, I disagree that checked exceptions are a misfeature. Java’s implementation definitely leaves a lot to be desired (inheritance doesn’t make sense for them), but otherwise checked exceptions are a better form of Result types.

[The_Colonel]

Unchecked exceptions are the better version of Result type.

The problem with checked exceptions is that methods throwing them force its callers to react to the even if they are irrelevant to them. In 99% of cases I don't have any JSON specific error handling, yet Jackson forces me to do a try-catch-rethrow ceremony in thpse 99% to declare I don't want to do anything specific.

[kaba0]

That’s the not too comfortable part. But with a tiny bit of syntax sugar (say, a ! or ? that expands to a mini-try-catch block) it would be more than fine.

[The_Colonel]

Yes, I would be fine with a shorthand syntax like that. But it's not available which makes checked exceptions more trouble than worth.