Java IAQ

This has a lot more to do with the GUI toolkits than the JVM. Python is most often used with bindings for GTK (C), QT (C++) or tk (C). I don't know a lot about .net but I believe it just links to the standard windows gui toolkit probably also written in native code.

For Java the main issue is that Swing/SWT/AWT suck and java is mostly used as a server language so there is little impetus to fix them.

Eclipse is just bloated, that is why its often slow. Android has its own custom JVM (Dalvik) but I imagine the majority of the UI rendering / handling code is native with Java bindings.

All that said, the full JVM (both openJDK and sun's) have multiple garbage collectors and many tuning options. This creates flexibility to tune the GC for particular work loads but also makes them complicated to work with. It doesn't help that the default GC/memory settings in the JVM are a bit...off, and use the high throughput GC vs the low pause collectors.

It's been a while since I've done work in Java, but I'm pretty sure the GC is not to blame for this. Java uses a concurrent mark and sweep GC. The concurrent part means it does not pause the world while it's collecting. So as mbell says, it has to do with the UI frameworks.

But I don't think it has to do with whether or not the UI code is written in C either. In the UI frameworks I've used for both Python and Ruby, you could write slow interpreted code that would run on the UI thread. The key thing was you tended not to do it, because the frameworks didn't encourage you to do so. The problem is that Java frameworks make it easy to for example do IO on the UI thread, whereas the other frameworks make it hard. Threading is relatively hard to get right in any of these languages, so the choices made by the framework authors really matter.

Another thing contributing to Java being perceived as being slow is the long boot time of the JVM. (It used to be slow at least, don't know if it still is.)

It's pretty simple... Hotspot collectors are optimized for throughput, not latency. That's where the money is for Sun/Oracle. It's a trade off between one and the other in any garbage collector.

You can tune it to some extent.

It's the libraries. Write an app with OpenGL or SDL and it works fine. (Minecraft is a perfect example)

I second this recommendation, actually even if you do not program in Java nor on the JVM. Like no other book it taught me a particular kind of foresight - to analyse the consequences of each small decision being made during implementing some new thing and to design things in such a way that they are least likely to cause problems now or in the future, to me or to other programmers working on the project - my code is much more solid and less error-prone ever since and it was definitely a big AHA moment for me. The author, Joshua Bloch, designed some of the standard Java APIs and I actually can't think of a better way to learn about those things than implementing an API used by other people, which explains why he has so many interesting things to say that are seldom found in other places. Here is also a very nice talk by the author:

http://www.infoq.com/presentations/effective-api-design

Did you read "Scheme In One Class" at the link he attached to the paragraph you're sniping at?

For this example, I would expect that any decent Java compiler optimizes this away nowadays. That does introduce a dependency between compiler and standard library, but the benefit is large enough, given that this is idiomatic code, and that Java has it easy here because Java strings are immutable.

For general collections, things are more difficult, but I still expect java to optimize things in many cases. I haven't checked, though.

A C/C++ compiler has a tougher job. It can only move strlen calls out of a loop if it can determine that the strlen you call came from the correct <header> file and that there is no defined behavior under which either the pointer or its contents change inside the loop.

If it cannot do either, it must 'call' strlen each time through the loop (That 'call' can be inlined, especially if the compiler knows it is the standard library's strlen)

The thing is String.length() doesn't do any re-computation. All it does is return a variable defined in the String object that is modified when the string it contains changes.

See my other comment saying you should ignore any speed suggestions by the article.

I like this way to rewrite it when the end test is slow (I think this is correct syntax):

for(int i=0, len=str.length(); i<len; i++)

One evaluation and you don't have an extra len variable hanging around.

I don't like them in general either, but there's one place I use them extensively: JUnit tests (statically import Mockito, Hamcrest, Assert, etc).

It mostly has to do with how much the library tries to be a DSL, and how much readability will suffer if I don't use a static import. IMO, this

  assertThat(6, isGreaterThan(5));

reads a heckuva lot better than

  Assert.assertThat(6, Matchers.isGreaterThan(5));

Of course the combination of poor Java type inference and Generics-heavy libraries make it so that often I have to do the latter to make use of angle braces, but that's another story.

I don't understand this comment at all.

Do you not know that import statements are at the top of every class file, or did you mean that you hate wildcard imports? Do you also eschew local variables, because they might clobber fields and method parameters if you ignore the compiler warnings?

It's not. HashMap<K, V> works exactly like Hashtable with regards to equals() and hashCode().

Its not like Java is changing that much :)

Is this still true these days: "creating a new object is a fairly expensive operation" ?