Manni Wood

So I’ve been doing some bit fiddling in Java, and because I don’t do a lot of bit fiddling, I want to print out the bits of longs so that I can get some feedback.

So I set up a long like so:

long someLong = 1L;

And I ask Java to show me each individual bit like so:

System.out.println(Long.toBinaryString(oldhash));

And here’s what Java outputs.

1

Thanks for printing the other 63 zeros there, Java. Great effort.

Happily, I like collecting programming books, and John W. Perry’s Advanced C Programming by Example has a nice example of printing all the bits in short ints.

It’s actually kind of cool. First what you need is a way to test each bit in a series of bits. Let’s say you have the following byte:

00000010

and you want to test its second bit (from the end). You shift that bit to the end:

byte i = 2;  // i is 00000010
i  >>= 1;  // shift one place to get 00000001

If we were interested in the first (end-most) bit, we would harmlessly shift zero places:

i = 2;  // i is 00000010
i  >>= 0;  // shift zero places to get 00000010

If we were interested in the third bit, we would shift two places:

i = 2;  // i is 00000010
i  >>= 2;  // shift two places to get 00000000

You take advantage of the fact that byte’s binary representation of 1 is

00000001

so if you & together 00000001 with any other short, the first seven zeros are guaranteed to make your result have seven zeros, but the final 1 will either & together with a 1 to give you 1, telling you the last bit was set, or & together with a 0 to give you 0, telling you the last bit was not set.

// let's test the second bit:
i = 2;  // i is 00000010
i  >>= 1;  // shift one place to get 00000001
i &= 1;  // i is 00000001; the second bit was set

// let's test the second bit again:
i = 6;  // i is 00000110
i  >>= 1;  // shift one place to get 00000011
//   00000011
// & 00000001
// -----------
// = 00000001
i &= 1;  // i is 00000001; the second bit was set

So you can write a testBit function (sorry—method; Java doesn’t have functions) that tests the i-th bit of a byte like so:

// return 1 if bitToTest-th bit of val was set,
// else return 0
byte testBit(byte val, int bitToTest) {
    val >>= bitToTest;
    val &= 1;
    return val;
}

And you can write a toBinaryString method that uses testBit like so:

String toBinaryString(byte val) {
    StringBuilder sb = new StringBuilder(8);
    for (int i = 7; i >= 0; i--) {
        sb.append((testBit(val, i) == 0) ? '0' : '1');
    }
    return sb.toString();
}

And so you can print all the zeros in your bytes:

byte i = 6;
System.out.println(toBinaryString(i));

Which will print this:

00000110

instead of this:

110

Nice, eh?

Sometimes all I want to do in my blog is link to other blogs, like A Farewell to ORMs and ORMs are a thing of the past.

Not that ORMs are bad for all situations; just that they are not a panacea. I wonder what Ted Neward thinks of this continual rediscovery that ORMs have their issues?

Mwanji Ezana asked me in a comment on my previous blog post:

I think one of the major advantages of ORMs is their lazy-loading, caching and query-batching ability. It’s not just about generating a schema and queries.

In all your anti-ORM posts, I’ve never seen you mention these capabilities. What do you make of them? Are they unimportant to you?

(Thanks for reading, Mwanji!)

I have a few comments, and I’ll have to start with the definition of ORM itself: as I discussed in my previous blog post, ORM has come to mean a lot of things, including SQL mappers like iBATIS, which I personally don’t consider ORM, but which, apparently, much/some of the programming community does.

So I’ll repeat that I only dislike the ORMs that write SQL for me behind my back. For the rest of this blog entry, if I say ORM, just think ORM of the sort that automagically does things for you; not ORM that facilitates easier writing of SQL queries, such as iBATIS.

When it comes to lazy-loading, caching, and query-batching, I like them all! It’s just that I think they are all best when decoupled from ORM. Caching, in particular, is arguably something that you may want decoupled from your ORM.

For instance, Django, has separate ORM and caching mechanisms: caching even has its own standalone chapter in the Django book.

I think this makes sense: caching is for more than just database queries, so I think it’s a great facility to offer outside of an ORM.

I consider query-batching to be another facility that can just as easily be offered outside of an ORM. If anything, the most effective ways I know to do large batch jobs on RDBMSs is to use the tools offered by the RDBMSs to do so, rather than those offered by any ORM or library. RDBMSs’ batch tools usually work best from the command line, allowing you to not only avoid your ORM for batch jobs, but avoid the whole application altogether.

I think I’m partly anti-ORM for aesthetic reasons: I try to avoid impedance mismatches instead of embrace them.

Consider a project where an object model perfectly describes the business domain, but there’s a need to store the data in SQL, perhaps because of SQL’s ability to generate great reports, or whatever. It’s the classic object/relational impedance mismatch.

Some (most?) projects embrace this mismatch by using some sort of ORM to bridge the gap.

Personally, I’d see if I could find a really good object database so that I didn’t have to deal with the mismatch. Why not store my objects in an object database and not even have to deal with an RDBMS? Maybe there’s an object database out there that can still generate the reports I need, or do other things I though I needed SQL to do.

On the other hand, if it turned out that the project needed features only SQL can provide, I’d think long and hard about whether or not my business data really had to be an object model. Maybe I could use the relational data model after all? Maybe in my application code I could use lists of maps to represent my data (so it would be a lot like SQL tables and/or result sets) and avoid the impedance mismatch by essentially bringing my relational model up into my application layer.

But that’s just me. I’m heavily biased towards solving problems by not having to solve them in the first place: Got an impedance mismatch? Pick a side. Now you don’t have to liaise between two ways of looking at the same data, because you just eliminated one by deciding that the other was more important.

But I’m happy to admit to at least two things:

1) Not all developers have the elimination/simplicity bias that I have, and

2) Not all projects can just pick one paradigm and eliminate another.

The continued popularity of ORM must mean that a lot of people are using it in a lot of successful projects.

I may personally suspect that a lot of projects probably succeed in spite of ORM, but I have to admit that it’s only because ORM has never been a good fit for the project I’ve worked on, so that experience has influenced my thinking. But I think us programmers need to admit that it’s a big world of programming problems out there, and one size does not fit all.

If your project is doing great, and you’re using ORM, then in the context of your project, you are right, and I am wrong. I’m glad you’re not listening to my criticisms of ORM, and I’m glad you’re sticking with what works.

On the other hand, if ORM is not working for you, or it’s showing some strain, check out Ted Neward’s The Vietnam of Computer Science, or about 25% of the blogs I’ve ever written. ;-) You may find some observations that ring true, even if you continue to use ORM.