Okay, here's a topic to discuss Java versions of Box2d. I saw that quixote_arg was planning to do a Java port, so maybe we can split up some of the work.
First, though, best to figure out some nuts and bolts, and decide how exactly to move this from C++ to Java.
From a quick look through the code, I would say about 95% of the engine appears to be almost trivial to translate, meaning that a Java analogue exists and is pretty obvious (class/struct -> class, pointer -> reference, find/replace "->" with ".", textually resolve all typedef stuff, make sure all bit-fiddling matches with Java's type sizes, etc.). I didn't see too much function pointer or macro shenanigans, which is good because that doesn't translate too well. Just be on the lookout for any pointer arithmetic, because you don't want to accidentally try to increment the pointed at variable when you're just supposed to be traversing an array or something like that.
But the allocation/deallocation stuff is too low level to use as written. I'm a little torn as to what to do here, as it seems to be a pretty important piece of code in the C++ version - do we just punt and leave it up to the JVM to decide what to do to deal with all the small objects, or do we try to come up with a Java specific solution? To some extent the need for this type of stuff in C++ is that the usual malloc implementation is slow because it's not highly optimized for small objects; Java is _supposed_ to be better for these (I recall reading somewhere that these allocations tend to happen in just a couple machine instructions in the JVM, compared to several dozen from your usual malloc, mainly because the garbage collection allows the JVM to organize its memory space so that it's real simple to dole out new chunks), so maybe it's not such an issue. Then again, Java has historically had issues with object creation overhead, and though Sun always claims this type of problem should magically disappear because their JIT compiler is so fabulous, I've definitely had programs that were bound by the creation overhead of vectors (as in, the programs ran slow until I inlined all the vector ops by hand, then they became fast...). Phys2d hit some pretty fantastic amounts of new object creation (I've seen it go up to over 100,000 vector constructions per frame, and on my computer that's about the limit of new objects per frame I can create without affecting frame rate, even with no additional logic involved), so this is probably something worth thinking about. We could do something like use a temp pool for throwaway vectors and matrices, and only create new ones if we need them to last past the function call. Stuff like this always irks me, though, because under reasonable programming assumptions it should always be better to declare something locally than globally if that's how you're using it, but I suppose reality trumps logic in the end...in theory Java should be better about this stuff if the JVM actually uses escape analysis like they claim it will (or does? I'm not sure, I'm on a Mac so it's a bit different for me as I won't get 1.6 'til the next version of OSX comes out), but I'm always skeptical when it comes to promises of performance increases "real soon" in Java...
What I'm thinking is that first we should attempt to get things running without trying to trick Java into doing anything special with memory, and then we can see if we need something more subtle. I guess what that means is translating the calls to the block allocator into something more standard - any ideas on the simplest approach?
quixote_arg, how far along are you in your translation? I was going to start from scratch, but if you've already gotten up and running I have no need to reinvent the wheel, so I'd be willing to help out as long as the ultimate product will be under zlib or a similar free license. I might branch off at some point, as one of my ultimate goals is to get a simple rigid body physics library for Processing, which means making a bunch of default choices and wrapping/simplifying the API a bit (to the point where programming newbies can use it easily, which is kind of the goal of the Processing project), as well as plugging in some default drawing code and stuff. But step one is definitely just getting it working in Java, so...