///////////////////////////////////////////////////////////
//globals
Ball[] theBalls;
int numBalls;
int totalBalls = 17;

void setup() {  
 ellipseMode(CENTER);
size(400,600);
 theBalls = new Ball[totalBalls];
 numBalls = 0;
framerate(15);

int x=200;
 int nX;
 int y=400;
 int redFlag=0;
 
 for(int i=1;i<6;i++){
 nX=x;
 for(int n=1;n<(i+1);n++){
 color aColor=color(0,0,0);
 if (redFlag==0)
 {
 aColor = color(255,255,0);
 redFlag=1;
 }
 else
 {
 aColor = color(255,0,0);
 redFlag=0;
 }
 theBalls[numBalls]=new Ball(nX,y,20,0,0,aColor,numBalls,1);
 nX+=20;
 numBalls++;
 }
 y+=20;
 x-=10;
 }

}  

void draw() {  
 color backDrop=color(0,255,0);
 background(backDrop);

 for (int i=0; i < numBalls; i++) {
   
   for(int j=0;j < numBalls;j++){
   
   if(theBalls[i]!=theBalls[j]){
   theBalls[i].checkBallCollision(theBalls[i],theBalls[j]);
   }
   }
   }
 for (int i=0; i < numBalls; i++){
   theBalls[i].moveMe();
   theBalls[i].drawMe();
 }
 drawCorners();
 loop();
}  



void keyPressed(){
 if (keyCode == ENTER) {
   //create a new ball
   if(numBalls+1!=totalBalls){
   color aColor = color(255,255,255);
   theBalls[numBalls] = new Ball(100,(int) random(height-20), 20,0,-10, aColor,numBalls,2);
    numBalls = (numBalls+1)%totalBalls;
   }else
   {
     theBalls[15].v.x=-20;
     theBalls[15].v.y=-20;
   }
 
 }

 if (keyCode == UP)
  {
   theBalls[15].v.y=-20;
  }
  if (keyCode == DOWN)
  {
    theBalls[15].v.y=20;
  }
  if (keyCode == LEFT)
  {
   theBalls[15].v.x=-20;
  }
  if (keyCode == RIGHT)
  {
   theBalls[15].v.x=20;
  }
 
  }

void drawCorners()
{
   int x1=0;
   int y1=0;
   
   int x2=width;
   int y2=0;
   
   int x5=0;
   int y5=height;
   
   int x6=width;
   int y6=height;
   
   
   fill(0,0,0);
   ellipse(x1,y1,50,50);
   ellipse(x2,y2,50,50);
   ellipse(x5,y5,50,50);
   ellipse(x6,y6,50,50);
}

class Vector
{
 float x;
 float y;
 float vectorLength;

Vector(Vector v)
{
  x=v.x;
 y=v.y;
 vectorLength=sqrt( (x*x) + (y*y));
 
}  

Vector(int vX,int vY)
{
 x=vX;
 y=vY;
 vectorLength=sqrt( (x*x) + (y*y));
 
 
}
float vectorLength(Vector v)
 {
  return( sqrt( (v.x*v.x) + (v.y*v.y))  );
 }

Vector vectorNormal(Vector v)
{
 float temp_fp = 1/vectorLength;
 print(v.x);
 v.x *= temp_fp;
 v.y *= temp_fp;
// print(v.x);
 return( v );
}

Vector AddVect( Vector v1, Vector v2 )
{
 Vector v=new Vector(0,0);
 v.x = v1.x + v2.x;
 v.y = v1.y + v2.y;
 return( v );
}
 

Vector SubVect( Vector v1, Vector v2 )
{
 Vector v=new Vector(0,0);
 v.x = v1.x - v2.x;
 v.y = v1.y - v2.y;
 return( v );
}

Vector ScaleIncrease( Vector v, int s )
{
 v.x *= s;
 v.y *= s;
 return( v );
}

Vector ScaleDecrease( Vector v, int s)
{
 v.x /= s;
 v.y /= s;
 return( v );
}


float DotProduct( Vector v1, Vector v2 )
{
 return((v1.x*v2.x) + (v1.y*v2.y));
}

}
 
}
//////////////////////////////////////////////////////

The 10x / frame trick works fairly well, though it assumes you have some processing power to burn.  The other nice thing about that is that you can get blur trails real easy by drawing the earlier steps with some alpha (and perhaps draw them somewhat smaller).  I used this trick in http://www.slimearena.com/hackeysack.php (which is in Flash, not Processing, but same idea), and the ball ends up looking pretty nice, and the collisions come out well.

If you don't have enough free time in the loop to do 10x (or 5, or something like that), you can do a quick check to see if two circles could possibly collide during a time step using a simple bounding rectangle test (the rect for each would be the bounding rect for both this and the last time step).  If they can collide, you subdivide the time step and continue subdividing until you a) see that they actually don't collide, or b) find the actual collision point to within a certain tolerance, at which point you resolve it normally.

Alternatively, if you don't want to subdivide at all, you can do so-called swept collision detection.  The way this works is that you start with the positions of the two circles in the previous and current steps.  You then find the position of circle B w.r.t. circle A at each time step (basically you move into the reference frame of circle A), then you solve for the amount of time it takes for circle B to be exactly rA+rB distance from circle A.  This gives you the TOI (time of impact), which tells you exactly when they collide, and you move the particles to there, alter the velocities, then finish up the time step by moving them with the new velocities for the rest of the step.

Clearly all of the "correct" methods are a bit tricky to do, so if you can achieve the same performance just by using multiple time steps, do it - trust me, it will save some headaches.  And in reality, even the methods I outlined above don't completely solve the problem because you could be missing other collisions in the meantime.  There are ways to handle even this problem, but they get nasty and if you're not careful they can get you in situations where your single frame time step gets into an infinite loop.  At some point if I get a chance I'm planning to put together a collision detection/resolution tutorial or library using Processing, but at the moment I don't have this stuff coded up in a fashion that would be useful.

One other tip: as much as we all might like to, it's not a good idea to make a class called Vector, because Java already has a Vector object that has nothing at all to do with real geometric vectors (FWIW, whoever started this trend - I think it began with the C++ STL - should be beaten, because they wasted a really useful name on something that completely craps upon the standard usage of the word vector).  It probably won't cause problems for you here, but if you plan on using your code elsewhere, at some point you may find yourself in need of the actual Java Vector class, which will make things a bit difficult (though you should be using ArrayList instead of Vector unless you need thread safety).  Long story short: call it Vector2d instead, or something like that.

Also, a performance tip: watch out with vector methods that return new vectors.  It will work fine when you're only calling these a few hundred times per frame, but in a recent project I was using a lot of vector methods (~30,000 per frame), and I discovered that the overhead of creating a new object was taking up a good proportion of the processing power.  I was able to fix it by merely reusing the same temporary vectors over and over again whenever I needed a something that didn't persist from frame to frame.  Just keep it in mind as a potential optimization point if you use this stuff in other projects.

@skanaar : your link is considered like a trojan