Java is a useful language, has many strengths, is widely used, and is attractive early on when you are learning because it is consistent and predictable. Much good software has been written in Java. It even has an aesthetic appeal, as it has been designed with great care. Java's shortcomings are more subtle. Curiously, its problems involve issues that one might not even notice at all early on, or perhaps, for a long time -- and this is exactly why they are so serious.
Java has a certain inherent inflexibility, partly in its technical details (such as a verbose syntax that can't be shortened easily), but also its culture does not encourage solutions to these shortcomings, but rather an embrace of structure and consistency, often at the expense of clarity, maintainability, and flexibility.
The bottom line is that compared to most other languages, Java code is more heavyweight and less agile, and longtime Java programmers often have a bias toward over-engineering.
1) It's relatively verbose and many things are clumsy to do in the language directly, e.g. work with SQL, building a DSL, working with functions, regular expressions, etc. The amount of plumbing code you have to write to get stuff done is often pretty bad. Which is also one of the reasons there are so many frameworks for Java. The main reasons for this are probably static typing and it's inheritance from C++.
2) The officially pushed frameworks were designed by committees with lots of mingling of powerful companies trying to make a buck off the language (which means selling it to big enterprises which, right, are the shining example of how we should all do software development). That has led to awful over-engineered technologies like J(2)EE, big complicated application servers and a decennium worth of bad examples to both learning programmers using Java and programmers using other languages to point at.
# I believe that focusing on being the number 1 solution for enterprises and trying to monetize of the language has been particularly disastrous. That this was done with some degree of fairness in mind (make standards so that vendors can compete openly) only made the bloat worse.
# When many of these technologies were designed, many people believed that the future of software development was in commoditization. Components, not languages, high level design, not coding, were seen as the future (you'll still run into plenty of people who think you should more often than not buy rather than build, but unlike a decade ago, this is not taken for granted by the majority anymore). This was the time of the 4th generation languages (though already declining), UML roundtrip tools, WS-*, etc, and Java's ecosphere formed in that period.
3) Its an established, middle-aged language that is popular by Fortune 500 companies; you wouldn't want to be seen with it by your brogrammer friends!
Also like to add:
one of the issues I've run into with java is managing a complex type hierarchy. It's a pain because rearranging the hierarchy in any way generally means updating dozens of classes to make sure that they provide all the necessary functions. "Design patterns" generally make this worse, and generate code bloat.
Courtesy:-DZONE
Java has a certain inherent inflexibility, partly in its technical details (such as a verbose syntax that can't be shortened easily), but also its culture does not encourage solutions to these shortcomings, but rather an embrace of structure and consistency, often at the expense of clarity, maintainability, and flexibility.
The bottom line is that compared to most other languages, Java code is more heavyweight and less agile, and longtime Java programmers often have a bias toward over-engineering.
1) It's relatively verbose and many things are clumsy to do in the language directly, e.g. work with SQL, building a DSL, working with functions, regular expressions, etc. The amount of plumbing code you have to write to get stuff done is often pretty bad. Which is also one of the reasons there are so many frameworks for Java. The main reasons for this are probably static typing and it's inheritance from C++.
2) The officially pushed frameworks were designed by committees with lots of mingling of powerful companies trying to make a buck off the language (which means selling it to big enterprises which, right, are the shining example of how we should all do software development). That has led to awful over-engineered technologies like J(2)EE, big complicated application servers and a decennium worth of bad examples to both learning programmers using Java and programmers using other languages to point at.
# I believe that focusing on being the number 1 solution for enterprises and trying to monetize of the language has been particularly disastrous. That this was done with some degree of fairness in mind (make standards so that vendors can compete openly) only made the bloat worse.
# When many of these technologies were designed, many people believed that the future of software development was in commoditization. Components, not languages, high level design, not coding, were seen as the future (you'll still run into plenty of people who think you should more often than not buy rather than build, but unlike a decade ago, this is not taken for granted by the majority anymore). This was the time of the 4th generation languages (though already declining), UML roundtrip tools, WS-*, etc, and Java's ecosphere formed in that period.
3) Its an established, middle-aged language that is popular by Fortune 500 companies; you wouldn't want to be seen with it by your brogrammer friends!
Also like to add:
one of the issues I've run into with java is managing a complex type hierarchy. It's a pain because rearranging the hierarchy in any way generally means updating dozens of classes to make sure that they provide all the necessary functions. "Design patterns" generally make this worse, and generate code bloat.
Courtesy:-DZONE
No comments:
Post a Comment