The Querki project is slowly grinding forward, and I've wound up leaning towards Java as the likely platform. It's not perfect, but none of the options seem to be perfect. I love Ruby, but it is still very slow, and the threading model is a joke (Python is better, but looks to have similar problems); .NET is too Microsoft-centric (there's an open-source port, but it's always going to be running behind MS); and I just plain don't like Perl enough to want to write something this big in it. And most other choices don't have enough distribution to consider good options for what is intended to be a pretty serious open-source project. Java's a bit heavyweight, and requires compiling, but it's a good solid language that works well for enterprise projects, and there are plenty of open-source projects that I respect using it well. So it's the leading contender.
That said, I'm rather naive about the platform. My Java experience is ancient -- I was once a serious Java guru, but that was back before it was even being used for server-side apps, over a decade ago. So I've got a whole bunch of self-education to do. I've written plenty of high-power servers, so I'm not terribly worried, but I'm having a bit of trouble figuring out where to start.
The most obvious and immediate question is which version of the platform I should be using. J2EE is a buzzword that I'm reasonably familiar with, but I honestly don't have a good feel for the difference between it and J2SE. (Yes, I know that they've recently changed the names, but those acronyms are convenient.) I get the impression that J2EE is mainly intended for servers, and J2SE for clients, but I don't know if there's anything hard-and-fast about that. And I'm at best slightly familiar with servlets and beans.
My situation is this: I'm writing what amounts to a high-power wiki system -- it's not precisely what people normally think of when they think "wiki" (it's actually a superset of wiki conceptually), but that's close enough to understand the needs. It'll need to hook to real databases in the back end, which I think means I need JDBC. It needs to run under a conventional webserver such as Apache, but I'd like for it to be able to run in a relatively standalone mode as well, so the guts can't be *too* bound up in the ordinary webserver assumptions, and I don't want them too baked in. I'm honestly of mixed minds about whether it should have in-memory caching capability, which may well make a major difference to the architecture. (Since it affects whether there needs to be memory sharing between instances, or they can be treated as completely independent, which is likely a scalability win.) It is very important that it be easy to distribute and install, without requiring a ton of Java-installation overhead, so if J2EE is much harder to install and maintain than J2SE, that's an important consideration.
So I put this to the experts in server-side Java: what pieces do you think I should be using here? I'm sure that I *could* build this whole sucker from the ground up in J2SE, but I'm not sure what I'd be sacrificing in the process. Some pointers to relevant topics that I should be teaching myself would be useful...