Monday, November 28, 2005

Intro J2EE Books

So as a part of my new job I may, as time goes on, have a need to deal with the looming monster of J2EE in one way or another. We have a lot of Java code in the system, and while I don't actually work on it, there are definately going to be times when the part of the system I work on will intersect the part of the system I know virtually nothing about.

You see, despite the fact that I do, in theory, know Java, and in fact that I've been paid in the past to write both desktop Java applications and Java web applications, I really know very little about J2EE. Honestly, I don't even like the term J2EE. If people could just say "Java Web Applications" I'd be fine with it, but as soon as they try to use the term "Enterprise" to make something like a web page sound impressive I really start to glaze over.

Despite this, I do recognize that there are a lot of smart J2EE developers out there, and they have built a number of impressive systems using those technologies, and since I do have a need to interact with this stuff it's probably a good idea that I actually learn something about it. So this weekend I stopped at a book store and tried to find a decent looking intro J2EE book. So far, I've been largely dissappointed. I picked up a copy of "Core Servlets and Java Server Pages", which seems reasonable enough for the JSP and Servlet stuff, which I already know, but could probably use a reference on, but it's like 3 inches thick, and covers a bunch of useless "HTTP and HTML 1.0" crap that nobody who's been alive in the programming world over the past few years should need to see again.

Plus, it doesn't cover anything other than Servlents and JSP, plus a smidgen of things like JDBC. I mean I've got no freaking clue about EJBs, or any number of other acronyms that show up in the J2EE world, but I'm certainly not willing to go out and buy a 40 dollar book for each and every one of them, and from what I can see that's what you're buying into when you start picking up books in the J2EE space.

So does anyone have a good intro J2EE book they'd like to recommend to me? Something to get me to the point where I can be conversant in the terminology and know enough to poke around in some code without being totally lost, but where I don't have to spend hundreds of dollars and waste weeks of my time reading hundreds of pages of crap?

Sunday, November 20, 2005


Back when Sun launched OpenSolaris, I was pretty psyched about the whole thing, but one of the things that actually interested me the most was their online source browser. For those who haven't played with it, it's pretty much a reimplementation of LXR, which you may have seen in use over at

Of course, at the time, the code to this part of the OpenSolaris web site wasn't available, so I just sort of wrote it off as "pretty cool, I wonder if it'll ever be released".

Well, apparently its code was actually released last week, it's called OpenGrok, it's written in Java, uses Lucene for its searching, and calls out to exuberant ctags to parse source code in a dizzyingly large variety of languages.

I just downloaded it and pointed it at a copy of the Subversion source code, and I've gotta say it's pretty cool. The instructions were pretty straitforward, just run a simple command to index your code, edit a few lines in WEB-INF/web.xml, drop the war file in Tomcat's webapps directory, and away you go.

It'd be nice if it had actual Subversion support built in (so far just CVS and SCCS), but that's on the todo list. Other than that my only complaint is that it requires Java 1.5. Requiring Java at all is a pain, but I can get over that, considering that it comes from Sun and all. The Java 1.5 thing really sucks though, since it means there's like zero chance it'll work with the open source Java implementations.

Also slightly annoying is the fact that while the code is available, there doesn't seem to be any way to contribute changes back, or at lease none that's mentioned on the web page. It's basically just source and binary distributions with some instructions on how to get started.

Hopefully a public source repository and some mailing lists will show up in the future, because it's really a neat tool, and I'd love to at least keep track of its development, if not actually contribute to it.

Thursday, November 10, 2005

Subversion in C++?

So a while back one of the Subversion committers mentioned that it might make sense to write some (as yet theoretical) future version of Subversion in a dialect C++ instead of C.

You see, Subversion is VERY object oriented, at least for C code, and we jump through a LOT of hoops as a result of the C language. For example, there's about a million places in the source tree where we pass around void pointers as a way of storing context for some callback. In C++ we could pass objects that carry their own context around with them, instantly cutting in half the number of arguments we need to keep track of.

Anyway, I was thinking about this on the drive home from work today, and I started to wonder what would be required to make that really possible. The first thing that jumped to mind was making APR interoperate with C++. Virtually all resource management in Subversion is done via APR pools, and we're kind of used to that by now, so switching to a non-pool based world would be kind of weird. But APR pools deal in void pointers, low level raw memory C stuff, and setting up higher level cleanups is a pretty manual process.

Now it's possible to take the raw memory you got from a pool and turn it into an instance of a C++ object, via something called placement new, but it's kind of a pain in the ass, and even then you have to manually call the destructor when you're done with the object, which is kind of contrary to the point of allocating things out of a memory pool...

So the question is, how do we allocate a C++ object from a pool, but automatically register a cleanup that takes care of calling the object's destructor when the pool is cleared or destroyed?

It took a little doing, but I managed to come up with something I like. It looks like this:

main (int argc, char *argv[])

apr::pool p;

for (int i = 0; i < 10; ++i)

Foo *f = p.allocate();


Now to make that work, you do have to jump through one little hoop. The Foo class needs to have a static 'cleanup' function defined on it, which calls the object's destructor. That function will be used as the pool cleanup callback, so you don't have to worry about cleaning it up yourself. To simplify the process of writing this function, there's a helper macro that pounds it out for you, so the Foo class looks like this:

struct Foo
std::printf("in constructor\n");

std::printf("in destructor\n");


That really doesn't seem like such a horrible price to pay for the convenience of being able to work with pools the way we've come to expect, right?

Anyway, I doubt this will ever really be used for anything, but if you want to check out the code I wrote to make this work, you can grab it here.

Monday, November 7, 2005

Back From The Weekend

So I flew out to MA this weekend for my Dad's surprise birthday party. It was a total success, he didn't know that anything was happening until my sister showed up saturday morning, and she told him I couldn't make it, so when I showed up later that afternoon the surprise was complete.

I got to hang out with my relatives, which is always cool, and generally had a good time. It was kind of odd that it was like 70 degrees out (what the heck, it's November in MA for crying out loud!), but I did get to see actual autumn foliage, which I've missed being out in CA this year.

One odd thing, the flight from San Jose to Boston, which has been totally packed every single time I've taken it so far, had empty seats on both friday's flight out and sunday's flight back. Is this just a slow weekend or do people no longer want to fly from San Jose to Boston as much as they did when Jet Blue first started doing this particular route?