Processing build for Windows: Error: Could not create the Java Virtual Machine


I’m in the unfortunate situation of trying to build an exe for Windows and sending it to someone else to test. I exported the exe from Processing 2.2.1 on OS X 10.8.5 without issue.

The only serious abnormality of the sketch is that it loads about 75 Mb of jpegs between 12 PImage arrays. (Could be a memory thing with Java?). On my Macbook Pro it takes a bit to start up but runs smoothly both compiling in Processing and exporting for OS X.

Sent the exe to my friend. He reports:

Error: Could not create the Java Virtual Machine
Error: A fatal exception has occurred. Program will exit.

systems info
windows 8.1
64 bit

He says he updated Java the other day.

Any suggestions?

I have the files zipped and on gdrive if anyone wants to try it out on a Win machine.


This fixed it, but if anyone has a Windows touchscreen and would like to test it, that would be a final test. (I doubt anyone has a Windows touchscreen).


Sounds like you need to give the JVM more memory.


Also, 75MB of jpeg-compressed images can expand to fill much more than 75MB once they are decompressed into raw pixels in RAM.


Part 2: The project is working now but my intrepid user tester reports that hovering too long over one of the image sets, or moving back and forth inside one particular image set, causes the application to crash.

This is not the case when I try it on OS X. I am probably doing something wrong here.

Note: In my defense, this project, from 2006, works perfectly fine for the WWW, using Flash, but our curator has some windows TV touchscreen thing and swiping to the left or right causes the browser to move the webpage, so I am rapidly building a new app to deal with curatorial ineptitude. Please take this as a pedagogical note, future ATS graduates. You may think you’re done with a project but until you’re ready to stop showing it, you’re never done with a project. (5.1 KB)


I’m wondering if mapping to an index like this:

      position = int(map(mouseX,x,x+320,0,images.length));

is a problem.

Remember that the map function does not clamp or constrain by default. It continues linear interpolation for mouseX values outside of x < mouseX < x+320. So, if mouseX > x + 320, it will map to a position index that could be outside of the bounds of the index. To solve this, you need to constrain your position to never be less than zero or greater than images.length.


You’re right, Chris, thanks, and it became a serious problem when I tried to use translate to center the grid (translate + mouse interactivity is an issue!). I intended to go back and fix that. However, when it was broken, it broke completely into a crash so I don’t think that’s causing the memory issue.

I played around with it while monitoring in Activity Monitor and, while it is not a upward spiral memory leak, it is definitely causing memory spike while moving back and forth in one image area.

My plan now is to significantly reduce the number of frames in the really high difference image areas, which I think will help memory more than anything, and tell processing to only update when the mouse was moved (housecleaning).


To get a better sense of your resources, calls, etc at a much finer grain than Activity Monitor, you should check out VisualVM ( It’s super useful for profiling java apps on all platforms.


Update: I got this working beautifully with Windows 8. No issues. Ready to go.
Sent it to the gallery tech.
“I cannot get the application to load at all. Does it require a specific java vm? I am not using Windows 8 btw, I am using Windows 7”

Thanks, guy, thanks a lot.