But I don’t want to use Eclipse or Netbeans. I want to use Vim.

Enter Eclim, which is a way to use Eclipse’s wide array of features in Vim. Check out the site, it gives a better idea of how it’s used than I can. Unfortunately, only binaries for Linux and Windows are available, so we’re going to have to do this the hard way on OSX. Let’s get started.

The first thing we’ll need is Eclipse. I’m using Eclipse 3.4.3, which I downloaded, uncompressed and moved to /Applications/Eclipse (so the full path is /Applications/Eclipse/Eclipse.app, this is important for later).

Next, let’s grab Eclim from the sourceforge site, the tar.gz file (not the .exe or the .sh). I’m using Eclim 1.4.7. Untar and wait a second, we’ll need to grab something before we can build Eclim.

Eclim requires Ant 1.7.1 in order to build (OSX ships with Ant 1.7.0 instead), so download the Ant 1.7.1 binary for OSX from Apache’s sites, untar, but don’t worry about installing it.

Lastly, grab the latest Vim 7.2 tarball from vim.org. Unfortunately, Apple decided not to compile the system vim with ‘sign’ support, so we’ll have to roll our own version of vim.

Now, let’s begin:

First, we’ll need a folder for the vim plugins, which needs to be created manually or Eclim will complain:

[~]% mkdir ~/.vim/eclim

Next, compile the Eclim files from the eclim directory using the ant 1.7.1 binary. In this example I’m only compiling the ant and jdt plugins for Eclim, because the CDT and PDT plugins require other Eclipse libraries, and I only use Eclipse for Java development anyway. Be sure to change your eclipse.home setting if you didn’t put it in the same place as me:

[~/code/eclim_1.4.7]% ../apache-ant-1.7.1/bin/ant -Declipse.home=/Applications/Eclipse/ -Dplugins=ant,jdt

The Ant command will build and install the files at the same time, so afterwards you shouldn’t have to manually install any Vim or Eclim files.

Next, we need to recompile Vim with sign support, here’s how I compiled my version, make sure to keep the –enable-gui=no and –without-x options, or else vim will start X11 every time you run in:

[~/code/vim72]% ./configure --enable-gui=no --without-x --with-features=huge --prefix=/usr/local
[~/code/vim72]% make
[~/code/vim72]% sudo make install

Switch out the system vim for the one we just created:

[~/code/vim72]% sudo mv /usr/bin/vim /usr/bin/vim.mac.old

We’ll need some way to start the Eclim daemon that was installed, and eclimd doesn’t care for symlinks, so I created an alias in my .zshrc (or .bashrc if you use bash):

alias eclimd='/Applications/Eclipse/eclimd'

Next, we need to fix the /Applications/Eclipse/eclimd shell script, because Apple’s readlink command does NOT support the -f option, so change this line:

RESOLVED=`readlink -f "$0"`

To this:

RESOLVED=`readlink "$0"`

Now, after all that, start up eclimd:

[~]% eclimd

You should see something like this (screenshot):

Alrighty, now we can start Vim, give these two commands a try to see if eclimd communication can be established:

:PingEclim (Will output the Eclipse and Eclim version if everything is working)
:EclimValidate (You should get: “Result: OK, required settings are valid.”)

Hopefully you were able to get a connection. If not, leave a comment and I’ll try to help you out

Okay, so it’s set up, congratulations! Now what can you do with it, well I suggest checking out Eclim’s Java page to see what you can do, but the features I end up using the most are validation, completion and correction. Validation will validate the Java file every time you save it, marking the lines where errors in compilation occur. See the following screenshot (notice the red “>>” markers):

Completion (through Ctrl+x-Ctrl+u) gives you the awesome completion that Eclipse has, like so:

Correction allows you to go to a line with an error marker, and have Eclipse suggestion a fix, just like it would in the IDE, to apply the fix, put the cursor on the red line and hit Enter:

Now go read all the documentation to see the neat things you can do

I usually end up doing the actual project management (adding files, adding external jars to the classpath, generating ant build.xml files and other gui-type stuff) from Eclipse still, but for the actual coding, I’m all about Vim.

Oh yea, one other thing I should mention, so Vim settings for your .vimrc that are really helpful for this:

If you use Supertab (tab-completion with tab instead of Ctrl+x-Ctrl+u):

" Supertab settings
" supertab + eclim == java win
let g:SuperTabDefaultCompletionTypeDiscovery = [
\ "&completefunc:<c-x><c-u>",
\ "&omnifunc:<c-x><c-o>",
\ ]
let g:SuperTabLongestHighlight = 1

And some Eclim .vimrc settings that I use:

" Eclim settings
" ,i imports whatever is needed for current line
nnoremap <silent> <LocalLeader>i :JavaImport<cr>
" ,d opens javadoc for statement in browser
nnoremap <silent> <LocalLeader>d :JavaDocSearch -x declarations<cr>
" ,<enter> searches context for statement
nnoremap <silent> <LocalLeader><cr> :JavaSearchContext<cr>
" ,jv validates current java file
nnoremap <silent> <LocalLeader>jv :Validate<cr>
" ,jc shows corrections for the current line of java
nnoremap <silent> <LocalLeader>jc :JavaCorrect<cr>
" 'open' on OSX will open the url in the default browser without issue
let g:EclimBrowser='open'

Enjoy!

I started out writing the script in Perl, which at this point is the scripting language I know the best, I then decided that now is as good a time as any to learn Ruby (which I’ve been interested in for a while now), so I re-wrote the entire program in Ruby (first *useful* script I’ve actually written in Ruby). Then, one day at work I was told that I needed to extend the program to support 5000 simultaneous threads doing disk I/O. I thought about this for a while and (after talking with my friend Jon about it) decided on using Java, as the threading was much more robust (something I had problems with using Ruby and Perl). Well, I’ve got working versions of all 3 programs and I thought I’d share my perspective on the pro’s and con’s of each one:

Java pro’s:

• Most robust thread implementation of the 3 languages
• Handles SMP much better than ruby
• Code is portable with minimum requirements to run
• OO language (a bigger pro to actual developers who this matters more to)

Java con’s:

• JVM overhead (not really that much nowadays)
• More difficult to read due to Java’s extreme verbosity
• Requires jdk 1.5+ (1.4 is still the only actual “supported” JDK in my company)

Ruby pro’s:

• Most readable code of all 3 (shortest too)
• I got to learn Ruby
• Ruby implementation available for most platforms
• More OO than Perl (not that I used OO…)

Ruby con’s:

• Ruby only took advantage of 1 of my CPU cores (Java used both)
• Ruby is slower than Perl (maybe one day they’ll be just as fast?)
• Almost no one in my department has heard of Ruby

Perl pro’s:

• Super-easy to install with ActiveState for windows, comes default with most *nix
• Super-easy to install the required module: perl -MCPAN -e shell ; install File::Random
• Allows fine-grain tuning of thread parameters (adjustable thread stack size)

Perl con’s:

• If you don’t have threaded perl, gotta reinstall (/cry @ Solaris)
• Least readable code (unless you loooovvve punctuation)
• Perl doesn’t like me spawning millions of threads and detaching all of them

Overall, since I need code that’s portable to multiple platforms easily, while allowing for very large amounts of IO, I’ll probably stick to the java version (which was renamed CIOSim [Customer I/O Simulator] because you actually pronounce it :P), followed by the Ruby version (so easy to write), and then the Perl version, which, actually has the largest amount of features.

I haven’t written all the features into each version yet (except for the Perl one), but, if you’d like to take a look at them, here they are:

Java version
Ruby version
Perl version

Next tool I need to write, I’ll probably be looking at Ruby

Anyone out there use anything different for sysadmin tools? Python? Lisp? Assembler? Leave a comment and let me know

While I agree with the fact that many many more people have heard of the “Java” brand on just about every technical device made, those people are also not exactly the kind of people who I would imagine spending their money buying stock in a large computer corporation. Yes, you might appeal to the 14 year old with the cell phone because he/she knows that Java is what runs the games on his/her phone, but will that same 14 year old actually be purchasing stock in Sun?

Another thing that worries me slightly about this change is the face that Sun is presenting to its corporate and business clients, it sort of seems like they are shifting their complete focus into the Java/software industry, and perhaps diminishing their focus on Solaris and hardware (I know this isn’t true, but for someone who doesn’t keep up with the company, it could seem that way).

I really hope for the best for Sun in this case, it would be nice if their stock price tripled and they gained more market share, maybe then more people would switch to Solaris :D. As more me though, I think this is more of a marketing gimmick than anything else (but hey, companies have to market, right?).

What do you think of the ticker change, is Sun changing their priorities and direction, or are they just making an attempt to grab media attention?

[edit]: Hahahaha…reading the comments, I would have to agree with some of the commenters about what most people first think of when they hear Java: It’s Slow.