
Hate Java? Maybe you should hate the industries stuck in the 50's. - jjohns
http://blog.jelastic.com/2012/08/13/hate-java/
======
rb2k_
I always had the impression that people that say they 'hate Java', usually
don't hate "Java: the language". Most people that dislike programming in Java
have a negative sentiment because of:

\- the usage of XML (or now: annotations) to configure all of the tiny
parameters that nobody really cares about

\- a class hierarchy in which you have to jump to 20 levels of inheritance to
get to where you want to go

\- that a lot of Java developers aren't able to compile their application
outside of Eclipse

\- that people build in "flexibility" in form of factory methods but at the
same time only have the factory only build the same thing over and over again

\- that setting up java projects is usually an unpleasant experience with way
to much work if you only want the basic functionality because there are no
sane defaults

\- that there is no proper package management for libraries (similar to
something like 'gems' in Ruby)

\- that all of the concepts that the language is missing was 'patched' in
using reflection, injection and annotations

\- that the language just seems stuck (for how long did the Java community
talk about Lambdas by now?)

\- that most Java libraries don't seem to be able to provide a simple example
(compare to ruby, examples on the front page: nokogiri.org, sinatrarb.com)

~~~
altcognito
I agree with all of this -- Maven has fixed the issue with package management
to _some_ extent.

~~~
rb2k_
Using maven was a horrible experience for me every single time :(

It seemed to download the whole internet and POM files are using everybody's
favorite configuration language: XML

~~~
lmm
It is, but it uses XML _right_ : for a declarative document, and one that has
tools for editing rather than having to do it by hand. Maven is glorious
because it ensures your builds are actually reproducible, something which I've
never seen any other language or build tool accomplish.

~~~
batto
What a non-sense. You can't sanely describe build of your project(s) in
documents. Did Maven folks include every possible scenario in markup? Nope.
And that's why all Maven builds that are not simple jar of classes tends to
have long sequentional calls of build plugins.

I see it this way:

First we had bash and make and ability to do almost everything (run other
programs, ...) by using the right thing/language for the job. There was only
lack of the functions to deal with Java builds and package management.

Then we had Ant, XML programming language with very limited possibilites (I
don't regard targets as a feature). But at least we could express what we
wanted.

Then we had Maven. If we needed something special we need to add it to
sequence of build plugins (in several hardcoded build phases). Mostly we
resort to do things in Ant plugin.

This is why I hate Java. Because of such idiocy.

~~~
lmm
The ability to call random external programs during the build of your project
is not a feature, it's a bug. Likewise the ability to lay out your source
arbitrarily. Your project's build is not a unique and special snowflake; it
can build the same way as every other project, the way that has already been
tried and tested by millions, the way that any developer will immediately
understand.

If there's really some step that needs to be done in your builds that isn't
covered by the existing plugins, you can write your own (it's not hard) and
then at least that step is happening in a structured, testable way. But if
you're doing something unique to a single project, you shouldn't be doing it
in the build system.

~~~
pnathan
> Your project's build is not a unique and special snowflake; it can build the
> same way as every other project, the way that has already been tried and
> tested by millions, the way that any developer will immediately understand.

No, actually, builds can get very unique in multi-language systems or in
embedded systems... believe me. =)

------
rufugee
I've recently come back to java after around 5-ish years doing mostly ruby.
Know what? It's been a breath of fresh air. Code performs as you'd expect, and
when you need to track down behavior, it's usually very straightforward
(completely the opposite of ruby, in my experience). Almost _everything_ runs
super-fast. IDE's actually work with it. Docs are very good.

When I hanker for dynamicity, I've been reaching for groovy...a language I
tried years ago which has come a LONG way and brings a lot of the features
(namely, anonymous blocks/closures) I liked about Ruby. I'm nervously courting
scala but in the early days.

What I liked about Rails can for the most part be found in Play
(<http://www.playframework.org>), although I must admit I felt better about
Play in its 1.x days when it was written in java. The core is now written in
scala (though _you_ can develop your app in either java or scala)...perhaps as
I learn more of this language I'll feel more comfortable opening Play 2's
hood. We're already started converting one of our Rails applications to Play,
and it's been a great experience so far. And oh, by the way, we're finding
that whole "rails/ruby won't slow you down...your database will slow you down"
argument isn't always true.

Anyway, count me among Java's (and the jvm's) fans. It probably doesn't hurt
that I have been working with it in one way or another since 2001, but I tried
my best to leave it, only to find that sometimes you can indeed go home again.

~~~
rufugee
That said, it hurts my brain to understand why in 2012 we're still forced to
create our own empty getters and setters, and why there are no anonymous
blocks. I know that closures/anonymous blocks are supposed to be delivered in
java 8, but I'm not sure the elimination of redundant getters/setters are even
on the road map. I'm so tired of opening classes which are comprised of 20%
business logic and 80% getters/setters simply because one might need to
override that behavior in the future. It really increases the noise.

~~~
icebraining
Have you considered using Project Lombok? <http://projectlombok.org/>

~~~
rufugee
I have. Little too magic for me.

------
dasil003
Wow, what a chip on this guy's shoulder. If you're a single-language Java (or
Cobol) programmer don't worry, your career is safe. But don't write rants
telling other programmers what they should care about. There is absolutely
zero chance I am going to give a shit about antiquated IT and business
processes not being updated. Management has their reasons, and I have no
interest in fighting to convince them otherwise. Rather I will work at a
company that is doing interesting things with tools that I like.

I don't dislike Java out of popularity, I just don't find it to be a pleasant
or expressive language. I like to code in vim without an IDE, so a lot of
verbosity and boilerplate is painful. If I want static typing, I prefer a much
more expressive and powerful language like Haskell, because frankly I just
don't see what the point of static typing is if I'm going to get null pointer
exceptions all over the place.

------
AYBABTME
I don't get why people complain so much about Java. It's definitely not
perfect, but it's not a complicate language to use. People complain that it is
slow; well it's much faster than dynamic languages. People complain that it is
verbose. Yeah, maybe more compared to dynamically typed languages. But
personnaly, I don't have much of an issue with Java. It's not hard to read,
not hard to write, and to my experience, its runtime behavior is easy to
predict.

When I look at benchmarks of languages (notably this [1]), and compare Java to
say Ruby or Python, it's about 40 times faster, and compare pretty well versus
C++. And I'd rather code something in Java than in C++ everyday, all the time.

Now I'm not versed in the benchmarking of languages, and I don't care that
much about them as I understand that they are not very reliable. But when I
need a lil'more performance than Python or Ruby, but that I don't want to ruin
my psychological balance with C++, I'm quite happy to have Java.

Maybe it's just my lack of knowledge that gets me to have this opinion. Maybe
once I get a chance to try out Go and Scala, I'll find there is no reason to
use Java anymore. But I don't think I'll get to the opinion that is it
terrible and that it deserves to be hated and laughed at.

[1] [http://shootout.alioth.debian.org/u32/which-programming-
lang...](http://shootout.alioth.debian.org/u32/which-programming-languages-
are-fastest.php)

[Edit1] weakly -> dynamically

~~~
yummyfajitas
Try out Scala. It's a superior substitute for Java in every possible way.

And even if my last statement is hyperbole, you can still use Java in your
scala project for the critical parts where scala doesn't do a good enough job.
Sbt, the standard scala build tool typically builds you src/main/scala and
src/main/java folders. Write scala in the scala folders, java in the java
folders, they can easily refer to each other, it's all seamless.

~~~
djb_hackernews
Only problem is the scala community is teeny tiny, tool support isn't there
(There isn't an IDE with a scala plugin that fully supports scala), pure scala
libraries tend to be unreadable and lack any solid documentation (looking at
you scalaz, lift, and dispatch), and I think most importantly the scala
compiler is SLOW.

I've written a bunch of production Scala code, and I'm glad to have gotten
away from it. Obviously to each their own.

~~~
thebluesky
_There isn't an IDE with a scala plugin that fully supports scala_

IntelliJ provides an excellent free scala plugin. What have you been using?

~~~
djb_hackernews
I mainly used the Intellij scala plugin... It's code completion was incomplete
and it identified syntax and type errors that weren't errors. This was on the
latest intellij with the latest plugin.

~~~
thebluesky
Yeah that seems to happen if you leave type aware highlighting enabled. Seems
to work well with that switched off.

------
altcognito
This article is a troll, but I'll bite: I'm not going to justify all of these,
but this is my short list:

1) Java is slow (the JIT hides only some of this -- see below)

2) Java makes working in Hashes and arrays very painful

3) Very little functional support (yes, Java8 will help)

4) The java language moves forward very, very, very slowly

5) It scalability is a joke. I've worked as a Java contractor at a number of
places and what a PERL/PHP/Python solution can get done in 5 boxes, it takes
Java 30-40 boxes. This is _NOT_ an exagerration. I think it's a side effect of
some developers stuffing everything into the session and expecting clustering
to fix everything.

6) Date and file handling is also really painful. (yes, JODA helps, but we're
15+ years into Java and only finally getting good date support baked into the
language)

7) Library management. Maven has largely "fixed" this issue at last, but
sorting through library conflicts in order to write in an exception is still
not fun. And as already noted, this is one of the reasons you can't just jump
in with a text editor and hammer out a simple example.

The library support of Java makes up for a lot, but honestly, Python looks
better and better every day.

edit: I will add in support for why many, including myself perceive java to be
slow. The startup of the JVM is horrendous. If you're doing even moderate web
development, there is a _minimum_ two to three second startup period for a web
server. That simply doesn't exist in PERL/PHP/Python. There's no such thing as
a permgen error in PERL/PHP/Python. I've never seen PERL/PHP/Python go off and
spin the disk as furiously as Java trying to load classes. It's ridiculous.

Java's strength is its maintainability and library support.

~~~
rufugee
_5) It scalability is a joke. I've worked as a Java contractor at a number of
places and what a PERL/PHP/Python solution can get done in 5 boxes, it takes
Java 30-40 boxes. This is NOT an exagerration. I think it's a side effect of
some developers stuffing everything into the session and expecting clustering
to fix everything._

Umm...I think you've been working in the wrong Java shops. I've never seen,
nor do I believe it's possible, for a well-written python/perl/php app to be
faster than a well-written Java app.

 _The startup of the JVM is horrendous. If you're doing even moderate web
development, there is a minimum two to three second startup period for a web
server. That simply doesn't exist in PERL/PHP/Python. There's no such thing as
a permgen error in PERL/PHP/Python. I've never seen PERL/PHP/Python go off and
spin the disk as furiously as Java trying to load classes. It's ridiculous._

Sure, Java's start-up is slow. But it shouldn't be an issue in web apps since
your application will likely use threads if it's a Java app. I can see if your
app was process-oriented, like many ruby/python web apps are, but with Java's
native thread support it makes no sense to start up multiple processes unless
you really have a need for the separation.

~~~
altcognito
_> Umm...I think you've been working in the wrong Java shops. I've never seen,
nor do I believe it's possible, for a well-written python/perl/php app to be
faster than a well-written Java app. _

I've been in the industry over 20 years. I've seen plenty. It is easy to
assume that the java and a JIT should be able to take advantage of all the
extra information to make fast code. But in practice, when you add in all the
frameworks and abstraction overhead, Java on the web is slower. I _routinely_
hit stack traces well over 50 levels of depth. Benchmarks really don't take
this into account.

> _Sure, Java's start-up is slow. But it shouldn't be an issue in web apps
> since your application will likely use threads if it's a Java app. I can see
> if your app was process-oriented, like many ruby/python web apps are, but
> with Java's native thread support it makes no sense to start up multiple
> processes unless you really have a need for the separation._

I mostly agree with what you say. It is mostly a development issue. While most
software development in Java attempts to be centered around TDD and therefore
eliminate the whole start-restart cycle, the ugly truth is that there are
reasons that tools like JRebel exist.

~~~
rufugee
_> I've been in the industry over 20 years. I've seen plenty. It is easy to
assume that the java and a JIT should be able to take advantage of all the
extra information to make fast code. But in practice, when you add in all the
frameworks and abstraction overhead, Java on the web is slower. I routinely
hit stack traces well over 50 levels of depth. Benchmarks really don't take
this into account._

But your original post said Java was slow. It's not. Don't conflate the
language with bad frameworks written with it.

------
snorkel
I don't hate the Java language. I hate the Java ecosystem.

The teams I work with that use Java end up being the slowest moving teams
because they can't deploy even the simplest code changes without a lot of pomp
and circumstance and inability to upgrade their servers without disrupting the
whole fragile of chain version dependencies. The java teams are the only teams
that have to stop the world for hours when doing server code upgrades. Rails
and PHP teams have much simple code deployments.

~~~
st3fan
They should pick a better ecosystem then. With Maven and Jenkins I simply tag
a release in git and Jenkins automatically builds new war files that are
deployable by copying them to a deploy/ directory. This basically means:

git tag -a v1.0.1 -m 'Version 1.0.1' ... wait till build is done ... cd
$WEB_SERVER_HOME/deploy curl -O <http://repo/myapp-1.0.1.war>

Done. The last step can also be automated. I've worked with setups where
production machines simply follow tagged release builds. Or just use puppet.

Java can rock. Specially with Maven it takes away so much pain of
build/package/deploy.

------
clwoodson
So, kind of playing devil's advocate here, but what do paying with a credit
card, adjusting your 401K, using an insurance card at the dentist, shopping
for the best car insurance and transferring money between banks have in
common? People can lose money if the system fails or is simply not reliable.
What do going to the emergency room, a BNSF train pulling a Union Pacific coal
car and filling a prescription have in common? People can die if the system
fails or is simply not reliable.

These industries and the activities listed have an inherent level of risk
associated with them. The existing systems work well enough that we take the
safety of these activities for granted. So while as an engineer, I might hate
working with old, outdated technology and not want to work in these
industries, as a consumer I appreciate that the people governing these
industries are perhaps overly cautious.

------
maayank
Arguing about problem #1 doesn't mean it takes away effort from dealing with
problem #2. Maybe the author should also write a blog post about "How can you
waste time arguing about eating your vegetables while THERE ARE COBOL LINES?"

Is that the most important problem for the tech industry? For the human race?
If the proverbial twitter DSL programmer wouldn't proverbially create a DSL,
would he use that time to meaningfully solve the systems' antiquity problem in
the X sector? Even if so, is that the most important/bang-to-buck problem in
known existence?

------
krutulis
I find it ironic that many of the arguments implied for "COBOL is absurd" can
be turned to make the case that "Java is absurd." Both have a legacy of
accumulated complexity, and some programmers dislike the buden this creates.
Others are genuinely concerned that Oracle is positioning itself to profit
from the accumulated legacy in the same way the author complains that
mainframe vendors have done. The community of people that tends to develop
around a language matters immensely in shaping the character of the code that
inevitably accumulates.

Java has a history of conservative implementation choices (E.g., see Guy
Steele's account of some of those choices at [1]) Having lived through both,
the Java world of a dozen years ago reminded me so much of the COBOL world of
the 80's, I personally chose to move on to more innovative communities. I
still occassionaly write Java, and am always struck by how memory-intensive it
is and by how it always seems to abstract by spreading things out rather than
by compression.

Regardless of your own preferences and choices, my recommendation to younger
programmers would be to work hard to avoid getting stuck in any language rut.
If you think of yourself as a "Java programmer," then you might already be a
casualty of your circumstances.

[1] <http://article.gmane.org/gmane.comp.lang.lightweight/2274>

------
ahi
As a user but nonprogrammer of java I have never found java to be cross-
platform. It seems every application of any real complexity has required me to
go on an hour long hunt for the right version and dependencies. If it take me
longer to make your "cross-platform" application cross-platform than it does
to install an OS, then there is a problem. These days if I get a whiff that a
project is java based I avoid it and keep looking for another solution.

------
Paul_S
Oh, the irony of advocating peace and love for java whilst waging a war
against COBOL.

How about we confine language battles to language specific discussions (and I
don't see anything wrong with those) and concentrate the overall engineering
argument on getting good practice in every language. I can get behind the
sentiment of replacing legacy systems but I don't see the point in hating on
COBOL.

~~~
ArchD
I think you missed the point. I think the point is about not having religious
wars over languages for ideological reasons but instead focus on the practical
cost and benefit of the languages. He pointed out the people running the COBOL
mainframes were paying ridiculous licensing fees for their databases.

------
wmat
I used to work in the insurance systems industry. There are many, many
expensive problems that have to be solved before legacy systems can be
replaced. In no particular order:

* The Myth of Uniqueness: Each and every company doing business believes that their business is different and couldn't possibly be the same as another company's. This is not completely untrue, but it's also not completely true. The problem is that this myth is propagated by the enterprise software vendors. The profit margins on services to customize software is far, far greater than the margins on software licenses. It is in vendors best interest to promote software customization.

* 50 Years of Customization is Hard to Throw Away: OK, maybe there's not many 50 year old systems running in production any more, but there are 25 year old systems. The amount of money spent to customize those systems over the years is enormous and big corps are not eager to toss that money spent away to start over.

* Database Conversion is Hard: Not so much difficult, but hard in the sense that it requires many, many hours to first clean up the old database, run the conversion, then validate the new data. One mistake could mean that someone's policy lapses because the conversion broke the automated Pre-Authorized Cheque processing code for that one client.

* Working at Big Corps is Uncool: Let's face it, being a programmer at a big bank or insurance company is perceived as boring. The over 40 set that these jobs appeal to aren't traditionally big adopters of new technology. As these people get promoted into decision making roles, they default to safe, known technologies.

* Corporate Partnerships: Big financial industry companies outsource their IT to corporations like IBM. These services companies have a vested interest in maintaining the status quo. It's much like bee-keeping bears ;)

* The old stuff still works: Even though the legacy code is unreadable and numbers in the millions of lines, it still mostly works. The "if it ain't broke, don't fix it" argument is an easy one to make when your executives (beholden to the shareholders) have to make their quarterly numbers.

Don't get me wrong, I'd love to see start-ups in the financial services
software industry pop up with innovative solutions. In fact, I've thought
about attempting this myself, given my background. But the elephant herd of
legacy vendors to find your way around is extremely intimidating. In fact, I
actually saw a few small vendors pop up over the years, get small contracts
within the big insurance company to do something innovative with their shiny
new technology (but not mission critical to the corporation), and then watch
that company take on more and more lucrative services contracts further from
their core software product. Eventually, their initial product offering
becomes a footnote for them and they turn into something else, legacy related.

~~~
skue
Everything you so aptly described also applies to the healthcare industry,
which is mired in a language from the 60s (MUMPS).

~~~
sampo
Here in Finland (population 5 million) the government is preparing to allocate
ca. 1500 million euros to order a country-wide medical patient database from
Accenture, who are the local representative for Epic Systems [1] and Epic's
MUMPS-based [2] medical information systems.

[1] <http://en.wikipedia.org/wiki/Epic_Systems>

[2] <http://thedailywtf.com/Articles/A_Case_of_the_MUMPS.aspx>

~~~
eevo
My apologies. I live in the area where Epic is based. They tend to hire
straight out of college and work their employees into the ground. It's a weird
subculture over there, but they're swimming in money for all the government
kickbacks hospitals get for implementing electronic medical records here in
the States. [http://www.cms.gov/Regulations-and-
Guidance/Legislation/EHRI...](http://www.cms.gov/Regulations-and-
Guidance/Legislation/EHRIncentivePrograms/index.html?redirect=/EHRIncentivePrograms/)

------
ivix
I found this statement particularly surprising:

>Java, with its faults, has completely conquered web >application programming.

Is there any evidence that this is true? It's certainly my experience that the
direct opposite is true. Java is traditionally considered successful in
everything _except_ web application development.

~~~
cgh
The statement is certainly correct for webapps of a certain scale, meaning
enterprise-scale, not startups. I'm not sure where you get the idea that Java
is successful in anything else - certainly not in desktop apps, games,
embedded (except for Android), etc.

------
ihadaquestion
Java is a tad boring to program in, but other than that there's not too much
to complain about. I'm personally going to stick to what I think is its best
part, the JVM, and use Clojure to abstract myself from all the lower level
necessities.

At this point for me Clojure is simply more fun to write in, although it
remains to be seen if it gets ever accepted into the "industry best practices"
mainstream that will make your boss sleep well at night, just like Java has
for the past decade. Some of the old school LISPers (I'm talking people 70 and
older who taught the language before I was even born) I know claim that they
haven't gotten bored yet, so there's hope.

------
trebor
While the OP is correct about how arcane these industries are, there's one
statement I just couldn't agree with:

> So, why suddenly, in late 2010 and 2011, is Java suddenly the hated demon it
> is?

Suddenly? In the 2010s? Hah! I hated Java practically since _the turn of the
century_ , and only in the last 2 years did I relax and admit that it's become
a good language/environment. But with Oracle's acquisition I don't see that
staying. It was because of how Sun ran Java that the language flourished—if
Oracle so much as sneezes, or even insinuates a change in policy, the language
could see a major shift.

------
zv
We don't hate Java. We hate the developers who create ugly code in Java.

------
cyberp
Posted at the article, but the blog is censored ("Comment is awaiting
moderation").

On a high level, Java vs Ruby/Python is a question of suitability to purpose.

Java is a great language for large teams of incompetent programmers. You will
not be able to find competent programmers to code up the business logic for:
Paying with a credit card. Going to the emergency room. Adjusting your 401k.
Using your insurance card at the dentist. Filling a prescription.

That code is mindnumbingly boring, and has few technical challenges beyond
sheer size and complexity.

With incompetent programmers, you want a B&D language -- Java forces object
oriented. It forces a single object oriented paradigm. It forces a set of
standard libraries. Etc. It makes it as hard as possible for programmers to
shoot themselves in the foot, and it minimizes learning curve to get up to
speed, making programmers as interchangeable as possible. If you've got a team
of half-wits trying to write an employee management system, that's exactly
what you want. The problem falls well within the limitations of the system. If
you want to do something more complex -- a startup solving a problem that's
never been solved before -- and you have a team of hotshot programmers, you
really do want a less constricting and more flexible language.

COBOL is obsolete. Java vs. Python/Ruby vs. LISP/Scheme is a question of
suitability to purpose -- primarily problem difficulty and team composition.

~~~
jacques_chester
> Posted at the article, but the blog is censored ("Comment is awaiting
> moderation").

That's not censorship. That's the default setting for Wordpress blogs.

~~~
jjohns
Didn't see any comment, unless you put it on Jonathan's blog.

~~~
jacques_chester
Well, like I said, Wordpress defaults to placing all comments from new
commenters in moderation.

It's a flawless test for internet tinfoilery; such people immediately allege
scandalous CENSORSHIP when the software mindlessly does what it always does.

------
djhworld
I use Java in my day job and it's easy enough to write code in.

The problem with it for me is, it's totally unusable for writing quick command
line scripts/applications because you need to either

a) Run java -cp <classpath> <class-with-main>

b) Write a shell/batch script to do the above.

Then there's the lack of good stuff found in modern languages like first class
functions.

It's not all bad though, recently I've been learning Go and the lack of
generics makes me pine again for Java like a long lost love.

~~~
sbanach
Really? requiring a shell alias or a one line shell script to shorten your
invocation makes the entire language 'totally unusable'?

~~~
jjohns
You kinda have to agree that writing anything in Java isn't exactly... "fast".
That said, I don't use Java for "quick answers" -- if I want something that
super easy and needed tomorrow, I'll do it in Ruby (especially if I know that
it's not going to need to scale massively or get tons a hits and requests).

------
rsobers
The reason I dislike Java is because the barrier to entry is so high for
beginners.

    
    
      public class HelloWorld {
          public static void main(String[] args) {
              System.out.println("Hello, World");
          }
      }
    

First, you need to wrestle with Eclipse. Then you need to figure out things
like class and void and static and public before you can event print something
to the screen. Ugh. So...much...syntax.

~~~
thebluesky
High school students all over the world are quite happy to write Java code
like that without any issues.

~~~
emidln
No they aren't. It's appalling to me that high schools actually use Java for
introducing a subject that requires immersion to be successful. Nobody sees
"Hello World" or any other intro app in Java and thinks to themselves, "Hey,
wouldn't it be awesome if I spent hours on end making this compiler thingy
happy." If students aren't actually making things they can use and play with,
you're going to find very little adoption outside of the school-mandated time
it takes to pass the next test. This is why Javascript, Ruby, Python, hell,
even VB are so important.

1) Make them want to write code 2) Show them how to reason about the code
(this is where CS classes should come in)

~~~
thebluesky
If it took you hours to get hello world working perhaps you should consider
going back to school?

------
jimueller
This response is less on Java and more on the author's opinion of mainframes.

Large companies are risk adverse and generally for a good reason. That
mainframe running COBOL has probably been reliably processing orders,
crunching financials, and managing inventory for 30 years. No one is going to
replace that on a whim because COBOL isn't cool. What are they going to use
instead? It's certainly not Mongo DB and Lua scripts on AWS. SAP possibly, but
you still end up with an expensive system with even more unpredictable cost
and licensing terms.

------
robdoherty2
Java is a fine tool for many applications. And like it or not, it is going to
be around for a long time.

The problem I see with Java is that we're not sure whether Oracle is taking
good care of it.

------
cletus
There are several myths perpetuated by Java. Perhaps you can simply call them
"biases". It's certainly not the most modern language but like most things,
it's what you make of it. Here's my rebuttal to a few:

1\. People equate Java IDEs with Eclipse and all it's problems. This one
drives me the most nuts. IntelliJ is like night and day compared to Eclipse. I
honestly don't understand why anyone uses Eclipse.

For years I've listened to Eclipse apologists for things like:

\- Maven integration doesn't work. You need to add custom directives for
m2eclipse (in IJ, you just open a pom.xml and you're _done_ );

\- Previously, there were two Subversion plugins for Eclipse and neither of
them worked entirely right. VCS integration in IJ is excellent;

\- Find and Replace across files is awkward and slow in Eclipse. It's fast and
efficient in IJ;

\- At Google, it's a running joke about Eclipse grey-screening (with our
custom build processes and dependencies and so forth) to the point where it's
been described as "turn-based programming". We can use IJ too and it has good
Google integration but less resources dedicated to it. Still I've found it
generally far less problematic;

\- Am immense list of subtle improvements over Eclipse. Even something as
simple as scope selection. Keep pressing ctrl+W in IJ you select the
parameter, then all parameters, then the function call, then the block, etc.
There is a similar(ish) command in Eclipse you can bind to a key but it's just
not as good. That's just one example;

2\. Java means using bloated frameworks like JSF, EJB2, etc. It does not. For
example, I'm currently using Spring MVC (I haven't found a good relatively
lightweight Guice-based Web framework yet) and Objectify on AppEngine;

3\. You can't do closures in Java. You can. It's just incredibly verbose.
Guava [1] is pervasive in Google. I highly recommend it. So you can write:

    
    
        List<String> uppercase = Lists.transform(inputStrings, new Function<String, String>() {
          @Override
          public String apply(String input) {
            return input.toUpperCase();
          }
        });
    

Granted it's much terser in, say, Python:

    
    
        uppercase = map(lambda x: x.upper(), input)
    

or (my personal preference):

    
    
        uppercase = [x.upper() for x in input]
    

But more on this in (4)...

4\. There is a lot of boilerplate in Java. There is and there isn't.
Empirically there is but it doesn't matter. Take the above function. I type
(in IJ):

    
    
        List<String> uppercase = Lists.tr (autocomplete "ansform(") new (ctrl+space fills in the entire Function<> definition with correct types)
    

Same for getters and setters. I press alt+insert, getters and setters and
select the ones that have them. You can also auto-fill equals, hashCode and
toString methods (although the Guava versions of those don't seem to have a
generator).

5\. Java means using checked exceptions. While I also loathe checked
exceptions, this simply isn't true. It's one reason I like Spring. It tends to
wrap most checked exceptions in unchecked ones (eg DataAccessExceptions
instead of SQLExceptions).

6\. IMHO Maven is great. Previously there was Ant and of course everyone
thought their installation was different or they had their own preferences
about where files should be. I like that Maven is "opinionated". It means you
can go to any Maven Web project and know where to find things. YMMV.

Anyway, back to the issue at hand...

I've spent years working in such companies. It does tend to be a quagmire of
mediocrity and politics but not always. We, as engineers, tend to forget that
the easiest way to get anything done in such a company is to make a business
case for added productivity, cost savings, risk management or whatever. Once
you master this trick you can pretty much do whatever you want. It's simply
the language the higher ups tend to speak.

Also, people don't tend to give enough credit to just how hard some of these
jobs can be. Business processes and data migrations are incredibly tedious and
they need to work.

Also, no matter how bad systems might be engineers tend to underestimate the
ability of people to make them work. As engineers we tend to want to automate
people out of pretty much everything we can. Often having some person look at
something or correct something is far easier, cheaper and less risky than any
automated solution or systems change.

[1]: <http://code.google.com/p/guava-libraries/>

~~~
lmm
1\. IntelliJ forces you to manually build your project. This is enough to
force me to use eclipse despite all its problems

2\. Sure, you don't have to use the frameworks, but they're one of Java's big
selling points. If you didn't want them why would you use java?

3\. I think you make the point for me. Sure, closures aren't impossible in
Java, they're just much harder than they should be.

4\. Boilerplate isn't just there when you write it, it's there when you read
the code, which is much more important. The one major live bug I introduced
was when I accidentally replaced a getter that had some code in with an
autogenerated one.

5\. It is true in that there are a bunch of standard library methods that
throw checked exceptions (e.g. file I/O), so like them or not you have to
handle them.

~~~
bad_user
Why should continual/incremental compilation be part of the IDE?

You can do this in a separate process, the IDE only needs to detect that some
.class files have changed and refresh the metadata of those files.

Eclipse support for this is sure nice, but then I hate Eclipse for being
bloated, with a sluggish interface and shoehorning such features on top is the
reason why Eclipse is the way it is.

~~~
lmm
The IDE is supposed to be integrated, and compilation is one of its main
responsibilities. I don't really care how it's accomplished, but I can't write
java without "new errors show up in my IDE whenever I hit save". If there's an
easy way to set up this separate process malarky then I'm interested.

------
bad_user

         Java ... It’s one of the fastest languages 
    

Languages aren't inherently fast or slow, that's rather the quality of the
underlying virtual machine / hardware architecture the compiled binaries run
on. I think everybody can remember the days before Java 1.4 where the official
JVM sucked performance wise. Did that mean Java the language is slow?

Of course, in designing a programming language, the architect can make some
tradeoffs that will make the resulting implementations of certain algorithms
run faster or consume less memory. So on one hand the architect can make
tradeoffs regarding some features of the language that may help with
performance, but on the other hand those tradeoffs can also stay in your way
when trying to do higher-level optimizations.

    
    
         Community governance via that JCP (pre-Oracle).
    

It was Sun that refused to give a license for the TCK to Apache Harmony. The
JCP was never nothing more than a bunch of people and companies bending over
to Sun, now Oracle.

Of course, because of OpenJDK and because Sun always projected this "open"
image of Java to the world, the genie is out of the bottle because OpenJDK can
be forked, and because APIs aren't copyrightable (although that's still a gray
area), so even third party implementations are possible (as seen in the Google
vs Oracle trial). So Oracle has to be a good citizen here, or else they risk
losing whatever control they have left.

But the JCP was never and probably will never be a standards body and Java
will never be a published standard, in the same sense that C/C++ are.

    
    
         It’s popular to hate Java
    

You should definitely have feelings for programming languages, but only
immature people think in terms of love/hate based on what other people think
(basically you're kind of incompetent or still wet behind the ears if you hate
Java based on what other people say about it).

Many of us in the trenches avoid using Java because it's lower-level than say,
Ruby, or Clojure, or Scala. But Java is still there, still kicking ass,
whenever the high-level abstractions are in our way, or whenever we are part
of something bigger that imposes Java on us (like company politics). The same
can be said about C/C++ - still kicking ass, but you don't really have to go
that low level for 99% of the times, unless the project or organization
dictates it. So why should you? Best tool for the job, right?

    
    
         ... are the industries that 
         are still stuck in the 50′s the problem? 
    

Because you know, we should rewrite everything from scratch every 5 years or
so.

~~~
astine
"Languages aren't inherently fast or slow, that's rather the quality of the
underlying virtual machine / hardware architecture the compiled binaries run
on."

That's not really true. Some language semantics and features are difficult to
implement in an efficient manner. Continuations are a good example. Dynamic
typing, also can be inefficient because of the need for runtime inspection of
object metadata. Clojure has this problem and that's why they added type-
hints, purely as a speed hack to avoid this problem. True, most of Java's
speed is probably due to the Hotspot VM, but in practice, it's still among the
faster languages out there, certainly among the garbage collected languages.

~~~
bad_user
That statement I made is definitely true.

I'm not arguing for or against Java, I'm arguing that both the hypothesis and
the conclusion and everything about that article is flawed (it basically
screams LINK-BAIT).

    
    
         Continuations are a good example
    

First of all, most implementations for continuations that are in common use
are on top of virtual machines that are stack-based, so providing first-class
continuations is a bitch, because you've got no way out of it other than to
save the classical call-stack somewhere and restore it later, should you need
to. And because of the way the call-stack is implemented, saving / restoring
it is both time and space consuming.

This was a pragmatic decision, more often than not, because explicit support
is really not that useful, while being error-prone and because the major use-
cases, like exceptions handling, coroutines, asynchronous tasks, etc... can
receive language support that's also optimal on top of a stack-based VMs. And
in most cases you don't need the unlimited extent that continuations on top of
Scheme provide (most people just need the "async" support like it was done in
C#, which is just compiler-related syntactic sugar). Some people even consider
continuations "harmful" as sort of a modern Goto (a topic on which I have no
opinion btw).

However, if you get rid of the traditional call-stack and make all methods
receive an implicit continuation of the caller, and overload the "return"
operator to call that implicit continuation (basically making _everything_
CPS), then you could optimize this more efficiently. By how much, nobody knows
yet, because there have been only weak attempts at solving this (I only know
of Parrot, the new Perl 6 VM, but it hasn't done anything spectacular yet).

Also remember that our current commodity, general-purpose hardware is
optimized primarily for C, which assumes a traditional call-stack. And you can
always design hardware that's optimized for different things.

    
    
         Dynamic typing ... Clojure has this problem and that's
         why they added type-hints
    

You haven't actually mentioned the exact problem Clojure is having. Clojure
added type-hints mostly to avoid primitive boxing/unboxing. It doesn't have
much to do with "dynamic typing".

In case you weren't aware, the JVM bytecode is pretty dynamic. Besides
primitive operations on primitives, which have special bytecode instructions,
the only place where you really, really need the name of a class or interface
is when calling a method. And so the name of the Class.method ends up
hardcoded in the bytecode, but that's only because Java itself has clear rules
for method-lookup, so providing the means to override that method-lookup was
unnecessary.

However in Java 7 they added invoke_dynamic, which does provide the means of
overriding the method-lookup being done. JVM engineers, like John Rose,
promised the same performance characteristics as invoke_virtual.

But Clojure doesn't even need invokeDynamic most of the time, because in most
cases method calls in Clojure are only polymorphic and not dynamic. And
because most things in Clojure are immutable. JRuby would have been a better
example.

EDIT: formatting (moved ending paragraph to the beginning)

------
tsahyt
There are a ton of reasons for me not to like Java but on top of it all it's
how it clings to "object oriented niceness" in utterly stupid ways. It shoves
its paradigm down your throat and there's nothing you can do about it.
Starting with "You can't even have a Hello World program without a class" and
eclipsing in the horrid madness that is the Java Standard Library.

Don't get me wrong, there is a time and place for OOP as well as for GoF
design patterns but overdoing it is - I think - really bad design. Java tries
to force you to adapt to this, while for certain tasks a different approach is
clearly superior. Some programs benefit hugely from being written in a
functional style, others benefit from having purely imperative modules that
are _not_ part of a class hierarchy. Java doesn't do any of that and makes it
look like a good thing.

Again, I don't condemn the idea of OOP, I condemn sticking too closely to one
paradigm. C++ is a horrible language in many ways but I still prefer it to
Java by miles. Because it's multi-paradigm. Python - multi-paradigm. Heck,
even C99 is multi-paradigm in a way (assuming you dive deeply enough into it,
one can actually write OOP code as well [1]).

</rant>

[1] www.cs.rit.edu/~ats/books/ooc.pdf

------
clueless123
The main problem I ever saw while attempting to migrate legacy(mainframe/db2)
to modern (linux/java/oracle :)) systems was coupling.. there is so much
customized, non documented, completely forgotten coupling between systems that
is like changing engines on a plane (While flying!).

I takes a lot of patience, attention to details, and computer arqueology
skills. Still, it can be done, and it is very worth it $$ to the companies
(and to me! $ :)

------
dlikhten
I hate java.

I love the JVM.

90% of the benefits of java are benefits of the JVM.

the Java language itself is garbage though. Too many hacks, too slow release
cycle, too slow adoption cycle.

Kotlin is actually a great language built on the JVM that handles the
weaknesses of Java and builds on the strengths of the JVM.

So once again, I am sick of articles "Java s0x0rs!" and "Java r0x0rs!" Please
be specific as to what is a problem Java or JVM, and address that.

The only issue I have with Java is the JVM's garbage collector. I hate that
the JVM's GC can't automatically expand and collapse the total allocated space
to make your application run as lean as possible, but also expand to take up
as much ram as needed. And by the time OutOfMemory exception is thrown, you
are screeeeewed, best u can do is die. Wish there were strategies for out-of-
memory handling (like which memory can be scrapped in favor of application
stability)... then again you probably have a well designed app at this point.

------
zeru
Everyone has preferences and opinions. There's nothing wrong with disliking to
work with any language because of how you feel when working with it. Hating a
language itself is a bit different though, they all had, or have its uses
(well, there obviously are small exceptions), and I don't think many
experienced programmers would claim that they actually hate a language itself.

No language is optimal for every single type of project and workstyle, and
knowing only one language you wont get far in most situations, and thats fine.
However if I see a choice I can make between java and another language to use
at work for what I'm working on, I do end up using java in most cases simply
because I enjoy working with it more.

------
nic-ferrier
The OP is absolutely spot on, however, innovation in those fields he mentions
is very hard because they tend to be closed shops. I think the best thing
those places could do would be to talent buy some startup teams and see what
happens because it's sure as hell true that their existing IT is failing to
move with the times.

Witness the ridiculous mess the British banking industry has gotten into (with
RBS, a massive British consumer bank having a failure that caused them weeks
of further problems).

It can often seem to those of us outside that management in those companies
has focussed on pure profit, not dealt with technical debt and not even tried
to make an effort to adapt their IT strategy to the rest of the world.

------
padobson
Did anyone notice that the industries described are dominated by players who
hate their customers? Banks and insurance companies treat their customers as
adversaries, and the only reason they can do it is because they all do it
Before we talk about solving the technological problems in these industries,
we should be talking about solving these industries. The disruptors will solve
the technology problems. I sure hope no one at Bank of America or AIG never
attempt to shift their legacy systems to more elegant solutions. I want it to
be one of the many albatross hanging around their neck.

------
jordanbaucke
So what's the best path forward? I'm interested in building new models on top
of existing software infrastructure (for the financial industry), not because
I like brain damage, but because I'm very interested in finance.

If its a given that the industry is "antiquated and ridged" there has to be
some room for people to solve existing problems. Even if it's laying new on-
top of old (as some have mentioned). The question is: how do you identify the
problems without going to work for a legacy infrastructure provider /
integrator? Any advice out there?

------
superxor
Many people claim Java gives better performance. I would like to know from
some experienced programmers how it had been a few years ago. Was Java always
this well performing?

Seems like Java community did quite a lot to get Java to perform better. How
likely is it for a language like Python or Ruby to do something like that? I
understand that these are vastly different technologies and we simply can't
compare implementing a JVM feature in say a Python interpreter, but any
commentary would be appreciated.

~~~
parasubvert
Sun hired some of the best minds in the business to make Java perform around
1999 - literally the guys that wrote the first runtime optimizing compilers
and generational garbage collectors (eg. David Unger and team from Self), and
also had some of the pioneers in LISP (Guy Steele). The major performance
gains began in Java 1.3 in 2000 through Java 5 in 2004, with steady gains
since, particularly in terms of garbage collection in large-memory, multi-core
environments.

IBM also had some very bright minds working on their J9 JVM which was
aoriginally targeted at embedded environments but was so good it became their
mainstream VM. I'm not sure how much "borrowing" it does from the Oracle VM,
but it's definitely a different architecture.

Another language could do this of it had wealthy patrons with a keen interest
to make it so. Google with Python might be a possibility, but they are huge
Java users already and have some of the old Sun team working for them.

~~~
archangel_one
Google started with Python with Unladen Swallow, but stopped after a
combination of uninspiring results and the fact that while Google uses a lot
of Python internally, it's generally for non-performance-critical
applications. For the cases where performance counts, it's generally done in
C++ instead.

------
clueless123
Quick example of legacy architecture tricling all the way up to today's java
code: as of 2005 the largest travel network in the world, still used bit
twirling on a byte to record the frequencies of flights.. on a flat file!
10000000 - monday 10100000 - monday and wednesday and so on ...

of course there was no documentation whatsoever to figure out what was going
on :)

~~~
Roboprog
Many languages support using a bit vector as a set of enumerated values.
Loading this byte into a suitable variable and checking it in the language
debugger would be clear.

------
sanxiyn
I must link this here:

NACA: Automatic migration from COBOL to maintainable Java --
<http://code.google.com/p/naca/>

"4 millions lines of COBOL were 100% automatically transcoded toward their
Java equivalent."

I think this is a really cool technology.

------
jeffmess
I couldn't care what language industries use. As long as they expose a better
API than transferring damn text files and I don't have to wait 15 minutes for
a response, I'm happy.

------
bzalasky
The article is interesting on the whole regarding industries dragging their
feet... but it didn't seem like it had much to do with Java.

------
indeyets
that's the repost. original link here:
<http://thecodemechanic.wordpress.com/2011/05/30/hate-java/>

------
zkar
I work in the banking industry and agree 100% on the mainframe usage and
costs. There is a vudu/cult following that stack that likes to keep itself
away from any controversy and keep a low profile. The biggest winner in this
is IBM.

~~~
jordanbaucke
so where do you think the biggest areas are for improvement?

------
agpen
This post is a complete non-sequitur. You can hate Java AND hate antiquated
practices. They're not mutually exclusive and there's plenty of room for more
hate in this ol heart of mine.

