Comment by alasdair_ | Hacker News Reader

Comment by alasdair_ | Hacker News Reader

Parent Full thread

I agree, it’s verbose. That being said, The boilerplate often helps when reading unfamiliar code. More importantly, the IDE support is fantastic, especially on large codebases.

An example: if I want to refactor a simple thing like Rename a method called “doFoo()” I can do this trivially.

Now, this seems simple but it’s not - I only want to refactor uses of this particular method, NOT any other methods that happen to be called “doFoo()” on unrelated classes or interfaces. Moreover, I want the refactor to intelligently work on everything, including inherited classes, abstract classes and interfaces, while correctly ignoring the stuff i mentioned previously.

None of this matters much if you have a small codebase and a fee developers, but on a huge codebase with many developers, all that boilerplate lets people quickly understand new code and easily refactor that code while being sure they did not break anything.

>The boilerplate often helps when reading unfamiliar code

I don't believe this to be true at all, especially for large code bases. Often the people who support this position have not worked on 100k, 500k, 1m LOC applications I've found.

Boilerplate makes it much more difficult to read and scan large swatehs of code. I think when people say boilerplate 'helps', they often noticing a correlation between the fact that many strongly typed systems happen to have excess boilerplate. I believe it's the typing that helps, not the boilerplate.

I agree on the strong typing note.

That being said, IntelliJ's IDEA is fantastic at hiding a lot of the boilerplate in Java (like getters and setters and all those import statements at the top of the file) and modern Java is FAR FAR better about being less verbose than it was in 1.0

Java also has Lombok (https://projectlombok.org/) that hides almost all of the repetitive stuff completely.

I absolutely agree, and that is why Java is a great choice for monolithic applications. It's verbose and it's extremely flexible.

The real reason to move away from Java is to move towards different software architectures (microservices!)

>The real reason to move away from Java is to move towards different software architectures (microservices!)

This is a SpringBoot microservice:

@RestController public class BasicController {

    @RequestMapping(value="/{id}", method = RequestMethod.GET)
    public String get(@PathVariable("id")Integer id) {
        return doStuff(id);
    }

}

I'm not sure it's any more verbose than the equivalent Ruby on Rails microservice (for example).

Reply on news.ycombinator.com