This is a very recent one, not that hard to spot but I have to admit I had to take a look at the code a couple of times over before realizing what a silly mistake I’d made.

So what I wanted to do is use a simple thread pool, and then I wrote a thread factory so I could make sure the threads I created had names I could recognize while debugging the program. Here’s sort of what the code looked like;

        
ExecutorService pool = Executors.newFixedThreadPool(10,new TFactory(10));

public void doSomething(final String something)
     Runnable workOnSomething= new Runnable() {
          @Override
          public void run() {
               System.out.println("Do " + something);
          }
     };
        
     pool.submit(workOnSomething);
}

public class TFactory implements ThreadFactory {
     int threadCount;

     @Override
     public Thread newThread(Runnable run) {
          return new Thread("MyThreadFactoryThread-" +
          (threadCount++));
     }
}

The problem? My threads weren’t running, if you call doSomething(“test”) you won’t see the corresponding “Do test”. Ever.

Do you see the problem?

OK, like I said this is not a hard one. I used the wrong constructor, and omitted to pass the Runnable run along to the thread. No big lesson to learn here, just to be careful with the constructors.

I guess I could also have focused on using the constructor that takes a runnable, and then set the name using setName() instead of doing it via the constructor. Kind of makes you wonder why have a Thread constructor that didn’t have a Runnable in the first place, since you can’t set it after creating the Thread. Of course the answer to that it can be useful for those times you may want to subclass Thread (which in most cases is not a great idea).

But no excuses, I messed up!

I had planned on continuing posting about “Hidden Java 7 Features” much earlier, but spent too much time on working examples that were too elaborate. Such was the case with SecondaryLoop, so I decided to go ahead and just talk about it now and perhaps post my example later (it’s a cool visualization of hard drive contents).

java.awt.SecondaryLoop is a new Java 7 interface that enables improved control of the execution flow of a Swing/AWT program. I’m labeling it a “hidden” feature in the sense that there’s not much written about it (at least that I could find on Google) beyond its javadoc description. It’s the type of feature you won’t see in a “top ten” list of Java 7 enhancements, but if you’re doing Java UI work it’s a great addition that will simplify your code.

So what does it do?

Often in your UI program, your next step depends on some other task; input from the user, a network call, reading a file, etc. Being event driven, the flow of a UI application can get more complex in these situations, specially when these tasks could be long running and you don’t want to hang the UI. Remember, doing any task that takes a long time (like I/O) on the event dispatcher thread will hang your UI. The typical solution is to then use a SwingWorker for that code. The problem with SwingWorker is that it makes the code a bit more complicated. Once you do work in the worker, you have to call another method to perform the next task in the UI. Let’s look at this following diagram.

The blue boxes represent tasks that would have to be done in a SwingWorker. The flow of execution then is handed off to the worker, when the first worker task is done (Find all files), it then has to call “build treemap” when it is done. That worker will then do its work, and when done it will call “draw treemap” (which doesn’t need to be executed in a SwingWorker, here it just shows that it would have to be called again).

The alternative is to use SecondaryLoops. We can pretty much write the main flow of the code more linearly, as shown by the green boxes. Every time we have a task that can take a long time, we can then use SecondaryLoop to do the work in a thread but hold the flow of execution without blocking the UI until that thread is done with its work. This is how this code looks like …

    public void start() {
        startStopButton.setText("Cancel");
        initializeFileTypeDatabase();

        JFileChooser fileChooser = new JFileChooser();
        fileChooser.setFileSelectionMode(JFileChooser.DIRECTORIES_ONLY);
        fileChooser.showOpenDialog(this);

        List files = findFiles(fileChooser.getSelectedFile());

        if (working) {
            FileAnalysis analysis = analyzeFiles(files);

            treemap.buildTreemap((List)analysis.getCategories());
        }
        progressText.setText("");

        working = false;

        startStopButton.setEnabled(true);
        startStopButton.setText("Start");
    }

The code is:

• Asking the user for a top-level folder/directory
• Gets all files under that directory (block without freezing UI)
• Builds treemap (block without freezing UI)

Let’s look at the SecondaryLoop usage of the findFiles method.

 /**
 * Given a root file/directory, return all files underneath it.
 * This method can be safely invoked from the UI dispatch 
 * thread without blocking the UI
 */
 public List findFiles(final File baseDir) {
        working = true;
        final List files = new ArrayList<>();

        if (baseDir == null || !baseDir.isDirectory()) {
            System.out.println("Not a directory!");
            return null;
        }

        if (baseDir != null && baseDir.exists() &&
            baseDir.isDirectory()) {
            Toolkit kit = Toolkit.getDefaultToolkit();

            // Create secondary loop from awt Toolkit, this is the object
            // we'll use to block the flow of code without freezing the UI
            // until another task/thread finishes its work
            final SecondaryLoop loop =
              kit.getSystemEventQueue().createSecondaryLoop();

            Thread work = new Thread() {

                public void run() {
                    getFiles(baseDir, files);
                    loop.exit();
                }
            };

            // We start the thread to do the real work
            work.start();

            // Blocks until loop.exit() is called
            loop.enter();
        }

        return files;
    }
    /**
    * Recursively traverse all children of "root" 
    * and store them in "files"
    */
    public void getFiles(File root, List files) {
        if (root.isDirectory() && working) {
            File[] children = root.listFiles();

            if (children != null) {
                for (File file : children) {
                    if (file.isDirectory()) {
                        getFiles(file, files);
                    } else {
                        files.add(file);
                        status(file.getAbsolutePath());
                    }

                    if (!working) {
                        break;
                    }
                }
            }
        }
    }

So findFiles() is a method that will return all files under a given base directory. This method will gather all the results and come back when done, without freezing the UI even when called from the event dispatch thread. The nice thing about it is that then our code can flow more naturally. As we see in the previous code listing, start is a method called after a button pressed and we can call sequences of methods that do a lot of work, while keeping the main UI code nice and simple. When we do this with SwingWorkers, the flow of execution gets more complicated, because once the SwingWorker is done, if there are more tasks to be performed we have to called another method.

Another great thing about this method is that we can change the UI state directly after actions are performed. At the beginning of the start() method we change the name of the startStopButton to “Cancel”, then at the end we reset it back to “Start”. We can then write cleaner UI methods with state changes (like enabled, hidden, etc) in one method, instead of doing this at the end of our last SwingWorker, coordinating across different SwingWorkers and/or methods.

In conclusion, SecondaryLoop is not very difficult to use and is great to simplify your Java UI code and make your life happier!

A couple of weeks ago I wrote a summary of 7 new cool features in Java 7. Others have written great blog posts about them, so I was thinking it might be useful for me to focus on lesser known or “Hidden Java 7 Features”. In the next few weeks, I’ll try to explore and write a series of blog posts about them.

System and Process CPU Load Monitoring

Java 7 provides a new MBean that finally allows Java developers to access overall System and current process CPU load monitoring. This feature is not really that hidden as it’s listed in the what’s new page for JDK 7, but I haven’t really noticed a lot of talk about it and I certainly overlooked it initially.

The interface com.sun.management.OperatingSystemMXBean, has two new methods that easily get this information; getSystemCpuLoad() and getProcessCpuLoad(). Both methods return the load as a double value in the [0.0,1.0] interval, with 0.0 representing no load to 1.0 representing 100% CPU load for the whole system or the current JVM process respectively.

It’s pretty easy to get access to this MBean;

import com.sun.management.OperatingSystemMXBean;
...
OperatingSystemMXBean osBean = ManagementFactory.getPlatformMXBean(
                OperatingSystemMXBean.class);
// What % CPU load this current JVM is taking, from 0.0-1.0
System.out.println(osBean.getProcessCpuLoad());

// What % load the overall system is at, from 0.0-1.0
System.out.println(osBean.getSystemCpuLoad());

Wasn’t this already available?
Java 6 introduced a new method in java.lang.management.OperatingSystemMXBean called getSystemLoadAverage(), which could get the CPU average for the overall system (there wasn’t a mechanism for the JVM/current process load). However this doesn’t seem to work on Windows and would just return a -1 (tried this with Java 7 in Windows 7 and that is still the case).

Other ways of doing this prior to Java 7 would include Java APIs implemented via native libraries like SIGAR, which are good alternatives but obviously not part of the standard Java distribution, or may not support most platforms.

Now the bad news
If you notice in my code I use com.sun.management.OperatingSystemMXBean, not java.lang.management.OperatingSystemMXBean which means the methods getSystemCpuLoad() and getProcessCpuLoad() are not part of the official, supported public interface of the Java Platform. Oracle actually discourages the use of these packages, since they could be removed in future releases or may not be available in all JVM implementations.

I’m not 100% sure why these methods were only added to the com.sun version of OperatingSystemMXBean. Initially I thought it was because Oracle didn’t want to add a method to a public interface (which would break any code implementing that interface), however Java 6 added getSystemLoadAverage(). If anybody has any insight on this, please let me know.

There are ways to use these new methods without having a hard dependency to these com.sun classes (for example via reflection, or using JMX conventions), I may cover these in a future blog post or update to this one.

Demo, JCPUMon
Finally, I wanted to do a simple UI that would use this feature to have a little widget to monitor system CPU and current process load graphically. I call it “JCPMon”, it can be launched as a standalone Java application, run inside an application you want to monitor or just used as a Swing component in a Java UI.

The green part of the graph represents the overall system CPU load, while the yellow part represents the current process load, in this case CPU load imposed by the GUI (I did a lot of resizing to get a few yellow bars for this image ). If you want to monitor a Java application you already have, you can easily do so by calling;

// This method won't block, so you can call it at the start of your program
com.sellmic.apps.monitoring.jcpumon.Main(null);

// And then continue doing anything else ...

Of course an improvement would be to have the ability to connect to an external process via JMX (remote or local).

You can launch this app via webstart, .You’ll need Java 7 to be installed.

This simple GUI uses this new Java 7 capability and also has some extras to configure the look of the UI (squares or circles, size, how often to update, always on top, full screen). If anybody is interested in the code for this let me know and I can setup a page to host it.

UPDATE: JNLP URL was wrong, if you tried webstart before and it failed please try again. Sorry about that!

The evolution of the Java language and VM continues! Mark Reinhold (Chief Architect of the Java Platform Group) announced yesterday that the first release candidate for Java 7 is available for download, he confirms that the final released date is planned for July 28.

For a good overview of the new features and what’s coming next in Java 8, I recommend this video on the Oracle Media Network, which features Adam Messinger, Mark Reinhold, John Rose and Joe Darcy. I think Mark sums up Java 7 very well when describing it as an evolutionary release, with good number “smaller” changes that make for a great update to the language and platform.

I had a chance to play a bit with the release candidate (made easier by the Netbeans 7  JDK 7 support!), and decided to list 7 features (full list is here) I’m particularly excited about. Here they are;

1. Strings in switch Statements (doc)

Did you know previous to Java 7 you could only do a switch on char, byte, short, int, Character, Byte, Short, Integer, or an enum type (spec)? Java 7 adds Strings making the switch instruction much friendlier to String inputs. The alternative before was to do with with if/else if/else statements paired with a bunch of String.equals() calls. The result is much cleaner and compact code.

    public void testStringSwitch(String direction) {
        switch (direction) {
             case "up":
                 y--;
             break;

             case "down":
                 y++;
             break;

             case "left":
                 x--;
             break;

             case "right":
                 x++;
             break;

            default:
                System.out.println("Invalid direction!");
            break;
        }
    }

2. Type Inference for Generic Instance Creation (doc)

Previously when using generics you had to specify the type twice, in the declaration and the constructor;

List<String> strings = new ArrayList<String>();

In Java 7, you just use the diamond operator without the type;

List<String> strings = new ArrayList<>();

If the compiler can infer the type arguments from the context, it does all the work for you. Note that you have always been able do a “new ArrayList()” without the type, but this results in an unchecked conversion warning.

Type inference becomes even more useful for more complex cases;

// Pre-Java 7
// Map<String,Map<String,int>>m=new HashMap<String, Map<String,int>>();

// Java 7
Map<String, Map<String, int>> m = new HashMap<>();

3. Multiple Exception Handling Syntax (doc)

Tired of repetitive error handling code in “exception happy” APIs like java.io and java.lang.reflect?

try {
    Class a = Class.forName("wrongClassName");
    Object instance = a.newInstance();
} catch (ClassNotFoundException ex) {
    System.out.println("Failed to create instance");
} catch (IllegalAccessException ex) {
    System.out.println("Failed to create instance");
} catch (InstantiationException ex) {
   System.out.println("Failed to create instance");
}

When the exception handling is basically the same, the improved catch operator now supports multiple exceptions in a single statement separated by “|”.

try {
    Class a = Class.forName("wrongClassName");
    Object instance = a.newInstance();
} catch (ClassNotFoundException | IllegalAccessException |
   InstantiationException ex) {
   System.out.println("Failed to create instance");
}

Sometimes developers use a “catch (Exception ex) to achieve a similar result, but that’s a dangerous idea because it makes code catch exceptions it can’t handle and instead should bubble up (IllegalArgumentException, OutOfMemoryError, etc.).
(more…)

Early reviews of Google+ are in and they’re generally positive. Obviously, not everybody love Google’s latest social network experiment, but I’d like to debunk one piece of criticism that keeps being repeated over and over. And that is, that the Google+ Circles feature is basically the same thing as Facebook’s Friend Lists.

Facebook Friend Lists lets users group friends under different lists; family, co-workers, etc., so that you can share things with subsets of your overall Facebook friends. As in real life, you don’t share everything with all the people you know, and with the Friend Lists feature you can emulate that. Sounds very similar to Circles right?

The problem with Friend Lists is the poor usability of this feature. Unlike Circles, you get the feeling that this feature was tacked on, and that it’s not a central component of the service. Creating and assigning people to Circles in Google+ is a lot easier and friendlier than managing Friend Lists, just look at this video from Google which gives you a good overview of how the Google interface handles this.

The main problem with Friend Lists is that once setup they’re a pain to use, which is probably why a lot of Facebook users either don’t know about this feature or don’t bother to use it.

Let’s try to share a message only intended for our family;

First non-obvious thing you have to do is click on the padlock icon. This icon gives you 4 choices; “Everyone“, “Friends of Friends“, “Friends Only” and “Customize“. Unlike Circles, it doesn’t list your Circles of friends or in this case your Friend Lists. What you have to do here is select the “Customize” option which opens up the “Custom Privacy” dialog.

The “Custom Privacy” dialog now gives us another 4 choices; “Friends of Friends“, “Friends Only“, “Specific People…“, “Only Me“. Again, Facebook decides not to show you your Friend Lists, and to select one you have to chose the “Specific People…” option. Now, in the previous screen, we already told the interface we don’t want to send a message to “Friends Only” or “Friends of Friends”, why is it showing us these options again? Bad UI design.

There’s also the strange option to only share an item with yourself (“Only Me“), I guess that’s usefull to save things and share them later. But instead of listing this, I’d rather see my family Friend List.

To find our desired list, again we select “Specific People…“ (1), which shows an empty text entry field. As we start typing “f” for family (2), Facebook is nice enough to show us friends with first or last names that contain the letter “f”. Note that I have so many friends with that letter that in none of the choices my family Friend List shows up. After typing a bit more, “fa” (3), we still see other friends but at the bottom of the choices we finally see our family Friend List. Finally we select it (4) and our family list is added to the field.

Another bad design choice is how Friend Lists are mixed in with regular (singular) friends, at the very least it would be nice to get a visual hint that something is a Friend List vs a singular specific friend.

We then click “Save Setting” at the bottom right of the dialog and go back to our Facebook wall. Obviously, the last step is to press the “share” button, unfortunately Facebook doesn’t make it clear what Friend List or group of friends I’m sharing with. To see that, you need to click again on the padlock icon which instead of indicating what Friend List is selected, it shows a cryptic “Custom edit” selected item on the padlock popup menu. Not clearly showing who we’re sharing with makes it easy to share the wrong thing with the wrong group of people by accident. Again, bad UI design.

And that’s how Friend Lists are used in Facebook. The feature is hidden via the padlock icon, the option is not clear (“Customize“), selection is cumbersome, and Facebook does its best to hide away Friend Lists from the user. It’s almost as if the UI is designed on purpose to discourage the use of this feature.

In contrast, in the Google+ interface, you simply type the text you want to share (or image, video, etc.) and then click on the “Share” button;

From right there you can select with Circle of friends you want to share with. The Circle can be typed in or selected from the list, if it’s not shown in the list simply clicking “more …” will show the rest of the Circles. Unlike Facebook, Circles are not hidden but featured front and center. In this case 2 clicks allow me to quickly select who I want to share with.

Another key usability item to note, once a Circle is selected, Google+ makes it very clear who you are sharing with. In this example we can see the family Circle highlighted in blue and with a Circle icon to denote it represents a group of people. Singular friends added to the group, will also be shown highlighted in blue but without the Circle icon to differentiate them with Circles.This is much better than clicking on a padlock and trying to figure out who “Custom edit” is.

Simply put, when contrasting both approaches we note that;

1. Google has spent a lot more effort on usability in their User Interface design; minimizing clicks, removing the need for additional dialogs, preventing users from sharing information with an unintended Circle, etc.
2. Circles is a key and central feature of Google+, whereas Friend Lists seems more like a feature added as an afterthought, rather than a fundamental aspect of how people share information with different groups of friends.

It is clear that Google+ Circles are friendlier and easier to use than Facebook Lists. On this one central aspect of sharing, it seems Google has done their homework while Facebook really needs to evaluate and reinvent their approach to usability.