3 ms·

Actual Java dev here, not just someone who used it in college and got annoyed -- but I have no idea what you're talking about. Java has not been boilerplatey fo

Actual Java dev here, not just someone who used it in college and got annoyed -- but I have no idea what you're talking about. Java has not been boilerplatey for a long time, I'd say since sometime between Java 5 and Java 8. 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.

jen20 3y ago
> The real nice thing about Java is everything is statically typed 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.
- kaba0 3y ago
  I have never ever ever seen a null inside an Optional -- the most common constructor actually Optional::ofNullable makes the correct decision, so you can't even fck it up, and if you deliberately try to, I'm sure intellij would scream your head off.
  - waynesonfire 3y ago
    The reason you've never seen it is because it won't let you, private Optional(T value) { this.value = Objects.requireNonNull(value); }
  - jen20 3y ago
    The problem is whether the optional itself is null, not whether the contained value is.
    - kaba0 3y ago
      That’s not a problem either.
- galdosdi 3y ago
  Yep, this is a great point, and while these days people use stuff like @NonNull/@Nullable, it does not help a lot, for the exact same reason. 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
revskill 3y ago
You're correct ... in theory. 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,... ?
- galdosdi 3y ago
  Well, I can't speak for how others write Java. It's like any other language -- if a function or file or class is growing too big and complex, you split it up. If you have several that are too tiny and they are logically related, you can group them together. 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.
Tainnor 3y ago
> Java has not been boilerplatey for a long time 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.

jen20 3y ago

> The real nice thing about Java is everything is statically typed 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.

kaba0 3y ago
I have never ever ever seen a null inside an Optional -- the most common constructor actually Optional::ofNullable makes the correct decision, so you can't even fck it up, and if you deliberately try to, I'm sure intellij would scream your head off.
- waynesonfire 3y ago
  The reason you've never seen it is because it won't let you, private Optional(T value) { this.value = Objects.requireNonNull(value); }
- jen20 3y ago
  The problem is whether the optional itself is null, not whether the contained value is.
  - kaba0 3y ago
    That’s not a problem either.
galdosdi 3y ago
Yep, this is a great point, and while these days people use stuff like @NonNull/@Nullable, it does not help a lot, for the exact same reason. 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

revskill 3y ago

You're correct ... in theory. 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,... ?

galdosdi 3y ago
Well, I can't speak for how others write Java. It's like any other language -- if a function or file or class is growing too big and complex, you split it up. If you have several that are too tiny and they are logically related, you can group them together. 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.

Tainnor 3y ago

> Java has not been boilerplatey for a long time 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.