Welcome to the first installment of the JavaRanch Journal edition of the SCJP Tip Line, etc. This column was inspired by my blog. This month, our topic of choice is bit shifting.

In my experience, a lot of people are just too "frightened" of bit shifting to spend any time studying the operations. With just a little study, questions on bit shifting quickly become "gimme" questions on the SCJP exam, rather than the impossible questions that people make them out to be. Let's take a quick look into bit shifting.

First off, let's consider the bare basics. Every primitive data type in Java is made of a set number of bytes. For example, a byte is, oddly enough, one byte, a short is two bytes, and an int is 4 bytes. Of course, a byte is equivalent to 8 bits, so a byte is 8 bits long, a short is 16 bits long, and an int is 32 bits long.

Now, let's start thinking about shifting bits. What is bit shifting? Well, it's exactly what it sounds like; we're going to slide the bits left or right a certain number of positions. Basically, we're going to "shift" them down the line. Let's start with this simple line of code:

byte b = 13;

00001101

When it comes to bit shifting, we have a few options. Obviously, we can shift the bits either to the left or to the right. I like to think of the bits as if they're sitting on a table that's just big enough to hold them. For a byte, you'd have a table able to hold 8 bits while an int would sit on a larger table that is able to hold 32 bits. When we shift to the left or to the right, the number on the far end "falls off" the table, never to be heard from again. As a quick example, let's shift our variable, b, to the right one position.

b = (byte)(b >> 1);

00001101 becomes 00000110 (which is 6 in decimal)

Notice that the right-most bit, which was a 1, has "fallen off" the table. It's gone forever. Of course, a byte contains 8 bits so, now that we've pushed one off the right side, we need to fill something in on the left. The right shift operator that I used will insert the same value as the sign bit on the left side. In Java, remember that the left-most bit is known as the "sign bit." If that bit is a 0, the number is positive and, if it is a 1, the number is negative. So, if the original value was negative, we'd shift in a 1 and, if it was positive, as was the case here, we'd shift in a 0. This operator is known as the "signed right shift" operator. Of course, we can shift by more than 1 position at a time, like this:

b = (byte)(b >> 3);

00001101 becomes 00000001 (which is 1 in decimal)

You might notice that a right shift is basically an integer division by a power of 2. Shifting right 1 position is the same as dividing by two, shifting right 3 positions is the same as diving by 2^3, or 8.

Also, notice the casting that I'm doing. When you perform a shift operation, both operands, the value to be shifted and the amount to shift it by, must be an int or a long. If they aren't, they are promoted (if they can be ? if not, you end up with a compiler error). The result of the operation is the type of the left hand operand, which will be an int or a long. As neither of those types are assignable to a byte, I must cast it as a byte or the compiler will complain.

That's really all there is to bit shifting. Now, we should probably look at the other bit shifting operations. We've already looked at the signed right shift operator (>>), but there are two more operations: the left shift operator (<<) and the unsigned right shift operator (>>>).

The left shift operator is identical to the right shift operator that we discussed previously except that it will shift the value to the left instead of to the right. For example:

b = (byte)(b << 2);

00001101 becomes 00110100 (which is 52 in decimal)

Again, notice that shifting to the left is just like multiplying by a power of two (whereas a right shift was a division by a power of two). In this case, we shifted left two positions, which is the same as multiplying by 2^2, or 4. Obviously 13 * 4 is 52, which is the same result we get from our bit shift operation. A left shift operation always inserts 0's to the right hand side.

Keep in mind, though, that a left shift can result in "overflow." Overflow occurs when we go beyond the limits of the range of the data type we're using. For a byte, our maximum value is 127. So what happens if we take 127 and shift it to the left? Well, let's look at that:

127 in binary is 01111111

Shifted left one position, it becomes 11111110.

Notice that, by shifting 127 to the left, we have turned a positive number into a negative number. Our result is ?2. That result, -2, is certainly not equal to 127 * 2, which should be 254. The value 254, of course, doesn't fall within the range of a byte ? this is overflow. When left shifting, you need to be aware of overflow.

The final shift operator, the unsigned right shift operator, is a right shift that behaves just like the left shift. This operator will always fill in zeros when shifting to the right. So, if we were to take a negative number, such as ?32 (which is 11100000 in binary) and shift it to the right using our normal signed operator, we'd see this:

byte b = -32;
b = (byte)(b >> 1);

11100000 becomes 11110000 (which is -16 in decimal)

Notice that, by right shifting a negative number, we push a one into the sign bit and the number remains negative. However, we now have this second option for shifting to the right, the unsigned right shift. The unsigned right shift operator ignores the sign bit and blindly pushes a zero into the left-most position. Let's do a couple quick examples with an unsigned right shift.

int i1 = -32;
int i2 = 13;

i1 = i1 >>> 1;
i2 = i2 >>> 2;

i1, which was 11111111 11111111 11111111 11100000,
becomes 01111111 11111111 11111111 11110000 (which is 134217727 in
decimal)

i2, which was 00000000 00000000 00000000 00001101,
becomes 00000000 00000000 00000000 00000011 (which is 3 in decimal)

That's really all there is to bit shifting. It's much simpler than many people make it out to be. However, before I wrap this article up, let's throw a wrench into things. The right hand operand of a shift operator must be an int. Well, in Java, ints are "signed" variables (they can be positive or negative), so this is a legal line of code:

byte b = 13;
b = (byte)(b >> -6);

So now the question is, what does that do? Does it shift left instead of right? Does it give an error? Actually, it does neither. When performing a shift, only a portion of the right hand operand is used. If you're shifting an int, you'll use only the right-most 5 bits of the shift value. That means that the amount you shift by will always fall within the range of 0 and 31. If you're shifting a long, you'll use only the right-most 6 bits of the shift value. In that case, your shift distance falls within 0 and 63. Let's see how that works with our last example:

-6 in binary is 11111010

We're shifting an int (remember that anything smaller than an int is promoted to an int) so we use only the right-most 5 bits of that value. Therefore, we're shifting by 26 (11010 in binary is 26 in decimal). So, our previous line equates to this:

b = (byte)(b >> 26);

Of course, if we shift 13 to the right by 26 positions, we've managed to push all of the real data off the table and replaced it with zeros. So, in the end, we have b equal to 0.

Hopefully you've learned a few intricacies about bit shifting that you might not have known before. Be sure to check my blog, the SCJP Tip Line, for more similar tips and look for more articles like this in future editions of the JavaRanch Journal.

If you'd like to consult the Java Language Specification regarding bit shifting, check out ?15.19 Shift Operators.

Discuss this article in The Big Moose Saloon!


Return to Top

BeanUtils, Digester, and Type Conversion

by Jason Menard

The following assumes some level of existing knowledge with the Commons BeanUtils and Commons Digester packages. See Resources for further information.

Brett Bell asked on JavaRanch recently if Digester can convert a String held in an XML attribute to a java.util.Date or int. This brings up a little understood (and poorly documented, IMHO) topic relating to the Commons Digester and BeanUtils packages - that of type conversion.

The first thing to realize is that Digester does not handle the type conversions itself. Digester makes heavy use of the BeanUtils package to work its magic, and this includes using that package for type conversions. So in order to answer Brett's questions, we need to take a closer look at a class in BeanUtils called ConvertUtils.

It is the ConvertUtils class that handles type conversion for BeanUtils. This class's convert() methods allow conversions from Strings to Objects of a given class, from Objects of a given class to Strings, and from a String[] of values to an Object[] of a given class. In order to do this, ConvertUtils must have registered with it an implementation of the Converter interface for each type of conversion it wishes to perform.

The default configuration for ConvertUtils will handle conversions of the following primitives and classes: java.lang.BigDecimal, java.lang.BigInteger, boolean and java.lang.Boolean, byte and java.lang.Byte, char and java.lang.Character, java.lang.Class, double and java.lang.Double, float and java.lang.Float, int and java.lang.Integer, long and java.lang.Long, short and java.lang.Short, java.lang.String, java.sql.Date, java.sql.Time, and java.sql.Timestamp. You can add custom converters to handle anything not covered by the default configuration merely by registering your own implementation of the Converter interface using the ConvertUtils.register() method.

Let's look at some code. Assume we have the following XML document, "testdoc.xml", which we wish to map to an instance of a Thing class.

<thing>
  <number>3</number>
  <date>06/07/04</date>
  <point>3,5</point>
</thing>

Here is our Thing class.

package commonstests;

import java.awt.Point;
import java.util.*;
import java.text.*;

public class Thing {
    private int number;
    private Date date;
    private Point point;

    public Thing() {
    }

    public Date getDate() {
        return date;
    }

    public void setDate(Date date) {
        this.date = date;
    }

    public int getNumber() {
        return number;
    }

    public void setNumber(int number) {
        this.number = number;
    }
    
    public Point getPoint() {
        return point;
    }
    
    public void setPoint(Point point) {
        this.point = point;
    }
    
    public String toString() {
        String dateString = null;
        if (date != null) {
            dateString = DateFormat.getDateInstance().format(date);
        }
        StringBuffer sb = new StringBuffer();
        sb.append("[Thing number=");
        sb.append(number);
        sb.append(" date=");
        sb.append(dateString);
        sb.append(" point=");
        if (point != null) {
            sb.append(point.toString());
        } else {
            sb.append("null");
        }
        sb.append("]");
        return sb.toString();
    }
}

Looking at the XML and the Thing class we can see that we want to map the XML String data to an int, a java.util.Date, and a java.awt.Point. Assuming an instance of Thing is at the root of our digester stack, we would use the following processing rules.

digester.addBeanPropertySetter("thing/number");
digester.addBeanPropertySetter("thing/date");
digester.addBeanPropertySetter("thing/point");

Knowing that Digester uses BeanUtils to handle the type conversion, and knowing that an int is handled by the default configuration of ConvertUtils, we should have no problem processing the <number> element. Unfortunately, things will come to a screeching hault as soon as Digester tries to process the <date> element. You might think that this would be a good time to implement a custom Converter. Luckily, we don't actually have to.

The BeanUtils package comes with a number of concrete Converter implementations for use with locale-sensitive classes, such as java.util.Date. These locale-sensitive converters may be found in the org.apache.commons.beanutils.locale.converters package. Included in this package is DateLocaleConverter, which will handle conversion for java.util.Date. We can just go ahead and use this Converter instead of implementing our own.

At this point I should quickly mention that the org.apache.commons.beanutils.locale package contains locale-sensitive LocaleBeanUtils and LocaleConvertUtils classes which you can use in place of BeanUtils and ConvertUtils respectively, if you are doing a lot of locale-dependant population of your Java Beans. Digester does not use these however so it's nothing we need to worry about right now.

In order to configure a DateLocaleConverter for our needs, we need to provide it with a Locale and a pattern for our date format. DateLocaleConverter uses an instance of java.text.SimpleDateFormat to handle the formatting, so a quick look at the API for that class will allow us to come up with a suitable pattern for our date. Once we configure an instance of DateLocaleConverter then we must simply register it with ConvertUtils, also supplying the class type we wish ConvertUtils to use this Converter for, which is of course java.util.Date in this case. We'll also set our instance of DateLocaleConverter to be lenient in its parsing, by using the setLenient() method.

String pattern = "MM/dd/yy";
Locale locale = Locale.getDefault();
DateLocaleConverter converter = new DateLocaleConverter(locale, pattern);
converter.setLenient(true);
ConvertUtils.register(converter, java.util.Date.class);

Now if we use Digester to process our XML it will have no problem handling the date conversion. Unfortunately, this time it will error out when it tries to process the <point> element. We need to write a custom implementation of Converter to handle java.awt.Point.

Writing an implementation of Converter really isn't all that involved, and the only method we need to provide is convert(java.lang.Class type, java.lang.Object value). This method throws a ConversionException if a problem is encountered during a Conversion. One thing to keep in mind when writing your converter is what should happen when an empty element exists in your XML, such as <point/>. Should it populate your Object with null or should it use some default value? With that in mind, it's not a bad idea to allow your converter the option of providing a default value. Here's a converter that will handle java.awt.Point.

package commonstests;

import java.awt.Point;
import org.apache.commons.beanutils.Converter;
import org.apache.commons.beanutils.ConversionException;

public final class PointConverter implements Converter {
    private Object defaultValue = null;
    private boolean useDefault = true;

    public PointConverter() {
        this.defaultValue = null;
        this.useDefault = false;
    }

    public PointConverter(Object defaultValue) {
        this.defaultValue = defaultValue;
        this.useDefault = true;
    }

    public Object convert(Class type, Object value) throws Conversion Exception {
        if (value == null) {
            if (useDefault) {
                return (defaultValue);
            } else {
                throw new ConversionException("No value specified");
            }
        }

        if (value instanceof Point) {
            return (value);
        }

        Point point = null;
        if (value instanceof String) {
            try {
                point = parsePoint((String)value);
            }
            catch (Exception e) {
                if (useDefault) {
                    return (defaultValue);
                } else {
                    throw new ConversionException(e);
                }
            }
        } else {
            throw new ConversionException("Input value not of correct type");
        }

        return point;
    }

    private Point parsePoint(String s) throws ConversionException {
        if (s == null) {
            throw new ConversionException("No value specified");
        }
        if (s.length() < 1) {
            return null;
        }
        String noSpaces = s;
        if (s.indexOf(' ') > -1) {
            noSpaces = s.replaceAll(" ", "");
        }
        String[] coords = noSpaces.split(",");
        if (coords.length != 2) {
            throw new ConversionException("Value not in proper format: x,y");
        }
        int x = 0;
        int y = 0;
        try {
            x = Integer.parseInt(coords[0]);
            y = Integer.parseInt(coords[1]);
        } catch (NumberFormatException ex) {
            throw new ConversionException("Value not in proper format: x,y");
        }
        Point point = new Point(x, y);
        return point;
    }
}

There's not really all that much to it. Of course, we also have to remember to register our PointConverter with ConvertUtils.

ConvertUtils.register(new PointConverter(), java.awt.Point.class);

Now we should have no problem with Digester performing the proper mappings. Here's a driver you may run which demonstrates this.

package commonstests;

import java.io.*;
import java.util.*;
import org.apache.commons.beanutils.ConvertUtils;
import org.apache.commons.beanutils.locale.converters.DateLocaleConverter;
import org.apache.commons.digester.*;

public class TestDigester {
    private Digester digester;

    public TestDigester() {
    }

    public void run() {
        configureConverter();
        digester = new Digester();
        Thing thing = null;
        File file = new File("testdoc.xml");
        digester.setValidating(false);
        digester.push(new Thing());
        addRules();
        try {
            thing = (Thing)digester.parse(file);
        } catch (Exception e) {
            e.printStackTrace();
        }
        System.out.println(thing);
    }

    private void addRules() {
        digester.addBeanPropertySetter("thing/number");
        digester.addBeanPropertySetter("thing/date");
        digester.addBeanPropertySetter("thing/point");
    }

    private void configureConverter() {
        String pattern = "MM/dd/yy";
        Locale locale = Locale.getDefault();
        DateLocaleConverter converter = new DateLocaleConverter(locale, pattern);
        converter.setLenient(true);
        ConvertUtils.register(converter, java.util.Date.class);
        ConvertUtils.register(new PointConverter(), java.awt.Point.class);
    }

    public static void main(String[] args) {
        TestDigester td = new TestDigester();
        td.run();
    }
}

Happy converting!

Resources

• Jakarta Commons BeanUtils
• Jakarta Commons Digester
• Touring the Commons - part 1: BeanUtils
• Touring the Commons - part 2: Digester
• Touring the Commons - part 3: Dynamic DTOs

Discuss this article in The Big Moose Saloon!


Return to Top

The Coffee House

Grounds for Change

by Solveig Haugland

Discuss this article in The Big Moose Saloon!


Return to Top

Meet the Author

Harshad Oak, author of Pro Jakarta Commons

by Jason Menard, Thomas Paul, and Mapraputa Is

This month we introduce a new column for the JavaRanch Journal, the "Meet the Author" column, which will include interviews with authors of Java related books. For our first interview, we spoke with Harshad Oak, the author of several books, including Pro Jakarta Commons.

JavaRanch: You just had two books published by Apress within the span of only a few months: "Oracle JDeveloper 10g: Empowering J2EE Development" and "Pro Jakarta Commons". That's pretty impressive. Writing one book is challenging enough, but how did you manage the challenges of writing two books at the same time?

Harshad: Thanks. It wasn't meant to be this way. The Commons book was expected around this time but JDev was supposed to come out earlier. We began with JDeveloper 9i but the announcement of JDev 10g meant that we had to rethink the book and I had to put in a lot of time with the new version. Early 2004 was crazy yet fun as I tried to meet deadlines for both books.

JavaRanch: You previously co-authored "Java 2 Enterprise Edition 1.4 Bible", published by Wiley. Were there any eye-opening experiences writing that one that really prepared you for your next two?

Harshad: Oh yes! I have been writing articles for a long time but writing books is just so different. There are 'n' number of reviews. You need to use templates, follow guidelines, stick to certain rules...Although I was already working on the JDeveloper book back then, the J2EE 1.4 Bible experience certainly taught me a lot about writing technology books.

JavaRanch: Tell us about your relationship with Apress. Were there any major differences between your experience with Apress and Wiley?

Harshad: My experience with both publishers has been very good. I worked with Wiley for a relatively short time but I have been talking to folks at Apress for over a year now. All the people I have been interacting with have been down to earth and polite (very important). Also most of them have written books in the past and so can empathize with an author.

JavaRanch: What has Apress done to promote your books?

Harshad: I suppose budgets these days are very tight and so Apress' role has primarily been that of making the book available across stores and countries. Apress also has been sending out free copies for review to magazines and other opinion influencers.

JavaRanch: Many authors admit that they can get rather obsessive about how their books are doing on Amazon. They will watch their Amazon sales rankings like they do their stock portfolio, and religiously check for new user reviews. How about yourself? Can you identify with this or do manage to remain unphased by the whole Amazon thing?

Harshad: I do keep track of how my book is doing on Amazon. I think the real reason behind Amazon addiction is that book sales figures aren't very transparent to the authors and most authors unfortunately have to look at Amazon to get an idea of how their book is faring. All publishers really need to address this problem.

JavaRanch: "Pro Jakarta Commons" is an interesting albeit uncommon topic to write a book on. What prompted you to approach this subject?

Harshad: Take up any popular Java/J2EE software like Tomcat, Struts and Hibernate and it is very likely that the software is internally making use of some Commons component. I was surprised to see that although Commons is very useful and used quite widely, there was no book on the subject. Also as the docs for some of the components aren't that great, it made even more sense to write a book about the project and fill the docs void.

Jakarta Commons was one of the book ideas I had send to John Zukowski who was back then the Java editor at Apress. Surprisingly, he himself was considering writing a book on Commons but he graciously let me take the idea further. John took up the task of being the technical reviewer of the book and I wrote the book.

JavaRanch: What do you think the value of the Jakarta Commons project is to the software community?

Harshad: Jakarta Commons is awesome. So often it happens that we see the Java community raving about some concept or software but we finally think that "Nah! this isn't for me!". Guess what! Jakarta Commons is something that is useful for every Java developer. It is a collection of some simple yet very powerful components. I like to call it the Swiss knife without which you better not enter the Java jungle.

JavaRanch: Is there any particular component or combination of components in the Jakarta Commons project that you find most useful?

Harshad: I like and use a lot of the Commons component but l guess I am most fond of Digester and Validator. I hate having to parse XML without the Digester and Validator has in a way revolutionized field validations on all projects that I develop as part of Rightrix Solutions. The HttpClient and Lang components also can be very useful.

JavaRanch: After these latest two books, are there any others on the horizon?

Harshad: There are a couple of ideas being discussed but things are rather vague at the moment. No Harshad Oak book at least in the next few months. :)

JavaRanch: From your bio, we see that you are a Sun Certified Java Programmer and a Sun Certified Web Component Developer. What do you feel is the place of the Sun Java certifications in our industry?

Harshad: I owe a lot of what I know about Java to my certifications. If it was not for those, I am quite certain I would not have taken the pains to study the intricacies of the language. I occasionally teach some Java and J2EE and I always make it a point to encourage my students to take up certification. I would also like to thank Javaranch for the great cert content it has. Although I did not contribute regularly, I read and learned a lot from the Javaranch forums.

JavaRanch: Is there anything else you'd like to tell us about yourself, or are there any final bits of wisdom you'd like to leave our readers with?

Harshad: Wisdom...Now that's a tough one! I would just say that any software developer today needs to stay open to new ideas and also make a conscious effort to work smart and not work hard. This might seem clich?d but I honestly think that software developers do a lot of unnecessary hard work. For example, many developers will never invest time in learning to use a powerful tool like JDeveloper but instead will keep working with basic editors and manually do a lot of things that the IDE could have easily done for them. Why parse XML using SAX instead of using a component like Digester, why write string manipulation code when the StringUtils class in the Lang component can do a million things with strings....

I will be presenting about JDeveloper at the ODTUG meet in June and hopefully will also be around at JavaOne this year. I am looking at other speaking engagements as well and so if the readers happen to be at a meet where I am, I would be more than happy to meet up. Also please send any feedback about my books to harshad@rightrix.com

Discuss this interview in The Big Moose Saloon!


Return to Top

The tag-team and married authors, Kathy Sierra and Bert Bates, are the creators of the popular "Head First" book series, published by O'Reilly. We managed to pin down the busy duo, and even convinced them to answer a few questions. On June 30th, in San Francisco, both Kathy and Bert will be on hand for further questioning at ExitCertified's Meet the Authors Event.

JavaRanch: Kathy, you founded JavaRanch.com. Why? What were you hoping to do with it? Today, are we anything close to your initial intent?

Kathy: What Paul Wheaton has done with JavaRanch.com has dramatically exceeded anything I could have imagined. Also, it couldn't have gone in this direction without so many hard-working volunteers, and Paul's really good at getting people involved and somehow working together as a kind of team, despite some pretty dramatic differences among the bartenders and sherrifs. To me, what he's done with it is like magic.

I founded it for one reason only--the one that's still on the main page, to be "A friendly place for Java greenhorns". When I started learning Java in early 1997, it was so awful out there. You were lucky to find three books on Java at your local bookstore, and the only forums were the newsgroups like comp.lang.java. And they were BRUTAL. Just about *any* question you asked, you felt like you were asking a dumb question, and most of the responses were either harsh, flaming you for being so stupid, or just so cryptic that it didn't really help. Interestingly, the two people I remember most from those days, who were actually helpful and *nice*, are still around, and on javaranch! Bill Brogden and Marcus Greene.

So, I wanted to make it a fun, friendly place where people could learn without feeling stupid. The one thing I never did that I meant to, was to add a lot more campfire stories. But the forums are so much more helpful than anything I could have put up there.

JavaRanch: Could you describe for us the 30,000 feet above overview of just what "Head First" is all about? What is the goal of "Head First"?

Bert: My goal with a Head First book is to write the book that I wish I'd had when I was first learning a topic. More specifically, I hope that when a reader has finished a HF book she has gained a solid foundation in the topic. A foundation from which she has enough tools in her toolkit to be creative and discover what she needs to discover. A HF book is NOT a reference book. HF books will probably be about topics that can't be fully explored in one book, topics like Java. For instance, when a programmer new to Java finishes HF Java, she should be ready to go tackle whatever advanced Java books she needs to tackle... Swing, J2EE, patterns, etc.

Kathy: My main motivation was to take everything we could draw on from learning theory, to cognitive science, to game design, to neurobiology, to advertising and marketing, and create a brain-friendly approach to learning. Then the challenge was how to represent that in a printed book. The goal was to give people a way to *get it* much more quickly. The goal was NOT to entertain them at the same time... it just turned out that the *fun* part is a huge contributor to why it works the way it works. If people actually learned more quickly when subjected to verbal humiliation, we would have found a way to do THAT ;)

I guess the overarching goal is to make people smarter, and to make sure that they FEEL smarter.

Too many books make you feel slow and stupid. It's nearly always the fault of the book, not the learner. But a lot of tech books seem written by people who are concerned that the readers think the *author* is smart. We have no illusions about that ;) , so our goal is make sure that the reader realizes that HE is smart. Who cares what he thinks about us? It's not *about* us. It's about *the readers*. They are who we care about--we hear from people all the time, and it really makes it personal for us. We are not writing for some abstract concept of "readers". We are writing for the real PEOPLE, people like Jeff Cumps,Praveen Kumar, York Davis, Jim Steiner, Adeeb Jarrar, just to name a few of the people who've written to tell us about their experiences with the book. We picture *real* people when we write, and we write for *them*.

We believe that most *traditional* learning works against the way the brain functions. Some of it, no, MOST traditional learning (either classroom or textbook), is the way it is simply because that's the way it's been done for a loooong time. Some of it is because *we* (learning professionals, teachers, authors, etc.) didn't *know* any better--a lot of brain research is still very very new. And some of it is because it's just easier on the teacher to, say, line students up in rows and make them sit and listen for an hour. (Easier for the teachers and the administration, certainly not the learners). I always thought it was interesting that what we do to learners in a classroom, is very close to the way in which children are often punished--we make them SIT in one place and be quiet. And certainly, it's easier to *write* a text book than to *build a learning experience*. It took us twice as long to write the Head First Java book as it did to do the text-based Java 2 certification book.

JavaRanch: How long have you been working on developing "Head First" teaching concepts?

Bert: Kathy's answer is very different than mine. I've been teaching various computer topics, in enemy territory, for maybe 25 years. To avoid being eaten alive I learned a lot of teaching techniques ad hoc; by talking to other teachers, by experimenting, etc. Kathy had taken a more formal approach, and when we got to talking about what she'd discovered, I learned a lot of stuff I wished I'd known, and I also confirmed a lot of stuff I'd learned by the seat of my pants.

Kathy: about 15 years. I started in the late 80's writing what we called then "Intelligent Tutoring Systems", basically CBT with some artificial intelligence (it was still cool to talk about AI in those days) thrown in to make the learning adapt to the learner. I believe that the majority of the important research in learning theory was (and still IS) driven by the work to make computerized learning products (*good ones*, I'm not talking about the 95% of web-based training that's out there). SO much cool research on this has come out of places like PARC, for example... but you have to haunt obscure conference proceedings to find some of it. The idea was, "We want to represent what a really good tutor does, or how learning really happens, but in a computer. So we have to analyze how learning *really* happens." And these folks anaylzed learning in a way that traditional education never did. And they found some very surprising things...

But then I went to work as a game developer for many years, and that led me to design and teach courses at UCLA's IBM New Media Lab, on how to combine the domains of learning, game design, and advertising to create interactive experiences. That's where most of this stuff ultimately came from. But it was interesting that Bert, who *also* came from an artificial intelligence background, had reached most of these same conclusions on his own, based on his experience both as a knowledge engineer and a teacher. So he was doing all the right things, he just didn't know or have all of the research and formal support to explain what he was doing.

Some of what we do is just common sense and obvious, but some is counter-intuitive, and a LOT of pepole were against Head First at the beginning. It caused a little rift inside O'Reilly even, because some editors just couldn't imagine that anyone would ever like this, let alone buy it. :) But Head First Java came out as THE number one best-selling Java book in the US, and it has remained that way for very nearly a year. It isn't the top-selling Java book on Amazon (that spot goes to our *other* book ;) ), but Head First Java is the top seller when both Amazon and bricks and mortar stores are combined. Then everyone said it would never work with a more advanced topic, so we took that as a challenge to do the EJB book...

JavaRanch: Where can folks learn more about "Head First"?

Kathy: They can learn some things from the O'Reilly site, and some things from our book site at wickedlysmart.com.

There's not much up there now, just emergency info and a few downloads--but our plan for the summer is to *really* build out that site, putting up a LOT of content on learning theory, especially. It won't be the place to come for Java info (because that place is HERE); but we do want it to be a site about learning, and books, and training, and fun. Oh yeah, before I forget--the point of wickedlysmart is not that *we* are smart--it's that we help craft learning materials that make YOU wickedlysmart.

JavaRanch: What books have you written so far using these "Head First" techniques?

Bert: HF Java, HF EJB, and we're 95% done with HF Servlets and JSP. (It will be out in early July.) Several books are in progress, with the help of incredibly talented co-authors who are taking the lead; Patterns, Movie making using Final Cut, Flash. And we're deciding what to take on next as lead authors. We'll probably update HF Java for Tiger.

Kathy: No, we're DEFINITELY doing HFJava for Tiger! :) There will be a lot more HF books coming up on different aspects of software development, including as Bert said, Design Patterns (that will be the next one to come out), and also UML.

JavaRanch: You two work together, and you're married! Any secrets?

Bert: Kathy does all the final edits :D

Kathy: Bert lets me do all the final edits.

Then there's the sex thing... ;) We always say that to really work well with your co-author, you need to be sleeping together.

JavaRanch: Any advice for aspiring technical authors? Have you suffered any experiences you'd like to educate others about? What were they?

Bert: I'd say focus. There are lots of directions a technical book can go; reference material, teaching, cookbook style, almanac style... Pick one style for your book and stick with it. And don't think you can do everything at once! We certainly had a few lucky breaks, but one thing we did was to really, really, polish the samples we sent to publishers. We didn't write the whole book first, we created the absolutely best sample we could and sent that out. We also followed the publisher's instructions as closely as we could. We did everything we could to make it easy on the publisher. The other thing is to really understand everything about your proposed book contract. There a some subtle concepts to look out for in book contracts.

Kathy: Anyone who seriously wants to do a book can probably get a book contract. You can't be in it for the money, but that doesn't mean you *won't* make money from the book. It's true that this is a really *dark* time for book sales and especially tech books, but there's still a lot going on. The important thing is to find a topic that you're *passionate* about! That matters a lot. You have to consider a lot of factors, especially the marketplace. You can't, for example, think- "I have this cool idea for a book" and take that to a publisher unless you have thought through who (and how big) the target audience is. Also, what can your book do that makes it significantly better than the others? (And unless it's a brand new and very hot topic, it should be SIGNIFICANTLY better, or at least different, in a way that will be obvious to prospective buyers.) Why should someone choose yours over so many others? These are the key questions a publisher wants to know -- and wants to know that YOU know.

But if you have some ideas and you have a compelling desire to communicate this to other people, through a book, then you should go for it! There is NO reason not to put together a proposal. But I think it's a *really* bad idea to write a book in advance, and *then* try to get a publisher. That's how you get your first novel out, but that is NOT how it works with computer books. You might get lucky, but your best bet is to just start with a good proposal, that includes a couple of sample chapters. There's a lot of good info on the O'Reilly site about how to submit a proposal. We followed it *exactly*.

The publisher wants to influence the direction of the book and most of the time, they know best. Plus, the publisher may have a specific series format in mind for the topic you propose, and if you've already written it, you can count on a HUGE rewrite. I see no advantage to writing a book in advance, and lots of disadvantages. If you work from a proposal, then you can collect advance money *while* you're working on it, rather than waiting until it's complete.

There are some serious gotchas on book contracts, so you need either an agent (we don't have one), or an attorney, or a very experienced author look over the contract and help you figure out what you can negotiate on. Do NOT sign the first thing they hand you (although if it's O'Reilly, you're probably safe). These contract issues can haunt you for a very long time, so you should be very careful. Also, I would ask about (and make a big deal about) how the publisher plans to market your book. You might write a great book, that *could* sell, but doesn't see the light of day because the publisher doesn't push it.

JavaRanch: How long have each of you been writing technical training materials?

Bert: Ad hoc, for a long time, we've been writing official books for a little over two years now.

Kathy: I wrote computer-based training courses for several years, then I wrote courseware for my own courses at UCLA, then I also worked for a while as a Sun course developer, working on Java courses. That was my toughest job, though, because their guidelines are SO strict, and *they* (the folks in charge at the time) did NOT consider it appropriate to include anything that might be seen as *fun* :) I was always in trouble for trying to sneak stuff in. I think I got *written up* in my performance eval for using the word "cool" in a document, after being told not to ;)

JavaRanch: What are your favorite subjects to write about? Why?

Bert: Any technology that's interesting and challenging, and that we believe in. For instance I'll never write about .net. We've talked about topics like calculus, physics...

Kathy: What Bert said... it has to be something we can be passionate about, and it has to be technically difficult. Tim O'Reilly believes that a Head First book should be on topics that have a pretty high pain factor. If the topic is easy, then you don't really NEED all of these learning techniques, anyway. We have at least twenty books on our list right now! We are always looking for ways to speed up our own process, and also for other co-authors and subject-matter experts who can help us do more Head First books. Right now, Bert and I are the bottlenecks.

JavaRanch: Have you noticed any other folks in the industry that are doing great, interesting or new things in the realm of adult (or child) technical educating that might be worth paying attention to? In brief, what are they doing and what interests you about it?

Bert: Kathy can give you a whole list of authors we continue to learn from. Richard Wurman, Donald Norman, and David Gelernter come to mind. We are both really interested in 'metacognition', or thinking about thinking. So my 'meta' goal is creating learning materials that pay attention to how human brains (of every age), really work.

Kathy: Roger Schank! He's really out there doing all the right stuff. We're trying to be a really poor man's version of what Roger Schank does--his stuff has pretty huge development budgets. I've been following his AI work and books for many years, and was so thrilled to see him come into the learning world so strongly. Some of the good work has been around a long time, Maria Montessori was way ahead of the curve in a lot of areas. There are some very good and interesting things under the banner of "accelerated learning", although we don't subscribe to *all* of it. Multiple Intelligences. My favorite books are by Roger Schank, Don Norman, and also "Flow: The Psychology of Optimal Experience". We pay attention to what some of the top game designers have to say. Chris Crawford.

We also pay attention to what storytellers have to say... people who write novels, screenplays, etc. have a lot to teach us about getting and keeping someone's attention, and because storytelling has been the number one method of learning for thousands of years. Natural selection favored those who could learn well from stories, so I believe that's a hugely underestimated approach to teaching. Joseph Campbell has something to say. Steven King probably has much more to say about keeping people engaged than most teachers.

There's a guy who is absolutely brilliant at this stuff, and has authored many academic papers and books on intelligent tutoring and learning--Dan Russell. He used to head one of the two Apple Advanced Technology Groups, and was also a leader at Xerox Parc. Now he is the head of the User Experience group at IBM. When I first got into this, he was mentoring me about learning theory, etc. and he sent me a bunch of Prarie Home Companion tapes. That was NOT what I was expecting... I figured he'd send me another cognitive science book. He said, "Work on your storytelling".

We find most of the work that's really helpful happens *outside* of the education/academic world. Madison Avenue spends far more money researching the brain than learning institutions do. Advertisers have to get inside your head and make a difference in an extremely short period of time. They are concerned with retention, recall, and emotional impact. Isn't that the goal of any teacher? So we look at what they're doing in the world of advertising and marketing and positioning. If you want to find books that can help you with learning theory, go to the business and psychology sections. There's a lot of very new and exciting research on memory, too--the neurochemists are unlocking more and more of the mysteries there.

JavaRanch: Is "Head First" strictly geared towards adult education, or can the techniques be applied well in adolescent education? Any plans for a "Head First" introductory computer science book for teenagers, or even pre-teens?

Kathy: The brain is the brain. Most of the real differences in the brain (with respect to learning) happen at a much earlier age. Some of the approach might be slightly different for teens, but more from a style perspective. A 10-year old's brain is tuned for novelty just as an adult brain is. The main differences are not in the *age* of the brain in question (until you're about age 50), but about the *preferences* and *visual sensitivity* that come from growing up in a particular point in history. A brain raised on MTV is different from a brain raised on Lawrence Welk. Not so much because the latter brain is *older*, but because the MTV brain was wired differently. The cultural context in which that brain developed has a larger impact on learning preference than the number of years that brain has been around (assuming the older brain is in good shape).

We've heard from a lot of high schools that are using Head First Java. We didn't expect that, even though we *do* write these books skewed toward a younger audience. We consider our target audience to be 20-35, but we hear from people of all ages.

For *pre*-teens, we'd probably take out any of the mildly suggestive sexual references :)

JavaRanch: Thank You. We'll be looking for you at JavaOne.

Discuss this interview in The Big Moose Saloon!


Return to Top

Announcements

Big Moose Saloon changes
The forum formerly known as the "Struts and Other Frameworks" forum is now known as the Web Application Frameworks forum, and has been relocated to the Engineering section of the Saloon. Also, in recognition of the growing popularity of the scripting language Groovy, we've changed the description of the Object-Oriented Scripting forum to include Groovy. If Saloon traffic about Groovy picks up enough, as we suspect it has a good chance of doing, we'll create a new forum dedicated to Groovy discussions.

Now hear this
Junilu Lacar is the latest JavaRancher to create a blog on the JavaRanch Radio. See what he and other JavaRanchers have to say in their blogs at http://radio.javaranch.com/channel.

Return to Top

Following are the scheduled book promotions coming in June and July. Be sure to check our book promotions page often for changes and new promotions.

June 15	Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services	Thomas Erl	Prentice Hall PTR	Web Services
June 22	Eclipse Live	Bill Dudney	SourceBeat	IDE's and other tools
June 29	Java Demystified	James Keough	McGraw-Hill Osborne Media	Java in General (beginner)
July 6	The Definitive Guide to SWT and JFace	Rob Warner	Apress	Swing / JFC / AWT
July 13	XSLT 2.0 Web Development	Dmitry Kirsanov	Prentice Hall PTR	XML and Related Technologies
July 20	J2EE 1.4: The Big Picture	Solveig Haugland, Mark Cade, Anthony Orapallo	Prentice Hall PTR	EJB and Other J2EE Technologies
July 27	Pro Jakarta Struts, Second Edition	John Carnell	Apress	Struts and Other Frameworks

Return to Top