This may seem like deja vu to Slashdot readers, which is what prompted me to post this. I think JSava is particularly interesting, however, because it can handle many fairly advanced features of the JVM and is capable of executing much (most?) of the JDK standard library. Some feature highlights include:

• All 200 JVM opcodes are implemented.
• All native Java types are supported, including 64-bit Longs, which are not natively supported by JavaScript. This is because JavaScript represents everything as 64-bit floating point numbers, which cannot store the full range of 64-bit integer values.
• Full support for the Java threading model, including multithreading, synchronization between threads, and monitors (wait() and notify()). However, note that multithreading does not imply parallelism, which is at the moment effectively impossible in JavaScript - JSava provides threading support by timeslicing a single actual thread of execution.
• JSava is complete enough to execute most major JDK library classes, such as java.util.HashMap and java.util.Random. Even some more exotic classes are mostly functional, such as java.util.concurrent.ExecutorService and company.
• Substantial support for the Reflection API. This may seem like a weird thing to support, but reflection is heavily used in the JDK library classes, so supporting it is critical in enabling complete functionality.
• All the usual Java goodness: exceptions, inheritance, interfaces, runtime error checking, etc... basically all the language features we know and love.
• Native method handling capabilities for handing off to JavaScript implementations (e.g., System.arraycopy(), Thread.start() and lots of JDK support methods).
• Rudimentary I/O support, accomplished through a lot of low-level trickery involving intercepting file descriptors and mapping them to native Java streams. JavaScript itself has effectively zero I/O support, but the only time Java is invoked to handle I/O is in the lowest level native methods (e.g., 'write these bytes to this file handle'). Everything above that (such as I/O buffering) is handled inside the interpreter.

The JDK class files which JSava was developed with are taken from the Mac OS X 10.6 JDK (Java SE 6). The interpreter may work on Linux, but probably won't on Windows without a little bit of tweaking, particularly for I/O (it's on my todo list).

As usual, I've also created a new program page for the project. The main download link (or Dropbox mirror) provides the entire JSava runtime environment, including Rhino and JDK library classes (3.3M). If you have Java installed, running the interpreter is as easy as executing one command (no building required!). If you only want to look at the source code and not actually run the interpreter, you can also download the source only (54K).

There were a lot of engineering tricks that went into JSava and I may write about some of them in the future. However, JSava is still very much a work in progress and I plan to extend it to handle even more than it already does.

Update (9/26/2011): Smarthome has come out with a new revision of the iMeter that breaks this utility -- the meter firmware seems to have changed, and the new one does not provide all the information of the old. To see if you have the old meter (that does work), look for a sticker on the back side of the iMeter. If you see a "V1.1", then you have the old one (good). If you see a "Rev. 1.15", then you have the new one (bad). I'm working on figuring out the 1.15 protocol to get this utility working again with the new ones.

One of my current research projects involves instrumenting a house with a lot of Insteon home-automation devices and collecting data from them. I've been using the very useful Linux plmtools utilities to talk to the Insteon devices programmatically. However, the plmtools suite has a few shortcomings for my purposes: one, the current release doesn't compile or run on ARM-based machines (such as the GuruPlugs I'm using) and two, it has no functionality for talking to the new Insteon power meter, the iMeter Solo. The iMeter Solo basically works exactly like a Kill-A-Watt meter, except that since it's an Insteon device it's possible to interface with it.

I've dealt with both of the above problems. I've fixed the ARM-specific problems in the code so it runs great on the GuruPlug, and I've added functionality for querying the current wattage level from an iMeter Solo. I imagine there are others who would like to use plmtools on ARM-based machines, and as far as I know there are no existing tools that allow you to query the iMeter from within Linux. Now, you can query the current watt draw reported by the iMeter using a simple 'insteon mydevice meter' command.

Also note that the iMeter Solo is frequently advertised alongside a special 'HouseLinc'-enabled version of the PLM that's required to use the HouseLinc software that can talk to the iMeter. This is unnecessary for my solution, which works just fine on a regular PLM.

You can download the modified plmtools here. See the included README for details both on how the base plmtools utilities work as well as how the added meter functionality works. I'm trying to get in touch with the original author of plmtools to see if I can get these changes integrated into a future release on SourceForge, but so far haven't had any luck.

I'd like to avoid using the mouse at all, of course. Someone got the sources to SoundSource and created a little command-line app called audiodevice that can do the switch without a GUI. Making progress, but that still requires executing a custom command to switch from the headphones to speakers or vice versa. As a final step, I threw together a quick script that uses audiodevice to toggle between the two without any arguments:

#!/usr/bin/perl -w

use strict;

my $device1 = 'Headphones'; # my speakers, plugged into my computer's jack
my $device2 = 'iMic USB audio system'; # my headphones, plugged into my iMic's jack

foreach (`audiodevice`) {
  if (/output: (.*)/) {
    if ($1 eq $device1) {
      system("audiodevice output '$device2'");
      exit;
    } elsif ($1 eq $device2) {
      system("audiodevice output '$device1'");
      exit;
    } else {
      print "Unrecognized output device '$1'.\n";
      exit;
    }
  }
}

print "Failed to find output device.\n";

I saved this script as audioswitch and added it to my LaunchBar index so I can call it from anywhere using only 4 or 5 keystrokes. Works exactly as I'd like, and you can modify it to toggle between any two devices by substituting the name of the devices (in the Output tab of the Sound preference pane) into the script.

UPDATE (3/11/10): I've fixed up the above script so that it automatically figures out what the two output devices are and switches between the two accordingly. This means that it'll work for switching between the iMic and either internal or external speakers. Also fixed a problem where system sounds would continue to play through the original device after switching and added a Growl notification with growlnotify.

#!/usr/bin/perl -w

use strict;

my $device1;
my $device2;

foreach (`audiodevice output list`) {
  chomp;
  if (defined $device1) {
    $device2 = $_;
    last;
  } else {
    $device1 = $_;
  }
}

foreach (`audiodevice`) {
  if (/output: (.*)/) {
    if ($1 eq $device1) {
      activate($device2);
      exit;
    } else {
      activate($device1);
      exit;
    }
  }
}

print "Failed to find output device.\n";

sub activate {
  my $device = shift;
  system("audiodevice output '$device'");
  system("audiodevice system '$device'");
  system("growlnotify -n audioswitch -m 'switching to $device'");
}

You'll need to have iSightCapture installed and in your $PATH -- you can either do that by manually installing the binary at the above link or via MacPorts with 'sudo port install isightcapture'. Then create a new file in /usr/local/bin (or wherever) and put in the following Perl snippet:

#!/usr/bin/perl -w

use strict;

foreach (split(/\n/, `ps aux | grep loginwindow`)) {
  if (/^\w+\s+(\d+).+?loginwindow\.app/) {
    my $sudo = ($> == 0) ? '' : 'sudo ';
    exec("$sudo launchctl bsexec $1 isightcapture @ARGV");
    exit;
  }
}

print "Failed to find loginwindow process.\n";

I called the new binary 'snap', so at the command-line, I just type 'snap image.jpg' instead of 'isightcapture image.jpg'. The only real difference from isightcapture is that you need sudo -- that's an intentional Mac OS X security restriction that can't be circumvented (and probably shouldn't) as far as I know. All the iSightCapture command-line options should work as-is, so just refer to its documentation for those. The wrapper script is definitely a hack that might break with a future OS update, but has worked flawlessly for me on several different machines running a variety of Mac OS X versions.