I took a look at your code and tried to understand what u were doing there.
I would suggest that your start with handling the collisions with propper physics first, take a look at http://en.wikipedia.org/wiki/Momentum
I know what momentum is, I've played Portal. >_>
The age old problem of correctness vs. performance.
You state in your post that it is not a performance problem, which is solely the case because you didn't take correctness into account. Once you do, you'll see it starts to become a performance problem. JBox2D is on the other end of the spectrum. It's up to you to find a balance.
The biggest problem is that you push two circles out of eachother, without checking whether there is actually space available at the new position. If not, you can push a center a circle so far into another circle that you'll have extreme forces pushing it out. So once you find there is no room at the new position, you have to move the all circles affected, recursively. You can see how you have to give up a lot of performance for this to be more correct.
I'd guess this is spot on.
I am making a strategy game, and the circles are units. I don't want any fancy physics for now, just some basic collision solving. I figured a simple solution like this would be enough, but apparently it wasn't. I thought it would kind of solve all collisions by pushing away circles little by little in an order independent manner, but when several units are pushing in the same direction it just can't compensate. It all depends on how fast units are moving ( = how hard they can push). By limiting the maximum movement speed of units to a reasonable value I can improve the situation.
I remembered that JBox2D had this "iterations" variable in the update function which controlled quality in some way. For now, I'll just take multiple smaller steps get more accurate physics. Dividing the time step into 4 eliminates almost all artifacts in my test program while still running at around 100 FPS. It is also an easily thread-able solution; I don't mind if you need a dual-core or better to run my game with 1 000 units, which is a pretty extreme case in the first place.
Still I am very interested in solving collisions. Collision detection is one thing, but solving them seems to be the real problem in physics engines. How does JBox2D do it? What about recursively check every circle in the game on collision? Wouldn't that give a worse scenario of ridiculously bad performance? I mean:
1. Check collisions between all nearby circles (potentially n^2)
2. For each collision, check collisions of new positions (potentially n^2)
3. Recursively do the same thing potentially n times.
The multiple collision problem is a hard one to solve for a non real time simulation. To do it correctly you need to order every collision and process the next collision, then work out the new order, there are many papers on this sort of thing. However this is always too slow. Everything else has stiffness problems and accuracy trade offs. The classic method is to allow some penetration that provides a *force* not a displacement with damping. Its hard to get it all right, but most game physics libs use this method. However many objects, as in thousands and more, is very much a topic of current research even for offline methods.
Ah, I see. For now, the solution I posted above does its job, but I will want to upgrade to more proper physics later. Thanks for the info!