Screaming Penguin

POJO to XML serialization with XStream (and POJO to JSON to boot)

charlie.collins — Wed, 20 Aug 2008 13:39:06 +0000

I recently started a project where I am exploring whether or not to use GWT-Ext with GWT in order to leverage some of the widgets therein. One of the first things I ran up against, which seems to hit everyone at some point in this same process, is that GWT-Ext doesn't support GWT-RPC for data feeds out of the box (though they do offer a non-free "Plus" package that can do it - I didn't want to drop the cash though just for an evaluation - maybe more on that later).

So what do they use typically, if not GWT-RPC you ask? Well, JSON of course. JSON is actually pretty nice, and might come in handy for more interop as well in my case, so I decided to see how long it would take to turn a few of my server side POJO data objects into JSON - in order to later work with them with GWT-Ext (the GWT-Ext evaluation I haven't completed yet).

Using XStream it is extremely easy to serialize POJOs to XML, and back again. Now I know there are many libraries that do this, but this is the first one that literally took me 2 minutes to have it working like I expected. Big props to XStream (and Jettison, and XPP3). Below is an example (see the XStream site for more info):

import com.mycompany.proto.gwt.client.model.AssetPojo;
import com.thoughtworks.xstream.XStream;
import com.thoughtworks.xstream.io.json.JettisonMappedXmlDriver;

public class XStreamExample {
   
   public static void main(String[] args) {
      
      // first a POJO (this one is defined in another class, 
      //    but you get the idea, it's a plain getter/setter idiom bean)
      AssetPojo ap = new AssetPojo();
      ap.setAlpha(0.22);
      ap.setBeta(0.12);
      ap.setCash(false);
      ap.setComposite(false);
      ap.setCusip("CUSIP");
      ap.setDescription("description");
      ap.setId("123E47W");
      ap.setTicker("JAVA");
      
      // create a plain jane xstream with an alias (requires xstream and xpp3 on the classpath)
      XStream xstream = new XStream();
      xstream.alias("assetpojo", AssetPojo.class);
      // turn it into XML and display it - this is how it should be my friends, this easy      
      String xml = xstream.toXML(ap);
      System.out.println("XML - \n" + xml);
      
      // turn it back into an object, from the XML
      AssetPojo backToObjectXml = (AssetPojo) xstream.fromXML(xml);
      System.out.println("\nbackToObjectXml id - " + backToObjectXml.getId());
      
      // now turn it into JSON instead of XML (requires jettison on the classpath)
      XStream xstreamJson = new XStream(new JettisonMappedXmlDriver());
      xstreamJson.alias("assetpojo", AssetPojo.class);
      String json = xstreamJson.toXML(ap);
      System.out.println("\nJSON - \n" + json);
      
      // and back to an object again, this time from the JSON
      AssetPojo backToObjectJson = (AssetPojo) xstreamJson.fromXML(json);
      System.out.println("\nbackToObjectJson id - " + backToObjectJson.getId());      
   }
}

And the output looks like this:

XML - 
<assetpojo>
  <id>123E47W</id>
  <description>description</description>
  <isCash>false</isCash>
  <isComposite>false</isComposite>
  <alpha>0.22</alpha>
  <beta>0.12</beta>
  <cusip>CUSIP</cusip>
  <ticker>JAVA</ticker>
</assetpojo>

backToObjectXml id - 123E47W

JSON - 
{"assetpojo":{"id":"123E47W","description":"description","isCash":false,"isComposite":false,
   "alpha":0.22,"beta":0.12,"cusip":"CUSIP","ticker":"JAVA"}}

backToObjectJson id - 123E47W

Android SDK 0.9 beta finally drops

charlie.collins — Tue, 19 Aug 2008 20:49:53 +0000

Announcing a beta release of the Android SDK

Upgrading the SDK

A first look at the Google Android SDK

James Ward does the Flex and Java show at AJUG tonight

charlie.collins — Tue, 19 Aug 2008 15:05:33 +0000

Free, and often even free beer (thanks to the sponsors, you can get ripped even if the talk sucks ;)).

---------- Forwarded message ----------
From: Burr Sutter
Date: Tue, Aug 19, 2008 at 9:02 AM
Subject: [ajug-announce] AJUG Tonight: Flex=Java+Flash
To: ajug-announce@ajug.org

When: August 19th at 7:00 PM
Who: James Ward (Adobe)
Where: Holiday Inn Select - Chamblee-Dunwoody http://www.ajug.org/meetings.html#directions
What: Rich Internet Applications with Flex and Java

The Session:
The Web 2.0 crowd has had significant debates about the use of plug-in based solutions to RIA vs JavaScript-based ones and in this presentation you will see how powerful a Flash-based business-focused web application can be. This presentation will include numerous live coding examples and illustrate how a Java developer can add Flex to their development skillset and environment. Bring your hardest questions, James has been all around the globe speaking with developers about the use of Flex/Flash technology in their next generation applications.

Our Speaker:
James Ward is a Technical Evangelist for Flex at Adobe and Adobe's JCP representative to JSRs 286, 299, and 301. Much like his love for climbing mountains he enjoys programming because it provides endless new discoveries, elegant workarounds, summits and valleys. His adventures in climbing have taken him many places. Likewise, technology has brought him many adventures, including: Pascal and Assembly back in the early 90s; Perl, HTML, and JavaScript in the mid 90s; then Java and many of its frameworks beginning in the late 90s. Today he primarily uses Flex to build beautiful front-ends for Java-based back-ends. Prior to Adobe, James built a rich marketing and customer service portal for Pillar Data Systems.

AJUG Sponsors (provide the facilities, web hosting, speakers and equipment):
* 4t Networks, AJUG's hosting provider (www.4tvirtual.com)
* Anteo Group: Your Java Staffing & Placement Specialist (http://www.anteogroup.com/)
* Intercontinental Exchange (ICE): Looking for Atlanta's best IT talent (http://www.theice.com/jobs.jhtml)
* JBoss: The world's most popular enterprise-class Java middleware (http://www.jboss.com/)
* Sun: The Source of Java (www.sun.com)

Android phone approved by the FCC - HTC Dream

charlie.collins — Tue, 19 Aug 2008 11:25:26 +0000

SDK delays for the general public notwithstanding, its on the way: A ‘Dream’ Come True: U.S. Approves the First Google Phone.

Their reader feeds pretty much sum up the presidential candidates

charlie.collins — Mon, 18 Aug 2008 22:25:32 +0000

I know they are well aware that people check their feeds, and have manipulated the listings accordingly, but that only makes it a bit more shockingly clear: John McCain is officially way beyond losing his sanity (Drudge, and Fox News), and Barack has a brain (Chicago Sun Times, and The Daily Show).

Explore news sites read by McCain, Obama and political journalists

Really useful stuff - turn your Wii into a DVD player

charlie.collins — Mon, 18 Aug 2008 19:08:26 +0000

My DVD broke a while back (first one I have ever had that just stopped working, all the cheap ones over the years were fine, the fancy Toshiba upconverting one dies after a year - I digress). I had a Wii in the same room connected to the same TV, so I just threw out the DVD player thinking to myself - don't need it, will just play em on the Wii (if the need arises).

Later I found out the Wii isn't a DVD player, sorry, no dice. I was literally sitting there one day going with my Wiimote going "you have to be kidding me, right? - this $200+ device that plays all sorts of software on optical discs can't play a DVD movie? WTF!."

So that was a few months back, and today I come across this in my reader feeds (from a knet share) - ta da:
it's a Wii port of MPlayer (problem solved). Props to Team Twiizers, and thanks.

Business requirements are bullshit

charlie.collins — Fri, 15 Aug 2008 17:01:27 +0000

Stevey's Blog Rants - Business requirements are bullshit.

I like the headline too, and the thoroughness of the article, and completely agree - so I thought I would try to do my little part to propagate this knowledge (link it here - etc). Really, I know how hard this is for many PMs and "business analysts" (don't get me started), but it's true.

Call it what you want, but it's a sign of organizational (or individual) cluelessness. If you don't already know exactly what to build, then you're in the wrong business. At the very least, you should hire someone who does know. Don't gather business requirements: hire domain experts.

Two Georgians claim to have found Bigfoot

charlie.collins — Fri, 15 Aug 2008 10:38:41 +0000

Two Georgians Say They Have Bigfoot’s Body

Alternate headline - get yourself in the New York Times by throwing some deer entrails into a cooler on top of a monkey suit.

This article is filed under humor, because these clowns are obviously full of crap, but still, it's a great marketing ploy. One of them just happens to own a *business* that "offers bigfoot tours." The perpetrators of this hoax are going to offer up the "proof," today. But, before that happens, let's take bets on what the excuse will eventually be as to why actual scientists won't be able to examine their "evidence." (Georgia has a great primatalogy institute at Emory university, arguably one of the best in the world, but I guarantee you there will be some reason, or a host of reasons, that no one with any background in real science will be allowed to scrutinize anything.)

As an aside, I live in north Georgia, and mountain bike in many remote areas there often. I haven't personally seen a bigfoot in all my years (imagine that), but this story does scare me. You can never underestimate the stupidity of some rednecks with rifles and a large cooler - mountain bikers and everyone else in the vicinity when there is nothing else to shoot at, beware (and not to mention the stupidity of all the news outlets and bloggers and such that pick up the story just like the clowns want - including me ;)).

US gets uppity about an invasion of "sovereign" territory

charlie.collins — Thu, 14 Aug 2008 00:31:53 +0000

. . . stepping up to soap box . . .

I had an opinion or two about the US invading Iraq back in the day. Before the invasion I was concerned about the geopolitical standing of the US if we unilaterally invaded a "sovereign" country. I was also concerned about the actual effect on terrorism (repeatedly, and logically, noting that bombing the crap out of a group of religious zealots might not be the best way to make our country safer - in fact it might have the opposite affect - whereas dealing with the root causes of the ignorance and hatred might be more useful).

I can't help but chuckle (yes chuckle, in order to keep my sanity I have to laugh at the mostly insane world - I certainly do not mean to belittle the situation and the all too real consequences - getting to that) when I hear Condoleeza Rice, and other representatives of the Bush administration, pretend to be outraged at the Russian invasion of Georgia. They even had the balls to teach W the word "sovereign" and put it in the talking points. (And I may have confused the Georgias back in the day, but this time I am sure they are talking about the former Soviet territory ;).)

Yes it's a bullshit move by the dictator they now have in Russia, Mr. Putin. For years he has been destroying democracy there (shutting down the press, murdering journalists, jailing private citizens that disagree with him, stealing businesses from the private sector and taking them for the government, changing the government rules to suit his whims without a democratic process, etc), and for years we have mostly played along without batting an eyelash (an eyelash on the same eyes we used to look into Putin's "soul" to be certain he is a good guy, mind you).

So the move certainly is something the be outraged about, but just where does the US get off in putting anyone on notice about "invading" "sovereign" countries? (And I mean in reference to Iraq for now, let's leave any other US invasions of territory in the past out of the equation for the moment, such as the *democracies* the US pushed out to get in *dictators* they wanted, for example in Central and South America - and let's also ignore the current dictators the US supports in Pakistan, Uzbekistan, and other areas. The Iraq move itself is enough to make such a position by the US laughable.)

Maybe it's just me, but the world not paying any particular attention to the US administration throwing around "strong words" about the Russian invasion just doesn't seem surprising (one of the consequences of the damage done as a result of the Iraq decision). When the kid that steals everyone's lunch money for years finally tells the new bully to cut it out, it just doesn't seem to resonate.

August 12, 2008

kebernet — Wed, 13 Aug 2008 02:30:37 +0000

I write, therefore the LHC hasn't destroyed the planet.

Testing a Java "executable" (class with a main method, command line options, and std output)

charlie.collins — Mon, 11 Aug 2008 11:28:10 +0000

I was recently tasked with helping to create a Java class that had the same command line options and operation as a C executable. We already had a Java API that handled the actual work, so the goal was really just to handle the command line options and exit codes, hook into the API correctly for all the options, and output the correct stdout and stderr responses.

Sounds pretty easy at first, but, once you make a few options and then try to write a test for a class that only produces stdout (System.out) and stderr (System.err) output, and then exits the VM every time it does something, you realize there is a bit more to it than first glance reveals.

After I got done doing this for a fairly involved class with a lot of options, I made a small example application - App.java - for future reference of the key points. In this post I will discuss the example application, beginning with the easy stuff, parsing the command line options.

I used commons-cli for the command line option handling. There are other libraries out there that do this too, and it's also not out of the question to just roll your own command line parsing, but I was familiar with CLI from days past, and it has always worked well for me, so I just went back to it. The command line processing looks like the following:

   /**
    * Parse the command line options, and produce usage information - uses Commons-CLI.
    *
    * @param args input
    * @throws ParseException if problem encountered parsing options
    */
   private void parseCommandLine(final String[] args) throws ParseException {

      CommandLineParser parser = new PosixParser();

      // create the boolean options
      Options options = new Options();
      options.addOption("h", "help", false, "print this message");
      options.addOption("v", "version", false, "show version");

      // create the name/value pair options - d,r,l
      options.addOption(OptionBuilder.hasOptionalArg().withArgName("value").withDescription(
         "echo the value passed in (required)").create("e"));

      // parse the options
      CommandLine line = parser.parse(options, args);

      if (line.hasOption("h")) {
         HelpFormatter help = new HelpFormatter();
         help.printHelp(80, "TestMainExample [options]", "demonstrates a Main java class and options handling/testing",
                  options, null);
         System.exit(App.EXIT_NO_ERROR);
      }
      else if (line.hasOption("v")) {
         System.out.println("Version 1.0");
         System.exit(App.EXIT_NO_ERROR);
      }

      // if it's the e option, set the echo instance var value
      if (line.hasOption("e")) {
         String value = line.getOptionValue("e");
         if (value != null) {
            this.echo = value;
         }
      }
      else {
         System.err.println("ERROR: -e option with value is required");
         System.exit(App.EXIT_USAGE_ERROR);
      }
   }

With CLI you have a CommandLineParser, and Option[] array. You may notice that I created a separate method just for the CLI stuff. I didn't start out this way, but in order to make it more testable, as we shall come to, I refactored to avoid stuffing everything into the main method (in addition to being more testable, this also makes the class just easier to read and maintain overall). Also, you can see that when a USAGE_ERROR or other problem occurs, the VM is exited with the corresponding exit code.

Next, after the command line handling was in place, I moved the logic into a "process" method, like so:

   /**
    * Process method to keep logic/etc out of main and help testability. 
    * 
    * @param args
    */
   private void process(String[] args) {

      // first parse command line to set state 
      try {
         this.parseCommandLine(args);
      }
      catch (ParseException e) {
         System.err.println("ERROR processing command line args - " + e.getMessage());
         System.exit(App.EXIT_UNKNOWN_ERROR);
      }

      // normal processing 
      System.out.println("ECHO  . . . " + this.echo);
      System.exit(App.EXIT_NO_ERROR);
   }

The process method invokes the command line parser first, to ensure that instance variables are setup based on the selected options. This is one of the key points. I avoided statics for this stuff, which you often see in "main" method type classes, and just made sure the command line processing was the first step, after which the instance variables are used to "do stuff." (In this case just a simple echo, but whatever you need can be handled at this point.)

After the process method the next few things I needed were the main method itself, and a constructor. These are shown below:

   /**
    * Constructor that requires args, and then invokes process 
    * (guarantees that process occurs). 
    * 
    * @param args
    */
   protected App(String args[]) {
      this.process(args);
   }

   /**
    * Command line main runner, makes an instance.
    * 
    * @param args
    */
   public static void main(String[] args) {
      new App(args);
   }

The main method just makes a new instance of the class, and hands it the command line args[]. The constructor calls the process method (which goes through the command line parsing and then performs the logic, as we saw previously). One thing that may seem curious about this is that the constructor is not private. I did that to help out the testing, which we will look at next.

Changing ANY aspect of your class exclusively to facilitate testing always seems like a bad smell to me. Don't get me wrong, I think testing is very important, essential even, but I also think you should have more than just that in mind when you refactor (or add new dependencies for injection frameworks or such). Usually you can justify changes with enhanced readability, or better decoupling, etc, and not say, well, "it's easier to test" this way (just something to keep in mind, I like to see people justify changes with more than "it's easier to test this way" - well, *why* is it easier to test, there is another benefit right?).

At any rate, I made the constructor protected access, just for the tests. Sure there are a few other ways to create private objects that I could have hooped through, but the simplest way was just make it protected and put the test in the same package (as really should be the case anyway). This leads into the tests themselves, where the real challenges in this project were.

So how well does JUnit work when the VM exits, and when the only output is System.out/err? Out of the box, it really doesn't work. But, after searching around a bit I found a lot of people asking about this (testing a main method class), and only a few helpful responses (no articles though, hence this one ;)). Specifically the most helpful response was Lasse Reichstein Nielsen on a velocityreviews forum.

Nielsen mentioned using a security manager that prevents calling System.exit and then catching SecurityException. I went with that approach, modifying the code supplied in the forum a bit to create an AbstractSecurityTestCase:

package com.totsp.example;
import java.security.Permission;
import junit.framework.TestCase;

public class AbstractSecurityTestCase extends TestCase {

   public AbstractSecurityTestCase(String name) {
      super(name);
   }

   protected static class ExitException extends SecurityException {
      public final int status;
      public ExitException(int status) {
         super("There is no escape!");
         this.status = status;
      }
   }

   private static class NoExitSecurityManager extends SecurityManager {
      @Override
      public void checkPermission(Permission perm) {
         // allow anything.
      }

      @Override
      public void checkPermission(Permission perm, Object context) {
         // allow anything.
      }

      @Override
      public void checkExit(int status) {
         super.checkExit(status);
         throw new ExitException(status);
      }
   }

   @Override
   protected void setUp() throws Exception {
      super.setUp();
      System.setSecurityManager(new NoExitSecurityManager());
   }

   @Override
   protected void tearDown() throws Exception {
      System.setSecurityManager(null); 
      super.tearDown();
   }   
}

With that testing support in place, it then became pretty easy to write tests for a main[] method class, not only checking the exit codes, but also redirecting the System.out and System.err output and asserting against it as well. My AppTest test class demonstrates this:

package com.totsp.example;
import java.io.ByteArrayOutputStream;
import java.io.PrintStream;
import junit.framework.Assert;

public class AppTest extends AbstractSecurityTestCase {

   private ByteArrayOutputStream out;
   private ByteArrayOutputStream err;
   private PrintStream stdout;
   private PrintStream stderr;

   public AppTest(String testName) {
      super(testName);
   }

   public void setUp() throws Exception {
      super.setUp();
      this.stdout = System.out;
      this.stderr = System.err;
      this.out = new ByteArrayOutputStream();
      this.err = new ByteArrayOutputStream();      
      System.setOut(new PrintStream(this.out));
      System.setErr(new PrintStream(this.err));
   }

   public void tearDown() throws Exception {
      super.tearDown();
      System.setOut(this.stdout);
      System.setErr(this.stderr);
   }

   public void testOptionH()  {
      try {
         String[] args = new String[] {"-h"};
         new App(args);
         Assert.fail("should have exited with status 0");
      }

      catch (ExitException e) {
         String output = new String(this.out.toByteArray());
         Assert.assertTrue(output.indexOf("usage: TestMainExample [options]") != -1);
         Assert.assertEquals("Exit status", 0, e.status);
      }
   }
   
   public void testOptionV()  {
      try {
         String[] args = new String[] {"-v"};
         new App(args);
         Assert.fail("should have exited with status 0");
      }

      catch (ExitException e) {
         String output = new String(this.out.toByteArray());
         Assert.assertTrue(output.indexOf("Version 1.0") != -1);
         Assert.assertEquals("Exit status", 0, e.status);
      }
   }

   public void testInvalidCommandLine()  {
      try {
         String[] args = new String[] {"some", "crap", "with", "no", "e", "option"};
         new App(args);
         Assert.fail("should have exited with status 2");
      }

      catch (ExitException e) {         
         Assert.assertEquals("Exit status", 2, e.status);
      }
   }

   public void testProcessE()  {
      try {
         String[] args = new String[] {"-e", "TESTING"};
         new App(args);
         Assert.fail("should have exited with status 0");
      }

      catch (ExitException e) {
         String output = new String(this.out.toByteArray());
         Assert.assertTrue(output.indexOf("ECHO  . . . TESTING") != -1);
         Assert.assertEquals("Exit status", 0, e.status);
      }
   }
}

So, this was a quick example, but has a few pretty key, and handy, points: you can handle command line options easily with CLI, you can refactor to keep things out of main, and you can test classes that exit the VM with the security manager approach.

This full example is available as a Maven project in SVN here: TestMainExample.

EFF brings out Switzerland tool to test ISPs

charlie.collins — Mon, 04 Aug 2008 11:38:53 +0000

Net neutrality, Switzerland, get it.

Yeah it's clever, but it's also very cool. Switzerland, brought to you by the EFF (really, you are a member by now, you have made a donation, right?) is a tool for testing ISPs to determine what kind of packet shaping is going on, if any.

"locking in a particular standard for searches would have a dangerous, chilling effect"

charlie.collins — Mon, 04 Aug 2008 11:34:01 +0000

Just how far the US government has gone with its overt destruction of civil liberties is astounding. Not only has habeas corpus been thrown out the window, selectively, but communications are wiretapped illegally, people are rendered to other countries to be tortured (torture itself being something we "don't do," while splitting hairs over the definition), due process in general is pissed on, and all the while the government asserts it has the right to conduct its business - in our names - secretly.

In yet another example of the lunatic bullshit, any electronic device can now be seized at the border by the not-so-secret-yet-still-gestapo federal authorities. They can keep a device for any amount of time, and can seize it without any probable cause.
Travelers' Laptops May Be Detained At Border - no suspicion required under DHS policies.

Of course, the reason for this great power given to the authorities is to protect the people - from the ever present terrorist threat. Yet, when Chertoff testifies what does he proclaim to have found on confiscated laptops to justify the program . . . wait for it . . . child pornography. See how the bait and switch works once again, so long as you play the fear card anything goes. Chertoff also said they have discovered "violent jihadist materials," but, he is not allowed to tell you if that led to any substantive information about a real terrorist group or operation - the old if I tell you I have to kill you trick - "national security" prevents the disclosure. See how convenient and self-fulfilling that is.

Hope it's not the same "national security" set of reasons that put Colin Powell at the UN professing about all kinds of evidence for attacking Iraq - which became, exactly as predicted, a giant clusterfuck costing the lives of hundreds of thousands of people and at the same time inflaming the *reasons* for the terrorism problem around the world. Thanks for "protecting" us citizens US goverment, you're doing a heck of a job.

Unlocking Android update

charlie.collins — Fri, 01 Aug 2008 03:45:44 +0000

I have been busting my hump lately, outside of the "day job," to get a few more chapters of Unlocking Android wrapped up. At this point we are entering the final review. If you want to be a reviewer, just ping me, I will send your name to Manning (it's a giant help, and you get some recognition and a free copy of the book, but the pay is lousy [read: zero]).

Also, the book finally made it onto Amazon proper - Unlocking Android. It's pre-release of course, but always good to be there, especially with the gaggle of other Android related books in the same boat (late this year or early next release dates - I believe ours was one of the first projects to start, remains to be seen who will finish first ;)).

I don't know how we will handle the four authors thing in the long run, as 2 authors have done the lion's share of the work (whether we will label the chapters, how much final polishing it will take to make it feel like a book, etc), but all in all we have some good content to be proud of. It's been a challenge to have 4 authors - the mythical author month if you will - but it's getting there.

Lastly, I know I haven't been posting much here lately, about the book or anything else - apologies. I have just been swamped with the book, the travel for work, and real life. Also, I don't know where all the other posters have gone. Hopefully penguin will get more attention when other things calm down - yeah, right.

Ex-Googlers build new search: Cuil

charlie.collins — Tue, 29 Jul 2008 02:13:57 +0000

I still haven't figured out exactly what one of their edicts - "popularity is useful but not always but important" - actually means, like a lot of the other marketese, but Cuil is here.

It has a pleasing look (with a main blank black page, direct contrast to Google while still getting the non-clutter concept), and some handy features like search suggestions in the search box, and an appealing privacy policy that notes that they don't save any user information or even have search logs.

The search results seem a bit strange though. The main thing that I noticed is that the pictures they put with each search are often contradictory to the search topic. They say they take pictures from the relevant pages for the topics, but it looks like ads, and even little RSS logos and so on, often end up as THE picture for a particular result (annoying). I also don't really like the columnar result layout - even though they justify that saying most people process information better that way (I also like more results per page, which a single list layout seems to be better suited for).

Cuil (pronounced "cool"?) is an old Irish word for knowledge, apparently. It's a new twist on search, and it has been founded by a group of ex-Googlers.

(Side note, I am running across a lot of "ex-Googlers" lately, what's the deal with that?)