Skinning Components in Flex 4

Artima.com has posted another article from my book Flex 4 Fun. Check out Skinning Components in Flex 4 for an overview of the awesome new component/skinning architecture in Flex 4.

Flex 4: Get some skin in the game...

Linear Gradients in Flex 4

Artima.com has posted another article from my book Flex 4 Fun. Check out Linear Gradients in Flex 4 for an overview of using linear gradients in the new graphic primitives in Flex 4.

Flex 4 Fun: Amazon Existence Proof

There's a basic philosophical question that is fundamental to so many situations in life:

• If a tree falls in the forest and nobody is there to hear it, does it make a sound?
• If you tell a joke and nobody hears it, is it funny?
• If your children respect you, are they really teenagers?

The equivalent in the book world is:

• If your book isn't sold on Amazon.com, has it really been published?

I'm happy to say that Flex 4 Fun now passes this last existence proof; the book is available for pre-order on Amazon.com. The book is at the printers now, supposedly available in hard-copy in mid-September. At Amazon's discount of 34% off the list price of $36, it seems like a pretty good deal to me.

Notice that the Amazon price of $24.39 is just shy of the $25 you'll need to reach for free shipping. Which is probably just the excuse you were looking for to finally pick up When I Am King....

By the way, if any reader is so inspired, it would be great if you posted a review on Amazon (and elsewhere). I know how I feel about my books, but I'm slightly more subjective than you might be. Besides, I already used up my quota of words in the books themselves. It's time for me to shut up and let someone else talk. Briefly.

Flex 4 Fun: Final Post(PrePrint)

As promised, the eBook of Flex 4 Fun has been updated to the final version of the text, which was uploaded for printing last week. So if you bought the eBook already, a fresh download will give you the final bits.

If you didn't buy the eBook version already, what are you waiting for? Oh, you want the hardcopy version so that you can enjoy its graphical goodness in the way that Gutenberg intended? Well, you'll still have to wait a bit for that. Even now, armies of typesetters are setting up printing presses to make a run at printing the tome. Look for the book in bookstores and online in mid-September.

Fills in Flex 4: It's What's on the Inside that Counts

Artima.com has posted another article from my book Flex 4 Fun. Check out Fills in Flex 4 for an overview of fills for the new graphic primitives in Flex 4.

printf(Flex 4 Fun);

If you listen closely, you can probably hear it; the slight rustling of hundreds of pages, the chuckles of the shop foreman as he reads the section headings and subtle footnote humor, the collective sigh of the machinery as it mass-produces page after page of graphics programming wisdom.

After months of writing, followed by many more months of editing and revising (it's still unbelievable to me, and more than a little depressing, to know how much you can continue working on your own text and still find things to improve), Flex 4 Fun has gone to print. It's a bit like being put out to stud, except that books are self-reproducing and there's little chance that one of the offspring would win the Triple Crown.

If all goes well at the printer, there should be hardcopy available in mid-September, right before the JavaOne conference, and in plenty of time for your holiday programming-book-giving needs. Just imagine what your mother will say when she opens that completely unexpected gift.

For anyone that bought, or is thinking about buying, the online version, the PrePrint will be updated soon with this version of the text. I'll post something here when that happens.

Stroke of Genius: Drawing Lines in Flex 4

Artima.com has posted another article from my book Flex 4 Fun. Check out Stroke of Genius: Drawing Lines in Flex 4 for an overview of the stroke object, used for defining the properties of lines and outlines for the new graphic primitives in Flex 4.

Varargh!

Varargs, a feature of the C language since roughly the late Victorian era, was introduced into the Java language in JDK1.5.

I love varargs. They allow me to declare a function flexibly with the ability to take zero, one, or several parameters. This ability is useful when the user may have an unpredictable number of things to add to some data structure, eliminating the need for them to create some collection to pass the parameters into your function. It makes for a nice API. And I'm all about nice API. (And donuts).

But sometimes varargs don’t work so well. I suppose it’s because I expect too much of them. Like when you meet someone that you really like, so you call them every few minutes or so, then hang around outside their apartment and workplace and friends' houses until they get a restraining order on you. It’s not that they weren’t really cool and worth getting to know, but that your needs weren't necessarily compatible.

I was working recently on some API improvements for a library I'm writing. I had some constructors that users would call with exactly two values of different types, like this:

  public MyObject(int value1, int value2) {}

  public MyObject(float value1, float value2) {}

This worked well, vectoring the code path off in different directions depending on the types of the values that the user passed in.

But sometimes, the users might have just one value to pass in. Or three. Or nineteen. Rather than having variations for all of these situations, multiplied by the number of types that I wanted to support, I wanted something simpler that took variable numbers of parameters.

So I rewrote my API with varargs. It looked something like this:

  public MyObject(int... values) {}

  public MyObject(float... values) {}

This new version was awesome. Now the user could call my functions with the appropriate values and it would do the right thing, no matter what the types were or how many values they passed in. I compiled the code for the library, wrote my test code:

MyObject obj1 = new MyObject(1f);
MyObject obj2 = new MyObject(1);

and

FAIL

I got a compiler error. Specifically, Eclipse gave me the following completely unhelpful message for the test code: “The constructor MyObject(float[]) is ambiguous” for the second line of that test code (MyObject obj2 = new MyObject(1)).

Never mind the fact that the error was telling me that the constructor takes an array instead of varargs; I know that varargs is syntactic sugar for a construct that gets turned into an array. The real problem was that my code wouldn’t compile.

Apparently, varargs cannot handle the method overloading situation and make the correct type inference and just fails to compile. Although the compiler can make a good decision about the correctness of a constructor with float vs. int, it can’t make that decision for float[] vs int[]. So it bails.

Meanwhile, I discovered another nuance of using varags; you can’t pass them around between constructors willy-nilly. One of the things I wanted to do in my rewrite was to record the type that the user wanted to use and send it to a private constructor like this:

private MyObject(Class valueType, Object... values) {}

Meanwhile, I wrote a single type-specific constructor (to avoid the previous compiler error for now) that called this more generic constructor:

public MyObject(float... values) {
 this(float.class, values);
}

Again, my code compiled fine. And when I eliminated one of the float/int varargs combinations, I was able to write a test that successfully called my varargs constructor:

MyObject blah = new MyObject(1f, 2f, 3f);

This code called the private Object-based constructor above. But then I encountered bugs at runtime where the number of values was not what I was expected. In particular, the number of values being stored by the private constructor was 1, not 3.

But, but, but, ...

It turns out that the call to the private constructor turned a perfectly fine threesome of parameters of type float into a single parameter of type float[]. That is, my varargs had just turned into the array that it was pretending it wasn't when I first wrote the code.

At this point in an article, the climax as it were, I would typically say, “And here’s how you work around these issues.” I would love to do that, because I like neat tricks and workarounds. And I’d love to actually have that workaround in my code.

Unfortunately, I have no such workaround. I frankly don’t know how to make this work in any reasonable way. You can be more clear with the compiler, by telling it things like new MyObject(new float[](1f, 2f, 3f}) to get around the compiler error. And maybe you even like the way that that looks for an API. If you are sadistic. Or hallucinating. You could also find a different way to store the individual parameters in the varargs rather than having the VM think that it’s just a single array item. But at this point, my original attempt at a more attractive API and flexible implementation was looking like a bad prototype or an industrial accident.

So I did the only thing that any responsible captain would do after his vessel had hit an iceberg and was going down with all hands: abandon ship on the first lifeboat.

For my situation, I could limit the flexibility to just one or two parameters for the main case, and then have a completely different constructor with a custom data structure for the more flexible, and less common, case of having several parameters. So I walked away from varargs completely for my code with nary a look back. The second problem of calling the private constructor with varags then magically disappeared because I no longer had to pass the varargs around.

For other situations that may benefit from varags, but may run afoul of method overloading, I can only recommend that you know and understand the limitations of the nifty varargs feature. I searched around on the web for answers to my compiler problem and didn’t find anything immediately, so I thought it might be worth noting for posterity. Or at least for the pleasure of venting.

Varargs: great when they work. But when then don’t? Nobody knows. Maybe that's why the syntax uses ellipses. It's like a little language joke that says, "Sure, use varargs, Let's see what happens..."