This is great for me, but not necessarily the most efficient way to manage memory. As a Java developer, I don’t need to manage my memory programmatically: I can leave it all to the garbage collector.
When designing languages, you go either minimalist, and rely on the users to implement all the functionality they need or you go for the opposite, and provide an extremely rich language where developers can rapidly produce software. However, one man’s feature is another man’s bloat and I suppose this is where a lot of the debate stems from. The JVM and the Java runtime classes are feature packed. Yet, you must think about what you get for your money, so to speak. A simple “Hello world!” class of say a kilobyte will still require the entire JVM, and the several megabytes that entails. Object-orientated languages typically have a slightly larger memory footprint as you have to carry around a lot of information about all your objects currently initialised.
I don’t believe that it is, so I’m not going to pretend. To be honest, even the most faithful Java evangelist would have trouble believing that Java is light on memory usage (relatively speaking, of course). It suggests to me that not all the criticism is entirely objective! This article aims to discuss some of the criticisms aimed at Java and see whether they are justified.
Funnily enough, in my experience, many people who have commented to me, “Andy, I don’t like Java because it’s slow” are the very same people who use Perl/Python/PHP. The corollary being that Java on the desktop is infeasible for those without the patience of a saint. Coming under yet another two-pronged attack, you’ll typically hear complaints falling into the two camps:
#Snappy trap skin
Following on from my previous article, the Java platform has an even greater image problem that is more than skin deep.
0 kommentar(er)
