Configuring Java development on Linux

I run Linux Mint on my workstation and my laptop, and so my students see me using it in the classroom and in my office. A few students have dipped their toes into GNU/Linux this semester, but configuring a useful and robust Java development environment can be challenging for someone new to the Linux ecosystem. I am writing this blog post to document how I set up my environment, and why I do it this way. I will assume a Debian-based Linux distribution, although I have used this approach on RPM-based distros as well.

The first step is to get rid of the default OpenJDK installation. I sympathize with the goals of the OpenJDK community and of free software in general, but at the same time, I am content to run Oracle's JDK for development purposes. Instructions for doing this depend on your distribution, and a quick search will likely show something like this:

sudo apt-get purge openjdk*
sudo apt-get purge icedtea-* openjdk-*

It probably doesn't matter if you keep the OpenJDK installed, but since we're not using it, we may as well clean it out.

In the bad old days, I would install all my Java libraries into /usr/local, and then I would curse myself over getting the permissions right. These days, I just put them in an apps folder off of my home directory—that is, at /home/pvg/apps. If you're very new to *nix, not that the tilde (~) is used to represent your home directory, so I also refer to this directory as ~/apps.

Next step is to download the JDK from Oracle. I will assume we're using Java SE 7, release 40, just for the sake of discussion. The approach is the same for any release, and in fact, allows for parallel installation of different releases. I extract the JDK into ~/apps/jdk1.7.0_40 using standard archiving tools. Then, set up a symbolic link in ~/apps to point to this particular release of the JDK. From the ~/apps directory, it looks like this:

ln -s jdk1.7.0_40 jdk1.7.0

Now, I can reference ~/apps/jdk1.7.0 and it goes immediately to release 40. If I want to update my Java version, I simply drop it into ~/apps and update the symbolic link—no other changes are required.

Making this JDK accessible from the command line just requires a few tweaks to the .bashrc file. This is a hidden file in your home directory; this means you won't see it with a standard ls command, but you can if you do ls -a. Since I use emacs, I can open the file with emacs .bashrc from my home directory; vim or another editor would work similarly, except not quite as well because they are not emacs. What we'll do is add two export commands, one to specify JAVA_HOME and another to tweak the path. I put them at the bottom of my .bashrc, along with a comment reminding myself what I was doing. The result looks like this:

# Use the JDK in ~/apps
export JAVA_HOME=/home/pvg/apps/jdk1.7.0
export PATH=$JAVA_HOME/bin:$PATH


You will need to open a new console or source the .bashrc file to see the change. Now, if you type the command java -version, you should see that you're running JDK 1.7.0 Release 40 (in my example). Note that you can use the which command to determine which executable is being run, so which java should return /home/pvg/apps/jdk1.7.0/bin/java.

My installation strategy for Maven, Ant, and Eclipse is similar. This gives me fine-grained control over which version I have installed, and I can hop between versions by simply tweaking my path. For example, in my ~/apps directory I have apache-maven-3.1.0, and then in ~/.bashrc I have added the following lines:

export MAVEN_HOME=/home/pvg/apps/apache-maven-3.1.0
export PATH=$MAVEN_HOME/bin:$PATH

I keep a link to Eclipse on my desktop for ease of access. There is a trick to making this work in KDE; I don't know if this is applicable to other desktop environments. In my Eclipse configuration file (~/apps/eclipse/eclipse.ini) I have added a link to the JavaVM that should be used to start Eclipse. The two lines look like this:

-vm
/home/pvg/apps/jdk1.7.0/bin/java

These go before the -vmargs flag that is probably already there.

I hope this is useful information for my students and others who are experimenting with configuring GNU/Linux systems for Java development. If you have other tips or approaches, feel free to leave them in the comments.

Screencasting on Linux Mint 17

Sometimes I post philosophical essays, and sometimes I describe important teaching experiences, and sometimes I reflect on my miniature painting hobby. Today, however, I go to that much more pragmatic use of the blog: writing down how I actually got screencasting to work on my work machine.

I have a Dell Precision T3600 running Linux Mint 17. I switched from KUbuntu to Mint on my work machines last year, when I had some trouble with hardware recognition. Since I've been using KDE for over a decade (from Mandrake to Mandriva to KUbuntu), I use the KDE distribution of Mint as well. It seems this puts me in the minority, as most of the Q&A I see online assumes one is running something newfangled.

I have USB Logitech headphones that used for the screencast. After a bit of fighting with my mixer, I was able to get the microphone to work: the system wants to default to the hardware ports, even when there's nothing connected there. Audacity makes it very easy to test the sound configuration, and so I was sure that the microphone was working.

However, getting that microphone to work through screencast software was another problem entirely. I had no luck with the old standard recordmydesktop at all: video capture was fine, but the audio came up with nothing. A bit of searching revealed some newer applications I had never heard of. Vokoscreen had a reasonable user-interface with several configuration options, and I was confident enough to record an 11-minute take. Unfortunately, upon playing back, the audio was terribly choppy. I spent quite a bit of time fiddling with the framerate and pulseaudio settings trying to fix this, since otherwise Vokoscreen was convenient to use, but a tutorial with no audio is hardly a tutorial at all. Since the mic was working fine in Audacity, I inferred that it was a software problem, not a hardware problem.

I switched over to Kazam, and this ended up doing the trick. It allowed me to select an area of the screen where I could hop between Eclipse, Chromium, and the console, and the audio was captured with no trouble. The default file format uploaded flawlessly to YouTube, and I was able to share the video with my students. I had actually tried Kazam before Vokoscreen, but it wasn't working—turns out it was because I had the mixer settings for my mic much too low, and they needed to be at almost 100%. (Recordmydesktop still did not work with this fix, incidentally.)

The screencast itself is just an explanation of how to set up a PlayN project and hook it up to a Mercurial repository using the Computer Science Department's Redmine server. Hopefully next time I want to do an 11-minute screencast, it will take less than two hours of tinkering.

MythTV Upgrade

I have just completed an upgrade to my MythTV box. I originally set it up in 2007, basing it on Mandriva 2007.1, and it's been running mostly seamlessly since then. I have had occasional problems with session management, in which multiple frontends would start upon boot, but after some tinkering this became a matter of routine maintenance. However, I've been more recently interested in leveraging the streaming options of my NetFlix subscription, and unfortunately, they do not support streaming to Linux. I understand that this must be due to contracts with the content providers, who insist upon DRM. I wish there were a better solution to this, but I honestly don't have one, and the more pragmatic issue was that I was disappointed with my inability to stream video to my family room TV.

A few days ago, I was browsing the Web and came across a mailing list post from earlier this year in which the author describes how he configured NetFlix streaming in MythTV by way of running Windows XP within VMWare Player. I usually use VirtualBox for all my virtualization needs, but the mythtv-users thread suggested that there are impassable audio barriers with VirtualBox that don't show up with VMWare Player. I have a spare Windows XP license, so I installed it on my myth box about two weeks ago. There is a sense in which it worked, but it was painfully slow: the machine only had 512MB RAM on a Sempron 3000, and trying to do anything with VMWare Player caused hard drive thrashing with swap access.

Poking around my closet of abandoned hardware, I found a case from my previous desktop machine and booted it up. Finding everything in working order, I picked up a 1TB drive on a Newegg Thanksgiving deal and proceeded to transfer the Myth hardware to the other box. This one had 2GB RAM and an Athlon 64 3700+, a vast improvement of memory and a significant improvement of processor.

Unfortunately, getting the new system installed was not as seamless as I hoped. I tried many different distributions and each one ended up with some kind of problem. The odd thing is that moving the old hard drive into the new shell worked just fine, and I was able to check that the hardware configuration was working. However, Mandriva 2007.1's ALSA drivers were too old to work with VMWare player, and so the audio was garbled when streaming video.

After quite a bit of tinkering, I started doing more diagnostics of the installation media themselves, and I found each to have an error. It appears that the burner on my workstation cannot accurately burn 700MB CDRoms. Who knew? When I took the ~700MB image and put it on a blank DVD instead of a blank CD (and swapped the graphics card, which may or may not have made a difference but definitely reduced noise), the installation went more smoothly. I still had to specify "nomodeset" as a kernel parameter in order to get to an installer, but now I have a nice shiny Mythbuntu 10.10 installation working great.

Two unexpected changes from the old installation: First, my USB wifi device worked automagically, without having to download any extra drivers or anything. Huzzah! Second, my StreamZap remote control was automatically recognized as a keyboard, but it was also configurable through the Mythbuntu control center. The odd result was that I was getting double input for the four arrow keys. After some digging online, I discovered that I could just comment out the arrow keys in the ~/.lirc/mythtv configuration file, and now it's working fine.

One of the nicest features I originally set up was for the machine to wake itself up to make a recording and then shut itself down afterwards. This way it doesn't have to be an always-on machine. On the Mandriva 2007.1 installation, this was enabled through nvram-wakeup, and because my motherboard was not in the database, this required a good deal of tinkering to get set up correctly. By switching to Mythbuntu and a newer motherboard, it is all done now with ACPI calls. Specifically, I followed the instructions for configuring ACPI wakeup on the mythtv wiki, and this worked like a charm.

Installing Windows on VMWare Player was not a problem, but hooking it up with the MythTV frontend was not as easy as described in the mailing list. I had an odd situation: if I opened a terminal through the desktop environment (XFCE), then I could run vmplayer with no trouble. It generated some warnings, but it started and run without issue. However, if I launched a terminal from mythwelcome or via the mythfrontend button, running vmplayer would generate the same error messages but then do nothing. After many fruitless attempts to fix this, I asked the resident Unix expert in the department, and he suggested I use printenv in both terminals and diff the results. I had been trying to do something similar but in a much more awkward way—always nice to learn a new *nix command! After a few failed attempts, I discovered that by unsetting GTK_PATH, I could start vmplayer consistently.

So there you have it! I have a machine that boots faster, runs quieter, and allows me to watch streaming Netflix movies from the comfort of my living room. It also has four times the hard drive space, so my son can record as many Dinosaur Train episodes as he wants without my wife's America's Test Kitchens needing to be deleted to make room. My original build four years ago was supposed to be built of spare parts, but it ended up costing me about $400 due to my hardware being faulty or having the wrong interfaces. This revision only required purchasing a bigger drive, and the rest was accomplished with existing hardware and elbow grease. Thanks to the Myth community for all the excellent software and resources, thanks to Spencer for the Unix help, and thanks to Paul for the TV tuner cards that allowed me to build it at all the first time.

Screencasting in Mandriva

I spent too much time today making a short screencast in order to demonstrate a specific property of Eclipse and Java. I could not find any clear recommendations on what software to use on Mandriva, my preferred Linux distribution, at least not beyond what was given on Wikipedia's page comparing screencast software.

I ended up using recordMyDesktop with the qt frontend, both of which were in the standard Mandriva repositories. You can select an area of the screen to record via the main window, but there is also a tray icon. Initiating a recording from the tray icon seems to always grab the whole screen, regardless of what is selected.

Additionally, the selection only seems to work if you choose the box and then hit record on the main window. Stopping that recording and then clicking record a second time results in having a full-desktop recording, which is not what I wanted. These complications caused me to have to throw away three reasonable takes, because it was easier to recreate them then to figure out how to crop a whole video. (Although if someone knows how to do that on Mandriva, let me know.)

With an acceptable take--although I forgot one important point, but am not willing to try yet again--I uploaded the file to YouTube. RecordMyDeskop produces Ogg Theora video output with Ogg Vorbis audio, which I think is great as a supporter of open formats. YouTube happily accepted the upload, recognizing it as Theory+Vorbis, and did its magical processing. The end result, unfortunately, had completely garbled video, just some colored flecks on the screen, while the audio worked fine.

A little scouring of the Web, and I discovered a Devede, a Linux application for mastering DVDs that can also be used to convert to AVI video format. After installing the requisite codecs, I was able to convert the ogv into avi, and I uploaded that to YouTube. Somehow it got confused and thought I cancelled the upload, so I had to do this twice, but the final one stuck.

This worked for me, but if anyone knows of a simpler and more streamlined process, I'm open to ideas.