Tuesday May 26, 2009

FIRST Show-and-Tell at Burlington, MA campus

Last Friday we had three teams, five robots, WPI and FIRST come to visit Sun's Burlington, MA campus. The teams talked about their robots and experiences with FIRST, and mentors explained what mentoring for FIRST was all about.

Two of the robots were Java-powered - team 1519's little "Speed Racer" (look for the Duke on top), and WPI's demo robot ("demo" may stand for demonstration or demolition). Steve Heller arranged a demonstration of torque:


Check out FIRST Robotics @ Sun for future FIRST show-and-tells on campus, and more information about FIRST.

Next stop - JavaOne!

IMG_4555 IMG_4554 IMG_4552

Wednesday May 20, 2009

Upcoming FIRST events - JavaOne & Burlington Campus visits

Here are some upcoming events where you can learn more about FIRST, the FIRST Robotics Competition, Java + FIRST, and FIRST @ Sun.

This Friday, for Sun employees, we will have one or two FRC teams visiting the Burlington, MA campus. They will show off their robots  - and you can learn about what FRC means to them, and about mentoring and volunteer opportunities that exist. I'll also be here to talk about Java on the FRC robots, and should have a robot to demo.

Sun has given FIRST a big platform at JavaOne to show off what FIRST is about. It's also a chance to announce that along with Java being available for the robotics competition next year comes a need for experienced Java developers to mentor teams all across the United States and internationally.

There will be live robot demos in the Pavillion, where you can also talk to teams, mentors, and volunteers about FIRST. There will be a Tech Session describing Java for FRC - both how it was ported and how it can be used (TS-4945), a Birds-Of-a-Feather session for existing FIRST participants as well as though interested in learning more (BOF-4953), and perhaps a comment from James Gosling at his closing keynote!



Venue Location
May 22


FIRST Teams "show-and-tell"
Sun Cafeteria\*\*\* Burlington, MA
Jun 1-4

FIRST booth and Robot Arena
Java Playground - Pavilion JavaOne
Jun 4

Tech Session 4945: FRC-FIRST Robotic Competition
Esplanade 305 JavaOne
Jun 4


BOF-4953: FRC-FIRST Robotic Competition
North Hall 124 JavaOne

Keep in mind that the JavaOne Pavilion access is FREE. Students can get access to all JavaOne events FREE

\*\*\* The event at the Sun campus in Burlington, MA is open to emplyees only.

Monday May 18, 2009

Java for the FIRST Robotics Competition!

On April 16th we announced that Java would be available for the FIRST Robotics Competition. This is joint work between Sun and WPI to port Squawk (an open-source Java virtual machine) to the compactRIO robot control system, as well as the WPILib robotics library from C++ to Java.

We expect this to be a great addition for FRC teams that have some Java programming experience, and will bring not only the combination of power and safety inherent in Java to robotics programming, but also the ecosystem of Java tools, libraries and learning resources.

The exact flavor of Java that will be available is Java ME (Micro Edition), configured with the CLDC and IMP libraries. This is essentially the same flavor of Java that is installed in millions of cell phones (but without the graphic user interface libraries - LCDUI).

In addition the system is based on the libraries and SDK of the Sun SPOT project. It includes over-the-air debugger support as part of integration with the NetBeans and Eclipse IDEs and also includes ant-based command line tools.

The Java system will be in closed alpha and beta releases over the Summer and Fall, and will be ship in the "kit of parts" for the 2010 season (if not earlier).  We have also developed a software-only robot emulator that allows you to learn how to develop robotic software in Java using the Sun SPOT APIs (but doesn't yet include the WPILib APIs).

I'll be blogging more about this, including technical details, the Atlanta Championship, and Java + FIRST @ Java One, but here are some pointers to more information:

Monday Mar 23, 2009

Colorado FIRST Robotics Regional This Weekend

Just a reminder that the Colorado FIRST Robotics Regional competitions are this weekend! This is a free chance to see high school students compete with "gracious professionalism", as well as watch their adult mentors wears funny outfits and tear their remaining hair out.

Just 31 minutes from the Broomfield campus (says Google).

Date Event Venue Location
Mar 28 Colorado FRC Regional University of Denver, Ritchie Center Denver, CO

There are more details at FIRST Robotics @ Sun , especially the Event tips page.

Burlington High School, Team 2876

(Burlington High School, Team 2876, Boston FRC Regional)

Thursday Mar 12, 2009

Silicon Valley FRC Regional This Weekend

Just a reminder that the Silicon Valley FIRST Robotics Regional competitions are this weekend! Don't miss out on a great chance to watch students turn into engineers - oh, and some robots compete also :-)

Date Event Venue Location
Mar 14 Silicon Valley FRC Regional San Jose State U, The Event Center San Jose, CA

There are more details at FIRST Robotics @ Sun , especially the Event tips page.

Thursday Mar 05, 2009

Article on LAST year's FIRST Robotics Regional in Boston

Xconomy.com had a nice write up of last year's FIRST Robotics Regional in Boston. Maybe they'll promote this year's events in Boston, San Diego, and Seattle.

Boston and San Diego FIRST Regionals This Weekend

Just a reminder that the Boston and San Diego FIRST Robotics Regional competitions are this weekend. I'll be visiting the local Sun-related teams in Boston.

Date Event Venue Location
Mar 7 Boston Regional Boston U., Agganis Arena Boston, MA
Mar 7 San Diego Regional San Diego Sports Arena San Diego, CA

There are more details at FIRST Robotics @ Sun , especially the Event tips page.

[Sorry for the repost - going out to the Sun Labs blogroll this time...]

Wednesday Mar 04, 2009

2009 FIRST Competition Game - Lunacy

Re: FIRST Robotics Events Over Next Few Weeks.

If you're thinking about going to a competition, it helps to know the rules for the game (it changes every year).  Here's a 3 minute overview:

Boston and San Diego FIRST Regionals This Weekend

Just a reminder that the Boston and San Diego FIRST Robotics Regional competitions are this weekend. I'll be visiting the local Sun-related teams in Boston...[Read More]

Tuesday Feb 24, 2009

FIRST Robotics Events Over Next Few Weeks

This is the time of year when the FIRST Robotics Competitions start the regional championships. This is where six weeks of hard work by high-school students and their mentors are put to the test - complete with loud music, cheer leading, flashing lights and major enthusiasm.

If you've ever been curious to learn more about these robotics teams - for your kids, or for yourself as a potential volunteer, this is the way to find out. It's fun and it's free!

 Here's a short list of events near major Sun campuses:

Date Event Venue Location
Feb 28 Granite State Regional Verizon Wireless Arena Manchester, NH
Mar 7 Boston Regional Boston U., Agganis Arena Boston, MA
Mar 7 San Diego Regional San Diego Sports Arena San Diego, CA
Mar 14 Silicon Valley Regional San Jose State U, The Event Center San Jose, CA
Mar 28 Colorado Regional University of Denver, Ritchie Center Denver, CO

There are more detail at the FIRST Robotics @ Sun Wiki, especially the Event tips page. You can search for all events at the FIRST website.

Monday Feb 23, 2009

FIRST Robotics @ Sun Wiki

I've started a public Wiki FIRST Robotics @ Sun for Sun employees, alumni, and family to learn and sharing information about getting involved with the various great FIRST robotics organizations:

I can't say enough good things about FIRST - their goal to inspire kids to learn about science and technology meshes really well with Sun's goals and with the engineering mindset of many employees. FIRST is always looking for volunteers to mentor teams and impart that engineering mindset. So check out the wiki!

Friday Feb 06, 2009

GC debugging + surfing + nutrition?

      A year ago I was tracking down a garbage collector bug in Squawk over many days. Like most debugging, you start with a theory of what might be going wrong, figure out what data would prove or disprove the theory, and try to reproduce the bug while getting this critical data.
recycle logo
But now life starts getting interesting. We can't use a debugger on device when the system is this broken. And the system is built on an abstraction of objects (almost everything in Squawk is written in Java), but when memory overwrites can blow away metadata like object lengths and class pointers, you realize that you can't trust everything you see.

This isn't the profound, but ultimately simple, betrayal of the ground during an earthquake. Garbage collection can effect every object in the heap, so garbage collection bugs are more like betrayal in a bad Kung Foo movie:


I had spent a few days and several dives down into the system, only to rise to the surface with theories disproved or becoming deeply disoriented. So one morning, I started with a new theory and tools, took a deep breath, and dove into the system again. Suddenly I was struck with a flashback of body surfing as a kid at Hendry's Beach and getting slammed by waves, tumbling around until I didn't know which way was up. cc

After reminiscing for a few minutes, I realized how amazing it was that my metaphoric dives and confusion could invoke such as strong memory. I could feel the oily tar residue of the ocean in my mouth. I could taste the seaweed that always reminded me of ice cream and of the kelp harvesters on the horizon.

I started thinking about how high-level metaphors could trigger such low-level sensory memories, when a sudden small burp reminded me of the fish oil pills and smelly vitamins that I had washed down that morning with a cup of hot coffee. Lesson learned :-)

ps. There was still a GC bug to fix. It turned out that we were removing the stack object (yes, it's an object) for a dying thread from the set of GC roots while the thread was executing the last few steps of thread shutdown. Yikes!

Tuesday Jan 13, 2009

Terminal to Serial Device From VMware Fusion

This describes how to get a terminal in Windows running on VMware Fusion on a Mac to a serial device connected using an adapter (in this case, a Keyspan USB High Speed Serial Adapter). For example how to connect a Mac using VMware to a National Instruments cRIO for the FIRST Robotics Competition...

[Read More]

Monday Jan 12, 2009

Terminal to Serial/USB Devices From a Mac

How to get a terminal window on a Mac to a USB device or a serial device connected using a USB-to-Serial adapter (like a Keyspan) using the screen command. Useful for talking to Sun SPOTs, FIRST Robotics Competition controllers (cRIO), etc...
[Read More]

Monday Dec 15, 2008

Class Literals in Java ME


Last week I learned that there was more to Java class literals than I expected - and not in a good way. If you're working in Java SE you can skip reading now, but in Java ME this might be of interest...

Class literals were added to the Java language in 1.1 days - they allow you to get a reference to a Class object as if any class had a static field called "class". So you can get the Class object for the String class by using the expression String.class instead of calling Class.forName and dealing with exceptions.

This is a great convenience - not for avoiding some try-catches (you could use a helper method for that) -  because the class name is checked at compile-time instead of run-time. If you change the name of a class everywhere but in the string passed to Class.forName, javac won't be any help.


In Java 1.5 the JVM Spec was updated to include direct support for class literals (extending the ldc bytecode). But how did class literals worked in Java 1.1 through 1.4? And how do they work in Java ME CLDC now?

It turns out that javac just keeps generating code until it works :-) There are a couple of variations in what it does depending on the Java target version used, but I'll describe what I've seen for -target 1.2 or 1.3 (which includes most (all?) Java ME CLDC applications).

Consider this trivial class using a Class Literal:

public class ClassTest {
    static Class c2 = String.class;
Javac will generate code roughly like this:
public class ClassTest {
    static Class c2;

    static Class class$java$lang$String; // cache (would make sense with a different example)

    static {
        if (class$java$lang$String == null) {
            class$java$lang$String = class$("java.lang.String");
        c2 = class$java$lang$String;

    static Class class$(String name) {
        try {
            return Class.forName(name);
        } catch (ClassNotFoundException ex) {
            Exception newex = new NoClassDefFoundError(ex.getMessage());

Bigger Issue

OK, so this is getting a little messy - the simple expression String.class is generating about 33 bytes of bytecode plus overhead for an anonymous field and method. But what happens when the class literal is referenced from an interface instead of a class? Note that interfaces can't have static methods, so javac generates an anonymous class to hold the anonymous method!
public interface InterfaceTest {
    static Class c2 = String.class;
Javac will generate code roughly like this:
public interface InterfaceTest {
    static Class c2;

    static {
        if (InterfaceTest$1.class$java$lang$String == null) {
            (InterfaceTest$1.class$java$lang$String = class$("java.lang.String");
        c2 = (InterfaceTest$1.class$java$lang$String;

public class InterfaceTest$1 {
    static Class class$java$lang$String;

    static Class class$(String name) {
        try {
            return Class.forName(name);
        } catch (ClassNotFoundException ex) {
            Exception newex = new NoClassDefFoundError(ex.getMessage());
This results in the same amount of bytecode overhead, but now we have extra class overhead. The class file for the anonymous class InterfaceTest$1 is about 587 bytes. Now multiply this by every interface that references a class literal.

Java Native Access

So why would anyone have interfaces that references a class literals? Check out the Java Native Access (JNA) project. JNA is an interesting system that lets you declare native functions you'd like to call from Java, and JNA takes care of generating a callout, without generating any JNI code. I'll be blogging about JNA in the future.

The typical JNA usage pattern is to declare an interface that contains the functions you want to call (as interface methods), and JNA creates an implementation that will actually do the call. To match the interface and implementation to a dynamic library containing the native code, the interface should declare a static variable such as:

    public interface CLibrary extends Library {
        CLibrary INSTANCE = (CLibrary)
            Native.loadLibrary((Platform.isWindows() ? "msvcrt" : "c"),
        void printf(String format, Object... args);

So What? And Where's the Squawk Connection?

OK, to recap, in Java 1.5 and later, this doesn't happen because the JVM can handle class literals. But in a Java ME system with tight memory constraints, such as what Squawk is designed for, this could add up.

But the Squawk VM handles class literals just fine, it's just that javac doesn't know that. In the process of converting normal Java bytecodes into Squawk bytecodes, we can do a lot of cleanup. The simplest trick that comes to mind is to pattern match in the static initializer "clinit", looking for the initialization of the anonymous field with a call to the anonymous method.

If we simply replace the call to class$("java.lang.String") with a load of the class literal, then the anonymous method will not be called, and the dead method elimination (DME) phase will delete the method.

Getting rid of the anonymous class is trickier than I first thought, because the cache variable ("class$java$lang$String") gets declared in the anonymous class. In theory we can handle this by constant propagation - the cache field is final, and is really initialized by a constant value, so we can replace references to the cache with the load of the constant class litereal. If we implemented dead field elimination there would be no references to any fields or methods of the anonymous class and dead class elimination (DCE) could do it's job!

I've got to get dead class elimination checked in one of these days, but in the meantime I now know where all of these anonymous classes are coming from.

ps. I'd like to thank openjdk.java.net for having the sources for everything, in particular Lower.java.


Out of the fog... of bits, bytes, and really small Java Virtual Machines, by Derek White. The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.


« April 2014