1. IntelliJ forces you to manually build your project. This is enough to force me to use eclipse despite all its problems
2. Sure, you don't have to use the frameworks, but they're one of Java's big selling points. If you didn't want them why would you use java?
3. I think you make the point for me. Sure, closures aren't impossible in Java, they're just much harder than they should be.
4. Boilerplate isn't just there when you write it, it's there when you read the code, which is much more important. The one major live bug I introduced was when I accidentally replaced a getter that had some code in with an autogenerated one.
5. It is true in that there are a bunch of standard library methods that throw checked exceptions (e.g. file I/O), so like them or not you have to handle them.
1) IntelliJ automatically recompiles your project in the background.
Its only when I do something drastic like changing dependencies that I have to hit the 'build' button.
I think IntelliJ gets this balance right.
Why should continual/incremental compilation be part of the IDE?
You can do this in a separate process, the IDE only needs to detect that some .class files have changed and refresh the metadata of those files.
Eclipse support for this is sure nice, but then I hate Eclipse for being bloated, with a sluggish interface and shoehorning such features on top is the reason why Eclipse is the way it is.
The IDE is supposed to be integrated, and compilation is one of its main responsibilities. I don't really care how it's accomplished, but I can't write java without "new errors show up in my IDE whenever I hit save". If there's an easy way to set up this separate process malarky then I'm interested.
2. Sure, you don't have to use the frameworks, but they're one of Java's big selling points. If you didn't want them why would you use java?
3. I think you make the point for me. Sure, closures aren't impossible in Java, they're just much harder than they should be.
4. Boilerplate isn't just there when you write it, it's there when you read the code, which is much more important. The one major live bug I introduced was when I accidentally replaced a getter that had some code in with an autogenerated one.
5. It is true in that there are a bunch of standard library methods that throw checked exceptions (e.g. file I/O), so like them or not you have to handle them.