> GC Sucks So Badly, That You Should Avoid Using Memory
I'm assuming this is from before Java 8. The latest GC algorithms don't do this.
> Worst of Exceptions and Value Checking
Sometimes the correct thing to do is to throw an exception and other times it is to return a sensable value. An exception is an unrecoverable state, a null is a sensable value for when nothing exists. Something not existing and an unrecoverable state are two very different things.
> Won't cast an int to a long
Again, are we using the same language? This works. see code example at the end.
> name clash: X and Y have the same erasure
This is not sensable behavior but entierly avoidable. Objects contain data and then process them, then return the processed data to another object. The Java way of doing this is to pass "List<Long> listOfLongs" and "List<String> listOfStrings" to the constructor of foo and to have funcLong() and funcString().
> incompatible types
I've never seen this but I also suspect that this isn't an issue as I've never run into it and I've had interfaces in interfaces.
> static methods and members in a class
Static means the meaning of the method or object never changes. It will mean the same thing in every instance of usage. As such this makes sense. You never need to override a constant meaning as it will always mean the same thing.
> The "class" type is an afterthought
What does he mean by this?
> No control on member access
Use lombok. Not an issue and is fixed at compile time, not runtime.
> RSI
This makes no sense. An IDE is a tool that Java is deisgned to make use of. Locking yourself in your cave and saying it's bad isn't going to pursuade anyone.
> Camel Case
Nameing conventions aren't a reason a language is bad.
> Class-centric
That is the idea behind Java. The other concenrns not addressed by the title have been fixed by the Java 8 additions allowing you to treat one-method interfaces in Java 8.
> Iterators SUCK!
That is an implementation but it's fairly standard to just have tihs backed by some form of collection and see if there is data left in it. I usually use an index in an array and see if I have run past the end of the array.
> foreach doesn't take iterators
Yea this is crap.
> Function Pointers -- Missing
Java 8
> Constructors can't call each other
Again see the code at the end.
> Methods With the Same Name as Constructors
Yea that's allowed, I don't see what's wrong with that. It's a real function name so it should be allowed. I've never accidently made this error.
> Run-time Dispatch: Fantasy
This is a design pattern issue but you're meant to use the highest or lowest version of an abstraction. From there you can ideally handle it in a generic way or if not you can use if (x instanceof Object) to filter out specific cases.
> No Globals means Frameworks
This is where decorators and static/singleton classes come in handy. You can do some amazing things with decorators, singleton/static classes, and if you need it a bit of reflection.
> import is Useless
You can just use the fully-qualified name of the other class and it will work fine. I've had maybe one instance where my naming conflicted with another package but that was a rare case.
> No List Literals
Arrays.asList
> Inner classes Don't Work
I don't know what he means as this works perfectly fine for some design patterns. Inherit state? No way. Provide impelemntations of an abstract/interface for a specific object? Yes way.
In ArrayList it is perfectly fine to make an ArrayListIterator as they are the same bits of ideas and as such should be in the same file.
I also prefer state enums to be defined in a class.
> Java is So Hard People Prefer to Write Code in XML, Jython, Scala, and Clojure
I don't do this only """ENTERPRISE""" Java developers do this. There's a lot of great work being done moving away from this mentality but there is still a lot to be done.
> Speaking of the JVM...
I'd love some numbers on these claims.
> DNS Client Implementation
Yea this is a problem. It's in here for compatability. There are many libraries implementing this better at the moment.
> Sun Microsystems May Sue You
I don't know if this applies to OpenJDK.
> Why Use Java at All?
Why use any language at all? Write binary and opcodes (like I've been doing in my CPU project). It's very fun!
In seriousness Java gets concurency right and I've not found another language that lets me write concurrent code like this ever before. Very nice platform to run on and one of the worlds best VMs. Everything is simple and documented well. I don't need to read a novel to get something working. I can think of a class, type that a control-space on my IDE, get a list of classes, find the one in the right package and move on. No google, no searching, just tooling and built in documentation. What's even better is most of the language is implemented in Java! I have the sources downloaded so CNTRL+Click and I can see everything's implementation! I'd love to see a python dev do that (I cant and I've been writing python for years).
I'll be emailing the author at this email: jgardner @ XXX .net and giving him this comment. I hope he can rebute some of these points.
class Test {
private final int i;
public Test(int i) {
this.i = i;
this.test(i);
}
public Test() {
this(10);
}
private void test(long number) {}
}