Too much verbosity in generics!

Why do I have to write the following bold part:
Map<SomeLongClass, SomeOtherThing<Another>> myPoint = new HashMap<SomeLongClass, SomeOtherThing<Another>>();

(Update 2009-03-03: As you probably already knew, I am not the only one realizing this!)

As far as I know, anything else than a verbatim copy of the stash that already is present in the declaration of that variable/field is a compile error. So why do I have to type it?? Argh..!

And OH so annoying Eclipse behaves if you haven't yet imported Map while writing that line - because if you've come to the point where you're about to write "Hash.." and then think that it would be reeeally nice if Eclipse could just autocomplete the rest of that shit for you, it doesn't quite work! And at that point it doesn't help to arrange imports either, because the code is currently to uncompilable for poor Eclipse to even understand what you're aiming at, so you'll have to delete up to the equals-sign, stash in a semicolon, then arrange imports, and finally start up with the "Hash..." again, now having autocomplete functionality at the ready. Grr..

Please, someone: I'd like Java itself to remove the need for that duplicated stupidity, and then Eclipse to be better at trying to compile partially if it doesn't understand the line the cursor is on (so that at least arrange imports would work at the described annoyance), and finally, I'd like some extra-super context-assist for writing the line in the first place - letting Eclipse know of the standard implementations of all Collections, and also picking up the classpath. For that matter, it could do such stuff all the time.

(And while I'm whining: Blogger doesn't handle <'s and >'s in "rich text" mode..)

Java Garbage Collection details - "Garbage First" G1

For folks into the details of java, there's an interesting blog entry called "Our Collectors" over at Jon Masamitsu's blog, who apparently is a Sun GC guru. It has a nice low-down over the different collectors - what they are, where they are used, and how they can be combined.

Also, this is a good place for some insight into the G1 GC - "Garbage First", a new algorithm that is going to be the default in Java 7.

Some interesting discussion ensues, where Tony Printezis, apparently another Sun insider, chips in with comments.

http://blogs.sun.com/jonthecollector/entry/our_collectors

Also, don't miss this good whitepaper, Memory Management in the Java HotSpot™ Virtual Machine (pdf, April 2006).

Linux RAID1: Failing disk in boot set, part 1

I'm running software RAID on Linux, using the md module.

I have everything RAIDed, including /boot and swap.

The /boot and / is on a RAID1 set. The logic behind that is the boostrap problem: the kernel must be loaded to enable the md_mod module and hence enable RAID, but the kernel resides on the RAID set - catch 22! However, since RAID1 is pure mirroring, things work out: assume the boot disk isn't a part of a RAID set while loading the kernel from /dev/sda1 in read-only mode, then, when it comes up, load and activate the RAID module, enable the RAID set, and continue taking up the system using the now /dev/md0 device.

So, if a disk fails, find out which one (find its serial number), chuck that out, stick in a new one, and then boot up. The RAID module will upon trying to assemble the RAID sets discover that one of the device is gone, and simply take up the set in reduced mode. You are then able to partition your new disk exactly as the one already present, and then add the new device back into the RAID set.

Simple!

However, there is a bootstrap problem before the one described, which is what really is called "the boot process": When the computer starts up, it reads the first sector of the boot harddisk (typically the first in its discovery sequence, possibly changeable in the BIOS setup) into memory, and runs that. This is where the bootloader resides.

The only problem is that a normal system only sticks the bootloader on the mentioned boot harddisk. This part of the disk isn't handled by the RAID module - so it won't be copied over to the other disk (e.g. the partition table is there too - can't have two different sized disk's partition table hard-copied from one to the other).

So, if a disk fails, you'd better hope that it is the other disk, not the boot disk!

I wasn't that lucky...!