I can't put my finger on it, but as an end-user I find a lot of Java use simply distasteful. One of my biggest gripes is server manufacturers wrapping the remo

I can't put my finger on it, but as an end-user I find a lot of Java use simply distasteful. One of my biggest gripes is server manufacturers wrapping the remote console functionality in a LOM in some stupid Java app. Why not just allow raw VNC or RDP connectivity? There's a 50% chance that any given server I try to manage will fail on my primary browser (Firefox and Chrome on FreeBSD), and I'll most likely need to fire off IE in a Windows VM just to do my damned job. Plus, the size of the run-time environment itself is shocking. Sure, I have 8GB of memory in my workstation, but why use a few hundred of it when a binary client would consume just a couple? A perfect example of this is the units converter "frink" (by Alan Eliasen), distributed as a jar file. I just fired it up, and it consumes 55MB of resident memory and a total virtual memory size of 343MB. This program is mostly a fancier version of the unix "units" command. (I don't wish to disrespect the author here -- I find frink insanely useful -- but 25-to-50 times the memory footprint of the likely equivalent C program hits an aesthetic nerve with me.) There are quite a few slick products I simply don't use because I find the requirement for Java distasteful. Limewire is a good example. Whenever I'm exploring my FreeBSD ports collection for something I need (or just looking for cool stuff), I tend to skip the ones where Java is a dependency.