

If Java Is Dying, It Sure Looks Awfully Healthy - apetresc
http://www.drdobbs.com/jvm/if-java-is-dying-it-sure-looks-awfully-h/240162390/

======
jasallen
Java may not be dying, but it does take off early on Fridays for golf.

Java is not dying the same way Cobol was not dying 10 years ago. It has a lot
of legs left but nobody is 'hoping' to use it, they are told to do so.

Java is and always has been almost completely a corporate tool. Again, like
Cobol, so the 'cool kids' are not going to give it much love. It's too slow to
execute to compete with C++, its too slow to write to compete with Groovy or
Scala. And all the cool kids pick an extreme and vote that way.

Java is not 'dead', but thought leaders aren't using it right now. The people
who inherited the decision of thought leaders of 15 years ago are using it, so
the writing is on the wall, its just going to take a while to be read.

~~~
dkuntz2
I'm fairly certain Java and C++ have comparable speeds, and I think in
someways Java's faster.

~~~
axaxs
Java is not as fast or faster than C(++). The assertion always makes me
cringe. I won't say Java is slow(though the startup time is annoying for some
tasks), as it does perform better than many languages. But how does it make
sense to you that a platform written in C can produce results faster than C is
capable of?

~~~
artsrc
I agree that C code is currently faster than Java in most benchmarks:

[http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?t...](http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?test=all&lang=java&lang2=gcc&data=u32q)

There is no contradiction that a compiler written in a language with expensive
semantics (say python), could compile a program written in another language
(say C) to produce highly efficient machine code.

The JVM operations, such as JIT compilation and garbage collection, are bound
by the performance of C code.

The performance of the code you write depends significantly on the quality of
the machine code produced by the JIT compiler. This quality of this code is
not theoretically dependent on the implementation language of the JIT.

~~~
waps
> There is no contradiction that a compiler written in a language with
> expensive semantics (say python), could compile a program written in another
> language (say C) to produce highly efficient machine code.

Maybe not a contradiction in logic, no. But in practice the compiler has to
solve a problem that is much harder than the problem the programmer would have
to solve to write efficient C code for this one case. It's also one that has
different complexity.

So you're in the situation now that a few compilers (VERY few, though this is
very very hard to do) will actually beat stupid programmers in optimization,
but there is nothing any compiler can do to beat the optimizations a good
programmer will implement.

As for startup time, the sad part of that is that is one area where you could
really improve C/C++ : startup time. Right now a C program has 4 distinct
things that need to run before main() starts, and involve quite a bit of
calculation, C++ has a lot more (the various kinds of initializers which can
cause arbitrarily complex calculation).

A lot of these initializers result in constant (and small) memory layouts, and
could in fact be run at compile time. What you generally do in initialization
phase is to calculate registered classes (e.g. for serialization, or
protocols) and make indexes of them. Maybe even compile regexes. All of that
could be optimized to occur at compile time (as long as memory usage of the
code is reasonable).

~~~
artsrc
Sorry I was not clear enough.

I am _not_ making any kind of sufficiently smart compiler claim
([http://c2.com/cgi/wiki?SufficientlySmartCompiler](http://c2.com/cgi/wiki?SufficientlySmartCompiler)).

You think I am saying that a compiler can do optimization better than a human.

What I assert is that the implementation language of a the tool that generates
machine code guarantees nothing about either the source language, or the
quality of the generated code. This was the assertion of the parent that
invalid. He said that because the Java JIT compiler was written in C, that
necessarily implies that the generated machine code would be slower that C.

Consider an Assembler, written in C, that generates machine code. By your
logic you can't argue that assembly code is always less efficient than C.

Or alternatively Fortran compilers, written in C, which produce machine code
that outperforms code generated from C for many tasks.

------
zainny
I'm surprised nobody has mentioned Android yet. When you add in the Android
factor, Java is probably still one of the most widely used programming
languages today.

It's funny the article straight away brings up the verbosity argument as well.
You want to talk about verbosity - take a look at Objective-C and Cocoa
(again, hugely popular today!)!

Personally, I quite like Java.

~~~
EpicEng
Popular in terms of use, yes, but liked? I don't know, I doubt it. Android and
iOS essentially force you to use Java or Objective-C respectively. I don't
hate Java, but I don't like it either. It lacks quality of life features that
other, similar languages have had for years. I can't stand writing code in it
if I don't have to (and don't get me started on Objective-C...)

From what I hear from others and read on a weekly basis, few people enjoy
writing Java code. It may not be dying in terms of numbers, but given an
option to use something else those numbers would likely drop very quickly.

~~~
taspeotis
> and don't get me started on Objective-C..
    
    
        itsNotTheLanguagesFaultPerSe:butIfTheFunctions:andTheirParameters:werentNamedLikeThis:itWouldBeBearable

~~~
shaggyfrog
I find the descriptive nature of method signatures to be quite delightful.
Unlike other languages like C++, I don't always have to go looking for the
function definition to see the types of the parameters it takes, and what
exactly was the order again? Combined with Xcode's autocomplete, it saves a
lot of time.

I shed a small tear every time I have to call a C API with and endless parade
of (NULL, NULL, 0, NULL).

~~~
nitrogen
In C99 it's possible to use compound literals to implement something like
named parameters. You create a struct with all of your parameters, and only
include the ones you want to set in the compound literal. Anything not
explicitly specified in the compound literal gets set to 0, so the caveat is
that 0 can't be a valid value for your parameters.

~~~
epsylon
The book 21st century C talks about that trick:

[http://books.google.fr/books?id=_EdbrocXX9MC&lpg=PA183&ots=D...](http://books.google.fr/books?id=_EdbrocXX9MC&lpg=PA183&ots=D8EhqfWRSU&pg=PA183#v=onepage&q&f=false)

~~~
j_s
Switch .fr to .com:
[http://books.google.com/books?id=_EdbrocXX9MC&lpg=PA183&ots=...](http://books.google.com/books?id=_EdbrocXX9MC&lpg=PA183&ots=D8EhqfWRSU&pg=PA183#v=onepage&q&f=false)

------
zmmmmm
There's a lot wrong with Java, but even while having moved on and learned /
used professionally many other languages I keep coming back to it and its
ecosystem. There is still not another language / platform that provides the
same level of a variety of things that are important to me:

    
    
        * platform independence
        * performance
        * low level features
        * simplicity and clarity (for reading, writing not so much)
        * infrastructure/tools (IDE, visualvm, etc)
    

Admittedly, I lean more and more into JVM languages like Groovy and Scala
these days. But even then I still drop into Java to write parts of the code
that I want to be as fast as possible.

~~~
jimmaswell
You can get all of that and clearer writing in c#, with Intellisense.

~~~
Theriac25
Doesn't C# have "magic" getters and setters, where code like "foo.bar = quux;"
might mean a function call? To me, that's not clearer at all.

~~~
russellsprouts
Yes. However, C# uses the convention that capitalized "fields" are actually
properties, and lowercase ones are true fields.

For example, Foo.X might be an x position, returned from a getter method, and
set with a setter method. Internally, the class make use the Foo.x field to
store it, in which case the getter and setter are trivial. In fact, C# will
write them for you The property could look like:

    
    
        int X{
            get;
            set;
        }
    

(Though my syntax might not be completely correct, I haven't used C# in a
while). C# will automatically create a private field to store the value for x,
and the getter and setter will work as expected.

Classes should, as a general rule, only expose properties and methods to the
outside world. All fields should be private. Yes, accessing a property calls a
method, but so does a Java getX().

Java uses the same rule, except getters and setters are implemented using
setX(int) and getX(). C# properties are the equivalent. The client of a class
should not care how the class stores values, but that the getters and setters
work.

~~~
Someone
_" However, C# uses the convention that capitalized "fields" are actually
properties, and lowercase ones are true fields."_

If only. In [http://msdn.microsoft.com/en-
us/library/vstudio/ms229043%28v...](http://msdn.microsoft.com/en-
us/library/vstudio/ms229043%28v=vs.110%29.aspx), Microsoft advocates:

 _" The PascalCasing convention, used for all identifiers except parameter
names, capitalizes the first character of each word"_

~~~
cmircea
The UI in MonoDevelop / Visual Studio will show the differences during
autocomplete. Also, fields should NEVER be public in a class.

------
msluyter
I primarily use java in my day job, and although there's a lot _not_ to like
about it, some standard complaints are somewhat overblown. For example,
nothing really forces you to use long variable/method names, but even if you
do, a modern IDE -- I use IntelliJ -- with auto-completion makes these fairly
painless. It's not like you have to type every letter of
"SomeClass.veryLongMethodName()" \-- rather, you type "SomeClass.v" and then
hit tab.

Similarly, I never type "for (int i = 0; i < blah; i++)." I type "cmd-J, fori,
return." Etc....

So, I'm not particularly persuaded to the "you have to type a lot" complaints.

Similarly, Spring has simplified a lot of stuff that J2EE had previously made
overly complicated.

That's not to say that Java doesn't have problems or isn't suboptimal for a
certain set of problems. (In fact, it's unclear to me where java might be
optimal.)

~~~
thorum
> Similarly, I never type "for (int i = 0; i < blah; i++)." I type "cmd-J,
> fori, return." Etc....

As someone who didn't realize this existed in Intellij, I think you may have
just changed my life :)

~~~
bhauer
Eclipse has something similar, which it calls "code templates." Features like
these leave me wondering why "excessive typing" is often cited as a criticism
of Java. As far as I can estimate on the fly, I type less than half of the
characters that make up my Java code.

And as the article points out, for readability, verbosity is arguably a good
thing. I sure believe it is, perhaps because I am more distracted by poor
symbol selection and syntax than most programmers I know. Speaking of, I don't
particularly like the C-lineage syntax, Java included. I don't like the braces
and parentheses. I prefer a syntax with fewer symbols and more keywords.
Crazy, I know.

~~~
TimPC
Excessive typing isn't the issue. The problem with verbose code is that code
gets read way more than it gets written. In Java you're often reading 15 lines
of code for something that could be 2-3 in other languages.

~~~
danieldk
And still, I have seen plenty of Java code which is perfectly readable and
Haskell, Perl, or Ruby code (2-3 lines) that resembled line noise. And I am a
Haskell fan :).

The worst offender in Java are IMO anonymous inner classes. But IntelliJ shows
them abbreviated. E.g. IIRC Runnables are displayed in Java 8 lambda syntax.

------
dmk23
Any talk of Java "dying" is just nonsensical

Java hands down is the most obvious choice for any applications that require
performance, yet are too complicated to write and support in C/C++/other lower
level languages. Java JIT is very mature unlike JITs for most other languages,
which largely remain at the level of experimental projects and fall short on
key production requirements.

Given that the entire Hadoop ecosystem is based upon Java as well, it is here
to stay for anything that has to deal with "Big Data"

~~~
fleitz
Yes, that's why kernels are written in java.

If you're writing complex code java is rarely the answer as it requires so
much complexity itself.

Hint: Most java projects just appear to be complex because of the poor quality
of the language (and developers).

Java is hands down the choice for simple projects written by way too many poor
quality developers. The JVM can barely manage 12 GB of memory, Java is a piece
of crap when it comes to anything that's actually complex.

~~~
millerm
I would venture to say, with no facts or figures mind you, that if you were to
evaluate the number of lines of code dedicated to kernel programming to that
of applications running applications on the Internet, that the resultant
figure would be so small for kernel code that it would look like kernel
development doesn't even exist.

Saying that developers who use Java are poor quality is also an awful thing to
say. Yes, there are many "poor" Java developers. But, it's only because there
are so many Java developers in the first place. So, of course when you take
even a small percentage of such a large number there will still be a large
enough sample to look significant. It's the same for all other languages.

Java has been my primary language for the last 14 years. During that time I
have worked with countless individuals who I would regard as some of the
smartest and most competent programmers (who develop using Java) I have known
or heard of. These people make your banks, file sharing sites, massive online
market places, electronic billing etc. work. So, go ahead and bash all the
developers from Google, Sun, SpringSource, Apache Contributors, Oracle and the
other 10,000+ companies out there, but empirical evidence has shown that the
language and platform work.

Your statement is just so "trollish"... seriously?

Edit: capitalized Internet. Letting the run-on sentences and bad grammar fly.

~~~
fleitz
What about java makes it better for high performance / complexity code?

I never said there isn't a lot of java code, or that it doesn't work, my
assertion is that java is not the hands down choice for high complexity /
performance work.

If you've got a bunch of mediocre programmers who can't be trusted to make +
add things together then sure java is a great choice.

~~~
bdamm
It's a natural fit for enterprise programming where time to implement is
usually key and logic is endlessly extended to accommodate whatever new
business requirements emerge after the last round was deployed. And robustness
is valued more highly than raw performance. Use Java - pay for twice the
servers and get ten times the uptime? Done.

That means that days or weeks spent hunting your latest memory corruption
issue makes C a non-option for these applications.

As for mediocre programmers - sure, and a large bunch of mediocre programmers
scales, whereas a small team of star programmers doesn't. Someone has to tweak
the UI. Someone has to implement all that tedious persistence logic. You need
star programmers for that? No.

I'm excited to see if Go intrudes on this field, but it's a big field and Go's
just starting out.

~~~
fleitz
Yet again I ask what makes java good for high complexity / performance code
and get told it's good for managing mediocre programmers.

~~~
kd0amg
In the kind of situation GP describes, what matters is probably the well-
established practices for extending the behavior of an already-built system
without breaking what's already there. A lot of Java practice has built up
around having behavior determined dynamically (OOP is a nice fit for that,
whereas C does not have great facilities for it). Much of the "ceremony"
involved in using the big, complex Java frameworks is about preparing a piece
of code for eventual extension. When some behavior is hard-coded in, it's
difficult to change later, so the code is parameterized over anything and
everything that might eventually change. Of course this looks silly when you
do it for small things that won't change -- no need for FizzStrategy and
BuzzStrategy interfaces when the only thing you'd ever want to do is print
"fizz" or "buzz".

Quite a bit of that programming practice did develop in C++, but Java as a
language provides stronger safety guarantees than C++ (lots of memory-related
errors are difficult to impossible to have in Java) without sacrificing all
that much performance. When you ask for a reasonably performant, statically-
typed, memory-safe, object-oriented language, you're going to get pointed at
Java (and C#). So that's what people use in that domain.

------
jordanthoms
I just wish they'd fix the generics - Been writing some c# recently, and the
lack of type erasure is a really nice advantage.

The decision to do it that way because of backwards compatibility issues looks
really shortsighted now - virtually nobody runs JVMs from before they
introduced generics, but we still have this hack in place to maintain
compatibility with them. Would have been better to break the compatibility and
introduce a little temporary pain, but have a better result 10 years later.

------
fecak
I've run the Java Users' Group in Philadelphia for almost 14 years, and I
specialized in Java recruiting between 1999-2010. I know a lot of Java pros.

Our meetings still get pretty strong attendance (80-120 per meeting), but I'm
seeing far fewer new sign ups and the faces are much the same. There could be
several reasons, but young engineers that I speak with rarely have any
interest in Java work (though JVM is still popular).

Some members have taken to coming up to me and saying "Java is dying, you
know?" at meetings. It will become harder and harder to find engineers to
maintain the Java code as the first generation of Java pros start to move on
to other languages or retire. Java needs some new blood and better PR to
maintain interest from younger devs, and Android may be the best hope.

~~~
rurounijones
I have 0 interest in learning Java, the language, to a professional level.

The JVM on the other hand, with things like JRuby and being able to use
popular Java libraries and things like TorqueBox, is incredibly cool.

~~~
fecak
This is fairly common it seems, and one of the reasons my JUG (and some
others) have modified our guidelines from a Java language focus to a focus on
anything Java language or JVM. It has opened things up and allowed us to dive
into some topics that will keep our audience more engaged.

------
auggierose
Stopped reading the article when he referred to Scala as a scripting language.
Clearly the author has no idea what he is talking about. Sure, you can use
Scala for scripting (I never do) but its main value is in software design,
whereas scripting usually is not about design, but about a quick solution.

------
pmelendez
Well... I am one of those guys who hates Java, but I see Java far away from
dying.

I know it is not very reliable but Tiobe index is still a decent metric.

[http://www.tiobe.com/index.php/content/paperinfo/tpci/index....](http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html)

When Visual Basic dies I would start believing that Java could die.

------
frownie
How many of you are actually handling big Java projects ? Mine is not that big
but big enough to have 15 sub projects, 200 dependencies, 5 people for
maintenance, batch, GUI, JEE stuff. The only thing I can say is taht although
Java is nice, the maven, release mgmt, spring stuff it needs to be actually
manageable is absolutely enormous (the question is, how would I manage that in
another language ?). Contrast that with interpreted/dynamic languages... No
type safety ? But I don't have to wait 3 minutes 30x a day for my build to
complete in order to check that my code is actually running... So well,
there's room for compromise.

For me the tru force and problem with the java ecosystem is that it allows to
separate concerns in the enterprise : a team to provide some Eclipse plugins,
a team to handle release management, a team to deploy thnig on servers, a team
for development, etc.

------
cageface
One of the huge advantages of Java's static typing + somewhat boring/verbose
syntax is that it makes writing powerful tools for manipulating Java code far,
far easier than any of the C-based languages with preprocessors or any dynamic
languages.

After working in IntelliJ for a while with its phenomenal refactoring tools
going back to any other coding environment feels somewhat stone age in
comparison.

~~~
pjmlp
I have been using IDEs since the mid-90's, that is my feeling every time I see
anyone coding as if UNIX System V was the latest version available.

~~~
swah
I don't use IDEs, but it seems that there are only 2 or 3 that really work:
Visual Studio for C/C++, and Eclipse/Intellij for Java. Do you use one of
those?

~~~
pjmlp
I have used all of these during my professional life so far,

Almost all Basic, C, C++ and Pascal IDEs from Borland for MS-DOS and Windows

The initial releases of Delphi IDE

Visual Studio, only after 32 bit support, not earlier

The first releases of C++ Builder

KDevelop

Anjunta

Eclipse

Netbeans

Smalltalk environments

Lisp environments

Native Oberon environment

And a few more not worth remembering.

------
buckbova
Well what do they teach in schools?

When I was attaining my degree during the end of the last century, Java (and
XML) was being trumpeted as the saving grace for all soon to be software
professionals. We were all in love OO programming and this scratched us right
where C++ left an itch. Oh Java Beans and Servlets, how we loved thee.

It’ll take decades before all the code created by those who came right before
me and soon after is gone and we’re gone before Java is considered dying/dead.

From what I see the new generation wasn’t forced to learn Java and doesn’t
want to use Java.

~~~
koomi
I just started university and it's still all Java. I found out one university
in my country (Germany) teaches Scheme in their introductory course, but sadly
I had already enrolled at a different one at that time.

The high school CS curriculum here is also basically an introduction to Java.

~~~
gurkendoktor
I just looked up my old university's curriculum and it must be another
university - our 'Programming 101' is half C, half Java now. I bet our
students will never hear of recursion on campus anymore.

From what I heard as a student assistant, there were all sorts of reasons for
dropping Scheme. First, professors have to use half of their time for
research, and there isn't much useful research left in programming languages
(given that the industry is decades behind that research, anyway). Second,
many of our old professors started out in mathematics, unlike the new
generation. Third, everything is being dumbed down. :(

At least my job is secure...

------
nemothekid
>A recurring prejudice in the forums where the cool kids hang out (Hacker
News, Reddit, etc.) is against Java, the language.

Maybe I've been reading a different Hacker News, but I haven't seen this
sentiment at all one HN, especially with the love for everything JVM (Clojure,
Scala) and all the Database/Big Data tools written in Java (Cassandra, Hadoop,
HBase)

~~~
throwaway420
I disagree with you and think the statement that you quoted is entirely
accurate. People can like the languages and tools built on top of the JVM and
implemented in Java, without liking coding in Java the language itself.

------
mbillie1
Scala is a "scripting language?"

Also,

>When the JVM implementation of Ruby, JRuby, added native support for this
instruction, its performance zoomed past the C-based Ruby VM, which for years
has been the Ruby reference platform. As JRuby's performance continues to pull
ahead, I fully expect it to become the reference implementation. Certainly, it
will become the vehicle by which most organization first try out Ruby.

This was true at some time, afaik the MRI Ruby on 1.9.3+ is faster-than or
about-the-same-as the equivalent JRuby implementation. I also know zero people
who were first exposed to Ruby via JRuby.

JRuby is awesome btw. I just think this article has a bit of a defensive
tone...

~~~
acqq
[http://benchmarksgame.alioth.debian.org/u64q/jruby.php](http://benchmarksgame.alioth.debian.org/u64q/jruby.php)

There are some areas where JRuby is 3 times faster and the areas where it's 2
times slower. Not impressive, compared to native Java implementations:

[http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...](http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=jruby&lang2=java&data=u64q)

Where you can get even two _orders of magnitude_ speedup.

------
primelens
Aside - I miss the paper __Dr. Dobbs ' Journal __from the early nineties. Is
there a modern equivalent?

~~~
ternaryoperator
Dr. Dobb's puts out a monthly PDF issue. It's smaller in terms of content than
the paper issues of the 90s, but it's in that mold. Also, the website posts
new feature articles every Tuesday, covering a fairly wide range of
programming topics. Most articles have code.

~~~
primelens
Yes, I know about the PDF issues, and I also realize that there are so many
great resources on the web that having a dedicated general purpose programming
magazine doesn't make business sense anymore.

It is quite possible that what I miss is really my childhood and the
excitement of waiting for the magazine and learning about things (most of
which I didn't fully understand) with wide-eyed wonder. But of all the
computer magazines I have ever encountered I think it was Dr. Dobbs' that
struck the best balance between CS academia and the hands-on world of
programming. It straddled that world between abstraction and application
perfectly in my opinion.

It would be a wonderful role to resurrect in the age of big data and
increasing statistical and algorithmic sophistication. Won't happen, though.
So I'll just wallow in my moment of nostalgia :-)

------
chatman
With Hadoop, Lucene, Solr, etc. written in Java, there is no doubt that Java
is here to stay. None of these libraries (or many others) have competing
implementations written in other languages.

~~~
alpatters
"None of these libraries (or many others) have competing implementations
written in other languages."

Except the ones they were written to copy. Each example you give is an open-
sourced clone of an pre-existing version implemented in a different language.

~~~
sfjailbird
That's not true at all, Lucene is a Java project from the beginning, and has
since been copied to virtually every other environment because it is such a
kick-ass indexing engine.

~~~
alpatters
So in no way did they copy Google's which is implemented in C++ ?

Though I agree with OP - these projects and Java are here to stay for the
foreseeable future.

~~~
chatman
No, they didn't copy any of Google's implementation. They simply implemented
efficiently the TF-IDF based document retrieval model.

------
todd8
Java isn't new anymore. It wasn't really groundbreaking even when it was new
in 1995:

    
    
      * Object-orientation: Simula-67 mid 1960's, CLU 1974, Smalltalk 1980
      * Garbage collected memory: In Lisp since 1959 !!
      * JVM: UCSD Pascal had a similar idea in 1974.
      * Syntax: Java's was a basic evolution of the Algol-68 -> C -> C++ chain
      * Performance: in 1995 Java was too slow and too big
      * Write once, Run everywhere: other than assembly language, all languages strove for this.
    

Nothing in the language was that special. Most of it's features weren't new,
but it went on to be one of the most important programming languages because
the engineers at Sun had put together a good, solid, language on a good,
solid, implementation. They had a vision, largely realized now, of a language
to support professional software developers. It is now very fast, the size of
it's run-time doesn't seem so significant in 2013, it's current garbage-
collector is state-of-the-art, and it's eco-system of libraries and frameworks
is now unsurpassed.

Java may have already peaked. This doesn't change the fact that it has been so
important and that experiences with it will shape the future of software
engineering. I was impressed with Rob Pike's talk on the Go language:
"Language Design in the Service of Software Engineering" [1]. It seems to me
that Java's success was driven by largely pragmatic thinking and that the
designers of Go are now attempting a similar path to success.

Public service announcement: Don't squabble. If you program in C, be happy,
your language is the very best for embedded systems and kernel development. If
you program in C++, be happy, your language is the very best for developing
programs that deal with complex data structures and must run as fast as
possible while using memory efficiently. If you program in Objective-C, be
happy, your language is the very best for IOS and Mac OS X programming. If you
program in C#, be happy, your language is the very best for developing
Microsoft .NET applications. If you program in Python, be happy, your language
is the very best for rapid prototyping and exploring big-data. If you program
in JavaScript, be happy, your language is the very best for client side web
programming. If you programming in Haskell, be happy, your language is the
very best for exploring reliable software through detailed specification of
types. If you program in Ruby, be happy, your language is the very best for
putting together Rails apps (and yay, it's getting faster). If you program in
Lisp, be happy, your language is the very best for getting the most out of
Emacs. If you program in Visual Basic...be happy, there are better languages
you can learn.

[1]
[http://talks.golang.org/2012/splash.article](http://talks.golang.org/2012/splash.article)

------
KevinEldon
Java is doing just fine and with the addition of closures in Java 8 I expect
the already incredibly rich set of libraries to improve dramatically.

~~~
mbillie1
There are some pretty awesome libraries already... check out
[https://github.com/jnape/Dynamic-
Collections](https://github.com/jnape/Dynamic-Collections)

------
drunken_thor
I am really sick of these articles. "Java is alive and well", "Brand new
exciting things that tell you Java is still a leader" blah blah blah. To me
Java is a great tool, the JVM an even better tool. No one said your favourite
language is dying and if they did, they are naive. These articles only give me
a small hint that you think java is dying and are trying to do your part to
keep it alive.

I guess what boils down to is that I hate articles that give me the impression
of desperation. Maybe this is my own problem in the long run so I don't know
why I wrote this comment.

~~~
was_hellbanned
I agree. It's link-bait, battling the other link-bait about how Java is dying
and { x, y, z } is the #1 language, will dominate any day now, and anyone not
coding in it is inferior.

Unfortunately, as technology has matured, it has become just as politicized
and petty as anything mainstream. Countless people make their reputation
and/or income writing blog posts and churned articles, living in the tech
periphery like leeches, without creating any actual value. I think this is
part of why I have so much nostalgia for the 80's and 90's.

Code in whatever makes your life least painful, and learn whatever's in demand
for your desired career path.

------
pan69
I'm just getting back into Java (both platform & language) and I'm really
excited about it. It has really matured over the past 10 years both in tooling
and application architecture philosophies. I'm really looking forward to pick
up Java, Spring, Hibernate (maybe I settle for JPA, not sure yet) and my old
trusted friend Tomcat.

Oh, and I might throw in some Scala, Groovy and JRuby in here and there as
well.

------
linuxhansl
I use Java, C, C++, Python, Ruby/jRuby, bash, Perl, etc.

The right tool for the right job. Anybody making unconditional statements
about the decline (or not) of a language is a fool (IMHO).

Likewise saying the "C++ is better than Java", or "Java is better than Python"
or ... is devoid of any meaning without specifying the domain of the problem
to be solved.

------
retube
The best thing about java is the ecosystem around it - a massive range of
mature and robust open source libs to do just about anything you like (parsing
HTML, part of speech tagging, search indexes, neural networks, fast caches,
networking tools, web servers/containers, email servers etc etc) Does any
other language have this variety available?

------
memracom
Java is not dying, it has just started its long slow decline like COBOL did
back in the 1980s. But COBOL is still with us and so will Java be with us for
a long time. But the momentum is picking up on alternate JVM languages, in
particular Grovy, Scala and Clojure. Of course there is also Python(Jython),
JRuby, PHP and many others that run on the JVM, but Groovy, Scala and Clojure
are the triumvirate that is picking up steam and will end up pushing Java down
into the depths where, like C, it will remain as the tool of choice for
building JVM libraries.

The Oracle JVM is also not the only JVM available these days and there are
even some commercial JVMs that are higher performance than Hotspot. I think
one could make a strong argument that the JVM will outlive Java itself by a
large margin. Say, Java fades out of common usage by 2050 but the JVM is still
going strong in 2150.

------
nilved
"Java is dying" is wishful thinking. It's not the case, but we can only hope
it will be. Currently, it does a good job of marketing to developers too good
for Ruby and Python and not good enough for C.

~~~
ekimekim
I understand the "not good enough for C" comment, but why "too good for Ruby
and Python"?

Not trying to pick a fight, just would like you to elaborate.

~~~
PeterisP
Welll, the reasoning behind it might be from two facts - a) Ruby and Python
both are far better beginner/learner languages than Java & others - I mean, if
some kid wanted to learn programming, I'd suggest to start in those because
they don't have distracting boilerplate; and (b) other things being equal,
Java does get you better execution performance than Ruby/Python; not on C
level but it's halfway in between.

But still "developers too good for Ruby and Python" is an interesting
statement; IMHO the only ones who'd claim to be 'too good' for Python/Ruby
would be authors of their own languages or maybe the hardcore Lisp or Haskell
crowd.

------
TeeWEE
There is Java and there is the JVM. Both are doing well, but Java is
progressing slowly, and more and more developers -why actually now what they
are doing- are looking into alternatives. These may also be languages running
on the JVM though.

Java as a languages is getting old, in terms of concepts and verbosity.

Functional programming is what is -the next big thing-. And most java-only
developers don't know how todo that.

While it is still thriving, there is an unstoppable move to newer, more
functional languages (which can run on the JVM too).

------
grn
I haven't programmed in Java but I sometimes read Java source code. I must
admit that I like the language which to me is a better C++. However I don't
like the way it is used i.e. tooling, libraries and programs. I don't like
AbstractProxySingletonFactories, XML configuration files, long method names
and lots of other things. That being said I believe that a change in the
programming culture surrounding Java may lead to more pleasant programming
experience.

------
prottmann
Dying? I don't know, but surely not dead.

But look at the beginning of Java, at that time it was "cool" and growing. Now
Java is an adult and not cool, other languages grow, build new communities,
new tools and new possibilites, that's why they offer more fun and many people
think java is dying.

Java will be there for many many years, Cobol still there too ;-) But someday
it will die, that's normal life.

------
damian2000
Java is a pretty boring language, it must be said. But that's what makes it so
good for real world usage - its got a lot of library support and many issues
tend to have been ironed out already. Couple of weeks ago I was using
Selenium's WebDriver SDK with a Ruby client program. It failed in some obscure
TCP/IP stack error coming out of the C Ruby implementation. Using a java
client just worked.

------
edem
Check the tendency:
[http://www.itjobswatch.co.uk/jobs/uk/java.do](http://www.itjobswatch.co.uk/jobs/uk/java.do)

------
arikrak
I searched various job sites by programming language, and Java always came out
on top (by a significant amount) for listings, except on the startup job
boards.

------
Yaggo
Technologies with giant backers (e.g. Java or Windows) have massive inertia
keeping them seemingly alive for years (or decades) after losting their soul.

------
Apocryphon
Why did Google adopt the language for Android?

~~~
pjmlp
They didn't, the startup Android Inc was already using it.

------
NAFV_P
I thought C was dying out. I must be living in the dark ages.

~~~
ekimekim
I think C has kind of hit equalibrium, in that it's not often used for things
outside its "niche", but with no other language threatening it within its
niche.

~~~
NAFV_P
Is forth considered to be in the same niche?

~~~
pavlov
Not really. Forth is nowadays only used for tiny embedded systems.

In contrast, C is the glue language for pretty much everything. Even the
latest operating systems like iOS and WinRT use C as the base level API
language that is callable from anywhere. They do have significant libraries
and conventions to manage that (Apple uses CoreFoundation, Microsoft uses
COM), but it's still C.

------
xolve
Anybody using Rust?

------
francis-
Dead cat bounce.

------
AsymetricCom
Java is dying because it requires more and more resources to make it work.
People look at the growing resource requirements and think "wow, look at how
Java is growing! We even are teaching middle schoolers Java now!"

Wasn't the point of Java to release developers from having to worry about
memory? Well, now we have to worry about everything else. It's a failed
abstraction and now we have to live with it.

~~~
ternaryoperator
"Wasn't the point of Java to release developers from having to worry about
memory?"

I think you're thinking of releasing them from worrying about pointers, which
it basically did. When it first came out, its stated goal was to release
developers from having to worry about portability, which it did.

