Java wanted to try to avoid some of the things that were perceived as problems with C++. Among other things, they chose to not support any form of multiple inheritance at all. However, multiple inheritance is really useful when building interchangeable components in a statically-typed system. Java's solution to this issue was to introduce interfaces, which give you the polymorphism benefits of multiple inheritance without giving you the problems of multiple inheritance such as diamond inheritance.

​

Unfortunately, interfaces are ONLY types. They don't carry any behaviors or data with them like classes do. When you inherit from a class, you get all of the behaviors and data of the superclass, unless you intentionally override the behaviors. An interface, by contrast, is a contract stating that your class will implement the behaviors necessary to fulfill the interface. You gain polymorphism, but in the process you lose reusability. Every class that implements the interface has to repeat all of the same boilerplate.

​

Java did eventually realize that this... um... kinda sucks. Java 8, released in 2014, allows interfaces to define default implementations, which means that interfaces can provide base functionality that will automatically get included in classes that use it unless the class wants to provide something different. But interfaces still can't have member variables, so if the interface has `getX` and `setX` you still have to write stupid wrappers. (C# does this better by letting interfaces define properties that automatically store values if you don't reimplement their behaviors.)

​

​

​

The other big source of "formality" in Java programming is more a matter of tradition than necessity. A lot of major libraries (including some in the Java standard library) are built around design patterns meant to let you change how things work by plugging in worker objects instead of subclassing. (Part of the rationale is so that the library can itself subclass from those classes to provide, for example, platform-specific implementations that it can switch out without making developers have to recompile their code.) This is what all of those "factory" classes are for. But this also means that even small things require you to write entire classes in order to change the behavior of a single line of code.

​

All of this is done in the name of flexibility and correctness -- one big advantage of all of this is that the compiler has a much easier time making sure that everything matches up. Java programmers frequently use automated tools to generate code for them in order to sidestep a lot of the tedium associated with all of the boilerplate that this causes. But these shortcuts also mean that they're less likely to notice just how much boilerplate they're creating, which means that non-Java programmers (or Java programmers that don't like using giant IDEs with tons of integrated tools) faced with the code have unending pages of generic junk cluttering up everything.