Why I don't like Java
dgeex.de
dgeex.de
But the section talks about immutable strings (nothing to do with GC), syscalls (ditto), and only at the end about no manual memory allocation. Not even a word about why GC in Java is terrible (and why automatic memory management in Ruby and Python is not terrible).
> No pointers
Why is it a bad thing? Only because author wants to do pointer arithmetic?
> No preprocessor
And good for Java. CPP is vastly underpowered, thus being quite a trouble. Either macro system should be powerful, working on AST, or not there at all.
> No UNIX Syscalls
Oh, my. No UNIX syscalls in web browser. No syscalls on a DVD player. What a shame.
> It’s not suitable for big projects
ElasticSearch and Hadoop beg to disagree. I wonder how big systems has the author in his portfolio.
> It’s not good as a PoC language
Because...? Only because it's verbose? We've been through this few arguments before.
> No global variables
Author fails to provide any argument why this is bad. "I use them for debugging" is very, very, very weak.
> Java browser applet are insecure
So don't use them. Implementations of applets suck, we all know it, but nobody uses those anymore for anything serious (except for hardware vendors, who are generally clueless with regard to writing software).
I don't see why should people abandon Java for writing services because applets suck.
> Why then there are non-free implementations? What’s wrong with OpenJDK? What is IcedTea? Which implementation belongs to Sun?
One could say pretty much the same about Ruby, Python or C. I don't see why should this be held against Java and not against C.
Most of the arguments are pure trash. Don't bother reading.
It's like saying that a bus is slow and big, comparing a bus to a car. Obvious points are obvious.
Java is verbose. Any language used outside of its sweet spot is verbose--the PHP required to read a header, for example, is much shorter than the equivalent C. The MATLAB for backsolving a matrix is much shorter than the equivalent in Ruby, but at the same time, accessing the AST of a MATLAB program is magnitudes harder than in Ruby. For the benign task of shuffling a bunch of registers, a single assembly instructions beats out every other language.
The GC is terrible. Author points out that they really care about what they're program is doing (why, one wonders?), and so of course any GC solution is worse than bare hands and sbrk() and mmap(). There are well-establish issues with GC in the JVM, especially for graphics or anything with a bajillion little allocations, but those are also all well-solved problems.
No pointers. Author complains about not having pointers, which kinda makes sense for a GC'ed language. Pointers are of limited utility if the language is high-enough level, so their omission in Java is perfectly reasonable.
No preprocessor. One of the only things I agree with for the author--the lack of easy metaprogramming tools in Java is kind of sad. At the same time, it means that Java looks the same everywhere. C, also, is probably one of the most braindead preprocessors you could ever ask for. Nothing is stopping you from using sed as part of your build chain for Java, if you want equivalent power.
No UNIX syscalls. So, first, this is wrong--you can do this with native extensions. Second, though--the entire point of the JVM and runtime is that you just let it do the right thing (or its closest approximation) and get on with your project. What good would Unix syscalls do me when running a jar on Windows?
It's not suitable for big projects. This is absurd. Java is one of the few languages I would actually consider as having large-scale development as a selling point. All of the other stuff the author complains about? Yeah, that makes a Java codebase easier to have plug-and-play development on. Lots of large projects use Java, successfully. They're jungles, sure, but they're jungles that work--and consider how awful they'd be in Javascript or C or (urk) C++.
It's a bad PoC language. I've heard a lot of complaints about Java, but its lack of ability to be exploited has seldom been one of them.
There's more, of course, but I'm bored.