
Generating a Java program with 90% less code - rowland_street
https://www.unitily.com/articles/boilerplate.html
======
CoolGuySteve
Java seems to rely a lot on IDE tools to autocomplete, autorefactor, generally
shovel around all this boilerplate.

It always seemed weird to me. Like if my house was really cluttered but
instead of building shelves or closets into the house itself, I buy an
elaborate conveyor belt and excavator system to rearrange all my things all
the time so I can walk through all the mess.

~~~
dehrmann
I agree that Java is almost unwritable without an IDE, but that strictness has
led to Java having better IDEs than most languages. For large code bases, most
languages get unmaintainable without an IDE, putting Java at an advantage. I'd
still use Python for something simple that won't grow past a few thousand
lines, though.

~~~
jakub_g
This. Far from being a fanboy of Java (and I write JS for a living), but you
can generally quickly understand what's going on with the boring code, and can
refactor mercilessly.

Whereas in huge JS codebases relying on framework magic you can really have
hard time to understand what's going on without plugging a debugger (and even
then it's still not easy). Trying to refactor legacy code that relies on
`this` and prototypes is a nightmare.

~~~
_zamorano_
This!

I sometimes wonder if JS programmers know that with C#/VS you can just change
the name of a class, and without doing anything else (not even replacing), all
involved names just change, and everything works 100%, without writing any
test.

And the same goes for moving a method to another class, or renaming member
variables, modules, files... everything just works and is instantaneous.

To me, not being able to aggresively refactor withour worrying something will
break somewhere is like backwards and old school (in the bad way)

When a project evolves, a class, a struct... grows and suddenly a name,
perfectly fine at the beggining, does not make sense any longer. With C#/VS
you just change and 2 seconds later you're still working.

~~~
toolz
I sometimes wonder if IDE users realize you can do 99.9% of the same things
with simple tools. Personally I don't want my editor magically updating the
codebase because there will be edge cases and I don't want magic happening in
the background when those edge cases arise. In practice I'm sure the class
name change has likely not given you issues in a long time or maybe ever, but
that doesn't mean edge cases don't exist and when they happen to someone it
can be at the worst times and add significant troubleshooting to an unrelated
problem.

edit: further learning those simple tools has a more generic application to
other problems while the IDE magic will likely go until there's an issue to be
understood and you're depriving yourself of learning generally applicable
tooling to trade a slight inconvenience for magic that has the potential to
cause great inconvenience and once that magic from the IDE bites you and you
learn how it works - you've learned something with no general application to
other problems.

edit2: since I can't reply in-line

jcelerier - I _could_ do that with CLI tooling and depending on the language
it would be trivial. However, I would _never_ do that because changing the
method/function name to suit my context would be very unlikely to avoid making
other code less readable. That's a huge anti-pattern that your IDE is making
easy. Further, consider the implications for language design when making
language design decisions that require a specific type of IDE magic to be
considered a reasonable language design decision. I have a hard time believing
relying on the IDE lock-in is good for the community of that language.

philwelch - I genuinely don't know the answer, but what happens when you
change a class name -> forget you do it before saving the file -> go to
another file and try to change the class name there but have a typo -> go back
to the original file and save the change? I would bet the typo'd change goes
unchanged and now you're left scratching your head since that magic has always
worked before.

~~~
philwelch
With a statically typed language and an IDE this isn’t a real issue. There’s
no “edge case” when you rename a class or method symbol in a Java project
because the IDE deterministically knows what are the invocations of the same
symbol.

~~~
arbie
What if the IDE did not traverse a specific file during the global search and
replace?

Are you relying on a correct and comprehensive project/workspace setup within
the IDE?

~~~
pavel_lishin
Then your tests catch it, and you have to fix a single file manually, instead
of a dozen or a hundred or a thousand.

~~~
ken
Sure, and that’s exactly the same failure mode as “sed”. What’s the benefit of
the big IDE?

~~~
pavel_lishin
> What’s the benefit of the big IDE?

To quote myself, "fix a single file manually, instead of a dozen or a hundred
or a thousand".

And what happens when you need to rename, say, a method name that's also used
as a variable name in many places? xWhat happens if multiple classes define
the same method name, but you only want to rename that method for a single
class?

Yes, you can probably do it in sed. If you're used to it enough, you can
probably do it pretty quick, with sufficient regexps that you only have to
debug a few times.

Or you can right click or hit CMD-. or hit F2 or whatever with your cursor on
a method name, type in the new name, wait 2 seconds, and you're done.

------
ronnier
> We define the UserProvider interface

I'm strongly against creating interfaces for non-library (not shared) code,
that will only ever have one concrete implementation. I see it all the time in
internal service code, code that will never have a second implementation. It
makes code hard to navigate, harder to understand, and tedious to manage as
instead of updating one file, now you'll need to update two.

~~~
wvenable
So much over-engineering comes from the fear of changing already written code.
Some programmers, I believe, have the impression that changing code any reason
other than new features or requirements is wasted effort. So they try and
build out all possibilities they can imagine first so they won't have to
change it later.

If you eventually need that interface, you can change your existing code to
use it. Making that change is relatively easy compared to maintaining a bunch
of code that isn't needed. But still I find it hard for some programmers to
get past that mentality.

~~~
sna1l
+1 to this

In my own progression as an engineer who writes Java, I read Clean
Architecture by Robert Martin which lead to AbstractFactory(s) and interfaces
up the wazoo. The reasoning would always be "this can change!"

It definitely took me some time to understand that not everything will change,
and if it does change, having some extra work for simplicity is a reasonable
tradeoff sometimes. In general, knowing when to utilize OO design patterns
takes time and experience.

~~~
pscanf
> The reasoning would always be "this can change!"

As I understood Uncle Bob's argument for using interfaces though, the main
benefit is not supporting alternative implementations, but rather aiding in
the enforcement of the _Dependency Rule_ [1] and of the _Single Responsibility
Principle_ [2].

Interfaces make the relation between components explicit in two ways:

\- they make it clear what depends on what \- they make it clear what are the
responsibilities of the components on either side of the interface

So aside from the fact that it might make it easier in the future to swap
implementations, it first makes it easier _when writing the code_ to decide
how to organize its components (i.e. laying out its architecture).

Of course I agree with you that interfaces can definitely be abused, and can
make code more indirect and difficult to read. I just wanted to point out what
I think is Uncle Bob's point. :)

[1] [https://blog.cleancoder.com/uncle-bob/2012/08/13/the-
clean-a...](https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-
architecture.html#the-dependency-rule) [2]
[https://en.wikipedia.org/wiki/Single_responsibility_principl...](https://en.wikipedia.org/wiki/Single_responsibility_principle)

~~~
GordonS
I see a lot of interface abuse with C# too. My hope is that C#'s new default
interface implementations will put an end to this mess.

~~~
apta
Java also now has default interface implementations.

------
nostrademons
Kotlin is basically Java without the boilerplate. Some of the code snippets on
the page, translated into Kotlin, would be:

    
    
      data class User(val username: String)
      data class Config(val userTable: DynamoTable, val userId: String)
      typealias ItemToUserConverter = (Item) -> User
      class DynamoDbUserProvider(
          val configProvider: ConfigProvider,
          val userTableProvider: UserTableProvider,
          val dynamoReader: DynamoItemReader,
          val itemToUserConverter: ItemToUserConverter) {
        fun execute(id: String) = itemToUserConverter(dynamoReader.execute(userTableProvider.execute(config), id))
      }
    

Plus it comes with great debugging/refactoring/IDE support, async/await, type
inference, and good Java integration.

~~~
smabie
And, Scala is Kotlin without the boilerplate. Scala is the most expressive and
powerful language on the JVM, hands down. Kotlin is just a poor imitation. Of
course, Java is way worse than either, but unless you are targeting Android,
do yourself a favor and use Scala. Closure is okay, I guess, but I find
dynamic typing and the dogma of Clojure counterproductive.

~~~
nostrademons
> Scala is the most expressive and powerful language on the JVM, hands down.

So I'd agree with that statement...

> do yourself a favor and use Scala

...but not that one.

I've found that Scala gets _too_ expressive, much the same way that writing
production code in Common Lisp or Haskell can be slower than just writing it
in Python. It offers incredibly powerful abstraction capabilities that can
often dramatically reduce the amount of code you write; but at some point you
end up spending more time hunting for the perfect abstraction than actually
writing the code. The ideal programming language (for productivity at least,
not necessarily for fun or erudition) is one that melts into the background
when you program so that you can focus on the problem domain rather than the
program. That's the main appeal of languages like Go, Java, and Python: they
offer _just enough_ power to write the program, but not so much that you can
write the program in a dramatically better way and end up tempted to try and
find that way. Kotlin embraces the "it's just a better Java" approach: it's a
minor re-skinning of the concepts in Java, and to the extent that it
introduces new language features (like closures, lambdas, properties, data
classes, anonymous objects, type inference, and immutability), they're all
_concepts_ that skilled Java programmers would be immediately familiar with
but would otherwise have to write lots of boilerplate for.

The Java interop story is also better with Kotlin, because Scala introduces
abstractions for which there are no obvious Java equivalents, and hence
there's an impedance mismatch when you try to envision how your Java libraries
might fit into your Scala program. Kotlin's designers took care to make sure
that there's an easy, intuitive mapping between Kotlin concepts and Java ones,
usually one that had already been enshrined in existing Java conventions (eg.
JavaBeans work nicely with properties, functional objects with lambdas), so
most Java libraries just work in an obvious way. Basically they intentionally
made it dumber so you don't have to think about as much, which is a win for
everyday programming.

~~~
smabie
I guess I'm not an everyday programmer then? I want the machine to work for
me, not the other way around. I find it absurd when I find programmers
actually arguing for less power and less abstraction, it's like arguing for
less free speech or less freedom: contrary to your own interests.

~~~
nostrademons
I thought the same way when I got out of college, but changed my mind after a
decade or so in the industry. What changed could be neatly summed up by this
post:

[https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-
pr...](https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/)

Basically, I used to program for the intellectual challenge and the thrill of
programming itself. If that's your goal, by all means use Scala or Haskell or
Lisp. But at some point that faded, and now I program because somebody has a
problem that they will pay me to solve or (for various startup ideas) because
I want to understand the market or some data source that has the potential to
be worth a lot to a lot of people. For these, my focus is on the _problem_ \-
the programming is a means to an end for solving the problem, and so anything
that lets me spend less brainpower on the programming and more brainpower on
the problem domain is a net win.

~~~
smabie
You can program in Scala just like Java, with both hands tied behind your back
if you please. If you can’t restrain yourself and not use free monads or
whatever, that’s on you, not the language. I’ve worked on enterprise Scala
code bases for a number of years, and no single person on the team would ever
switch to Java. In fact, while many of them started as Java devs, many have
sworn to never take another Java job in their life.

------
nine_k
Compared to the currently fashionable Go, Java has quite little boilerplate.
Java 8+ has a number of quite powerful APIs in the standard library, some
limited type inference, reasonable interfaces that allow default methods. The
compiler has a well-defined custom processing interface (@annotations) which
allows for powerful boilerplate-reducing things, from Lombok to Spring to
JUnit.

80% boilerplate is a large exaggeration.

~~~
icholy
Idiomatic Java has much more boilerplate than idiomatic Go.

~~~
bdamm

      if e3 != nil {
        return _, e3
      }
    

over and over and over..

~~~
zzbzq
Control flow is not boilerplate, that's the application logic.

~~~
nicoburns
It's boilerplate compared to languages with exceptions where this code isn't
necessary, or Rust where the equivalent code is:

    
    
        e3?
    

^ Go could very easily add this syntax, but haven't for some reason.

------
injb
When I used to use Java, the thing that I found remarkable was how much stuff
you had to write in other languages. You had Spring, Ant, Hibernate, Ibatis,
text-based "properties" files etc. It seemed that Java programmers were
willing to go to great lengths to avoid writing anything in Java. But if Java
was so unsuitable for such a wide range of tasks, what made us think it was a
good general purpose language?

In contrast, when I started using Python, one of the things I liked was how
suitable it was for all the things that Java developers typically used other
languages for. Your typically Python project back then contained very little
that wasn't Python, because there weren't many things that it wasn't useful
for.

Things may have changed with Java in the 9-10 years since then but I think
that was certainly one of the things that led to Python becoming more popular.

~~~
oftenwrong
Spot on. Thankfully it is becoming more common to Just Write Java. Java
without the frameworks and other bloated crap is actually decent. The language
itself has a lot of warts, but the Java ecosystem is one of the best (Python
too).

~~~
smabie
What ecosystem? The JVM doesn’t require Java. Scala is pretty much
categorically better in every way than Java.

~~~
retbull
Not in maintainability. It is pretty hard to follow Scala when people use the
flexibility too much. You have so many options that everyone develops their
own flavor of overrides/overloads and style. This makes transferring skills
between jobs or even just projects much harder as the same looking code line
can mean several things.

------
JackFr
After developing software professionally for 30 years, I've come to believe it
largely comes down to tastes and fads. I've programmed professionally in
Fortran, C, C++, perl, C#, Python and Scala and various SQL flavors. I've
dabbled in JS and R and have no experience with Go or Rust.

You can write verbose garbage in any language and you can write clean, well
factored code in any language.

The garbage I'm most familiar with is "Consultant Java" where every class has
an interface, every field has a getter and setter, every method (especially
the getters and setters) has Javadoc -- oh and the test coverage is 100%,
thanks for asking. But you've got 450K lines of code for an app that does CRUD
on 3 tables. I've seen virtually the same thing in C#, only with the added
magic of the latest MS Framework. And if "boilerplate" is such a bad word, how
did Ruby on Rails ever succeed. It's an environment literally built on
boilerplate. And don't get me started on perl. There are perl scripts that
were healthy until they kept dividing until they were cancerous "systems"
throughout the enterprise. C++ pissing contests between developers intent on
showing their worth by writing the most difficult code possible.

So why do have so much garbage out there?

Because programming is a human endeavor. We have tastes. We're often
unwittingly subscribe to faddish beliefs. We all suffer from a host of
cognitive biases that will always prevent us from seeing things clearly.

I can say with certainty that particular tools are better suited for
particular jobs. At this point though, you can't pin me down as to which for
which. I can say that in the past I enjoyed using C and Java and I didn't
enjoy C++ and C#. I was lukewarm over Python. I currently enjoy using Scala
and I think I am most productive in it. But that is more about me than the
languages. Importantly though, I think they all contribute to the software
industry in ways that are not always obvious.

~~~
antpls
I can think of two cases, either :

1) the code had no external review, was written by one person. In this case,
the solution to boilerplate is code review.

or 2) if even with code review there is boilerplate, it means someone
somewhere has an incentive to make the code as difficult to understand as
possible (for example, to justify salaries of an entire team, or to justify
more maintenances, etc)

~~~
JackFr
In particular I know one code base of consultant written Java where part of
their contract was 100% Javadoc coverage and 100% test coverage, so you would
see tests of getters and setters and Javadoc for getFoo(): "Gets the value of
foo"

The code worked, but 80% of it added no value.

~~~
vincnetas
Don't blame consultants for such requirements.

------
rb808
I dont think this is true any more, especially with the changes in the last
few years.

My beef is with Spring. Spring seems to make simple problems very complicated.
Its like you have to learn a second more complicated API on top of the
original. Plus when something goes wrong you get some 100 call deep stack
trace. I just wish there were more pure Java applications without the Spring
magic.

~~~
3fe9a03ccd14ca5
I really enjoy using spring boot. My problem with Spring is that it feels like
I’m mostly metaprogramming with annotations.

Also I hate that I need to literally use a program to create the boilerplate
for a new spring app. And I can’t run my program without special IDE settings.

~~~
tonyarkles
I admittedly didn’t spend a whole lot of time with Spring Boot; I mostly did
Ops with projects other teams build with the occasional Dev assistance when
they painted themselves into a corner. But I’m hoping you might be able to
help with a question I haven’t had much of an answer to: I agree there’s a lot
of “metaprogramming with annotations”, but I didn’t ever find a great way to
dig into an annotation and figure out what the hell it was actually doing, or
how. Do you have any pointers for pulling back the curtain?

Edit: for example, Python “annotations” are generally just functions that
return wrapped functions/attributes/classes/whatever. Java annotations seem
significantly more “magical” than that.

~~~
vbezhenar
Java annotations are meta-data, they don't do anything. Actual code which uses
those annotations is located elsewhere. Usually you can use "Find usages" for
a given annotation to find the actual code.

~~~
tonyarkles
That's what I figured... it seemed like a lot of things didn't really take
effect until something else happened at runtime. It seemed to me (as a
seasoned developer with almost no Spring Boot experience) that there was a lot
of mysterious magic there that was great until it didn't work, and then it
turned into a debugging nightmare (e.g. stack traces that don't, at all,
mention the code where the error exists).

~~~
vbezhenar
I, personally, despite modern trends, don't like Spring Boot. It was never a
big issue for me to configure required beans manually. Spring Core reference
has all the necessary examples to cover it.

I guess, Spring Boot makes sense, when you're producing a lot of little web
applications with microservice architecture, so copying over that manual
configurations can become burden. My applications are monolith and last for
many years, so it's not an issue for me to spend some time configuring
everything as I need it and it's always visible and obvious what's happening.

------
throwaway13337
Interestingly, it's the culture of Java that makes it verbose.

You can write concise pure Java if you don't rely on libraries, have unit
tests, or do things _the Java way_.

It's too bad, too, because there are some things to love about Java, really.
It's simple, it's super fast thanks to the jvm, and it's well supported.

~~~
VeninVidiaVicii
As a genomicist I'm half biologist, half data scientist. I think for the
majority of my problems, it's the verbosity of Java that I just cannot stand.
Maybe the instruction I've had in Java is flawed, but the amount of codewords
to do anything has really kept me away from it.

I don't really ever run into the same problem twice. I've never been able to
write anything as concise for a one-off problem as I can using Python or Perl
(or even Awk) for data wrangling.

~~~
hirako2000
Scripts are superior in term of usability for what you do. Period.

Java is for enterprise scale applications, where dozens or hundreds of
developers contribute to the code base, for a decade or more.

The boilerplate, the verbosity, strong types, the dependencies on
complementary tools is what makes a large code base maintainable in the long
run. If cared for.

If you need to scrap a website a couple of times, convert text from one format
to another. Yea just use some script. Throw away code that nobody but you will
ever need to touch or even look at. It is possible to write a python, Perl,
JavaScript, or even Php app at scale. It may require a bit more due diligence
though. Frameworks have been introduced to help with that.

The article is written by someone who doesn't fully understand Java. No need
for interface to support injection. Interfaces are commonly written by CS
graduates or uninformed long time OOP developers, but composition and DI have
been around for over a decade. I stopped reading when the interface was
pointed out as the only way to go.

------
huherto
It is not Java. It is how people over engineer enterprise applications.

\- Annotations are overused.

\- Design patterns are overused.

\- Too many layers, too many abstractions.

\- Using properties where a constants would be enough.

\- Using concurrency when you don't need it.

Probably a cultural problem more than a technical.

~~~
forinti
Precisely! EJB used to be a nightmare (a lot easier now with annotations), but
I would see people use them for web apps that had 10 users tops. It was
insane.

~~~
theandrewbailey
I barely remember how EJB used to be, though I recall that it involved a mess
of XML and interfaces. Nowadays, EJB is a built-in dependency injection
system. Put @Singleton on one class, then @EJB on a field in a Servlet (or
what have you).

------
dougk16
"...they've developed a way of writing maintainable code, but the language
knows nothing about it, and is not expressive enough to describe it
succintly."

Good quote. I used to struggle with this feeling when I got to roughly the ten
year mark professionally and finally started to feel like I knew what I was
doing. But, with the help of a little Stockholm Syndrome perhaps, I've learned
to embrace the boilerplate as part of my workflow and use it to an advantage.
I came up with a saying "write twice, debug once", from the old carpenter's
saying "measure twice, cut once". The idea is that if you're writing sort of
the same thing twice, the compiler and/or PR reviewers can at least check if
those two things are consistent with each other, and debugging is more
straightforward instead of a long slog. You may still write the same thing
wrong twice, but that's much harder to do than writing it wrong once. I think
this is a hidden value of automated testing as well. I could talk for hours
about whether automated testing is "worth it" depending on the
project/language/team/etc., but one thing most people don't consider is the
value in the mere act of writing out some logic that must be consistent with
other logic, and the inconsistencies you can find without even having to run
the test. Essentially another "write twice, debug once" scenario.

I know that's all kind of vague, and I don't have time to get into specific
examples, but this encapsulates the feeling I have now working with Java. The
feeling that I'm sort of fact-checking myself, even though it's tedious. Sort
of a "show your work" thing.

------
joshlemer
My biggest beef with idiomatic Java code is that it is so annotation-based.
For example, I recently had to do a small CLI app in Java, and the command
line parser library that came up in searches was picocli. Now, I mean no
offence to the creators of picocli, it's pretty typical of most java code in
my experience, but why does it have to do everything via annotations? Take
their example for instance:
[https://github.com/remkop/picocli#example](https://github.com/remkop/picocli#example)

Not sure why a "just plain data" approach couldn't have been taken so that
instead of:

    
    
        @Option(names = { "-v", "--verbose" },
          description = "Verbose mode.")
        private boolean[] verbose = new boolean[0];  
    
    

You could've had something more...

    
    
        Option<boolean[]> verbose = 
          Option.<boolean[]>newBuilder()
            .names("-v", "--verbose")
            .description("Verbose mode.")
            .default(() -> new boolean[0])
            .build();

~~~
eitland
Because then people like the ones tearing down their strawman "Java is
verbose" would be closer to having a point.

Annotations work really well: they are easy to write, easy to write and
typesafe enough.

~~~
joshlemer
But they are in my opinion really difficult to understand, test or customize.
In the example above, the reified Option<boolean[]> can be passed around,
transformed, inspected, invoked in tests, etc. The annotation approach weaves
together the aggregate class (the overarching config class), the specific
field of the class (`verbose`) and how that field should be parsed from
command line arguments.

~~~
eitland
Ok. I can try to help: In this particular case, when you test you just set the
field to what you want.

In other cases where you actually want and need to test that the annotations
works at runtime you use a test container (Arquillian was the big thing for
integration testing JavaEE last time it was relevant to me, and since we are
talking enterprise Java there's a fair chance that Arquillian will still work
and maybe even still be the most popular solution.)

------
Yessing
The thing I hate about java the most is:

-that generics don't play well with primitives and arrays?

I understand that jep218 aims to fix the first one. But it's been quite a few
years now and why was this not done the right way from the start?

> equals() and ==

I think these should've been switched.

A general principle in languages (not only in programming languages) is that
things that are used often should be short.

Plus

\- get() and charAt(), instead of [].

just why?

\- verbose naming conventions:

Excessive redundancy does not increase safety or improve maintainability.
Having one blinking red light is useful, having a thousand lights of different
importance will just make you filter it out. People will simply gloss over and
skip long identifiers.

we are humans and we can't operate at full attention the whole time. if
something has low information content, we simply go on autopilot.

Easy things should be short, so that the hard things popout in the code.

\- Obsession with software engineering and OOP Principles?

Instead of thinking about the data structures needed and the alogirthms
chosen, time is spent just making a millefeuille of abstractions.

~~~
jayd16
Java not having operator overloads as a design choice explains the majority of
your complaints.

Generics are built around type erasure and as such generics treat the type as
Object at runtime. Primitives cannot be treated this way. The reason its not a
simple fix is because the language designers are not willing to break
compatibility to make this happen.

The style complaints are an artifact of Java being a popular corporate
language but there's no reason you need to write Java this way.

------
UglyToad
I'd imagine people criticise Java for the same reason they criticise PHP, or
C++, or many other languages. It's very easy to attack a strawman based on
outdated best practices from more than a decade ago ignoring the fact that
both the language and the best practices have moved on and many people are
very productive in those languages.

When I started learning C#, less than a decade ago, best practices were "Uncle
Bob" style nonsense, ultra-fragmentation of the codebase, interface
everything, boilerplate everywhere, pointless mocking and testing of
components which should have been treated as purely internal. But you look at
what changed in C# -- generics, dynamic, LINQ, async, auto properties, etc. --
in the last few versions and it's a brilliant language that can be written as
verbose or as golfed as you please (I lean now towards verbosity and loops
over LINQ just because while I think LINQ makes you feel clever it's also
harder to reason about).

Now I don't do Java other than porting a Java codebase to C# but I'm under the
impression Java has been on a similar journey with streams and whatever else.
Much like PHP or C++, workhorse languages that aren't 'sexy' but are widely
used and keep the internet and society running.

Different people like different things and that's ok (but assuming this new
language from the advertorial doesn't support autocomplete, easy refactoring,
whatever else it's going to be a hard sell to get productive teams to switch
over to it!).

------
charleslmunger
Lots of the boilerplate they create is totally unnecessary; other boilerplate
can be avoided through use of common open source libraries, like AutoValue [1]
for equals/hashcode/toString. No need for custom compilers, new ASTs, or a
whole new language. Don't create interfaces for classes that only have one
implementation, and don't create gratuitous indirection.

[1]
[https://github.com/google/auto/tree/master/value](https://github.com/google/auto/tree/master/value)

------
jillesvangurp
Convert your code to Kotlin (idea will do this for you). It won't get rid of
the boilerplate automatically but it will de-clutter your code and then put
you in a position to refactor to be more idiomatic Kotlin. Once you get that
sorted, you can start thinking about creating a DSL for things you do a lot
and get smart about eliminating boilerplate. IMHO javascript/typescript looks
more boiler plate heavy these days than well written Kotlin.

I know bashing java for boilerplate and verbosity is popular but a lot of its
reputation is people doing repetitive stuff without reflecting on better ways
to do these things. I see the same patterns and mistakes in other languages.
The best code is the code you don't need to write.

Likewise needless abstractions and over-engineering are a problem in many
places. Java certainly has seen its fair share of that and its a reason I
avoid the entirety of the Scala ecosystem in principle. Nothing wrong with the
language but it seems to provoke over-engineering.

------
mcguire
" _Using UnitilyLang we could replace the previous five code sections (3006
characters plus the hidden ConfigProvider and DynamoItemReader classes we get
for free in UnitilyLang) with (248 characters)._ "

Let me emphasize that, there: "classes we get for free".

" _UnitilyLang is designed around abstraction, immutability and composition.
It 's language agnostic, that is until we have to write logic._"

Well, language agnostic, but apparently not domain agnostic or framework
agnostic.

Then, there's

    
    
        workflow DynamoDbUserStore
        = 4 . (3 (2 1))
    

Pointfree _and_ nameless. Anyone have any idea what it does? Does the
subsequent picture help? Anyone think you could modify what it does without a
lot of unpacking? I'll leave it to someone else to figure out what's going on
with the "UnitilyLang complete project".

Is Java verbose? Yes. Is it possible to be less verbose, especially if you
invisibly provide domain knowledge "for free"? Yep. Is it possible to be too
succinct?

~~~
tom_mellior
> Pointfree and nameless. Anyone have any idea what it does? Does the
> subsequent picture help? Anyone think you could modify what it does without
> a lot of unpacking?

I don't understand why this isn't the only (or at least the highest rated)
comment in this discussion. There really is nothing more to say about this
article. "4\. (3 (2 1))" is not a program. "We apply the second dependency to
the result of the first. We then Partially apply the 3rd dependency and
compose the resulting function with the 4th dependency." is not an explanation
-- what _is_ the "3rd dependency"? Dropping names to somehow implicitly number
something does save keystrokes, but it doesn't make for "good code" (the claim
from the article's title).

------
Barrin92
People in the thread have given a few different reasons why Java is verbose
but in my opinion, it's not so much the language specifics or the culture but
the combination of static typing together with the inheritance and class-
focussed design.

A lot of the terseness of other languages is the result of dynamism (Ruby,
Python) and so on which basically gives you two thirds of the infamous
patterns that people complain about more or less for free, and for other
static languages that are predominantly functional a lot of the boilerplate
simply does not exist because the primary unit of computation is the function
and that spares you a hell of a lot of complication.

It's the C++/Java class of languages that all suffer from the same verbosity
and complexity and I don't think it's because the particular languages do
anything wrong specifically but that the combination of paradigms simply leads
to large, complicated structures.

~~~
boterock
I've always felt that having "private" fields by default (thereby suggesing it
is the right way to code), making all code live inside classes, and thinking
everything as an object, are dogmatic assumptions that make you write a lot of
boilerplate as you move forward (getters/setters, constructors, etc...)

If you could write your functions out of any class, you get 3 lines an an
indent level less, which I think reduces the cognitive load. you could change
your private fields to be by convention instead of forced just by prefixing
m_varName or whatever...

I dislike java because I feel the language somehow doesn't trust the developer
to know well the system he is coding. It is like handing a blunt knife to a
chef expecting he doesn't know how to handle it, making his work annoying, but
if he has to work for more time, he can bill more hours right?

------
bonyt
A lovely ridiculous parody of "Enterprise" style Java:
[https://www.github.com/EnterpriseQualityCoding/FizzBuzzEnter...](https://www.github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition)

------
datalist
Thats not Java. These are the wet dreams of some CS graduates who fell in love
with Spring and Hibernate and take rough OOP guidelines to extremes.

Nobody - NOBODY! - used to write such Java code in the 2000s, at least the
early ones. This insanity slowly started around 2005 and then really took off
late 2000s and then particularly 2010s.

Again, thats not Java.

~~~
eitland
And in the late 2010s JavaEE broke through and things are now really really
nice if you are working on a modern Java project where people know what thwy
are doing.

------
lostmsu
90% of this post is BS. They spend most of the characters on overriding
toString, equals, and hashCode to never use them.

------
username90
Most code shown here should be refactored from classes to a java functional
style with closure capture instead of members. Then almost all the boilerplate
disappears, the result is cleaner, easier to work with and the intent of every
object is straightforward.

Edit: Example rewrite of UsernameLetterCountPublisher as a function since I
realized a lot of people here might not be familiar with Java:

    
    
      public static Supplier UsernameLetterCountPublisher(
            final Supplier<Config> configProvider,
            final Function<String, Config> userIdProvider,
            final Function<User, String> userProvider,
            final Function<String, User> userMessageCreator,
            final Consumer<String> publisher) {
        return () -> {
          final Config config = configProvider.apply();
          final String id = userIdProvider.apply(config);
          final User user = userProvider.apply(id);
          final String message = userMessageCreator.apply(user);
          publisher.apply(message);
          // I didn't bother create a new interface for this so reused supplier.
          return null;
        };
      }

------
m0ck
The title should be tagged with [AD]

~~~
sigy
Agreed. Their site looks like an ad masquerading as a tech blog.

------
DrScientist
Yes - Java spells it out.

ie A lot of the 'boiler plate' is stuff that allows the compiler to check for
errors, and humans understand the code but at the same time allows you to vary
behavior if you want.

Java also has language simplicity and consistency [1] ( few syntax short cuts
) - which helps humans understand code - the coding equivalent of 'plain
english'.

Whether you see that as a good thing or not depends on whether you are writing
self contained scripts or large long lived complex systems.

[1] the later bolted on generics, not so much.

------
Nursie
I find this disingenuous from the outset.

No, the class name is not boilerplate. No, using parentheses rather than
whitespace to indicate scope is not really cutting out boilerplate.

No, defining custom hashcode, equals and toString methods is not boilerplate
or even always necessary, that's something you've chosen to do.

Much of the complaint about things like constructors and getters/setters can
be resolved using something like lombok.

Honestly this looks like someone really labouring the truth in order to try to
prove a point.

------
tombert
This is something I've been saying for years now; it honestly feels that
sometimes the mantra of the language is "why write code when you can just make
files?".

I feel like Java makes you _feel_ like you're accomplishing a lot, but in
reality if half your code is generated by an IDE, and is impossible to
understand without the help of a bunch of expensive tools, I do have to wonder
how good it actually is. I'm not sure I've ever seem a Java project where I
didn't shortly after think "this probably would have been better with Clojure
or something".

I know a lot of really smart people who absolutely love Java, so I'll admit
that it's possible that I don't know what I'm talking about, but I'd like to
think I'm reasonably competent at this coding thing now, and Java is routinely
the worst part of my day at my current job.

To make it clear, I'm _not_ knocking the JVM. That's a pretty cool piece of
tech, and enables awesome stuff like Clojure and Eta.

~~~
Nursie
>> I'll admit that it's possible that I don't know what I'm talking about,

I think a lot of people here, and probably out there in the world, have missed
the direction java has taken in the last 5 years or so.

I'm not saying it's definite that you don't know what you're talking about,
just that perhaps the changes to more functional styles, lambdas, function
passing, stream processing etc might have passed you by. It's a much more
expressive language now.

Or it might not, you may be bang up to date and still hold that opinion :)

~~~
tombert
I actually do use the modern features introduced by Java 8, like Lambdas and
Optionals and streams and whatnot, and while I definitely agree that they're a
step in the right direction, I think most of my points still stand.

The Optionals are definitely useful, but they're a far-cry from something like
Scala's algebraic data types. The streams are cool, but compared to virtually
any of the list-processing libraries for virtually any other JVM language,
they're fairly primitive.

Being able to pass functions around is great, but the lambda syntax is pretty
messy in Java IMO (the weird dichotomy between Function and Supplier still
confuses me occasionally). Not to mention that generics in Java are still
really weird and confusing...the dichotomy between the primitives and boxed
types is strange, at least in regards to generics.

And even with all the improvements, we still have issues like the expression
problem without much of a solution; the fact that I can't add to existing
types or have something akin to a multimethod means that there ends up being a
ton of wrapper classes and "extending but adding one method" classes all over
the place, adding to the noise of files.

If I have any choice in the matter, since my team is a JVM shop (at least on
the server), I typically choose Clojure. With Clojure I get _much_ more
concise and clear code, thread safety by default, an extremely fast and
interactive development process, hot code reloading, and access to literally
every Java library. I will admit that occasionally I would prefer to have a
good type system (which Clojure _sorely_ lacks...typed clojure isn't great
IMO), but nine times out of ten, I am pretty happy with Clojure overall.

TL;DR: I should make it clear, and I realize that I didn't in my previous
post, Java (the language) _has_ improved; I definitely won't deny that. It's
just not improved fast enough to address all my complaints. The language is
still incredibly wordy and noisy, even with the improvements.

------
enitihas
The examples given are full of intentionally created boilerplate. Anyone
writing such production code in java has no java experience for sure.

For example, the aws sdk for dynamo db contains DynamoDBMapper, which will
convert dynamoDBItem to your desired class, so the entire DynamoDbUserProvider
is totally unnecessary. It would simply be "dynamoDbMapper.load(key). This
also removed the need for Config and DynamoDBTable classes.

Also, the entire boilerplate of toString hashCode equals can be easily avoided
by using Lombok. I am sure some people will consider Lombok a hacky tool, but
I don't know of practical issues with it. It integrates well with IntelliJ and
Eclipse, and I think most java build tools.

Granted, with python you don't need a class to read from db, and can read into
a dictionary, but you also won't get the niceities like auto completion if you
do that, and will be much more vulnerable to typos.

------
lexpar
This may have a kernel of truth to it, but it's difficult to treat as
objective when the article is essentially an advertisement for the language
the author is developing.

------
whack
A lot of the boilerplate mentioned would disappear if you used a framework
like lombok or autovalue. I personally prefer simple verbosity over having to
learn the automagic intricacies of multiple different frameworks, but to each
their own.

The "90% boilerplate" in the title is highly misleading though. If you build
an application that contains no business logic at all, then by definition,
you're left with nothing but boilerplate. Especially if you insist on
formalities like creating interfaces with only a single implementation.

In real projects that I've worked on, the vast majority of the code is
application specific logic, with heavy use of external libraries to get rid of
any generic logic. The Java boilerplate makes up a small portion of the
overall code base, and has certainly never been a deal breaker.

------
humbleMouse
So tired of stupid articles like this hating on java. Java is an extremely
flexible language with an insane amount of libraries, frameworks, and design
patterns. Furthermore, using groovy is amazing, and can reduce your lines of
code quite a bit. The author of this article just sucks at implementing java.

~~~
mrkeen
Someone criticises Java for being verbose, and you want to refute that with:

> using groovy is amazing, and can reduce your lines of code quite a bit

?

~~~
humbleMouse
You just cherry picked one part of my rebuttal. Again, java is an extremely
flexible language, and the verboseness is up to the user. You can implement
very verbose code in plain java, or you can write extremely concise code in
plain java. It’s up to the user.

------
chvid
I do a bit of work in Angular (2+) at the moment.

And that involves a lot of boilerplate code; in fact so much that the
framework comes with a tool (ng generate) that generates the code for you. A
single component is split in 4 files and needs to be explicitly wired up in
another file (the module). An empty test case is more than 20 lines of code.

The point is. This is not really due to the language.

Angular is written in JavaScript which under other circumstances can be a very
condensed language.

It is not really the language that mandates verboseness and boilerplate but
the conventions, style, framework and so on.

Java can be low on boilerplating and a lot more condensed; though one has to
look outside the big mainstream frameworks for that.

------
datalist
Nothing against Kotlin, but please spare us the Kotlin hype. Groovy was
streamlining Java long before Kotlin even had a name.

------
mumblemumble
So, this catches me in the midst of an effort to try and migrate away from
Java (albeit to another JVM language) because I'm sick of the amount of effort
it takes to maintain Java code.

But, all the same, I want to play devil's advocate and argue that a lot of
this mess is really about Java-the-culture moreso than Java the language.

You can use `public final` fields instead of private fields with getters but
no setter. You can use public fields instead fo a private field plus a getter
and setter, too. It'll save a lot of boilerplate, and, if you're doing it
right, be functionally equivalent. The only things stopping you are cultural
factors. First and foremost, it's taboo. That's, frankly, the usual reason.
Second, some libraries that rely on reflection aren't equipped to handle
fields. Not because they can't, but because the getter/setter pattern is so
culturally entrenched that not following it is almost unthinkable. Finally,
and this is the prototypical reason that motivated this idea in the first
place, because, 20-odd years ago, some very clever people decided that it
should be very easy to do Truly Obnoxious and Anti-Social Things like
replacing a simple field access with a database round trip or some spooky-
action-at-a-distance state mutation without having to tell any of your
colleagues what you'd done.

To an approximation, a big motivation for the functional backlash against OOP
is the realization that maybe we shouldn't be so quick to enable ourselves to
do Truly Obnoxious and Anti-Social Things. Maybe it's even desirable that we
_not_ do that. Of course, politeness mandates that we couch that observation
in gentler language using terms like "referential transparency."

This maybe speaks to another aspect of Java's culture: Perhaps due to its
corporate roots, Java developers tend to rely strongly on thought leaders for
advice. Regular book authors, conference speakers, bloggers, etc. are the
arbiters of best practices. The more books, lectures, and blog posts one
delivers, the more name recognition one has, the more trusted ones opinions
become. In the limit case, you spend all your time telling people how to
maintain code, and no time actually maintaining code.

Strip all that mental noise away, and, while it doesn't turn Java into my
favorite programming language, it at least gets easier to see how Java doesn't
_have_ to be any more of a boilerplate-ridden mess than any other language of
its generation.

Just don't try actually writing clean Java code at work. That's a path that
can only lead to unemployment.

------
SatvikBeri
I have a hard time filtering things out, and prefer text that errs on the side
of being too concise where I can look things up if needed – e.g. Math
textbooks or papers.

A lot of people are the opposite – they have an easy time filtering and
skimming, and prefer all the details to be there on one page.

I think this plays a pretty big role in language choices – I find codebases in
more concise languages much easier to parse & work with, but others say the
same about Java/C#/etc.

------
wrd83
So a lot of the complaints are not entirely true anymore.

If you onboard lombok, you get data classes, which resolves the property
boilerplate. If you use IntelliJ the code is generated.

I used Java and Go and I have to admit, that Java feels like the more
practical language.

Generics and error-handling are really painful in Go.

The most painful part in Java is having to deal with other people's code that
makes it look weird. Google has a very good set of libraries that make the
Java world much more pleasant.

------
ka0lin
I only flew over the comments but I miss references from the past like
Software through Pictures (STP, from former Aonix, riding the wave of CASE-
tools) or the even older block oriented software. The latter thought of
objects forming blocks that offer or consume interface and join each other
through matching like LEGO.

Even big companies like Rational tried their best to generate boiler plate
code from UML diagrams. Also BPMN incorporated findings from the early days.

But after nearly 30 years of programming experience I know one thing for sure:
when it comes to real use cases beyond counting letters in a string only
dedicated generators or very limited general ones continue to work. If it were
the other way around there'd be product turning natural language directly into
at least a single formal one.

And every (Java-) programmer who still repeatedly writes down lines of code
doing the same boring input-processing-output did miss at least aspect
orientation, Java agents and this is the most powerful of all: ANTLR. Runs
right away with your BNF-grammar from Maven or a plain JDK. But be warned,
this is like any other complex craftmanship, you need to start with cleaning
the workshop before you can operate the heavy machinery.

------
DaveSchmindel
In my opinion, this is the reason Java still _mostly_ remains the enterprise
choice; When things are mostly boilerplate under the hood and following a
small set of patterns and principles, it's really easy to onboard/ditch
engineers.

That said, I like the motif brought up here, and I think the only thing
lacking from the piece is how this stifles developers' engageability and
creativity.

------
winstonewert
"Good code is 90% boilerplate"

Have you considered that you might be doing it wrong?

------
on_and_off
It feels like beating a dead horse. There are other options on the JVM like
kotlin that are pretty much boilerplate free.

I will say this for java though : it has what is in my experience the best IDE
support. Kotlin is not that bad but all these generated sugar (e.g. in a data
class) make some operations like "find usages" way more complex and slower.

------
vkaku
You're free to use many different languages with Java, like the new GraalVM
release does.

Of course, Java needs some radical improvements, but people are doing that,
and I can't wait for the day where these complaints will stop.

Verbosity is a personal choice too, and some people would prefer explicit
configuration over convention, and that is a choice too.

------
SmooL
Java hate aside, I love the idea of pictorial format for specifying data flow.

Haskell is wonderful in its partial application, '.' composing, and other such
tools, that really let you quickly and easily specify how your data flows
through your functions. My gripe is that it starts getting weird when the
order of arguments don't line up, when you have to swap some values, when you
have to take a partial result and only apply it 3 steps later.. the Haskell
syntax really breaks down from its usual purity in those cases. A flow diagram
picture, similar to as shown in the article, makes it immediately obvious what
is happening. I wish there was more integration with current IDE's for this
sort of different representation styles

------
rowland_street
I wrote this article, I'd just like to clear up my intent.

Firstly the Java patterns. Obviously it's not really necessary to use them for
my toy example, but I don't want to write a blog about a full scale enterprise
app. I have seen multiple tech teams at different companies evolve separately
towards using similar patterns in both Java and C#. Doing so solves problems
in concurrency and maintainability (This is documented in the other blogs on
the Unitily site
[https://www.unitily.com/learning.html](https://www.unitily.com/learning.html)).
I've seen teams be very successful using them. I like Java. Im not criticising
it, I'm trying to explain why people do.

UnitilyLang doesn't exist, I'm not writing that language, the examples in that
article are the only code snippets I've ever written (and probably ever will).
The point is that there is a one to one mapping between that representation
and the java code using the described patterns. This highlights the extra code
you have to write in Java (and similar languages) just to support the clean
code patterns.

Sure if you used Kotlin or Closure (or any functional language) it becomes
less of an issue, and this is exactly the point I'm trying to make. However,
its rare you have the option to choose a language, so developers end up coding
in Java and complaining about it.

I don't like the new title the moderators have created, (perhaps the my
initial one was a bit click baity) but generating code is only mentioned once
in the last paragraph. The point of this article is to highlight that once you
follow a set of coding principles which solve specific problems you are going
to have to write extra code to do so. Perhaps something like

Writing clean code in Java requires boilerplate, learn to love it.

would have been a better title.

The video demo at the bottom of the article generates the code from pictures
not UnitilyLang. These pictures are tightly coupled to the specific coding
patterns, but is (in my opinion) a more natural definition than both Java and
UnitilyLang.

~~~
purple_ducks
> I have seen multiple tech teams at different companies evolve separately
> towards using similar patterns in both Java and C#

Could you give us some background on your professional experience? There is no
"About" section on the site.

~~~
rowland_street
I've been a professional developer for 10 years at several mid size companies.
I've led teams for a large proportion of that time. Not claiming to know
everything, still learning. I'm just writing up my thoughts at this time, they
do change (they often cycle).

------
raldu
The infamous "FizzBuzzEnterpriseEdition" relevant to the topic,

[https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...](https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition)

------
another-dave
Java has it's problems, but I think they're mostly on the implementation side
(e.g. lipservice to OOP while having a load of AbstractFooHelperFactories or
leaking all your inner workings through Getters and doing "Ask, Don't Tell"
rather than vice versa) but I don't get why people rail against the
"boilerplate" so much.

It's just signposting, you can learn to look past it so soon it makes no
difference.

I play music and don't need the treble clef on the stave to tell me what notes
to play — you could call that boilerplate and get rid of it, but I don't think
it would make it easier to play or read

------
dclusin
A lot of boilerplate can be reduced by using Project Lombok _. It obviates the
need for a lot of this boilerplate. You can annotate a field with @Getter
/Setter attribute and it will automatically generate getters and setters for
you. You can also do @RequiredArgsConstructor, @Data class etc. I tried Lombok
but didn't end up continuing to use it. An IDE like Intellij makes working
with java painless enough to where Lombok didn't feel like this life changing
solution.

_ \- [https://projectlombok.org/](https://projectlombok.org/)

------
Glyptodon
> workflow DynamoDbUserStore > = 4 . (3 (2 1))

> workflow UsernameLetterCountPublisher > = 5 (4 (3 (2 1)))

The workflow notation seems a little rough for readability even though its
functional meaning fairly clear as you pretty much have to read a specific
invocation of a workflow in context to confirm what's happening since the
functions in a workflow could be anything and the workflow declaration is so
generic.

On the other hand, when you see the named picture versions it's very clear.
And I can't think of anything to address my minor criticism doesn't just make
the notation worse.

------
olavgg
A lot of the boilerplate can be removed by using Lombok
[https://projectlombok.org/](https://projectlombok.org/)

Another alternative is Groovy

------
vbezhenar
The only Java boilerplate that really bothers me is getters/setters. Lack of
properties in Java is depressing. And even more depressing lack of any plans
to add properties. There are records for Java 14 which somewhat solve the
issue, but they really aimed for a bit different use-case (which is not even
that important for me, personally).

Honestly the only reason I would choose Kotlin over Java today is properties.
Everything else is nice to have, but absolutely not important.

~~~
wtetzner
> Everything else is nice to have, but absolutely not important.

I would argue the null-checking is important.

~~~
vbezhenar
Those who need null-checking can use @Nullable @NonNull annotations with
static checkers. I've found Idea pretty good and it'll work very similar to
Kotlin. Some popular libraries already annotated their interfaces.

~~~
wtetzner
The static checkers I found that can check those annotations are very slow.

Also, it's not well-integrated into the type system. Sure, you can get by with
them, but it's certainly not ideal. It also requires someone to do work to set
it up, instead of it just being the default.

------
mnm1
What OOP language doesn't suffer from this? Sure Java is infamous for it but
C++, JS, PHP, Ruby, Python, etc. all suffer the same issue. The percentage
might be a little less, but the amount of boilerplate is staggering in most
modern OOP languages. When compared to something like Clojure, it's
unbelievable. You can write entire apps in Clojure in the space that most
other languages just deal with boilerplate.

------
martincmartin
I've always wanted an IDE that would transform Java into a higher level
language by "collapsing" the boiler plate. Just like we can collapse comments,
I'd like to "collapse types" if I already know the types and just want to look
at the logic. Or "collapse exception handling" if my current task involves
changing the happy path and the exception stuff is just clutter.

~~~
martincmartin
For example, what if an IDE could read Java, but display it in a form that
looks a lot like Kotlin? (Or Groovy, or your favourite high level language.)
The file would still be Java underneath, so you don't need to convince your
colleagues to adpot Kotlin. You can be in a happy Kotlin-esq world while
working with their Java code, and they don't need to know or care.

~~~
eitland
That is actually a good idea.

One idea to get it actually usable: by default it shouldn't update any code
you don't touch. (Some systems will load the file into a memory structure and
then save it back ignoring the existing formatting, thereby making commit logs
much harder to reas if you need to.)

------
jariel
Java has zillions of 'not very good' or 'not empowered' developers writing in
it, and the perceived safety of frameworks is valued over the ability for devs
to actually write decent code.

Especially in orgs for which the code/tech is a secondary issue, only seen as
a risk, they'd rather higher 5 more low-cost people to deal with the framework
cruft than just hire the right people for the job.

------
29athrowaway
The toString method does not use a StringBuilder.

Each concatenation will create a new string. That is not good.

If you find Java verbose, just use Scala or Kotlin.

~~~
miskin
Using StringBuffer may be premature optimization. Java compiler will replace
simple String concatenation with StringBuffer automatically [1] and you do not
need to polute your code with StringBuffer unless you really find that to be
performance bottleneck.

[1]
[https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.htm...](https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.18.1)

------
Kiro
> a program that queries a database, gets a specific user by ID, and prints
> the number of letters in that user's name to the console

I'm not a Java programmer but why would you actually need all the boilerplate
for this? I'm under the impression that this should be doable in any language
with just two lines of code: fetch and print.

~~~
Nursie
Yeah, they don't need all that, this whole article is basically nonsense, and
puts in a lot of completely unnecessary stuff.

------
chopin
I personally like the explicitness of the language even if it is boiler plate
(with some exceptions like checked exceptions in lambdas). It makes average
code very readable with only little caveats. More than one time I struggled
with my own code at a later point in time because I wanted to avoid
duplication at any cost.

------
TomVDB
Has anybody managed to figure out the license and/or the cost of the software
that they're promoting?

The website has a front page, an applications page with 1 example, and a read
the article page with a numerated bullet point list (which turn out to be
hyperlinks, but I only accidentally noticed that when mousing over the text.)

That's it.

------
he0001
I loathe the fact that you need to invent a new class Just for passing some
data along or piggyback on strings whenever you do a .map(). Maybe records are
going to ease that pain. But why can we just have the compiler be able to
construct a container to pass along some data to the next step in the stream?

------
manishsharan
We,enterprise java dev shops, don't mind because 90% of all enterprise
applications are bloody CRUD apps.

~~~
DaveSchmindel
Absolutely important to bring up. I don't care how creative you allow your
developers to be while they leverage Ruby/Python/etc.; At the end of the day,
they're accessing data from a DB and serving it to a client...

------
yarrel
I started programming Java in 1996. It really is a static boilerplate
language.

I'm wary of going too far in the direction of functional notation for the same
use case though. Replacing code that is slow to read with code that is slow to
expand in-head may not be the win people expect it to be.

------
sna1l
Looking at the youtube video of actually using Unitily, it seems way more
complicated to me of having to learn how to use this UI interface. Personally
I think with tools like Project Lombok, auto/value, and IDE tools, you can
streamline boilerplate code fairly well.

------
agsilvio
Surprised I'm not reading many comments about Lombok. We use this with great
success and predictability and it removes so much boilerplate. More
importantly, it focuses on the boilerplate that is truly boring. The projects
look great add a result.

------
neonate
I'm surprised no one has mentioned that this is an ad for a visual code-
generating tool.

------
hpoe
Just figured this article (or copy of an article originally posted by Joel on
Software Engineering) fit in this discussion.
[https://pastebin.com/VJUNqsU3](https://pastebin.com/VJUNqsU3)

------
The_rationalist
Kotlin solve everything about it.

~~~
datalist
Groovy did so long before that ;)

~~~
humbleMouse
Blows my mind how rare it is for anyone to mention groovy on hackernews.
Groovy is amazing and turns java into a wild west language where anything is
possible.

------
pron
See records, coming to Java next year:
[https://openjdk.java.net/jeps/359](https://openjdk.java.net/jeps/359)

------
Roboprog
I wanted to like this, but I struggled with the "s-expression with numeric
atoms" dependency injection notation.

How do I map the numbers back to their sources?

------
jerojasro
I could not find any link to github/download/trials... any ideas of how can I
try this language? or is this just vaporware?

------
co_dh
Psql select count(email) from table where name = "foo"

What the hell happened to the world.

------
greenie_beans
i hardly know java, but have to do something with the legacy system at work.
does anybody have any good, canonical resources for learning java? canonical,
like the pickaxe book for ruby

~~~
eitland
Effective Java is the one I see recommended most often.

I also wanted to add something I answered on a similar question in another
less public forum a few days ago, but it turns out to be in another (human)
language so I'll just add a summary:

> 1\. Java IDEs are way more sophisticated than anything else except Visual
> Studio with ReSharper. Learn one of them. I disliked Java strongly until
> someone used a couple of minutes here and there to show me navigation and
> editing. (Hint for people who come from editors: Java IDEs understand the
> difference between the same letters i.e. word in different context. If you
> rename a variable in one method it won't touch other things that contains
> the same characters elsewhere in the file.)

2\. Learn Maven and/or Gradle. You know you've got it right when everything
works as expected and there's next to nothing left.

3\. Don't trust everyone: people in this thread mention consultant Java. I was
exposed to it early and it only took a few months to realize that certain
(well paid I assume) consultants knew less than me: adding log statements and
rebooting application servers every time they debugged (the correct way is of
course to set a breakpoint and single step.) I also cleaned up a lot of their
code, including a 6000 lines of XML implementation of a crude authorization
framework that they had made because they didn't get Facelets.

~~~
greenie_beans
thank you!

------
iopeak
How do I get in touch with the author of Unitily? cc @rowland_street

~~~
rowland_street
This twitter account will find its way through to me
[https://twitter.com/LLambdas](https://twitter.com/LLambdas)

------
znep
TL;DR - "Here is a lot of boilerplate code that doesn't seem necessary for
what you are doing in this case..."

...

"Hey look another tool that can generate a lot of boilerplate code you then
have to deal with and makes the easy stuff easier and the hard stuff almost
impossible!"

------
fredgrott
no, its because concurrency is hard and most programmers fail at it...

------
platz
That's RAD

------
madhadron
If I understand correctly, the author has written a program in their pet
language, translated it directly to Java, and complains that you have to write
a lot of boilerplate to do 1:1 translation from their language to Java.

I think the right consideration is that they have simply done a poor job
writing this program.

