First of all, thank you to the other two answerers. Also basszero you were right about the blend file, and I should've checked Wikipedia first! It is a near-useless binary dump of Blender's memory.
Shortly after writing this question, I decided to go ahead and write an OBJ loader, because 1) it would give me the experience of loading a 3D file format and 2) it seemed a nice, commonly-used format but also easy to load. It ended up being a great decision, because it made me realize, I didn't actually know the difference between an object and a group, and I also didn't know much about materials. It helped me establish the code for these 3D structures.
Both answers recommend XML-based formats. I don't want an XML format. I do not believe this is the right place for XML. I believe those formats were created because XML is flexible, universal, and easy to create schemas for, but that's not what I'm looking for. I want a format that is fast to load (XML is not, relatively speaking), it does not have to be flexible or human-readable, and something that I can write an importer for, rather than relying on XML libraries. basszero even said, "at the cost of being XML," and he's completely right; it's a cost that I don't feel is worth the burden.
My OBJ loader is done. I separated it from the actual model classes, and implemented it with a MeshFactory interface so that I can in the future write a different loader if I wanted... Which is the plan. I have been doing more research the past couple days and decided on the ms3d format.
The ms3d format supports skeletal rigging (joints) and keyframe skeletal animation, and furthermore supports a texture map and alpha map. In addition, it is an easily-computer-readable binary format that wastes no space (like XML and OBJ do) with human readable tags and labels and such.
Blender, unfortunately, does not have a (working) ms3d export script, so I will be writing a script for it myself. Luckily, it's not a hard process, and you can read through Blender's documentation and use other exporters as examples. I'll have to brush up on my Python, but otherwise it seems very straightforward, from what I've seen of other scripts.
The Java side of things should be easy, in fact it will be even easier than the OBJ format because ms3d is more structured. I found specifications for the ms3d format online, in C style (genius!) so they are incredibly self-explanatory and I have no further questions about the format. I will be basing my implementation off of this spec, though I may at a later time implement my own variations; that's the great thing about writing my own importer and exporter, I can modify the format as I see fit.
All in all, I have decided this is the best solution.
And basszero, you are absolutely right, as I've seen from my OBJ loader: "Once you've got it all read in, organization of data (display list, textures, vertex array, vertex buffer, etc) and rendering are a completely different beast."
Cruachan: no Java3D for me, I'm sticking with JOGL. I do actually own that book (though it's not accessible at the moment) though I don't remember how he loaded models, but I'm pretty sure he used the Java3D format loaders which do it automatically. Not something I'm planning on using... Sorry!
-Ricket