It probably won't solve all your problems, but I would recommend changing your collision detection routines from looking for points inside polygons ( O(n*n) unless you're doing something really clever ) to looking for intersections between line segments ( can be done in O(n log n ) ).
As well as being more scalable, it will catch collisions that looking for point inclusion won't, particularly with fast-moving or thin bodies.

Once you've identified an intersection, you need to determine which is the incident face, and which is the penetrating vertex. This can be a bit tricky, but you can generally get away with just choosing the solution that results in the smallest corrective impulse.

Not necessarily, it all depends on how you determine which is the incident face and which is the offending vertex.
Choosing the smallest impulse solution should probably be the last resort after you've exhausted looking at the two body's relative velocities and so on.

Kev's code is certainly ready to do stuff like that, give it a try! 

I can't wait to use this in a game either, trouble is that i need polygons and i've got to iron out the bugs...

I looked a bit more into it and I wonder why is everything float and not double?

Speed-wise they should be the same.

I used floats because I thought they were faster than doubles, but apparently they aren't:

http://www.velocityreviews.com/forums/t134954-float-vs-double-speed-on-p4-machine.html, see Roedy Green's reply.

It could be changed to doubles, but it would be a bit of work removing all of the float casts.  Not much point anyway, as Riven said there's not much of an advantage to have that little bit of extra precision.

Thanks for taking a look at the code.  By the way, I've changed the polygon collsion code so its working much better.  I'll post it and a new demo in a couple of hours.  I figured out what was making the triangles demo go haywire - I was scaling the triangle's y-coordinates by -1 to flip them over, but that meant that the points weren't listed in anti-clockwise order which is what the collision code assumes.  Anyway, now the triangles bounce off properly and you don't see the big ones sucking the smaller ones in.

There's still problems with my code such as with fast-moving thin bodies & also with intersecting vertices where neither vertice is inside the other shape, which you'll see in the next demo.  I think I can only solve it by using intersections (as bleb prescribed), but I'll apply the forces at each bodies' vertices, not at the intersections themselves (this shouldn't require too much extra work). 

Until I solve this I think its best to keep your working code away from my buggy version.  If you want to add my project on to google code and have the two going in parallel that's fine.

Thanks for offering to integrate them.  Hopefully I will be able to do most of it - at least the parts that only I understand.  I'll post the new demo & code soon.

Keith

PS: I haven't changed too much except for what I said before: making the bounds a max radius from a centroid point.
The only other important change was using Point2D.Float class rather than Vector2f  - but that's not too much work to change. 

I don't really like Point2D.Float anyway since you can't serialize it or extend it.  Though I'd like to add some more methods to Vector2f  if you don't mind - like setX, setY, getPoint2DFloat() and let it implement Serializable.

@Float vs Double: Don't forget that opengl uses internally only floats. So the speed gain might be lost due the downcast from double to float.

Good to know this hasn't been abandoned. 

Looking forward to the newer versions