java hosting


JavaRanch Newsletter Articles in this issue:
The SCJP Tip Line - Bit ShiftingCorey McGlone
Printable Version
BeanUtils, Digester, and Type ConversionJason Menard
Printable Version
The Coffe House - Grounds for Change Solveig Haugland
Printable Version
Meet the Author - Harshad OakJason Menard, Thomas Paul and Mapraputa Is
Printable Version
Meet the Authors - Kathy Sierra And Bert BatesDirk Schreckmann
Printable Version
AnnouncementsDirk Schreckmann
Printable Version  
Book Review of the Month - Java Testing and DesignAndrew Monkhouse
Printable Version
Book Promotions coming in June and July Dirk Schreckmann Printable Version

SCJP Tip Line - Bit Shifting
The SCJP Tip Line
Bit Shifting
by Corey McGlone

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;
If we convert b, which has a value of 13, to binary, it looks like this:
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

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

Discuss this article in The Big Moose Saloon!


Return to Top
JavaRanch Newsletter

The Coffee House

coffee house

Grounds for Change

by Solveig Haugland

"Another day chock of full of coffee," grumbled Brenda as she stumbled out of bed. She sat down at her surprisingly large dressing table--the kind with little drawers all over the place for makeup that Brenda had filled with leftover computer cords and extra zip drives--and stared gloomily into the mirror. "Coffee...coffee...coffee..."

Across town, Lacey was having a similar kind of morning. Even a few minutes on the back porch with last month's Kansas City Times wasn't cheering her up. It took her two weeks to work her way through one Sunday paper and even if she hadn't excelled at differential equations and lambda calculus in college (and high school), she would have known that at this rate, she would never, ever catch up. Not at this rate and in this universe, at least.

They met at the JavaRanch Coffee House at 6 AM, as usual. Powered up the nitrogen cappucino maker, as usual. Ran a browser history searchbot as usual to clean up the onsite computers in the lab. (The cowboys had their wild side but they also liked to think that anything they did there was private.)

It was like any other day, except that both Brenda and Lacey had simultaneously gone over the edge of their coffee house tolerance. Brenda put on her frilly latte apron upside down and the eyes that peeked out from behind the apron's eyelet trim were glazed and dangerous and bright red. Lacey walked around singing "Java Jive" but with alarmingly different words. She also denied being the one to write on the coffee specials board

All coffee and no tea makes Lacey a dull girl
but there was little doubt, in Brenda's mind or the minds of the fifteen frightened cowboys who suddenly remembered they'd left a brisket in the oven, who was responsible.

"Lacey...here Lacey..." Brenda crept around the empty coffee house, apron now completely covering her head, which of course made it a little hard to find Lacey but she didn't really seem to notice.

"Lacey?" Brenda peeked into the bean barrel. Cowboy Pete was still hiding there but that was normal.

"Lacey?" Nobody was in the broom closet but Steve Ballmer, as usual, still trying to hook up a Windows server and make it run.

"Lacey?! Where are you!" Brenda even went up to the attic but no one was there but Scott McNealy and Bill Gates, gazing fondly into each others' eyes. Brenda rolled hers and headed downstairs.

"Here I am...I think. I think it's me. I might have turned into a giant bean. Do I seem a little Arabica to you?" Lacey had poured herself a half-and-half bath (hazelnut flavor) and was using one of the bigger brown sugar lumps as a loofah. "Could you hand me the chocolate shavings? I think I need a tougher exfoliant."

Brenda realized immediately that Lacey had gone round the bend, or "round the bean" as they say at the corporate headquarters in Seattle. She drained the tub, rinsed Lacey off good and proper, dumped her in the car and they both drove to a tofu bar in Kansas city where they downed nonfat decaf water and soybeans until they both felt comfortable enough to address what had happened.

"Lacey, we've been making coffee every day for three years straight. We need a frickin' vacation."

Lacey flinched at the word coffee but nodded. "Can we go somewhere where there is no...coffee? And where nobody will ask me about output streams? It ain't just the coffee. It's the Java. I mean, I love it and all, but...sometimes a girl needs a break. All beans all the time...I mean, a girl can only take so much getting and setting and brewing!"

Brenda smiled and nodded. And thus began the great Thelma and Louise style road trip,except that there were no felony assaults and no suicide, though they did rent a nice red convertible. Brenda and Lacey did everything they could that was the opposite of what they'd been doing for the last three years.

They drank Tang and tap water for the first three weeks to flush the toxins from their systems, or at least to swap toxins.
They went to procedural programming classes and wrote thousands of lines of brittle, difficult-to-maintain code.
They crept into fine restaurants and substituted volcanic sand for Folger's Crystals.
They got AOL email accounts and used their birthdays as their passwords, and attached their signatures in graphics-infested Microsoft Word documents.

And when they were strong enough, they stayed at a Motel 6, poured cups full of what is charitably called coffee there, and laughed and laughed and laughed.

When they got back, the cowboys were overjoyed and immensely relieved to see them. Zeke had broken the nitrogen cappucino machine, and there had been a brief but painful episode wherein shaving cream had gotten mixed up with the whipped cream. Sid was sleeping in the computer lab to make sure no one saw his bookmarks. The whole lab was in such a state of disrepair and had so many viruses that even Bill Gates had been horrified, and he'd skedaddled, leaving Scott upstairs alone and in tears.

Brenda and Lacey sent the lot of them home, called up a couple of Miss Kitty's girls who daylighted as maids, and, happy to be home and desperate for a decent cup of coffee and a stable programming language, sat down in the computer lab with big cups and big smiles.


Solveig Haugland is an independent trainer and author near Boulder, Colorado. Her businesses include GetOpenOffice.org for those switching from Microsoft Office to OpenOffice.org  (www.getopenoffice.org); Techwriter Stuff: The Single Source, t-shirts and posters for techwriters and those who love them; and of course Dating Design Patterns, the original reusable solutions to recurring problems.





Discuss this article in The Big Moose Saloon!


Return to Top
Meet The Author - Harshad Oak

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
Meet the Authors - Kathy Sierra and Bert Bates
Meet the Authors
Kathy Sierra and Bert Bates
by Dirk Schreckmann

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 of JavaRanch Happenings

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
Book Review of the Month

Java Testing and Design
Frank Cohen
This book is an excellent guide to testing web applications and web services, and will benefit all readers from someone just starting testing, through to experienced testers trying to test a particular service.

The first third of the book describes testing in general, and how it can be applied to web applications. The second part tackles different connectivity methods, from HTTP through XML & SOAP; from one off messages, through testing sequences of messages (including maintaining session data), from user testing, through performance testing. Each chapter describes the issues and the potential problems with testing, then provides a clearly detailed description of testing using the PushToTest open source test tool. The final third of the book details some case studies of tests that Mr. Cohen has been asked to devise.

My biggest concern with this book is that, despite it's title, it really has very little to do with Java. The tests definitely apply to applications written in Java, and java classes can be used by Mr. Cohen's test application, however the book equally applies to testing any networked service, regardless of the language it was written in! Of lesser concern is that there is practically no discussion about testing outside PushToTest testing framework (not a big concern since PushToTest is open source).

This does provide excellent insights into testing, and easy to use tools and explanations for performing the tests. I have no hesitation in recommending this book to anyone involved in testing networked applications.
(Andrew Monkhouse - Bartender, April 2004)
More info at Amazon.com || More info at Amazon.co.uk


Other books reviewed in April :

Effective XML by Elliotte Rusty Harold
Enterprise Java Security: Building Secure J2EE Applications by Marco Pistoia, Larry Koved, Anthony Nadalin, Nataraj Nagaratnam
OOP DeMystified by Jim Keogh, Mario Giannini
A History of Hacks and Pranks at MIT by T. F. Peterson
Databases Demystified by Andrew Oppel
J2EE Design Patterns by William Crawford, Jonathan Kaplan
Effective Software Test Automation by Kanglin Li, Mengqi Wu
Data Structures Demystified by Jim Keogh, Ken Davidson
Enterprise Messaging Using JMS and IBM Websphere by Karemm Yusuf
Exploiting Software: How to Break Code by Greg Hoglund and Gary McGraw
Designing Highly Useable Software by Jeff Cogswell
Developing Series 60 Applications: A Guide for Symbian OS C++ Developers by Leigh Edwards, Richard Barker

Discuss this book review in The Big Moose Saloon!


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
Managing Editor: Dirk Schreckmann