
Java Developers - nsainsbury
http://nsainsbury.svbtle.com/java-developers
======
mobiuscog
I agree with much of the article (also as being a java developer for the last
17 years).

However, I don't think the problem ie necessarily Java Developers - I think
they were just early adopters of the larger problem:

Frameworks.

Too much software these days relies on frameworks in order to 'get things
done'. The knock on effect is that developers don't have to think as much
about how things work (technical debt is at an all time high), and often code
following 'best practices' handed down from academia/conferences/books that
promote large abstractions which are often un-necessary.

It's similar to how C code would end up having pointers-to-pointers-to-
pointers-to-pointers...

A whole generation (generalising/stereotyping, I know) is now coding, who have
never grown up and learnt with basic logic gates and low-level code. The
framework is the obvious choice because 'why would you want to write it
yourself, if it exists' ?

(Ironically, many Javascript developers seem to be intent on re-inventing
everything that's gone before, and it's somehow seen as innovation - go
figure)

Grumpy old man ? Sure, I am. I'm also gladdened to see a recent upsurge in
assembly language and other low-level coding, as this is what the world
actually needs - less super-business-entrepreneurial startups, and more people
able to actually solve _real_ problems and not just hipster entertainment.

~~~
cousin_it
Interesting! The most important difference between frameworks and libraries
seems to be the "don't call me, I'll call you" pattern. Frameworks call your
code, while libraries get called by your code.

It's easy to see why "don't call me, I'll call you" leads to unreadable code.
A piece of code is readable if you can understand how it works, not just what
it does, and a big part of "how it works" is figuring out the control flow.
Inverted control flow makes code less readable, regardless of any other
benefits it might have.

Viewed in that light, it's hard to see how moving to better languages like
Haskell would solve the problem. Functional programmers pass functions around
all the time, so a lot of functional "libraries" are actually frameworks that
insist on calling your code in complicated ways, making it conform to very
precise types required by the framework. There's certainly no shortage of
abstraction in Haskell code. As a result, it seems that most Haskell
programmers don't even try to understand the control flow of their programs,
because it's almost impossible.

I wonder if we could have a principled approach to programming that
discourages the "don't call me, I'll call you" pattern, and encourages code
that you can simply read from top to bottom. Do this thing, then do that
thing, then do the other thing. It would probably be unlike anything that
exists in academia today.

~~~
seanmcdirmid
> "don't call me, I'll call you" pattern

Just call it the Hollywood Principle [1], and ya, it sucks. Databinding
frameworks like React go a long way in fixing this (and my own work [2] also).

[1]
[http://en.wikipedia.org/wiki/Hollywood_principle](http://en.wikipedia.org/wiki/Hollywood_principle)

[2]
[http://research.microsoft.com/pubs/211297/managedtime.pdf](http://research.microsoft.com/pubs/211297/managedtime.pdf)

~~~
cousin_it
I really like your work, but not sure that it lies on the right side of the
framework/library divide. For example, to realize the full benefits of your
approach, you define a new programming language with "no escape hatches".
That's the most extreme kind of framework thinking!

My favorite post about libraries and frameworks is this one:
[http://web.archive.org/web/20130810134741/http://an9.org/dev...](http://web.archive.org/web/20130810134741/http://an9.org/devdev/why_frameworks_suck)

> _Frameworks hurt sharing. I 'd really like to give you this fork Jimmy, but
> you're gonna need a knife and plate to use it. The framework checks out all
> your girlfriends for you, the framework won't let anyone dirty get through,
> the framework will wait up until you get in, the framework will always find
> out were you've been, the framework keeps you healthy and clean. Frameworks
> embrace, extend and hold on to greedily._

~~~
seanmcdirmid
We are not so much defining frameworks as we are new ways of computing. In
that sense, it's not really something that will be ready tomorrow (or ever). I
do use glitch as a library in C# for UI and compiler programming (hard to
program very interactive UI and compilers otherwise), but that is with lots of
escape hatches :)

~~~
cousin_it
Fair enough :-) Thanks for the pointers!

------
cromwellian
I think most of the problems are caused by enterprise, enterprise frameworks,
and the sheer age of Java. There's a lot of technical debt built up and a lot
of enterprisey frameworks that are way over engineered.

I use Java, but I tend to do low level stuff, stick to basic I/O, Guava, etc.

I think the article is right in one important aspect: the way Sun built Java
was to pretend as if everything should be a competitive market. So pluggable
drivers for everything. Rather than build in say, one XML parser, instead
let's build in a whole system to allow you to plug in any XML parser. As a
result, it takes 4 lines of code to do what should work in 1 line. On other
platforms, Python, Ruby, Go, et al, there is no such assumption that one needs
an abstract interface to allow multiple implementation providers. You have an
opinionated built-in implementation, or you use third party APIs.

This is why you have stuff like DocumentBuilderFactory/DocumentBuilder/etc.

When really, you want to write: Document doc = XML.parse(...)

Enterprise developers copied the basic design of having provider
lookup/locators. This is why we have AbstractFactoryLocatorServiceLocator
stuff.

Where I part company with the author is the total trashing of OO and the
language. There are certainly lots of warts and things to complain about, but
I haven't used a single language where I didn't have a boatload of things to
bitch about.

I think you fall in love and there's a honey moon period with most languages,
and then the beer goggles wear off after daily use and you see all the flaws.

~~~
josho
You are bang on.

It reminds me of the opposite take that we've seen in browsers as of late. Eg.
innovate with webkit specific extensions then standardize what works. Java
meanwhile standardized conceptually useful concepts (Swing, Java Server Faces,
etc), but the markets for pluggable Swing or JSF components never took off.

I think it's that under Sun's direction the intent was to create markets, e.g.
a market for GUI components or web components, a market for server components
(EJBs). At least in the case of server components, Sun made a lot of money by
licensing J2EE servers. I suppose that was their motivation all along for
forcing DocumentBuilderFactory's on developers.

------
seanmcdirmid
> The OO craze has a part to play in this madness as well. More and more
> developers are stepping back and realising that as a programming paradigm,
> OO is actually pretty shit.

Once real systems (like UI frameworks) are written with FP, we can compare
apples to apples. Until then...wtf? OO actually works well for scaling
complexity, much better than toy immutable functions do.

> Even today you’ll still find a strong bias towards OO courses being taught
> at the university level using Java, and the bias was certainly stronger 5 -
> 10 years ago.

Because that's what people use to write real programs.

> The engineers at Google working on Android are too busy architecting grand
> frameworks for solutions and not busy enough solving actual problems.

Because we all know, Google is known for hiring flakes who can't code or
design real systems.

Worse is better means getting things done even if your tools kind of suck or
your understanding of the problem isn't yet great. It leads to architecting
and less than ideal solutions, but at least you ship!

~~~
thaumaturgy
> _OO actually works well for scaling complexity, much better than toy
> immutable functions do._

Sure, but the problem is that OO is frequently applied where you don't need
scalability, and then OO becomes the complexity that needs to be scaled.

A low-hanging example of this is the singleton pattern, and the Wikipedia
section titled "Example of use with the Abstract Factory pattern" saves me
from having to bother making the point any further:
[http://en.wikipedia.org/wiki/Singleton_pattern#Example_of_us...](http://en.wikipedia.org/wiki/Singleton_pattern#Example_of_use_with_the_Abstract_Factory_pattern)

It is my fervent hope and wish that all programmers someday accept that there
is no universal methodology, that FP and imperative and OO all have their
place and their faults, and that it is OK to sometimes not use one of them
somewhere.

~~~
seanmcdirmid
If you get good at programming, you actually know when to apply these patterns
(and many others not in the GoF bible).

And of course, I mix OOP and FP styles all the time, I'm not a purist by any
means (a guy who does F# once commented on how FP my C# code looked).

~~~
robmccoll
> If you get good at programming...

This is a very important point (hopefully more "when" than "if"). I'm really
tired of seeing naive programmers throw the handful of design patterns they
know at every problem, not because the abstraction is a fit, but because their
toolbox simply doesn't have that many tools.

~~~
Chris_Newton
_I 'm really tired of seeing naive programmers throw the handful of design
patterns they know at every problem, not because the abstraction is a fit, but
because their toolbox simply doesn't have that many tools._

This is one of the biggest problems with Java — and other “pure OO”,
“everything is an object” languages of the same style — particularly from a
teaching perspective: when all you have is a class, every problem looks like
an object.

If we present a language like Java as being the default, standard, safe
option, how are new developers ever going to gain enough knowledge and
experience to realise that their elaborate design with seven different classes
in Java could have been replaced by a single 10-line function in Python, or a
few short lines of Prolog, or a single query in SQL?

------
skrebbel
A lot of these bloated patterns that got popular in the Java world have
shorter, simpler alternatives when programming in a functional style. You
often don't need multiple child classes to implement a template method if you
can just pass a function to the constructor. You don't need a BananaFactory if
you can just inject a createBanana function.

Remarkably many Gang of Four design patterns are unneeded once you can pass
functions around. The C# world is now learning this: when C# 1 and 2 were
popular, the ecosystem went right after Java in the kinds of boilerplate that
the author describes. Now, many years of Func and Action goodness later,
there's a large part of the community that codes way more to the point, and
this part is growing. People who release C# libraries in 2014 with factories
adapters and multiple layer inheritance hierarchies are laughed at.

Since Java 8, Java too has an accessible way to pass functions around. Not
really functions, because Java, but in practice it works the same way. This
means that there's nothing _technologically_ that's holding the Java community
from making these improvements, too.

I hope it happens.

~~~
icebraining
I don't think Android supports Java 8, though.

~~~
Alphasite_
I thought there was some work to support Lambdas in ART?

~~~
on_and_off
There is a retro-lambda library that allows to write lambda expressions. It is
compiled to jdk 6 compatible bytecode though.

------
philbarr
I've always found that the people who write the
AbstractFactoryFactorySomethingVisitor patterns are the people who read about
design patterns and want to use them for the sake of using them, because they
think it makes them better developers.

Instead they should learn about design _principles_ , and instead of thinking
"which pattern should I apply here", they should be thinking, "what is the
best way to create this code so that the basic design principles are upheld".
You can start with SOLID principles and go from there.

The same happens with language features; when generics were introduced,
everyone wanted a generic class for some reason when it's almost never needed
outside of the Collections framework (bit of a sweeping statement but I hope
you see what I mean).

In fairness, I don't think it's really Java's fault, only that it's been
around long enough for there to be many more examples of this kind of thing.
I've been working in Java for 15 years and C# as my day job for the last 3 -
you can easily pick out examples in C# where the langauge has been abused:
dreadful LINQ expressions where a simple for-loop would suffice (and be
quicker), or multiple Events added to a class, ALL of which need to be hooked
up by calling classes for it to be usable, so an Observer really would,
actually, have been a better solution.

I've played around with functional programming and there are a lot of claims
around how it forces programmers to write better code. I'm not sure how it's
going to stop programmers abusing language features or the language
characteristics, though. I may well be wrong about that and am happy to be put
right by a knowledgable FP dude.

------
thescrewdriver
I've been using Java for about 15 years and largely agree with the article.
The verbosity of the Java language is definitely part of the problem, although
that aspect is downplayed in his blog post. I agree with the author about the
culture. Java programmers in general seem to be on some sort of design pattern
frenzy, especially in the better known frameworks. It doesn't matter if you're
writing a fancy framework or writing a trivial app to process a file, chances
are you're going to see layer upon layer of over-engineering.

I switched to Scala a couple of years back and have never been happier. Only
part of the improvement is due to the language the other part is not having to
deal with Spring, builder patterns, and madness like
AbstractSingletonProxyFactoryBean [1]. My impression has been that the typical
Scala developer has had lots of Java exposure and has learned from their
experiences.

[1]
[http://docs.spring.io/spring/docs/2.5.x/api/org/springframew...](http://docs.spring.io/spring/docs/2.5.x/api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html)

------
nick_riviera
I disagree with this, as a part time Java developer (I do C# most of the
time). The points I disagree with:

1\. _OO is bad_. Every paradigm is bad if you misuse it. If you build deep
abstractions then you will hang yourself regardless. Some very elegant and
simple designs can emerge from OO code, but only if you think about the
problems first. The majority of pain consists of forgetting to do that step.
There is no magic bullet - FP has its own pitfalls as well as does simple
procedural programming.

2\. _Everything looks like it 's written by an architect_. Well that's a broad
generalisation and I'm sure some people titled architect would be sick at the
association (considering they usually reduce complexity) but the problem here
is that people aren't using the frameworks properly. Not joking but the last
two or three Java web applications I've put together have virtually no code in
them. It's just the domain model, the views and query encapsulations. Nothing
else. The abstract factory factory factory factory crap isn't your problem. If
you make it your problem, then you're just doing it wrong or not using the
tools provided efficiently.

3\. _Android_. Android is abysmal (I've written a couple of things for it so
far), but that's not because of Java but the fact that the Android API and
versioning mess is a pile of unstable crap. It'd be nice if there were't so
many exceptions.

If you're going to pick on Java, at least jump on: Idiotic code on the web,
Glassfish being a right pile, view technology being foul, servlet container
reloading, Swing/JavaFX or Eclipse...

~~~
signal11
Some of the complaints about the over-formal language is a matter of taste,
perhaps, but it does grate and is not a new complaint (see also: the Kingdom
of Nouns rant). However Java developers are learning (or migrating to
Scala/Groovy/Clojure). And there is hope -- the Play framework, for example,
is an example of Java done right (imho). Spring 4 is moving in the right
direction.

~~~
nick_riviera
I don't think it's a matter of taste. TBH I write very little of the code that
is checked in to the source control. The IDE does all the boilerplate. I
literally design the method signatures, define the access policy for the
methods and fill in a few gaps here and there.

Play is not Java done right by any means. It's tightly coupled, has really
poor documentation, breaking changes galore between major releases, deployment
is trouble (compared to tomcat) and rather tied to Scala's API.

Java done right is picking some lego bricks that you stick together to get
what you want and telling it how to wire them up.

YYMV but 99.9% of all problems are already solved off the shelf.

~~~
mike_hearn
Ninja Framework is rather nice, I've found. I looked around for Java web
frameworks lately and it seemed to be the one that balanced good
documentation, features, simple configuration and so on to my liking.

~~~
nick_riviera
Thanks - I will investigate this one.

------
arel
As the author said its not the languages fault. And if you know what you are
doing then Java is clean, mature, performant, dare I say it enjoyable platform
to use.

I think there also a generational conflict here. Java is a development
environment that was born in the big architecture and 'development as
enginerring' era of the late 90s. Spring was a reaction to the over engineered
J2EE and now even Spring, the early liberator is considered over engineered.

Its our dad's language.

There is still a certain mindset from that era that was conditioned by the GOF
and Universities and amaeteurs churning out developers but it is increasingly
rare.

In fact I find Java is amongst the most interally introspective and
disciplined in terms of coding taste and style.

I can almost guarantee if I look at another Java developers codebase that I
can follow their code structure and style without too much effort. I'm not
sure that would be the case for the large amount of very individualistic FP
code being generated currently.

------
larsmak
I've been a java developer for over 10 years (8 professionally). I've worked
as a consultant on large government projects, using legacy frameworks like
Struts/Tiles and being forced to use older versions of Java. I've worked for
tech-startups being able to use new and hot tech. like Cassandra, jdk8, and
the play-framework. And in between I've hacked on a ton of personal projects,
including tech like gwt, mongodb, android, etc. I've used lots of frameworks
like Spring and Hibernate. Although such frameworks often provides
abstractions and encourages usage of design patterns, I've never really found
my-self getting lost in their layers of abstraction, and I've can't really say
I've come across any "AbstractAdapterFactoryProviderBean"-either.

I've also never found my-self working with a code-base I'd considered clean
and highly maintainable. When code-bases becomes big and complex, they tend to
get messy. It's hard, if not impossible, to maintain a complete view of the
entire application at once - and this leads to different approaches at
different times, and places in the code. Having multiple developers come and
go, with various levels of skills, does not help either. Having some framework
dictate the overall structure of the application limits the potential for to
much diversity in the code, it also helps new developers get a grasp of the
codebase if they have used the framework, or similar frameworks, in the past.

When I design a simple application, the flow is limited, and I don't need the
abstractions - so I don't implement them. But when the system grows in
complexity, and the concepts and logic starts to overlap, it becomes
reasonable to implement abstractions. To layer the application into DAO,
service, persistence layer, etc. To group common logic, and make abstract
implementations. I could go on. Abstractions are good, but overuse is also not
good - of-course, like everything else it's about finding the right balance.

~~~
lnanek2
I can say the same re your experience, but I kind of experience the same thing
he links to with Gradle and really despise it. Handling the constant Groovy
errors and Gradle errors, and spending my life digging through their docs for
a language and a build system I couldn't care less about really depresses me
when I'm a Java expert. Give me a stack trace and I'll have the problem fixed
in five minutes with unit tests and UI automation tests done later that day.

But give me a gradle error and I'm stuck in their docs all day, you might have
a solution this week. And by the way it breaks automatically all the time as
Android Studio and the android tools plugins and all the rest version up. I
wish we could have just stuck with Ant and Eclipse for Android, which are
known evils. Instead every update of Studio and Gradle someone on the team has
to draw the short straw and try, then either give everyone else the OK or tell
them to stay the hell away from that version.

------
MrBuddyCasino
Java hits a sweet spot of simplicity, platform stability, safety and
performance. Also, its popularity in the enterprise is partly _because_
interchangeable, cog-in-the-machine low quality developers can be productive
in it and not cause too many meltdowns. Thats an economic advantage! If you
need lots of cheap developers for your IT department, good luck finding 15
Clojure and Haskell gurus.

I say that as a Java developer, btw.

~~~
dozzie
Simplicity -- none, if talking about the resulting code.

Stability -- none, regarding possible law suits from Oracle. Yes, it does
matter for a company. Yes, Oracle did that in the past.

Performance -- poor, regarding memory consumption.

Indeed, the sweet spot.

> If you need lots of cheap developers [...]

Shoddy, you mean. For Haskell or Clojure you have at least a guarantee that
the guys you found are decent. It's the same hard finding decent Java
programmers as it is with Haskell, except that Java scares good devs away and
Haskell attracts them.

~~~
matthewmacleod
_Simplicity -- none, if talking about the resulting code._

Bollocks. Java code can be over-complex and lack elegance, but it's not the
worst offender - sweet spot.

 _Stability -- none, regarding possible law suits from Oracle. Yes, it does
matter for a company. Yes, Oracle did that in the past._

Bollocks. I challenge you to provide an example of a Java developer being sued
for using the language.

 _Performance -- poor, regarding memory consumption._

Bollocks. Uses more memory than C, but no manual management. Sweet spot.

 _Shoddy, you mean. For Haskell or Clojure you have at least a guarantee that
the guys you found are decent._

Bollocks. In my experience, they're likely to be somewhat better skilled and
educated. They're also far more likely to spend their time arse-ing around
trying to implement an elegant, concise solution to problems which only exist
because of not-invented-here syndrome, or because their language lacks as
extensive a standard library.

As an example, I once worked on a Mac GUI app for a company - bog-standard,
nothing fancy. I took over from a developer who had been trying to build this
using Racket; this involved building a Qt-Racket interface, which involved
magical automated parsing of C++ header files, which meant… basically, not
delivering a product. Meanwhile, the Objective C build was done.

The point is, there's far too much focus and snobbery about what tools
developers use. There are loads of languages out there; pick one that has a
reasonable amount of support and fits the problem domain, and build simple,
maintainable code. You can do that in any language.

~~~
rakoo
> I challenge you to provide an example of a Java developer being sued for
> using the language.

Google ?
[https://en.wikipedia.org/wiki/Oracle_v._Google](https://en.wikipedia.org/wiki/Oracle_v._Google)

~~~
pjmlp
Google is not a software developer, rather a corporation that tried to work
around paying for J2ME licenses.

------
Hermel
There is a lot of Cargo Cult programming going on among Java developers.

Why using a simple constructor when you can use the factory design pattern? Or
why directly instantiating a logger using the "new" statement and the right
arguments, when you can also configure it using xml files? Making use of
design patterns and frameworks is professional, after all, isn't?

~~~
malka
over the years, I developped a fiery hatred of XML configuration files.

~~~
kasey_junk
and I'm starting to develop a fiery hatred for JSON configuration files. At
least XML had standard support for schemas and querying.

------
dmacvicar
While I have seen what you describe, I am not sure if it is only specific to
Java, and I have to admit that I enjoy working with the Java platform. There
are things in the ecosystem that annoy me more.

We use Java in a non-standard environment: products built on a enterprise
Linux distribution, and therefore built using the same infrastructure and
conventions: everything is built from source as a dependency chain, so that
you can patch it and provide support, and ship those patched components back
as packages. Everything is built in a repeatable environment, jailed in a VM,
no network, that only contains the dependencies you declared.

So there were those nice times where building a Java library meant packaging 2
or 3 dependencies, then packaging the library was as simple as unpacking,
apply any patches, set the classpath to the dependencies and run ant. Then
install the resulting jar. It played well with the environment.

Java build tools are insane.

To build most libraries I now need Maven. Maven needs like a hundred
dependencies to build, plus some plugins that need those dependencies, and
those plugins build with Maven, the dependencies too. At the end, to build
Maven, you need to have all components which are the reason you are building
Maven in the first place.

So this makes me thing Java developers don't think in terms of layers, and
they pull dependencies without balancing the costs (writing one function vs
depending on 20 more jars).

A build tool should have almost no dependencies outside of the base system (in
this case the JDK) and the compiler.

But no, they added even a Dependency Injection container. And now they
realized that the one from Google is better, so they switch to it, but without
removing the old. So now they may be depend on 150 packages instead of 100.
Great. Lets add more stuff.

Imagine if to build make you need to have Gtk, and a library that builds with
cmake and another library that builds with scons.

And all the noise with this advanced nuclear engines and frameworks to power
something as simple as a build tools is at the end useless. At some point the
project still declares technical bankruptcy and dies. Java has a lot of
"choice" in terms of libraries, but a good percentage of them are dead
projects.

~~~
dozzie
Programmers rarely see how their software is built and shipped. Those who have
this opportunity rarely have their taste developed to see that external
dependencies have cost associated. And it's not something specific to Java: I
see the same in Ruby and Python.

It could give the perspective to programmers requiring from them that they
always build their software on a freshly installed machine with no network
connection.

~~~
dmacvicar
That is why I don't understand the "enterprise" sticker they try to put on
some Java stuff.

Building without network connection was a feature most of these enterprise
"build tools" did not get right from the beginning.

Patching a dependency, rebuilding the affected chain and ship it back to the
customer is something I still ignore how the Java ecosystem does with their
native tools.

Probably they just do "mvn" in their workstations and .zip the output folder.

------
pjmlp
Java is not the problem, enterprise architects are.

If anything, Java allowed the so called architects a much easier path to such
crazy skyscrapper designs than any enterprise language before it.

So of course they went crazy with Java, and later on C#, because it was so
easy to do so, without being caught in core dumps and similar issues.

Anyone complaining about enterprise Java, just needs to go back a few decades
to see what was being done in C, C++ with CORBA/DCOM, VB/Delphi, CLIPPER and
tons of wannabe 4GL languages.

Any language that wins the hearts of enterprise architects will suffer the
same pains that Java is known for.

I can already imagine a "Enterprise Functional Design Patterns" and similar
books.

~~~
mike_hearn
Ah yes, DCOM. That was truly the domain of the C++ enterprise architect!
Today's AbstractProxyFactoryBean was yesterday's IDispatchProxy,
IRPCProxyBuffer and so on.

What's scary is that big chunks of heavy industry are all standardised on it
via OLE for Process Control (OPC).

~~~
pjmlp
Thanks to WinRT is it back!

------
markokrajnc
Disclosure: Long time Java programmer here (since 1996, previously worked many
years with Smalltalk). Java Language and Java Virtual Machine are great, but
Java Libraries are in many cases too complicated (using too much of "Gang of
Four" patterns).

------
lkrubner
Java combines OO with strict typing (unlike Ruby which has OO without the
strict typing). As such, that particular combination leads to bloat and
verboseness. See:

What did Rich Hickey mean when he said, “All that specificity kills your
reuse!”

[http://programmers.stackexchange.com/questions/199217/what-d...](http://programmers.stackexchange.com/questions/199217/what-
did-rich-hickey-mean-when-he-said-all-that-specificity-of-interfaces-cla)

Part of the answer given:

"If you have two entities { "name":"John" } of type Person, and { "name":
"Rover" } of type Dog, in Java-land they probably cannot interoperate unless
they share a common interface or ancestor (like Mammal, which means writing
more code). So the interfaces/types here are "killing your reuse": even though
Person and Dog look the same, one cannot be used interchangeably with the
other, unless you write additional code to support that. Note Hickey also
jokes about projects in Java needing lots of classes ("Who here has written a
Java application using just 20 classes?"), which seems one consequence of the
above."

~~~
frowaway001
> Java combines OO with strict typing [...] > As such, that particular
> combination leads to bloat and verboseness.

It's bloated and verbose, because Java isn't very good at it, not because it's
a fundamental issue of OO with types.

> in Java-land they probably cannot interoperate [...]

Ditto.

------
_pmf_
The proliferation of factories is not an indication of over-architecting
something. It is a direct consequence of finding a balance between
maintainability and the lack of first class functions (or constructors as
first class functions).

If you have never had the need to introduce factories, I claim that you have
not worked with a truly polymorphic system.

------
mark_l_watson
I agree with the general sentiment of the article. I have used Java since the
beginning and I have written many books using Java for the examples in the
books.

I mostly use Haskell and Clojure (with little text utilities in Ruby) now, but
I still do find that Java is sometimes the best language for some projects.
Off topic, but Java 8 streams and inline functions made the language better.

That said, I no longer use Java in any sort of "standard" way. I stopped using
getters/setters years ago in favor of public instance variables. I also write
a lot of static methods ("functions"). Basically, I try to make my Java code
as concise as possible.

I also have turned my back on large server side frameworks. For web services,
embedded Jetty and a JSON library is often all the library support that I
need.

------
vijucat
Blame the 90s : the Gang of Four design patterns book, UML, et al.

If you wrote code that did not abstract enough, such as not using factories,
it was jaw-droppingly obvious to your colleagues that you were not good
enough. FP and Scala owe the sheer verbosity of Java a lot for their current
success :-)

~~~
cam-
Java has been round long enough to have been influenced by whatever was the
coding fashion of the time. You can see it in the core java libraries and the
supporting frameworks. OO and GoF where probably the biggest fashions and you
can document when a core library was written by the approach to it.

------
kasey_junk
Wow there is a lot of bashing of the GoF patterns going on here. It seems like
lots of people have a misconception about what patterns are. Patterns aren't a
goal to meet with your software. They are common emergent solutions to
standard design problems. The GoF didn't invent them, they just cataloged and
provided a standard name for them.

So once we have a common name, shouldn't we use it? If I see a FooFactory, I
have a pretty good idea what to expect in that class. So the problem with a
FooFactoryFactoryAdaptor isn't that it is following GoF patterns or in it's
silly name, it's that you have a solution that has at least 3 levels of
abstraction. The patterns didn't cause that.

------
__Joker
Can't agree more.

The problem is not the language itself, rather who uses and whats the culture
associated with it.

Java is mostly used in the enterprises, where unfortunately thest "architects"
exists. Architects are nothing but people have grown out of the roles and in a
way of organization recognizing the peoples talent. Most of the times the
Architects are redundant.

Most of the cases use of Java is nothing but writing your business logic into
the Java code.

Unfortunately, architect to justify himself would try to engineer a solution,
which never needed engineering itself. and down you go in the rabbit-hole of
oops and abstraction.

Unfortunately it will be pretty hard for Java to shake up this image.

~~~
threeseed
Good architects play a vital role in the organisation especially if you have a
sprawling set of agile teams that don't necessarily work together.

There are plenty of really tough integration, security, scalability and
performance challenges that need someone who is across the entire stack from
very top to very bottom. You rarely find developers who can manage it all and
still find time to cut code.

------
kyllo
The language has some very poor design decisions baked into it (read: no
functions) but the biggest problem with Java is that it's the lowest common
denominator enterprise programming language, and managers have used it to
lower the bar in their attempt to commoditize programmers. As a result there
are lots of Java programmers on the market, with low salary expectations, and
the code they produce is of commensurately low quality. As Paul Graham put it,
Java is a language you learn to get a job. Do you want all your company's code
to be written in a language that your programmers only learned because they
needed a job?

------
uptownJimmy
Recently-graduated student here, middle-aged and with more than my fair share
of life challenges under my belt. I fell in love with coding by accident,
after half a life in the restaurant trenches. But one of the things you can
learn in the trenches is the value of patterns, and the value of recognizing
patterns. Over the years I've come to trust my instinct for recognizing
patterns, hard-won as it was.

Java is swamped in an over-proliferation of verbiage. That is the first
impression one has of the language in school: that it requires twice as much
code to do anything. And that was, as well, my last impression, as they tried
to prepare us for our entry into the world of enterprise computing by steeping
us in a rolling, boiling stew of jEverything. Too many cutesy names in a
programming language just felt WRONG, and I think my instincts have been borne
out. Java is a mess to behold and to work in, and I am fantastically glad that
I didn't get that first (Java) job I applied for, but instead got the second
(ASP.NET) job.

Irony abounds, I know, but .NET seems streamlined and elegant compared to Java
EE. Turns out, sometimes you actually CAN judge a book by its cover. And by
the 1496 pages in that Java textbook, which, hysterically, serves as merely an
introduction...

I don't know where I'll be in a few years, but I'm fairly certain I'll not be
coding in Java.

------
mlangdon
I for one appreciate the hard work that was Android and Java. I spent two
years intensively self-teaching, primarily on Android before starting my
developer job. Having to take in large, unwieldy systems with lots of moving
parts was mind expanding. I could spend a night in the API, go to bed and wake
up feeling smarter.

I haven't done any Android for my job (and just a little Java), but every time
I have to design more than a self-contained python script, I'm grateful for
the exposure to such complexity.

------
therealmarv
Java can be really glad that there is Google with Android. Otherwise this
language would be a strong enterprise focused language with very bad
reputation on the end user side.

~~~
andybak
However - how many developers are turned off of being Android devs by the fact
they have to use Java?

(and I know that probably many more are attracted because they already know
Java but that's not my point)

~~~
watwut
I was turned off by a.) horribly slow speed of Android virtual machine b.)
being hard to code for it with maven c.) I did not particularly liked their
xml language for gui.

I would have to write mobile, I would use one of those languages that compile
into both Android and iOS as much as possible.

~~~
cerberusss
Exactly. I personally think Java is fine. It's just that the development
environment is much less nice than Xcode.

------
kaonashi
The dependency-injected style is great for mitigating side-effects and
avoiding hard dependencies in code.

The problem is that it's a poor substitute for currying and composition.

~~~
_pmf_
I agree.It's good design in the disgusting veneer Java requires.

------
bmoresbest55
As a newly hired Java dev I can understand the problems that Java has with
many levels of unnecessary complexity. However, I do not think it is right to
simply say that all or even most Java devs are bad. First of all the
definition of bad is relative to the person and secondly I would not agree in
saying that they are all or mostly bad. People are usually trying to do the
right thing and if that does not fit inside your ideals then it is bad?

I guess all I am saying is not the throw stones. No one is perfect and to bash
a whole community today based a snapshot of what you have seen is narrow-
minded, look for the good parts and focus on those at least. Teach someone to
code well in Java, if you feel so inclined to say that you know better. I know
that there is a lot to learn, personally. I currently do like Javascript and
Python as well but I would never look down on Javascript, Python, or Java
communities. They are all great in their own way and in many similar ways.

We all enjoy coding at some level, why does anotehr way of doing that have to
be so worng?

------
JAlexoid
"Android - really the biggest reason today why anyone besides the enterprise
guys cares about Java anymore"

This line just says - ignorance. Thee is a __*tonne of stuff in Java. And just
because the majority of developers are low quality(what language does not have
that?), does not diminish the interesting stuff that is going on with the
whole platform.

------
talles
> "(...) OO is actually pretty shit (...)"

 _Relief washes over me in an awesome wave_ when I read this line.

No, no, I'm not attempt to mindlessly bash OO. But I've worked over the years
with folks that put OO as some sort of holy rules. When arguing X vs. Y the
discussion goes well until someone says "Y is wrong, Y violate {this} of OO",
shit, when that little statement is made I know I'm lost. Because even if I
attempt to show that in this particular case violating such principle is good,
I am doomed to be considered a heretic, an outsider, and sometimes
automatically a bad programmer.

I've tried to not thought of my self as an 'enlightened', but people kept
acting as believers of such religion over and over that I could help myself
sometimes. It's pretty much the feeling of being a philosopher teacher in
mormon cult of something.

------
kizer
As a relatively young programmer, I feel that I'm just now exiting this stage
of over-abstraction and pursuing a "perfect" design. Perhaps it does plague
many older programmers, but to me super object oriented programming was a sort
of programming puberty. In high school, I would sit down to write a Java
program and figure that I would have to construct this grand architecture
where each class reused absolutely no code and fit perfectly in an abstraction
hierarchy. Of course, I would quickly lose focus of business logic and write a
gazillion SomethingSomethingRepresentation classes and get nowhere. It really
hit me when I realized I had a file named Null.java :)

------
robmccoll
So happy to read this, yes, yes, and yes.

Another big problem with Java to me is that the standard library and available
frameworks are so massive, that there are thousands of ways to solve any given
problem. This is bad, because only a handful of the solutions perform well,
result in readable well-written code, and are efficient (from both a
productivity perspective and resource utilization perspective). I'm not sure
why, but it seems like many developers are almost trained to pick the bad
ones. Perhaps the high level of abstraction enables the programmer to ignore
the realities of the implementation?

------
sigmaml
> More and more developers are stepping back and realising that as a
> programming paradigm, OO is actually pretty shit.

It is sad to see such strongly-worded blanket statements. The author
generalises his experiences with Java to entire OO. He doesn't, unfortunately,
seem to realise that non-Java OO does exist.

Also, several lean Java frameworks exist, without deep class hierarchies and
factories of factories.

Finally, OO is one of several possible ways to modularise and scale code and
teams. FP is another. As languages like Scala have been demonstrating, it is
possible to selectively blend features of both in fruitful ways.

------
frugalmail
I'd much rather have a large application written in OO w/ Java then a
functional only application. I have serious concerns about maintainability
otherwise. This is of course assuming that we have good developers on either
side.

Especially when the language in question is getting libraries and native
features that pull in the good parts of other languages.

Blog posts like these make stupid generalizations.

I'd also like to say if 5% of the Java Developers are the good developers that
would be factors more than 100% of the Clojure developers + 100% of the
Haskell developers + 100% more than the F# developers.

------
virmundi
Having worked in the Java world for the past 8 years, I think the issue with
the developers is that the work is boring and they want to solve some problem.
Folk who work with Ruby (at least 2-3 years ago) were doing something
interesting. It could be a simple CRUD app, but Ruby made it interesting.
People wanted to be there. Java is not.

Instead, Java has a history of patterns for the sake of interest. Need to
inject something in? Use a FactoryFactory. Most of what Java becomes revolves
around having to do tedious CRUD apps for the enterprise that constantly
change what they want.

------
zmmmmm
It will be interesting to see if Java8 inspires a fresh look at the design
approaches used in the Java world. So many of those over-architected Java
designs are trying to solve lack of flexibility and expressiveness in the
language. There's an opportunity now to keep the good and move on from the bad
... it's terribly unfortunate though that it's not clear if Android will ever
properly update from Java6 syntax. If it doesn't a large amount of the Java
ecosystem is never going to move on from there.

------
jackhiggs
The real problem is developers not understanding Object Oriented programming.
Many developers write procedural style in Java or any other OO language. So
you get God classes, methods that are hundreds or thousands of lines long etc
- I'm sure we've all seen those horror shows. It's just a lack of education
coupled with a culture where there is no strive for technical excellence.

You need high quality developers in Java, just as you do in any other
language.

It seems like the article's beef is with OO programming, not Java per se.

------
TeeWEE
While I do agree that java developers are often low quality developers. And
than java frameworks are often bloated with Dependency Injection, Factories,
Proxies etc...

I disagree that Android has the same problems. To me it looks like Android was
actually written in lean-and-mean java. Ok its still Object Oriented. But for
UIX interfaces, Object Orientation makes a lot of sense...

There are some areas in the android API that are indeed a bit bloated. And
that is indeed inherent to java.

~~~
boobsbr
> While I do agree that java developers are often low quality developers.

That can be said for ANY language.

------
lukaseder
As the article states, this isn't a _general_ Java problem. Just a problem of
people copy pasting horrible code suggestions (or design suggestions) off some
vendor's tutorials.

Here's a blog post that shows how to make a game out of that madness we have
gotten used to thanks to JEE / Spring

[http://blog.jooq.org/2014/04/01/spring-api-
bingo/](http://blog.jooq.org/2014/04/01/spring-api-bingo/)

------
louischatriot
Interesting read, explains well why I don't like to code in Java anymore. Most
Java devs who go too deep in frameworks and complexity should try to build a
small project in a very dynamic and concise tech. I always recommend Node.js
for that, since you have to selcet the right module for every job, have to
think it through and really understand what's going on, and can easily step
inside the code if need be.

------
pramalin
I think the author is out of touch with modern Java development practices. Any
decent Java developer would have got exposed to POJO based development[1] by
now. [1]Expert One-on-One J2EE Development without EJB - Rod Johnson, 2004

These days even the much hatted EJBs are POJO based and lot easier to work
with. Not to mention Lambda support in Java 8 and the hybrid approach of
Scala, my favorite.

~~~
jeremyjh
I think the commentator should read the article. The author does not once
mention EJB. The problems he describes are endemic to all kinds of libraries
and frameworks and are VERY much a part of most shop's interpretation of
"modern" Java development.

------
curtis17
I totally agree with the original poster. I picked up Java in the mid-90's for
server-side dev. Grew to loathe it.

When Google announced an open-source OS for mobile - I was so happy. But ...
Java. Broke my heart. Don't Google have any taste. At least Google could bless
an alt-Java Swift-ish alternative like Kotlin, Xtend, AnythingButJava.

~~~
mike_hearn
They don't really need to bless it, do they? Any JVM language that targets
Java 6 should work.

~~~
curtis17
Google have issues with Oracle. Why not bless an alt-Java and give developers
a clear signal. The end game should be Kotlin or Xtend or ? -> Dalvik/ART. Cut
out Java.

~~~
wstrange
Dart for the win

~~~
curtis17
Dart is interesting but a little too Jave-ery in both syntax and tools - Dart
Editor is Eclipse based. Also, not sure how committed Google is long-term.

Google's issue is too many languages and runtimes: Go, JS/ES6/V8, Dart/DartVM,
Java/ART, PaNcl, RenderScript.

With the Material/Paper UI Google have given dev's a consistent, elegant
unified surface. But Google should also be moving in the direction of an
(elegant) unification under the hood. Java and JS are 20 years old - but are
at the core of Google's platforms - Android and Chrome/OS. But what - Kotlin,
Dart, ES6/7?

------
moretti
I think this code truly represents the essence of this article:
[https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...](https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition)

------
critium
I actually have a different problem. Java developers that are IDE jocks and
dont have any kind of understanding of what is happening underneath the API.
Take these guys outside of the IDE and they dont even know how to compile the
code.

------
jimmcslim
Great article, but I especially encourage you to read the one before it as
well...

[http://nsainsbury.svbtle.com/leonardo-da-
vinci](http://nsainsbury.svbtle.com/leonardo-da-vinci)

------
jaxytee
For Android developers interested in building apps in Scala check out Scaloid:
[https://github.com/pocorall/scaloid](https://github.com/pocorall/scaloid).

------
peterashford
I have been using Java for a really long time. I have never seen a
"AbstractAdapterFactory" anywhere. Ever. Disclaimer: never did any J2EE BS.

------
pdrummond
Good read - the bit about Android is spot on.

------
maxwin
"I’m an Android developer, stuck using Java. It’s breaking my heart." Glad
that I am not alone.

~~~
curtis17
Definitely not alone.

At the Google IO Android Fireside Chat, a developer asked the Android team
about using an alternative to Java for development - Scala in his case. Pretty
much 'no' was the response. But don't Google have any taste. Kotlin or Xtend
imo are lighter than Scala and would be good fits for Android.

------
oldmanjay
well nothing convinces me like unsupported assertions and undirected insults.
I now hate java as well.

------
CmonDev
You can use Xamarin (C#, F#) for Android though, which will let you go multi-
platform in future.

------
zkanda
I heard Kivy is getting more popular, that is if you like writing in Python.

------
rbanffy
Not only Java. I die a little every time I see a PHP application trying to
cargo-cult common Java overdesign patterns because "that's how 'Enterprise'
apps are built".

------
jdennaho
I've worked with java for 10 years now... I have seen some shit let me tell
you.

------
hawleyal
I second and third everything he said.

------
michaelochurch
One problem with Java is the 15+ years of bad taste. Design patterns are
"revenge of the not-nerds". It's "I don't know what a monad is and don't care
to learn, but I'm going to make _you_ feel the way I do when I see math by
renaming the sine function to VibratorVisitorFactory."

Moreover, Big Software is generally a bad idea. There are occasions where
large programs are a good idea, but the default should be small, composable
units. Scripting and batch jobs aren't "baby coding". They should be the
default _unless_ you need a long-running server process. _Most_ programs (over
90%) should be doing one thing and doing it well. The problem is that people
don't code this way because it's better for enterprise managers' and
architects' careers to say they oversaw gigantic, overarching software
projects.

I've actually noticed that data scientists, while their line-by-line coding
skills aren't as good as a professional software engineer's, are usually much
better designers (and far better communicators) than Java engineers. Sure, R
is janky and Python has ugly corner cases, but data scientists write programs
to do specific tasks and generally are good at keeping code small (because
they have a personal responsibility for the code-- if they can't read it, it's
basically lost-- not experienced by "architects" who can hire maintenance
engineers to clean up their messes). You don't see the enterprise "software
for software's sake" problem.

The result of Big Software tends to be Java Shop Politics, as described here:
[http://michaelochurch.wordpress.com/2012/04/13/java-shop-
pol...](http://michaelochurch.wordpress.com/2012/04/13/java-shop-politics/) .
It's not the fault of _Java_. It's just a bad way of writing software.

~~~
thecage411
I've noticed that the combination of math and communication skills is pretty
well correlated with producing clean designs and code. Data scientists
probably have those skills more often than programmers, but I'd argue that
it's the skills rather than the culture that account for the difference you
are seeing.

------
lukabratos
Knock, knock. Who's there? Long pause ... Java!

