[jgardner1]

Hi, this is the original author. You sent me an email asking me to respond so I will.

> Are we using the same Java?

No, I originally wrote the article back in 2008 or so.

>> 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.

AFAIK people still complain about the GC. I've noticed that more modern languages don't have advanced GC like Java's.

>> 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.

I rarely deal in absolutes when I'm coding. It's all about engineering tradeoffs.

It's true that something not existing may not be an error, but often it is, particularly when you expect it to exist. IE, if I go to fetch a record by ID from the database, but it's not there, there's no way to recover from that type of error.

An exception does not represent an unrecoverable state. It just represents that your code doesn't know the proper behavior. For instance, in a web server, the proper behavior is to throw a 500 and log the exception causing the error. In a UI, you might want to show a dialog box explaining the error and its source, maybe even sending the stacktrace to the developers. A CLI will print the exception and cease operation.

Mid-level code doesn't necessarily know what the appropriate response to an error is, so it shouldn't have to have to check for them. If things are working as expected, no exception. If something goes awry, let the calling code figure out the right response.

>> Won't cast an int to a long

> Again, are we using the same language? This works. see code example at the end.

Did you read my update?

> > 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().

So, you have to encode in the name of the function the type of parameters it takes?

And what's the point of classes if you can't take advantage of them?

> > 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.

It is an issue. LinkedList is a type of List, so a List<LinkedList> should match a List<List>. It certainly knows that a LinkedList<List> matches List<List>.

> > 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.

You seem to use this argument a lot: "You never need to..."

Did you read my introduction to the topic?

> > The "class" type is an afterthought

> What does he mean by this?

Originally, classes in languages like C++ were simply syntactic sugar. You could not have a variable that stored a class. It didn't make any sense, anymore than a variable that stored a function.

Java continues this tradition.

In every other language, classes are first-class values that can be stored by any variable. So are functions.

The idea of storing a class in a variable is probably just as foreign as storing a variable in a function to a Java coder.

> > No control on member access

> Use lombok. Not an issue and is fixed at compile time, not runtime.

Or I could use Python.

> > 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.

Let me help you understand.

A programming language like Java consists of many parts, but in the end, it is a program that takes a bunch of text files and converts it into bytecode that the CPU can understand and execute.

Why do you insist on using an inferior programming language that requires the use of specialized tools, when those tools can be built directly into the programming language itself? IE, if I want to create a class, I'll just type "class A", not load up an IDE, click around a few times and hope I fill in the boxes right to have a hundred lines of boiler-plate code autogenerated for me.

It's not the 1960s anymore. We can write code that writes code. Let's do more of that and less fussing with the minor details that no one cares about.

> > Camel Case

> Nameing conventions aren't a reason a language is bad.

It is if you have to type those names.

> > 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.

I'm not familiar with Java 8, but it sounds like they realized how bad of an idea it was if they're moving away from it.

> > 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.

So you're saying I shouldn't use iterators because it's easier just to code around them?

Iterators can be a powerful programming paradigm that is a major head-ache saver and time saver, but Java's implementation is so horrible you're recommending avoiding it. Got it.

> > foreach doesn't take iterators

> Yea this is crap.

I bow to your superior arguing skills.

continued ...

[gravypod]

> AFAIK people still complain about the GC. I've noticed that more modern languages don't have advanced GC like Java's.

I don't know many people who complain about Java 8.

> Mid-level code doesn't necessarily know what the appropriate response to an error is, so it shouldn't have to have to check for them. If things are working as expected, no exception. If something goes awry, let the calling code figure out the right response.

That said Null is still a valid responce. Sometimes it gets out of hand from implementation buy specifically .INI file readers I'd expect to return Null or Default if available for an unset property. There are many cases for null but that doesn't mean that it isn't abused.

> So, you have to encode in the name of the function the type of parameters it takes? And what's the point of classes if you can't take advantage of them?

I think your usecase there is indicative of a lack of understnading about the abstraction that classes present. Onesuch representation would be to not expose internal datasets. Another is to, if you need to exept a generic dataset make your function generic.

> Let me help you understand. A programming language like Java consists of many parts, but in the end, it is a program that takes a bunch of text files and converts it into bytecode that the CPU can understand and execute. Why do you insist on using an inferior programming language that requires the use of specialized tools, when those tools can be built directly into the programming language itself? IE, if I want to create a class, I'll just type "class A", not load up an IDE, click around a few times and hope I fill in the boxes right to have a hundred lines of boiler-plate code autogenerated for me. It's not the 1960s anymore. We can write code that writes code. Let's do more of that and less fussing with the minor details that no one cares about.

To quote you: you sound like someone who only uses vim. There is much more to an IDE then clicking New File. Again I do most of my prototyping outside of IDEs and move it into IDEs for the features that it provides.

VCS, static analysis, type checking, refactoring, debugging. All of this at your finger tips.

> It is if you have to type those names.

These are bad naming standards: __init__, __name__, __eq__

Magic names are not the answer. Names are only a problem if they are the only source of meaning.

Java's naming is a convention to help you be a better programmer but you don't need to use it. In python, some naming is forced on the programmer with no say inherintly in the language. The language will not work if you don't use their naming. This is not the case in Java.

> I'm not familiar with Java 8, but it sounds like they realized how bad of an idea it was if they're moving away from it.

If they are moving away from it then does it still "suck"?

> So you're saying I shouldn't use iterators because it's easier just to code around them? Iterators can be a powerful programming paradigm that is a major head-ache saver and time saver, but Java's implementation is so horrible you're recommending avoiding it. Got it.

I'm commenting on your iterator implementation. It's incorrect and not the best way to do it. The iterator is an abstraction and using a 1-item-stack is not an idea implementation. Compounding other datastructures to implement your data structure is the less-harmful alternative.

> I bow to your superior arguing skills.

I see no point in arguing against something that is correct. I also don't see how one flaw can make something suck. If you feel that way you should re-evaluate your love for JavaScript.

[grkvlt]

> That said Null is still a valid response. [...] I'd expect to return Null or Default if available for an unset property. There are many cases for null but that doesn't mean that it isn't abused.

We use a `Maybe<X>` return type that can handle returning a value (including `null`), an absence of value, or an exception. It extends `Optional<X>` and adds a new `isPresent()` method, and wraps the exception in such a way that the result `isAbsent()` and calling `get()` will rethrow the exception. Very useful...

[gravypod]

Null is meant to be used when it is likely there is a default handling for the responce. For instance

   String favoriteColor = accounts.get(username);
   if (favoriteColor == null) favoriteColor = "blue";
   setWindowColorTo(favoriteColor);

Removing null does not make your code more safe. Wrapping Null in more code does not make your code more safe.

You get null for free. I could write the same think that optionals do in Java with 1 static method

    public static boolean isAbsent(Object o) { return o == null; }

    public static <T> T get(T o) {
        if (isAbsent(o)) throw new RuntimeException();
        return o;
    } 

Now you get your nice abstraction from an inlined function. Wrapping it in an object in my opinion is bloat around seomthing that doesn't need it.

The best chance your have to sell all Java devs on something is @Nullable which is a fantastic idea. It lets you know where null WILL propegate so you know where to control it. IT will also help you get out of "I see NullPointerException so therefor null is the problem, not my code!"