Optional and generics would like a word...
Edit: OK, since this got a downvote, let me be clearer, with some help from the parent:
You just use Optional<T>, and if you're lucky some of your dependencies BUT NOT ALL OF THEIR TRANSITIVE DEPENDENCIES also use Optional<T> correctly and don't return null, and before you know it you've lost the nice safety and it's a crapshoot whether your Optional<T> will be null.
I wish Java had had non nullable types as default from the getgo, and it's hard to add now for the same reason JS/PY have a hard time adding static typing
private Optional(T value) { this.value = Objects.requireNonNull(value); }
At least in this project example code, i see tons of empty class like Result.java with empty content, on separate file.
So is this normal convention for Java dev ? No eslint (or similar tool) to prevent boilerplateness ? That's my point.
Do you Java dev have strict standard on prevent such things spread on all codebase, ecosystem,... ?
For some reason, some early java devs got the idea that you weren't allowed to have multiple classes in one file (an easy misunderstanding if you follow a Hello World tutorial and stop learning) so yeah, you'll find plenty of projects that have a bunch of class file with 3 lines.
So what? If you find this kind of mistake in a project you're working in, it's going to be very easy to refactor it safely, since Java is statically typed and IDEs like IntelliJ can use that static typing to make moving classes around extremely safe.
Considering records just made it into the language, I think "for a long time" is a very misleading description. And records only solve the problem if your type is actually immutable - which you may not be able to do if you have to interface with stuff like Hibernate which assumes that it can just mutate everything everywhere.
That's why people use Lombok - because the language itself is too clumsy.
And that's just one example. The way checked exceptions don't work well with lambdas and require manual catching and rethrowing would be another. And so on.
> The real nice thing about Java is everything is statically typed, unlike in TypeScript where just your code and if you're lucky some of your dependencies
Thankfully, there are many other statically typed languages, so you don't have to decide between Java or TypeScript/typed Python. With Scala or Kotlin, you don't even have to leave the JVM.
You do know you can declare multiple classes in a single file (static nested classes), contrary to the popular convention, right? And "public static void main" doesn't count as boilerplate, that's like one line in the whole program...
The real nice thing about Java is everything is statically typed, unlike in TypeScript where just your code and if you're lucky some of your dependencies BUT NOT ALL OF THEIR TRANSITIVE DEPENDENCIES are properly statically typed, and before you know it you've lost the nice safety and it's a crapshoot whether your type errors will really be caught, because a transitive dependency can do whatever it wants with your callback that you typed one way but it didn't care because it was plain javascript....
This is why I am not a fan of either Typescript or PEP 484 statically typed python. Typing works best when it was mandatory from day one, as long as there is some random untyped code in there somewhere nothing is really guaranteed.