Over a million developers have joined DZone.
Platinum Partner

Is Java Dying? No Way!

· Java Zone

The Java Zone is brought to you in partnership with ZeroTurnaround. Discover how you can skip the build and redeploy process by using JRebel by ZeroTurnaround.

After reading several blogs and comments on the demise of Java, I felt compelled to post some interesting facts.

Only a small percentage of developers go to conferences like JavaOne. These people constitute the majority of those who read, write and comment on blog sites and they are the first-adopters of new technologies and languages. These people are enthusiastic evangelists of new and cool technologies fueling, for example, the rise of Dynamic languages (which I applaud). But these same folks can be vocal complainers, ignoring possible work-arounds of existing features in languages such as Java, and predicting the death of Java. For many developers, these dire predictions can inspire fear for their jobs, compelling some to prematurely drop Java, further perpetuating the rumor that Java is indeed dying.

Maybe there are too many frameworks? Maybe Generics were an overly complex feature to introduce and maybe Closures will be too? It is hard for Sun to sustain the velocity of new features every year, and maybe this is a good thing that they do not. – It gives people breathing space.

It is impressive that Java has been consistently popular for over 12 years (Ruby was created in 1995, but only really became popular once David Heinemeier Hansson released Ruby on Rails in 2004). In our industry it’s impossible to predict how something will be used in a decade and maybe we shouldn’t try. Have Sun got carried away with the popularity of Java and tried to make it into something it wasn’t designed to be, creating an overly complex beast? Are these proponents of Java-Death simply Java gurus that who are just seeking perfection?

Do I think Java is dying? – No way! Each programming language goes through changes: it’s all aboutevolution. [Most] people do not program in Assembler anymore. The next generation of languages will build on the limitations (mistakes?) of the past and be more suited to the hardware and designs of the future. For example, concurrent programming is very difficult to manage in Java so maybe laguages such as Fortress will be indicative of things to come. With multi-core processor machines the norm, the industry will demand that future software development take better advantage of this hardware advance.

So here are a few facts:

  • The JavaOne Program Office announced that there were around 15,000 attendees at JavaOne this year. (There was also a lot of negative discussion regarding JavaOne, but this criticism was really about the show rather than Java–see my comment on Jason Lee’s: Postmortem on JavaOne 2008)
  • One of the most impressive announcements at JavaOne was that Sun have made a 68% performance increase running Java 5.0 against Java 6 update 10. On the same hardware (showing their commitment, at least, to the JRE)
  • Released only last month, Effective Java 2nd Ed by Josh Bloch is ranked #291 of TOTAL book sales at amazon.com and #8 in the Computers & Internet sub-section
  • Without too much analysis (i.e. just typing in the following keywords in Dice.com) current vacancies for the following are:

            Java     15,337
            Ruby    818
            C++      7,633
            C#        7728
            Python  1,395
            Perl     5,463
            Cobol  1,131
            Assembler 196

        - I was just interested in these last two ;-)

Note that I haven’t even commented on the millions (billions?) of dollars organizations have spent on applications written in Java. Are they about to drop and rewrite these applications in the next generation of languages?

Originally from http://www.enerjy.com/blog/?p=296

The Java Zone is brought to you in partnership with ZeroTurnaround. Discover how you can skip the build and redeploy process by using JRebel by ZeroTurnaround.


{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}