GNU Classpath

The last weeks I’ve been working on a command line interface (CLI) for Thermostat. Now the first bunch of commands are available. It’s not much yet, but the groundwork for the really useful ones is laid: 3 Commands can be seen in the above ... [More] screenshot: thermostat service --start (to start the thermostat agent and storage) thermostat list-vms (to list the currently monitored VMs) thermostat help (to print out a list of available commands and get usage information This command line interface will make Theromstat useful in settings where the already available Swing GUI is not feasible, like when running over SSH connections on a remote machine, or for automated/scripted monitoring. Next step will be to add some really useful commands, like getting some actual statistics and analysis about the monitored VMs, find memory leaks, deadlocks, and so on. [Less]

This patch Tuesday Microsoft released MS12-025 that fixes approximately a zillion vulnerabilities in System.Drawing.dll. Here's what they fixed (multiple instances of each issue): Added ... [More] security demands to unsafe methods. Wrap handles in SafeHandle instead of using IntPtr. Use checked to guard against integer overflow when calculating how many bytes to AllocHGlobal. It's a little embarassing to have so many vulnerabilities in this old code. Luckily, silently running .NET code in the browser is becoming a thing of the past. [Less]

The Space and the GridLayout components have been added in Android 4 (also known as Ice Cream Sandwich or ICS) : Space allows to add an empty area in an Android screen. GridLayout allows to organize screen elements in a grid. But how can you use ... [More] these 2 components if you must develop for an older Android version ? There is a compatibility library developed by google to backport some functionalities introduced by ICS. The problem is it doesn’t contain Space and GridLayout. Luckily, Daniel Lew has managed to backport these 2 components. This project is called android-layout and you can get its sources on github. As mentionned in project’s readme (see “Caveats” part), the only drawback is the inability to automatically manage the changes in visibility of the GridLayout‘s child views (it’s probably for that reason google didn’t integrate this component in the compatibility library). Bookmark and Share More »Powered by Bookmarkify™ [Less]

I unintentionally posted this before I verified everything, so once I have verified it all works, I'll updated this post. But this is what should work... Most Interesting Builder in the World: "I don't always build the jdk, but when I do, I ... [More] prefer The New JDK8 Build Infrastructure. Stay built, my friends." So the new Build Infrastructure changes have been integrated into the jdk8/build forest along side the older Makefiles (newer in makefiles/ and older ones in make/). The default is still the older makefiles. Instructions can be found in the Build-Infra Project User Guide. The Build-Infra project's goal is to create the fastest build possible and correct many of the build issues we have been carrying around for years. I cannot take credit for much of this work, and wish to recognize the people who do so much work on this (and will probably still do more), see the New Build Infrastructure Changeset for a list of these talented and hard working JDK engineers. A big "THANK YOU" from me. Of course, every OS and system is different, and the focus has been on Linux X64 to start, Ubuntu 11.10 X64 in particular. So there are at least a base set of system packages you need. I decided to use Ubuntu 12.04, hot off the press, you should run the following after getting into a root permissions situation (e.g. have run "sudo bash"): apt-get install aptitude aptitude update apt-get purge openjdk-6* aptitude install mercurial openjdk-7-jdk rpm ssh expect tcsh csh ksh gawk g++ ccache build-essential lesstif2-dev Then get the jdk8/build sources: hg clone http://hg.openjdk.java.net/jdk8/build jdk8-build cd jdk8-build sh ./get_source.sh Then do your build: chmod a+x common/bin/* cd common/makefiles bash ../autoconf/configure make We still have lots to do, but this is a tremendous start. -kto [Less]

Test driven development is all nice and dandy, but there are some areas that most people find notoriously difficult to test, and often dismiss them as not worth it. The main() method, entry point for any application, is one of them. The problem with ... [More] main methods is that they combine at least two of the patterns that make testing difficult: static method calls and many constructor calls. Let me illustrate it with a snippet of code from Thermostat: public static void main(String[] args) { CommandContextFactory cmdCtxFactory = CommandContextFactory.getInstance(); CommandRegistry registry = cmdCtxFactory.getCommandRegistry(); ServiceLoader cmds = ServiceLoader.load(Command.class); registry.registerCommands(cmds); if (hasNoArguments()) { runHelpCommand(); } else { runCommandFromArguments(); } } This is a rather common way to implement a main method: setup a bunch of things by calling factories and constructors, then launch whatever needs to be launched. The first thing that needs to be done to make this testable is to reduce the problematic static method and constructor calls by moving them into a separate class. How does this look? public static void main(String[] args) { new Launcher().run(args); } This way, we can now test the bulk of the functionality using fairly normal testing techniques such as mocking, injection, etc. We still want to test the actual main method though (even though many will now cry out that this is so trival that it’s not worth even thinking about it… but wait, the solution is not so difficult either). What would need to be tested here? Obviously, there is no state change, only interactions. Therefore, the test would need to be a verification of interaction of the main class with the Launcher class. More specifically, it would need to verify that the run() method is called on the newly constructed Launcher with the correct arguments (and not, say, null). However, we need to somehow get rid of the construction itself and open a way to inject the Launcher instance. That’s how I solved it: public class Thermostat { private static Launcher launcher = new Launcher(); public static void main(String[] args) { launcher.run(args); } static void setLauncher(Launcher launcher) { Thermostat.launcher = launcher; } } This way, we can override the launcher to be tested with a mock launcher, and verify the correct interaction: public class ThermostatTest { @Test public void testThermostatMain() { Launcher launcher = Mockito.mock(Launcher.class); Thermostat.setLauncher(launcher); Thermostat.main(new String[] { "test1", "test2" }); PowerMockito.verifyNew(Launcher.class).withNoArguments(); Mockito.verify(launcher).run(new String[] { "test1", "test2" }); } } The verifyNew() call verifies that we actually create a new instance of Launcher in the static initializer of Thermostat (the main class), and the last call verifies that run() is called on our mock launcher with the correct arguments. And if you are interested in how the rest of the launching code now looks like, and how we test it (in fairly normal unit testing style), take a look at the Launcher and LauncherTest classes. If you have other solutions to the problem of unit testing main methods, I would be very interested in hearing from them in the comments! [Less]

I'm back home after a really great Lang.NEXT conference. The video of my talk is available on Channel 9. The slides are here.