Processing isn't self contained, but you won't be exporting elements of your own JRE when you export from Processing.  If I recall right, Processing requires Java 1.4.  I've also found it doesn't like IcedTea much.

Edit: sorry, noticed on downloads page that for Windows, there are two options: standard, and without Java.

Yes, Java version will make a difference...but what errors are you hitting exactly?  Any hints from the Java console?

Edit: Just read your other post.  I think the "Wrong ELF error"  was fixed in Processing 1.0.9 -- are you using the latest version?

there was a hint in the stacktrace that you posted elsewhere:

Exception in thread "Animation Thread" java.lang.UnsatisfiedLinkError: /home/brokenjames/sketchbook/OPENGL_yourGoingTFW/application.linux/libgluegen-rt

.so: /home/brokenjames/sketchbook/OPENGL_yourGoingTFW/application.linux/libgluegen-rt

.so: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch)

it's using 32-bit jogl libraries on a 64-bit operating system.

http://www.flickr.com/photos/stopandfocus/4383824906/

Got it all sorted out finally
Still a bit quirky in deb 64-bit but everything is a little quirky in Linux.
---------------------------------------------

import processing.opengl.*;

class Sphere_the_Sphere {

 float sphereX=-5;
 float sphereY=-5;
 float sphere_rot;

 void omg_silly(float sphereX,float sphereY,float sphere_rot){

   this.sphereX=sphereX;
   this.sphereY=sphereY;
   this.sphere_rot=sphere_rot;
 }    

 void drawsphere(){
   pushMatrix();
   translate(width/2,height/2);
   rotateY(radians(sphere_rot));
   translate(sphereX,sphereY);
   sphere(3);
   popMatrix();
 }
}
//------------------------------------------------------------------------------
------------
int num=4000;
Sphere_the_Sphere[] ball = new Sphere_the_Sphere[num];
void setup(){
 size(300,300,OPENGL);
 hint(ENABLE_OPENGL_4X_SMOOTH);
 for(int i=0; i<num; i++){
   ball[i]=new Sphere_the_Sphere();
 }
}
float height_;   // this is the current height if the ellipse
float min_height=-100; // this is the ellipses lowest posible point
float max_height=100; //this is the ellipses hightest posible point
float sphereX;  // this is the ellipses calculated distance from the center of the sphere
float sphereY;
float degreez=0;
float sphere_rot=0;
int i=0;
int ww=0;
//------------------------------------------------------------------------------
-------------
void draw(){
 noStroke();
 lights();
 emissive(0, 26, 51);
 background(0);
 for(int dd=0;dd<num;dd++){
   degreez=degreez+2.7;
   if (degreez>=180){
     degreez=0;
     sphere_rot+=5;
     //  println(sphere_rot);
   }
   sphere_rot=sphere_rot+2.7;
   if (sphere_rot>=360){
     sphere_rot=0;
   }
   sphereY=cos(radians(degreez));    ///// these are the y values of the arc
   sphereX=sin(radians(degreez));    /////  these are the x values of the arc
   degreez=constrain(degreez,0,180);
   sphereX=map(sphereX,-1,1,min_height,max_height);
   sphereY=map(sphereY,-1,1,min_height,max_height);
   if(ww<num-1){
     ww++;
     ball[ww].omg_silly(sphereX,sphereY,sphere_rot);
   }
   //-----------------------------------------------------------------------------
---
   println(dd);
 }
 for(int zed=0 ; zed<num; zed++){
   ball[zed].drawsphere();
 }
 println("finish");
 save("spheres");
 noLoop();
}
//// debug for positions of all spheres
/*
for(int ded=0 ; ded<num; ded++){
println(ball[ded].sphereX );
println(ball[ded].sphereY) ;
println(ball[ded].sphere_rot);
println("---------------------------");
}
*/

Well I was hesitant to explain how I got it working because I really didn't do anything to fix it. Really all I did was figure out a simple hack I could do to make it work correctly.

I was trying to render something from a single frame one pass with a piece of code like this ....

import processing.opengl.*;
size( 300,300,OPENGL );
background(0);
lights();
translate(width/2,height/2);
sphere(30);

....when it didn't I assumed it was totally broke and exported it as an application to see if I could get some out put on errors. When I did this I ran into an entirely different and unrelated problem

Later on I for what ever reason ran the same piece of code inside of a setup and draw loop and everything worked correctly

import processing.opengl.*;
[color=#ff0000]void setup(){
 size( 300,300,OPENGL );
}
void draw(){
 background(0);
 lights();
 translate(width/2,height/2);
 sphere(30);
}

this worked correctly. Then I tried adding noLoop() to the end of the above program and again no render. So I decided for, what ever reason, when I run a sketch from inside processing it incorrectly renders the initial frame as being blank and then on the next passes it renders everything correctly its only this initial frame that has the problem.  I then ran this code to confirm thats what was going on....



import processing.opengl.*;
void setup(){
 size( 300,300,OPENGL );
}
int run;
void draw(){
 if ( run == 1){
   background(0);
   lights();
   translate(width/2,height/2);
   sphere(30);
 }
 if ( run == 2 ){
   println("finish");
   noLoop();
 }
 run++;
}

again everything went fine it ran a 1st pass which was expectedly blank and then rendered everything like it should have on the second pass.

One more thing to note is that if you run this piece of code......

import processing.opengl.*;

void setup(){
 size( 300,300,OPENGL );
}

int run;
void draw(){
 lights();
 translate(width/2,height/2);
 sphere(30);
 }

the background screen flickers wildly while the created GL object renders correctly as soon as you add in background(0)  to the code everything works correctly with no flicker.


For right now thats really all I have on the matter. I did not have time to check out why when exported as an application it was erroring out with something about damn elfs and fairies   but I feel like thats an easy fix and its just using/referencing the wrong libraries.

Im going to submit both of these issues this as a bug since I didn't run into anything on it in the dev section when I checked. Thankfully I have the feeling we might see better Linux support for processing down along some ways especially if this thing is going to be android friendly.(Hell besides being the 64-bit version which true is a big difference Debian and android use the same kernel)