Hacker News new | ask | show | jobs
by Sakos 1353 days ago
Confused about the criticisms now. Otherwise everybody complains about Java boilerplate. Remove some of it and make it optional, to avoid bogging down newbies in irrelevant details in the first instance, and further lead to less boilerplate to make simpler applications in the second instance (or further down the line). I'm not seeing a massive amount of effort being expended here, and I don't see how it's being wasted.
3 comments

When you have such a large ecosystem (Java's user base is larger than the population of quite a few European countries or the population of the San Francisco Bay Area), no matter what you do or don't do, there will be plenty of complaints because there are few things programmers are in consensus over. Satisfying everyone is impossible. If 99% are content with some Java feature (or lack thereof) and 1% of the remaining 1% complain online, you're looking at a thousand complainers.
> Otherwise everybody complains about Java boilerplate.

Do serious people actually complain about this often? I think it's more of a drive-by comment from people who don't like Java for whatever other reasons.

I wrote a lot of Java in the 2000's and the early 2010's. The verbosity of the language was always my #1 complaint. The amount of stuff I had to type vs the productivity of those lines was always out of whack. Maybe it's better now?
Requiring fewer lines for Hello World doesn't really change that though.
Alas, the language is incredibly verbose in and of itself and the plethora of examples continue to be incredibly verbose. From _Java in a Nutshell_ to the latest documentation, the examples all tend to be of the form:

UnbelievablyLongClassName unbelievablyLongClassName = new UnbelievablyLongClassName(parameterName, anotherParameterName);

Given that nearly all existing code follows this pattern (yes, there is var which is only useful in some cases as opposed to C++'s auto keyword) Java has become hopelessly convoluted.

Before I get downvoted, you should keep on mind that I was an early adopter (1996) of "Java as a sane C++" and have been stunned by the verbosity of "modern" Java applications. Unless the standard libraries change (and the effect of that would be staggering) and the open source libraries all change, and every existing application code changed to use reasonable names, Java will always be overly verbose.

> UnbelievablyLongClassName unbelievablyLongClassName = new UnbelievablyLongClassName(parameterName, anotherParameterName);

That's verbose, but how is it convoluted? It seems extremely plain and simple and linear to me? A local variable is set to a new instance of a class with a couple of parameters. What do you see as being convoluted here?

Individually the lines are verbose but are usually readable. But once you start talking about hundreds or thousands of lines across tens or hundreds of files the sheer volume of the text is what starts leading to convolution. What pushes it over the edge then are the endless abstractions, misdirections and enterprise patterns that may or may not make sense to solve the problem at hand but generally are "best practice" or at least were when lots of legacy code was first laid down 10-20 years ago. It becomes a giant headache very quickly.
I like and professionally write Java. Unnecessary boilerplate is the worst part of language, and I'm happy that Java authors agree with me and incrementally fight it.
I agree. One dev I was working with was complaining about how much code they had to write (wrt a design pattern, and not Java specifically). But the problem was not the design patter (which I agree is hella verbose, ports-and-adapters), it was the fact that they did not know how to use their IDE. I had to explain that until you increase the proficiency of your IDE skills, every pattern is going to be slow for you. What took them several minutes to do, could be done in a few seconds by an IntelliJ expert. I know counter arguments can be made. But still. If you gonna ride a horse through tough terrain, you should really get good at using your horse, and not complain about the terrain.
Yeah, to be honest I wouldn’t be surprised if someone proficient in IntelliJ actually does fewer keystrokes for a Java program than they would given an equivalent program in a “much” terser PL, simply due to the IDE helping so much. It is especially visible with dynamic languages, whose auto-complete is simply an order of magnitude worse than what Java offers due to static typing, and that’s just a small part of the equation.
You don't think serious people can be awfully opinionated about the tools in their profession? It's not like it's something unique to Java or even programming. A lot of professionals have dogmatic beliefs about what ideas, tools, etc. they subscribe to and a lot of time is wasted in bickering about it, whether unjustified or not.
Genuinely, I found out that people who tend to be very dogmatic don't tend to be all that great when you look at their actual output - whether measured by quality or speed or ability to orient themselves is someone elses code. They do tend to sound more capable then they are to those who dont work with their code, but that is social thing not capability or seriousness thing.

Opinionated yes, dogmatic not.

I can understand them having an opinion.

I wouldn’t think a serious person would continually bring it up as an actual issue preventing them achieving things.

I agree. Ironically, Java the language doesn't have any more boilerplate than, say, C++ or Go, which people are apparently okay with?

It does however have some stuff that's plain dumb (can't have functions outside classes, public static void main(String[]), ...) some of it isn't even fixable (default visibility should be private, final should be like const in C++, or even better like const in D).

This is a change that takes very little effort and doesn't impact professional development in the slightest.

Java the language is fine, but Java has - or used to have? - so much idiomatic boilerplate - worst of all IMO was the ridiculous imperative to write getters and setters for every field, but there was also a plethora of very broad interfaces - all of which required all kinds of boilerplate and/or delegation to be able to use. Don’t even get me started on the frameworks.

Maybe Java has changed in the last 5 years, but idiomatic Go has much, much, much less boilerplate than the idiomatic Java I used to know.

To your point, I started writing my POJOs without getters/setters. It felt like I was doing something wrong and the ghosts of senior devs I have worked with were looking down at me with shame.... "how could you".

The worst part is that some libraries use getters as convention. e.g. Jackson (by default) uses getter methods to decide what to serialize.

I used to do the same thing, giving total visibility and access inside a package. I do this in my old “Java AI” book (you can get a free copy at https://leanpub.com/javaai by setting the price to free).

I had not touched Java in a long while until yesterday when I wanted to do a quick benchmark of Lucerne to compare it to a search library in another language. I was surprised how easy and quick it was to do this.

I have considered updating my old book for modern Java. It would probably only take a few days to update the examples, but updating the book text would take longer.

Me too - I absolutely recommend using public member fields and not setters/getters! In 20 years of Java development I did not once benefit from all the extra fluff. Classic YAGNI.

I don’t recall having a problem with Jackson, maybe there is an option you can use? But it’s 5 years now since I used Java.

But my point of course was that this is idiomatic boilerplate you don’t find in other languages. Along with a bunch of other ceremony and nonsense like automatic dependency injection and reflection heavy frameworks that reduce mechanical effort by creating complex, invisible and abstract conceptual systems that require far more mental gymnastics than they save on typing. (I’m looking at you, JPA)

C++ boilerplate is criticized all the time. Just being able to pass a range rather than begin and end iterators was such a huge improvement in wordiness and is a widely loved change, for example.