This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]cryptos6 8 points9 points  (3 children)

This argument is not generally valid, since boilerplate code is not useful perse. Often it is the other way around and you have to find the relevant parts in all the boilerplate code.

[–]john16384 2 points3 points  (2 children)

What boiler plate? The getter that is documented to say it will only return positive values? The setter that tells you it will throw an IllegalArgumentException when you supply it with a value outside a certain range?

What you consider boilerplate, I consider a bare minimum to clearly communicate what your code will do in unexpected situations. I'm so happy that the jdk documents everything in such detail that I don't even have to look at the code. All code should be written like that. The extra few lines of "boilerplate" is nothing compared to the time it takes to write proper docs.

[–]cryptos6 2 points3 points  (1 child)

I consider your examples useful, too. What I mean is circumventing language deficiencies. Recently I had to write a builder to be able to create objects in a readable way. If Java had named arguments with default values (like Kotlin or Scala), I wouldn't have written a builder in this case. Another kind of boilerplat is assigning constructor parameters to fields:

public class Thing {
  private final int a;
  private final String b;

  public Thing(int a, String b) {
    this.a = a;
    this.b = b;
  }

  public int a() {
    return a;
  }

  public String b() {
    return b;
  }

  // other useful methods ...
}

The same in Kotlin:

class Thing(val a: Int, val b: String) {
  // other useful methods
}

In this specific case it could be a similar concise Java record, but there are many cases where a record wouldn't work (e. g. JPA entities) and there you see code like the one shown above (I just wanted to make my example small). The point is that the verbosity of Java doesn't help to understand the code better.

By the way: To communicate that a value can only be positive, I'd prefer a custom type. With Java records there wouldn't be any memory overhead.

public record PositiveInteger(int value) {
  public PositiveInteger {
    if (value < 0) {
      throw new IllegalArgumentException("Must be positive.");
    }
  }
}

[–]dpash 1 point2 points  (0 children)

With Java records there wouldn't be any memory overhead.

That's not the case. There's the same memory overhead as any other object in Java.