Fix: Add Apache Derby Nature in Eclipse does nothing

Tonight I had a strange issue with Eclipse: adding the Apache Derby nature to an Eclipse project wasn't working. Ordinarily, (provided that the Apache Derby Eclipse plugin is already installed) right-clicking a project and choosing Apache Derby->Add Apache Derby Nature to a project will do just that, enabling additional features such as starting or stopping the Derby network server.

This time, however, choosing that option appeared to do nothing. Rather than a menu full of commands, I was given only the option "Add Apache Derby Nature" in the Apache Derby context menu, which is what I had previously selected. I tried several times to add the nature in this manner, but to no avail.

The fix turned out to be simple. After grepping the directory of another project where I had successfully used Derby, I found that the change should have been reflected in my project's .project file.

The fix: if the Apache Derby nature isn't correctly added to a project through the Apache Derby menu, it can be done manually by editing the .project file (which is in the root directory the project). This is an XML file.

Find the <natures> node and add this line:

<nature>org.apache.derby.ui.derbyEngine</nature>

Here's how the entire <natures> node looks after the change in my project:



<natures>
<nature>org.eclipse.jem.workbench.JavaEMFNature</nature>
<nature>org.eclipse.wst.common.modulecore.ModuleCoreNature</nature>
<nature>org.eclipse.wst.common.project.facet.core.nature</nature>
<nature>org.eclipse.jdt.core.javanature</nature>
<nature>org.eclipse.wst.jsdt.core.jsNature</nature>
<nature>org.apache.derby.ui.derbyEngine</nature>
</natures>

Then, just save the file. Problem solved.

HOWTO: Elluminate Live Application Sharing on Ubuntu 12.04

TL;DR: Elluminate Live Application Sharing is broken under Oracle JRE 7. Use Oracle JRE 6 instead and configure Elluminate Live accordingly.

This week, in an online class I'm taking, I was asked to give the class a demonstration of an app I had just written. This was to be accomplished via Elluminate Live (which was recently acquired by Blackboard.com).

When I attempted to begin my presentation, I found that I was unable: under Tools->Application sharing, I only had one option ("stretch to fit") available. Two others, Request Desktop Control and Request Control of Shared Applications were present but greyed out. Normally, many more options should be available--the fact that they weren't made giving my demo impossible. I was left in a lurch and had to ask my professor to move on to the next presenter.

I knew there had to be a way to fix this, so I set about figuring one out. Fortunately, I found one. The issue turned out to be with Oracle JRE 7.

Here's what I did to get desktop application sharing working for Elluminate Live on Ubuntu 12.04:

1. Install the Java 6 JRE. This is easier said than done at this point as Java 6 is near end-of-life and is unavailable from the Ubuntu or Ubuntu partner repos due to licensing issues. Instructions for installing it (legally) can be found here. I used the flexiondotorg github repository method.
2. Set Java 6 as the default JRE (see Ubuntu help link in #1 above).

Note: There is one more step: tell the Elluminate application which JRE to use. After completing steps 1 and 2 above I noticed that under Help->About Elluminate Live->Information->Java Virtual Machine, Elluminate reported that it was using Java 6 for javaws but Java 7 for its JRE despite me setting Java 6 to be my default JRE. What I had to do was start javaws from the command line ($ javaws) and choose the Java tab, click the View button under Java Runtime Environment Settings and disable the Oracle 7 JRE. The next time I entered the Elluminate Live session, application sharing worked!

Now I won't have to resort to using a Windows VM to just to get into my class every week.

Note: OpenJDK might work, but I haven't tried it in a couple of years due to other issues I ran into with that JRE.

Recently, my HTPC began to throw an error upon boot, namely:

An error occurred while mounting /home/house
Press S to skip or M for manual recovery

My /home directory is located on a second hard disk, which I had recently upgraded from a 500GB to a 2TB drive. Running fsck from the shell I got when pressing "M" didn't do the trick. It found no errors and gave me no output. This was strange, but rather than troubleshooting that way (and subjecting myself to sitting awkwardly on the floor in front of my TV with a backup keyboard & mouse), I opted to pull the drive from the tower and hook it up to my laptop as an external drive. This at least made the whole affair somewhat ergonomic!

At any rate, I was able to successfully fix the issues the drive was having at this point using fsck. The relevant terminal output is below.

$ sudo fsck -p -t ext4 /dev/sdb1
fsck from util-linux-ng 2.17.2
/dev/sdb1 contains a file system with errors, check forced.
/dev/sdb1: Deleted inode 34604232 has zero dtime.  FIXED.
/dev/sdb1: Inodes that were part of a corrupted orphan linked list found.  

/dev/sdb1: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
    (i.e., without -a or -p options)
rick@satellite:~$ sudo fsck -t ext4 /dev/sdb1
fsck from util-linux-ng 2.17.2
e2fsck 1.41.14 (22-Dec-2010)
/dev/sdb1 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Inodes that were part of a corrupted orphan linked list found.  Fix? yes

Inode 34604378 was part of the orphaned inode list.  FIXED.
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  -(44735--44749) -(44759--44766)
Fix? yes

Free blocks count wrong for group #1 (1740, counted=1763).
Fix? yes

Free blocks count wrong (378412112, counted=378412135).
Fix? yes

Inode bitmap differences:  -34604232 -34604378
Fix? yes

Free inodes count wrong for group #4224 (6824, counted=6826).
Fix? yes

Free inodes count wrong (121926425, counted=121926427).
Fix? yes


/dev/sdb1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sdb1: 175333/122101760 files (1.4% non-contiguous), 109965865/488378000 blocks

At this point, I was able to hook the drive back up in my HTPC and it booted again.

Big Ten: 1, Pac-10: 0

Intrigue abounded last week as, in an attempt to preempt the Big Ten's much publicized expansion plans, the Pac-10 accepted the University of Colorado into league membership. This was expected to be the first domino to fall, setting off a chain reaction that would forever alter the landscape of college Football. Indeed, within a few days the University of Nebraska had joined the Big Ten and Boise State had moved to the Mounain West Conference. By Friday afternoon, it appeared that the Big XII was on the brink of Armageddon.

Perhaps bigger news than the demise of the Big XII, especially for those on the West Coast and those in Big Ten country (such as me), was what would be coming next: the "Pac-16" superconference. Pac-10 commish Larry Scott, in a swift and shrewd move, was set to one-up the Big Ten's expansion by adding up to five additional teams including elite programs in the Universities of Texas and Oklahoma, as well as Oklahoma State, Texas A&M, and others. The Big Ten's addition of a historical superpower who appear poised to return to their former glory, not to mention the addition of a much-desired conference championship game, would be completely overshadowed by the creation of what would truly be a juggernaut of a conference. Those sneaky west coasters!

However, further moves were put on indefinite hold today as the Big XII effectively circled the wagons and managed to keep the remaining ten members together. This is bad news for the Pac-10 and great news for the Big Ten: the former's expansion has stalled with the addition of a very mediocre team which adds nothing to conference prestige, and the latter has added a solid team and will be able to silence critics who complain about its teams not having as difficult a path to bowl season now that a championship game will be installed following the 2010 season. Not only that, but the Big Ten will finally no longer award shared conference titles, which is something I have never liked very much.

To summarize: Big Ten: 1, Pac-10: 0.

The non-BCS Mountain West Conference has come out of this looking good as well. That group, which already included several formidable teams in BYU, Utah, and TCU, now also includes Boise State, the plucky giant-killers. Some are saying that this will help them to finally become an automatic-qualifying BCS conference, which would help to quell some of the perennial controversy surrounding very strong teams from "mid-major" non-BCS conferences, such as Boise State and Utah over the past few seasons.

Now we just need to figure out what these conferences should be called. Pretty much everyone has been making fun of the Big Ten since it added its eleventh team--what will happen now that we have 11 teams in the Pac-10, 10 teams in the Big XII, and 12 teams in the Big Ten?

This first round of madness has left the Big Ten in a great position, helped to bolster the MWC, and given the Pac-10 another Arizona Wildcats team. I like how things have played out so far. Until the next round of conference shuffling, which appears not to be on the horizon for now, let's hope Jim Delaney can stay ahead of the game.

Using .jnlp files in Ubuntu 10.04

After a rocky upgrade to Ubuntu 10.04, I encountered my first issue with my out-of-the-box experience using the new release of Ubuntu. In order to attend virtual class sessions through an online course at a local university in which I am currently enrolled, I use a Java application (specifically, one built on the Elluminate platform). Accessing the class involves me downloading and running a .jnlp file using the installed JRE.

When I attempted to log in to class tonight, however, I was unable to do so. When I ran the jnlp file, the interface attempted to load, then crashed. The command line output was:


Exception in thread "Elluminate Live!" java.lang.NoClassDefFoundError: Could not initialize class com.elluminate.util.UtilDebug
    at com.elluminate.util.I18nText.getResourceList(I18nText.java:523)
    at com.elluminate.util.I18nText.(I18nText.java:52)
    at com.elluminate.util.I18n.(I18n.java:57)
    at com.elluminate.platform.Platform.(Platform.java:39)
    at com.elluminate.compatibility.CThread.(CThread.java:15)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:616)
    at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:454)
    at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:731)

The issue, I discovered after browsing launchpad for a few minutes, is known to come up with the OpenJDK JRE, which is the default JRE for Ubuntu beginning with this new release, and .jnlp files. At this time, there are multiple open bugs on launchpad regarding the same or similar issues, so I did not bother filing another.

Luckily, this can be worked around by installing the non-free Sun JRE. Here is what I did:

First, I followed the instructions here for installing Sun's JRE from the Ubuntu partner repository. However, these instructions are incomplete as there are no steps to configure which JRE is the system default. This is simple and can be accomplished by running the following command in the terminal:

sudo update-alternatives --config javaws

...and following the on-screen instructions. Once I did that, fortunately, I was able to access my course session jnlp file again with no issues.

Firefox 3.6

Every so often, I am surprised when a new version of software I use lands. Last Thursday, I received one such surprise in the form of Firefox 3.6. Normally I follow development news closely enough that it seems like release will never come; however this one slipped beneath my radar. When the browser notified me that the new version had landed, I had no choice but to immediately install it and begin geeking out over new features and performance improvements.

I was most pleased about the huge improvements in JS performance. This is particularly important at work, where I use an XP box that is decidedly less than cutting edge in terms of horsepower. Because I do most of my work in Firefox, improvements in speed are a boon to my productivity.

A comparison two runs through the Sun Spider test on my work PC are below (Spoiler alert: 173% improvement!):

Run 1 (FF 3.5)  Run 2 (FF 3.6)

Another Year of BCS Failures

Last night I sat on my sofa and watched with fascination--but not surprise--as two of the so-called top teams in the nation were embarrassed in big games. Of course, I refer to Florida's 32-13 debacle and Texas's 13-12 escape (which was also a debacle). Yesterday's events underscore the real problem that we have with the BCS/polling system used in college Football at the FBS level. Take this scenario into consideration:

A team has a stellar season, wins their conference and goes on to have a very solid win against a formidable opponent in the bowl game. The following season, most poll voters are very "high" on this team and give them a high ranking in the preseason polls. After a few weeks of play and good performance, this translates into an equal or similar slot in the BCS rankings.

This team goes on to run the table in a conference that turns out not to be as good as expected--top-heavy, indeed, with this team being at or near the top. They didn't prove as much on the field as they should have due to competition that was decidedly sub-par, but because they didn't lose to these other teams, the BCS kept them from falling below their inflated preseason position due to the importance placed on what teams have in the "L" column.

Then, after a season of trouncing any and all opposition, the team reaches the championship game: after so many months of media hype and a zero in the "L" column, the team shows up convinced of their superiority and possibly even slightly complacent. Maybe mix in a key injury during the game. The result is an ugly, ugly night. The team is exposed as a group of "frauds". Not capable of living up to lofty expectations. Charlatans. All of this because the team was propelled to a high position largely because of opinion (beginning with those preseason polls) rather than a résumé built on the field against quality opposition. This team, due to a lack of real challenges on the field during the season, did not progress as much as was needed to meet the challenge that came in the form of the opponent in the championship game. And boy, were they ever punished for it. Not only on the field, but afterward in the form of a critical media and gloating fans of the opposing team.

Who is this team, you ask? It's 2006 Ohio State in the BCS National Championship game. It's also 2009 Florida in the SEC Championship game; 2009 Texas in the Big 12 Championship game. Take your pick.

This kind of nonsense is exactly why the BCS should go. By nature of its very flawed design, this system produces teams like what have been described above. Voters decide which two teams are "best" at the beginning of the season and--barring upsets, which don't often happen when conferences lack parity--the BCS supports what is essentially an educated guess. Last night's games showed that those guesses were wrong. Florida, Texas, and other teams were essentially crowned among the nation's best based largely on last season's performance. Take from them the quality of competition that was expected (which is true this year in both the Big 12 and the SEC) and what do you get? A team that is ill-prepared and ill-progressed late in the season. A recipe for disappointment.

The BCS must go, but it probably never will because the powers that be are making far too much money on the way things currently work, which is a discussion for another day.