Is Java really Dying?
Came across this article in BusinessWeek via Kurt.
So here are the points that BW puts it to say Java is dying:
1. Evolution of LAMP.
My View: LAMP has been there since a long time only the name was missing.
2. Number of books sold by a publisher.
My View: When you have got tons and millions of resources online, you may tend to not buy books. The fall in book sales is no indicator of technology dying at the same time rise in sales of new technology is no indicator of its success, it could be that the new technoloy has not matured enough to provide the amount of resourses that are available with an already successful technology.
3. .NET picking up.
My View: Existing Java developers will not run away to .NET
4. LAMP is more preferred for web development.
My View: Think enterprise and claim the same :)
5. Number of developers. (Increasing for the new technology)
My View: How many number of designers, architects and senior developers?
6. AJAX is the next choice.
Here is the piece of information "while sales of books related to AJAX, a new Web site-building formula used predominantly..."
AJAX, new web site-building formula :-O
Ok.. serious! if they meant on the UI front AJAX is taking over, how come Java is impacted? The success of Java + AJAX can be seen anywhere across the web starting from Google (Blogger).
Can Java Die so soon?
My View: NO
Why?
1. Its not just a programming language.
2. Wide industry support.
3. Learn once, Apply anywhere. (Desktop, Server, Mobile, Consumer devices.. anywhere).
4. Proven.
5 - 100 add all the points you know already from the time when you started learning Java. viz. security, portability, object orientation, stardards driven etc. etc. etc...
Please feel free to share your views.
[Resource-Type: Views; Category: Java]
5 Comments:
LAMP is not that new... it's been around since years... but I don't think that it will be that dangerous for Java.
PHP is a crappy language and it leads to poor programming skills. I work with a guy who started with PHP and when he started with Java his code looked horrible. A lot of his bad syntax style came from his PHP-background. And when it comes to object orientation he is sometimes completly lost.
PHP stinks.. its maybe ok for some blog,forum,small-CMS , but at least when a project gets bigger Java is the language of choice.
12:39 PM
I think that someday we will all become enlighted and realize that the language/platforms wars were absurd...
At every new release of .NET/Java/Lamp someone declares that the others are all dead. Every one of them is too entrenched to die out anytime soon.
4:30 PM
i'm also not a big fan of platform wars, in the end, i believe it comes down to project specifics, scope, short-term vs long-term goals.
With that said, i find that most transactional PHP web applications are mere HTTP-interfaces to mySQL databases. Nothing necessarily wrong with this until scaling becomes an issue. Even then, through database partitioning and replication, memcached and various other techniques, it's still practical to scale applications in this model.
However, i believe there are often plenty of opportunities missed in HTTP-land, to alleviate load on a back-end data infrastructure. This is one of many places a simple Java Servlet Container (without even going into J2EE-land) can definitely shine.
A Java Servlet Container, such as Jakarta Tomcat, runs as one process with its own block of allotted RAM on a host machine. Today, RAM is cheap.
If an application serves large amounts of syndicated data, possesses large amounts of configuration information, all of which are stored in a mySQL database for easier manageability, proper in-memory caching algorithms can help. They're developed as part of the application running inside the servlet container. You basically load-up the RAM of the machines closes to the end-user, to completely alleviate disk and/or network/socket IO. As soon as the end-user hits your app, BLAM the data's right there in RAM, spit that out.
In other words, this model allows you to reserve database roundtrips for requests of a more transactional nature. Keep the static, semi-static, shared stuff in RAM.
Of course, if dealing with too many transient objects stored in RAM, garbage collection might bite you in the butt.
Such techniques are not possible in PHP-land, which is why memcached was developed. In PHP, every single end-user request MUST result in some form of I/O to either hard drive or database. You don't store stuff in memory in PHP.
4:39 AM
I'm actually not anonymous, but I seem to have forgotten my blogger password...
Anyway, while I seriously doubt that J2EE development is "dying", I do think that we're in some kind of transition right now. The collective J2EE / server side community went down several blind alleys over the past few years (EJBs are hard to write, hard to deploy, and hard to maintain, let's all agree on that). There have been a number of recent indications that "thin is in" again, and everyone is looking for a way to achieve the kind of robust enterprise-ready scalability and security of a J2EE implementation, without all the low-level crap-work, and without piecing together 50,000 separate open source projects.
I also think that the "inherent security and scalability" of J2EE apps is a bit overstated. Security and scalability come largely from design and deployment decisions, and are therefore largely (although not entirely) language and platform independent.
Nevertheless, Java has been around for 10 years now, and is well established. It is quite unlikely that it's "dying", and more likely that it's settling into the "boring end" of the technology frenzy cycle. At one point in time in the late 1960s, COBOL was THE way to write code, and IBM reigned supreme. Read any good COBOL books recently? Why not? ...it's boring, that's why. There is nothing new to be written about COBOL. While J2EE/Java are no where near THAT boring yet, they've started their approach into Yesterday's Boring Technology Airport, and will be arriving shortly. Please fasten your seat belts, and remain seated until the captain has turned off the seat-belt sign. Be careful removing overhead baggage as contents may have shifted during flight.
5:58 AM
I don't know how many serious developers have time to read books, a part from the fact that not being book savvy is what makes you are good developer (my opinion). Mostly the cycle is solve the online tutorials and start coding/posting problems on forums .... : )
4:45 AM
Post a Comment
<< Home