• GitHub help: dealing with line endings

• To fix an already duffed file in Eclipse, go to File | Convert line delimiters to...

1. A run-down of the Oracle suing Google thing by Miguel de Icaza, Mr Mono himself. The irony.
2. James Gosling confirms this was Oracle's game plan from the start.

The trick is to run both the app you want to look at and JVisualVM with the argument -XX:+PerfBypassFileSystemCheck.

remote: error: refusing to update checked out branch: refs/heads/master
remote: error: By default, updating the current branch in a non-bare repository
remote: error: is denied, because it will make the index and work tree inconsistent
remote: error: with what you pushed, and will require 'git reset --hard' to match
remote: error: the work tree to HEAD.

After reading this it started to make sense. My main/origin repo looked like a first-class, in-use repo, and git thinks that since it might be an active repo, pushing to it would be a bad idea.

The solution was in the post above. Step 1 is to change to the directory containing the origin repo and execute

git config --bool core.bare true

With that done, git knows that the repo is bare, and you can push to it.

Step 2 would be to delete of any checked out code in the origin directory so that all that directory contains is the .git directory.

In which I argue that (a) Generics have done egregious harm to both the elegance and readability of the Java language and, (b) they prove by example that static type checking is a linguistic dead-end. Are you persuaded? Do you agree? Read on...

I'm really busy at the moment so I must admit I haven't yet read on, yet I will say three things because the themes come up so often:

1. Generics do suck until you remember how ugly code used to be when you needed monstrosities like ((Widget)list.get(0)).foo().

2. I also remember how much effort it was when you couldn't type list.get(0) Ctrl-2-L and have your IDE autosuggest a sane local variable, etc etc. I also remember how I used to think C++ templates were much better - and in many ways they are, but the one downside is how easily templates break the IDE's autocomplete and navigation functionality.

3. the benefit of static typing isn't about the compiling, it's about the navigating and the typing (of the keyboard variety). A modern Java IDE allows you to move around and analyse code and autocomplete and generate code and refactor in ways that dynamically typed languages just can't hope to match. As I like to say, Java may be horrendously verbose, but when your IDE allows you to type in paragraphs and sentences instead of words and phrases, it doesn't seem to matter as much.

I suspect that many people in the anti-static/Java camp haven't seen and aren't aware of what an accomplished Java dev can do. Which isn't to say that I think static typing is necessarily or always better than dynamic typing, just that I don't think IDE capability is fully considered in the debate.