Troubleshooting \ Wiring ALPHA 1.0
Author: Hernando Barragán
Description: Wiring is an electronic sketchbook and hardware electronics for developing ideas. It is a context for learning fundamentals of computer programming and prototyping with electronics within the context of the electronic arts.
Keywords: Wiring, Processing, Interactive Media, Electronic Arts, Programming, C, C++, Hernando Barragán

Search wiring.org.co:

#

I've found a bug!
Processing won't start! Nothing happens when I click “Run”!
This used to work and now it doesn't
Export and Browser Troubles
Out Of Memory Errors
Why don't these Strings equal?
Why does 2 / 5 = 0 instead of 0.4?
Problems with Video
Problems with the Serial Port
Problems with OpenGL
Common Issues (not bugs)
Things that we probably can't fix
Known Issues
Supported Platforms
Windows
Mac OS X
Linux
Other Platforms
Java Versions

##### I've found a bug!

I know you're excited, but please avoid the urge to just email us! especially sending mail to Ben or Casey directly. This includes sending us "Instant Messages" on the discourse section of the site (we have to ignore these, sorry). While you may prefer the privacy of a personal message, it's much quicker for you to write to the board, where you'll find all sorts of helpful people who are also often at all hours of the night. If you email us directly, we'll either not respond or just ask you to use the discourse board anyway.
We spend a lot of our time helping people with Processing, so reading and following these instructions means that you respect our time and don't want to waste it.
First, read through this page and maybe the platforms page too in case it's something specific to your operating system (or your Java installation).
Second, search the bug database to see if your problem has already been reported. Most often, this will contain background on the bug, a workaround, or hopefully a bit about its status. The bug database is unfortunately incomplete so it doesn't cover everything, but it will get better with time.
If you don't find your bug, enter it as a new bug in the database, this will help us keep track of the issue.
When reporting please include information about

1. the revision number (i.e. 0135)
2. what operating system you're using, and on what kind of hardware
3. a copy of the smallest possible piece of code that will produce the error you're having trouble with
4. details of the error, either the red spew that you see in the console, or the last few lines from the files stdout.txt or stderr.txt from the 'lib' folder.

For stranger errors during compile time, you can also look inside the build folder which contains an intermediate (translated into Java) version of your code. The build folder will be located inside a temporary directory on your machine, probably /tmp/buildNNNN on Mac OS X and Linux, or on Windows, in one of its many "TEMP" folders, inside a buildNNNN folder (the Ns will be numbers or letters). The more details you can post, the better, because it helps us figure out what's going on. Useful things when reporting:

- We want the minimum amount of code that will still replicate the bug. The worst that can happen is we get a report with a subject saying "problem!" along with a three page program. Sure, everyone likes a puzzle, but simpler code will receive a faster response.
- Occasionally we may need you to pack up a copy of your sketch folder or something similar so that we can try and replicate the weirdness on our own machine. Rest assured, we have no interest in messing with your fancy creations or stealing your ideas. The Processing team is a pair of straight-laced boys who hail from the midwestern U.S. who were brought up better than that. and as we often lack enough time to build our own projects, we have even less time to spend figuring out other peoples' projects to rip them off.

##### Processing won't start! Nothing happens when I click “Run”!

Windows

- If you're using the "without Java" download, try downloading the version that includes Java. Chances are, your machine has another version of Java installed that is not supported. We only test with the version of Java that's included with the Processing download.
- Processing sometimes has trouble when run from a user account that contains non-ASCII characters. For instance, if your name contains umlauts or Japanese characters, it may not start, or may give errors whenever a sketch is run. The fix is to create a user account that uses only ASCII characters, but we're looking for a more permanent solution. Unfortunately it's taking a while because the US English version of Windows does not have this problem, and we don't own any international editions of Windows. (Bug 49)
- Try deleting your preferences file. On Windows XP this is located in Documents and Settings → username → Application Data → Processing → preferences.txt. On Windows Vista, it's in Users → username → AppData → Roaming → preferences.txt. Sometimes a bad preferences file can prevent the application from running. If you've recently hand-edited preferences.txt, that's also a likely suspect. Only delete the preferences file when Processing is not running. And do not modify the preferences.txt file inside the Processing "lib" folder.
- If you have lots of garbage in your CLASSPATH environment variable, that might cause trouble starting up a sketch. You might get "Couldn't find package xxx.xxx" errors. Clean things up by avoiding spaces and quotes. This is because of Windows' awesome hokiness and its not-as-distant-as-it-should-be ancestor DOS. In the future, we'd like to detect errors like this before they cause trouble. That issue is being tracked at Bug 112.
- Some graphics cards have conflicts with Java applications and therefore Processing, which can cause the application to hang or freeze. Under one scenario, disabling anti-aliasing on the card will get rid of these problems (Bug 232).
- If you're still having trouble, try disabling any overly protective virus scanning software. It might be holding things up, especially when libraries have been imported.

Mac OS X

- Processing requires Mac OS X 10.4 or later, see the platforms section for more information.
- First be sure that you're not trying to run Processing from the disk image. As with most programs, Processing needs to be copied to the Applications folder in order for it to run properly.
- If it's still not working, open Console.app, found in Applications → Utilities → Console and see if there are any messages. If you don't know what they mean, post them to the discourse board where someone can help you out.
- On startup, an error such as this one: (visible in Console.app)

      #
      # The exception above was detected in native code outside the VM
      #
      # Java VM: Java HotSpot(TM) Client VM (build 1.5.0_13-121, mixed mode, sharing)
      #
      /Applications/Processing 0123.app/Contents/MacOS/JavaApplicationStub:
      An unexpected Java error has been detected by HotSpot Virtual Machine:

  may be the result of a partially failed Java update. First try entering this with Terminal.app:

       /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Commands/java -version

  If that results in a message like:

      update_sharing command failed to execute

  followed by more text, then your install is messed up. To fix it, enter this:

       /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Commands/update_sharing 1.5

  and then try the -version command again. Hopefully, the "update_sharing command failed to execute" message will no longer be there, meaning that Processing and other Java applications should run again. (This problem was first tracked down here)
- Using developer releases of Java is strongly discouraged. These can often cause problems and we can't possibly support them.
- Fink users might see the following error:
  `dyld: /Applications/processing/jikes version mismatch for library:
  /sw/lib/libiconv.2.dylib (compatibility version of user:
  5.0.0 greater than library's version: 3.0.0)`
  It seems that this happens when an older version of Fink is installed. In this case, you should either update or uninstall Fink. (thanks to Ryan Govostes for tracking this down) As of release 0140, we're no longer using Jikes, so this problem has gone away.

Linux

See the Linux section for troubleshooting tips.

Any Platform

- Errors inside code that is outside of setup() or draw() may just hang/freeze Processing. For instance, with this code, if "blah.vlw" is not in the "data" folder, it may just hang:

        PFont font = loadFont("blah.vlw");

        void setup {
          // your awesome code
        }

  In general, a better practice is to use loadFont() (and loadImage and the rest) inside of a function like setup().

##### This used to work and now it doesn't

Read the changes section of the reference.

##### Export and Browser Troubles

Sketches (applets) often have trouble once exported that will cause errors in a browser.
To figure out what your problem is, you should first check the Java (not JavaScript!) console. On Windows, right-click the coffee cup at the right of the task bar, and select "Open Console". On Mac OS X, go to Applications → Utilities → Console.app and see what the last few error messages were.
The most common cause is a security issue. For details on how to avoid this, see this section of the reference. Java applets aren't allowed to do things like the following:

- Applets cannot open or write to files on the local machine. So things like saveFrame() will cause an error when run from an applet. To read files, make sure that you use "Add File..." to add the file to your sketch (or place it in the data folder yourself) so that it will be included when exported. Then, only use functions like loadStrings(), loadImage(), openStream(), etc. to read data from your file.
- Applets may not connect to servers other than the one from which they came. If you need to redirect things from another server, you can write a short script that will do it, understanding the possible security consequences for your own machine.
- Applets are also not allowed to do things like capture video or audio. You don't want a malicious applet that turns on your webcam and starts sending things back to their server.

Other issues:

- Another common problem is placing images or files into the sketch folder by hand, rather than placing them in the data folder (or using "Add File..." to do so automatically). This will work from the PDE, but on export, the files won't be in included with your sketch because they're not in the data folder.
- Watch out for issues with capitalization! Windows and Mac OS don't care about capitalization, so "blah.JPG" looks just the same as "blah.jpg". However, since most servers run on Unix, capitalization becomes a huge problem, because it must be exact. We've added some checks to try and catch this (at least for images) but they're not perfect. This can especially be a problem when the .JPG extension is not even visible (the default on Windows), so you don't know whether it's upper or lower case.
- If you get a "ClassCastException" when trying to run your code in a browser, you're probably trying to run non-Java 1.1 compliant code. This means any classes that didn't exist in java 1.1. Or, if if you're exporting as applet, variables that are 'final int' need to be 'static final int', otherwise they'll have trouble on a maching that only has Java 1.1 installed (i.e. running Microsoft's Java on Windows). You should also avoid using "final" variables inside of methods, since those aren't supported by Microsoft's VM (and that's the one most widely installed).
- Your browser may be using an old version of an applet. Unfortunately it's often difficult to get your browser to flush its cache. You may need to quit all instances of the browser, use alt-reload (or ctrl or shift or option, who knows) to get the new version to show up. On Windows, clicking the Java coffee cup at the right of the task bar can bring up a control panel that will let you flush the Java cache too. This is different across all platforms, but if someone wants to write a good explanation for any platform they're familiar with, please post on the discourse area of the site and we'll add it to the FAQ.

Some libraries simply don't work with the web (at least not for now):

- You cannot use the OpenGL library from the web. (Bug 166) As of revision 0113, it's possible for applets that use the OPENGL renderer setting to run from the web.
- The video library (both Capture and Movie) cannot be used on the web As of release 0115, it's possible to play back movies via the web, however you still cannot capture video without a signed applet (see above).

##### Out Of Memory Errors (java.lang.OutOfMemoryError)

If you get a OutOfMemoryError while running your program, use the Preferences window to increase the amount of available memory. Check the box next to "Increase maximum available memory" and enter an amount.
Depending on your OS and available RAM, there are limits on how much memory you can ask for.

32-bit operating systems and software are usually limited to addressing somewhere around either 2GB and 4GB of RAM at a time. This means that even if you have 8GB of RAM installed in your machine, you may only be able to use shy of 2GB per application. Most Windows systems seem to be limited to 2GB, while Mac OS X and Linux can usually access shy of 4GB. Upcoming 64-bit operating systems get around this restriction and increase the amount of available memory significantly. However, even if you're running a 64-bit OS like Mac OS 10.5, or a 64-bit Linux, a combination of factors (version of Java, etc.) may mean that you're still limited by the 32-bit boundary of 2GB or 4GB.

Use this preference with caution, because if you set the memory too high, programs will no longer run in Processing. When you hit run, you'll get error messages.
If this message appears after you hit Run, then you're trying to use more memory than the machine has installed:

    Error occurred during initialization of VM
    Could not reserve enough space for object heap

The following messages mean that you're trying to use more memory than the Operating System allows (regardless of how much RAM you have):

    Invalid maximum heap size: -Xmx5000m
    Could not create the Java virtual machine.

    Invalid maximum heap size: -Xmx5g
    The specified size exceeds the maximum representable size.
    Could not create the Java virtual machine.

On Windows with 1G of RAM, the limit seems to be in the neighborhood of 1.5 GB. Mac OS X and Linux seem to allow up to just shy of 4 GB, depending on how much RAM you have installed. Usually you can allocate almost 50% more RAM than you have installed. i.e. for a machine with 1 GB of physical memory, about 1.5 GB is the maximum that can be used. Your mileage will also vary with different versions of Java (1.3, 1.4, 1.5, 1.6...) and your operating system.
On the other hand, Java on Windows XP, for instance, cannot address more than 2GB properly. So with OS and JVM overhead, the total possible memory available is in the neighborhood of 1.5 GB (no matter how much RAM you have).
Unfortunately the memory limitations of Java set an upper bound that is outside our control. If you're having trouble creating very large images for this reason, you might look into the PDF or DXF libraries that are included with Processing, or the contributed Illustrator or SVG vector export libraries that can be found on the libraries page as another alternative for creating large format images.
Memory is like any constraint found in other media, you simply need to be more clever about how to deal with the limitations.
To check the amount of memory that's used so far, or how much is available, use Java's Runtime object:

    // The amount of memory allocated so far (usually the -Xms setting)
    long allocated = Runtime.getRuntime().totalMemory();

    // Free memory out of the amount allocated (value above minus used)
    long free = Runtime.getRuntime().freeMemory();

    // The maximum amount of memory that can eventually be consumed
    // by this application. This is the value set by the Preferences
    // dialog box to increase the memory settings for an application.
    long maximum = Runtime.getRuntime().maxMemory();

There are also some known bugs that eat memory that can be found in the bugs database.

##### Why don't these Strings equal?

Comparing a string (quoted text) is different in Processing (Java) than it is in ActionScript, which often confuses people. For instance, while this might make sense:

    String[] lines = loadStrings("sometext.txt");
    for (int i = 0; i < lines.length; i++) {
      if (lines[i] == "hello") {
        println("hello found on line: " + i); // you'll never see this
      }
    }

You'll never see the message, even if "hello" is in the list. This is because a String is an object in Java, comparing them with == will only compare whether the two things are pointing at the same memory, not their actual contents. Instead, use equals() or one of the other String methods:

    String[] lines = loadStrings("sometext.txt");
    for (int i = 0; i < lines.length; i++) {
      if (lines[i].equals("hello")) {
        println("hello found on line: " + i); // happiness
      }
    }

##### Why does 2 / 5 = 0 instead of 0.4?

The result of dividing two integers will always be another integer:

    int a = 2;
    int b = 5;
    int result = a / b;
    // result is zero

While somewhat confusing at first, this is later useful for more advanced programming.
To get fractions, use a 'float' instead:

    float a = 2.0;
    float b = 5.0;
    float result = a / b;
    // 'result' will be 0.4

It is not enough to just divide two integers and set them to a float:

    float y = 2 / 5;

In this case, integer 2 is divided by 5, which is zero, and then zero is assigned to a float. The number doesn't become a float until the lefthand side of the = sign. On the other hand, this:

    float y = 2.0 / 5;

will work just fine. In this case, Java sees that 2.0 is a float, so it also converts the 5 to a float so that they can be divided, which makes it identical to:

    float y = 2.0 / 5.0;

and because floats are being used on the righthand side, the result will be a float, even before it gets to the lefthand side.

##### Problems with Video

See the Video library reference

##### Problems with the Serial Port

See the Serial library reference

##### Problems with OpenGL

See the OpenGL library reference

##### Common Issues (not bugs)

Things that are often perceived as bugs, but aren't actually 'broken'.

- If your code has methods (it's not just in static mode) or needs to run over time, it must have a draw() method, otherwise nothing will happen. For instance, without a draw(), this code will stop after the setup() method:

      void setup() {
        size(400, 400);
      }

      void keyPressed() {
        println(key);
      }

- An UnsupportedClassVersionError means that you're using code that was compiled for a later version of Java than is supported by Processing. As of release 0136, Processing supports Java 1.5. A message like

       java.lang.UnsupportedClassVersionError: (Unsupported major.minor version 50.0)

  means that the code was compiled for Java 1.6, which is not currently used with Processing.
- Any code that accesses the pixels[] array should be placed inside `loadPixels()` and `updatePixels()`. This can be confusing because it was not required in older code, i.e. with alpha releases of Processing prior to release 0085. Strictly speaking, it's also not necessary for P3D (or the forthcoming P2D), but is required for the JAVA2D (default) and OPENGL renderers. It's best to simply get in the habit of using load/update in your programs. A complete description can be found in the reference for the pixels[] array.
- PSound has been removed as of release 0112. Getting sound to work with Java is a total headache, and therefore something better left to a library. We recommend using the Minim library.
- Unless you know what you're doing, you should not have a method in your sketch that's called run() (with no parameters, at least). This will break your sketch. Unfortunately, we can't explicitly disallow it, because some advanced programmers may need to write their own run().
- Why doesn't saveFrame (or saveStrings or saveBytes) write things to the data folder? All saveXxxx() functions use the path to the sketch folder, rather than its data folder. Once exported, the data folder will be found inside the jar file of the exported application or applet. In this case, it's not possible to save data into the jar file, because it will often be running from a server, or marked in-use if running from a local file system. With this in mind, saving to the data path doesn't make sense anyway. If you know you're running locally, and want to save to the data folder, use `saveXxxx("data/blah.dat")`.
- Objects with alpha (lines or shapes with an alpha fill or stroke, images with alpha, all fonts) are displayed in P3D and OpenGL based on their drawing order. This creates some annoying effects like making things opaque if they're drawn out of order with objects above or beneath them. This is simply how most 3D rendering works, but is something that we'd like to hide from users in the future. As of revision 0114, the situation can be improved by adding `hint(ENABLE_DEPTH_SORT)` to setup(). However, the implementation is far from perfect. It may improve things or it may not, better support will arrive in a future release. (Bug 176)
- Names of sketches cannot start with a number, or have spaces inside. This is mostly because of a restriction on the naming of java classes. I suppose if lots of people find this upsetting, we could add some extra code to unhinge the resulting class name from the sketch name, but it adds complexity, and complexity == bugs. :)
- Mind the capitalization of built-in functions. If a method or variable name is two words, usually the first word is lowercase and the first letter of the second word will be capitalized. For instance: keyPressed, movieEvent, mouseX, etc. If you have a function called mousepressed(), it won't be called when mouse events occur, because it needs the capital P on 'pressed'.
- On Mac OS X, the error message: `## Component Manager: attempting to find symbols in a component alias of type (regR/carP/x!bt)` is not something from processing, it is a bug in Roxio Toast 5.2's Video CD Support extension. To suppress the messages, move "Toast Video CD Support.qtx" out of /Library/QuickTime (at least until you need to do Video CD work).
- On Windows, sometimes your programs will run in a window that has a Java coffee cup icon, instead of the usual Processing icon. This simply means that the application is being run outside of Processing as an external application. This happens when extra libraries, multiple source code files (more than one tab), or extra code files in the 'code' folder are employed.
- As of release 0116, Processing sketches have a default frameRate setting of 60. This prevents sketches from needlessly running too fast and throttling the CPU. However, this is only the "maximum" frame rate, if a lot of computation is in the code, the sketch will attempt to use as much CPU as is available. On Windows, this can sometimes cause audio hiccups when an MP3 player is running at the same time, or another application is trying to do something simultaneously. To fix the audio issue, add a delay(5) or delay(10) to your code, which will give five or ten milliseconds to other applications so they can breathe. For other applications, you may have to set the frameRate() lower, or use a longer delay().
- If your sketch is based on "Java mode", where you explicitly say that the class extends PApplet, then the preprocessor assumes that you know what you're doing. You'll have to make sure that your code is named properly. This means that if you have "public class PooTime extends PApplet" at the beginning of your sketch, you bet your a-- the tab will need to be named PooTime. If not, your code isn't gonna run. I mean, c'mon... You know what you're doing, right? This is also true when exporting to an application.
- Don't name your sketch the same thing as a library or other class that's used in your sketch. For instance, your sketch shouldn't be named "Server" if you've imported the net library, because it already has something called Server. You can be more creative than that.

##### Things that we probably can't fix

Some things are out of our control, or not actually bugs...
All Platforms

- A long sketch menu that goes off the edge of the screen? Doesn't scroll properly? There's not much we can do. This is a java issue which happens on most platforms. To get around it, you can organize your sketches into subfolders which will appear as submenus (be sure to quit before reorganizing, and then restart when finished). (Bug 391)
- If you're seeing a `sun.dc.pr.PRException`, it's because you're trying to draw something that's waaaaay off screen (like an x coordinate of -100,000 or something nutty like that). (Bug 104)

Windows

- The system clock sometimes goes weird, especially when using frameRate() or delay(). This is a long-standing bug with the Windows version of the Java VM. According to someone on the sun site: This bug has been fixed in bug no 4500388 and one requires a PRODUCT FLAG to use the fix. This flag and fix are available in 1.3.1_4, 1.4.0_2, 1.4.1 and 1.4.2. But for Java to actually use the fix:
  Open your Java Plug-in Control Panel in the section 'Java Runtime Parameters' just enter: -XX:+ForceTimeHighResolution
- Create Font sometimes crashes on Windows, bringing down the whole environment. This seems to be a Java bug, because it's not a Java exception, but a full crash. (Bug 99).
- An error starting with `"hs_err_pid10XX.txt"` sometimes shows up. This is something within the Sun's Java VM that we can't fix. It's not clear what the problem is, but it seems to have shown up with Java 1.4.

Mac OS X

- An error that reads something like `2005-05-19 14:20:44.209 java[875] _initWithWindowNumber: error creating graphics ctxt object for ctxt:72059, window:26969` is a known bug in Apple's Java implementation. (Bug 53)
- Sometimes something like the following will come up: `*** malloc[438]: Deallocation of a pointer not malloced: 0xffffffff; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug` it seems to be a bug in Apple's OS X Java. It doesn't appear to hurt anything but there also doesn't appear to be anything we can do to fix it. (Bug 52)

Linux

- The following message (or messages like it) on startup: `Warning: Cannot convert string "-b&h-lucida-medium-r-normal-sans-*-140-*-*-p-*-iso8859-1" to type FontStruct`. This is just a Java issue, but doesn't seem to affect anything.

##### Known Issues

This section is incomplete, but contains some links to the bug database's Greatest Hits collection.
Automatically updated list of new and confirmed bugs. These are the things that are on our radar to be fixed. (That list does not include feature requests or things slated for a much later release). And of course, if these and others give you a burr in the saddle, join us and help!

- Sketches that size(w, h, OPENGL) and do not clear the background on each frame can cause major flickering or problems when the screen clears anyway. There are several possible solutions:
  1. You may need to disable the default 2x smoothing by using `hint(DISABLE_OPENGL_2X_SMOOTH).`
  2. Update the drivers for your graphics card.
  3. Get a decent graphics card — the OpenGL renderer is for advanced use, we don't support using it with cheaper built-in graphics hardware like the Intel GMA 950.
  4. If you're running Windows Vista, try disabling the Aero theme.
  This flickering issue is being tracked here.
- On some Windows machines, parts of the user interface (menus, buttons, etc) are mangled, or other strange artifacts show up when using Processing 1.0. The issue is being tracked here, and is a result of bad interactions between Java 6 update 10 and some graphics hardware.
- "An error occurred while starting the application" when launching Processing.exe on Windows. We think we've found the problems causing this error in releases 1.0.1 and 1.0.2, but if you find it again, please file a report in the bugs database.
- With P2D, P3D, and OPENGL, series of connected lines (such as the stroke around a polygon, triangle, or ellipse) produce unattractive results when strokeWeight is set. (Bug 955)
- Unlike most applications, the menu bar is inside the editor window when Processing is used with Mac OS X 10.5. This is a workaround for an Apple bug in Java 1.5 and 1.6 on Mac OS X 10.5 that causes the menu bar to be so excessively slow that the application appears to have crashed. (Bug 786)
  Please file a bug report with Apple at bugreporter.apple.com if you want this fixed. The problem has existed since the spring 2008, and we first filed a bug with them in June, and we have received no indication that it when it will be fixed, or if it will ever be fixed.
  Or if you want to take your chances with the slow menu bar, you can change the default setting in the Preferences window.
- Due to what appears to be (another) bug in Apple's Java implementation, the point() and set() methods are extremely slow in some circumstances when used with the default renderer. Using P2D or P3D will fix the problem. Grouping many calls to point() or set() together can also help. (Bug 1094)
- Sketches that use the video library plus OpenGL have a problem on some OS X machines. The workaround is listed here.
- Command line support arrived in a recent release, but is not working yet. (Bug 1048)
- OpenGL rendering is more dim/darker in release 0149 and later (Bug 958). Any help tracking this down would be most appreciated. Fixed for 1.0.2 with help from Dave Bollinger. Thanks, Dave!
- The first few frames of OpenGL sketches on Windows run slowly. (Bug 874)
- When used with P3D, strokeWeight does not interpolate the Z-coordinates of the lines, which means that when rotated, these flat lines may disappear. (Since, uh, lines are, you know, flat.) The OPENGL renderer setting does not share this problem because it always draws lines perpendicular to the screen (which we hope to do in a future release). (Bug 956)
- int() and float() don't always work, use ((int) blah) or ((float) blah) instead for the time being, or parseInt(blah) and parseFloat(blah). (Bug 4)
- When you have too many tabs, things get ugly (Bug 54)
- Error messages after you hit Run are often too long to read or too weird to understand (Bug 57)
- Lots of little UI things like proper key shortcuts (Bug 26 and many others)

##### Supported Platforms

The Processing Development Environment (PDE) is currently tested on:

1. Mac OS X 10.5 (Intel only, no PowerPC)
2. Mac OS X 10.6
3. Windows XP (latest service pack only)
4. Windows 7 (32-bit, limited testing on 64-bit)
5. Ubuntu Linux 9.04 (on i686 and x86_64)

These are the operating systems that are on machines at the Processing Release Testing And Quality Assurance Center (the PRTAQAC, which bears a suspicious resemblance to Ben's apartment). Builds usually get the most testing on OS X 10.4. If you run into trouble, you've gotta let us know, the PRTAQAC is badly understaffed.

##### Windows

Windows, and to a lesser extent, Linux, are by far the superior platform for running Java applications. It's not because we like Windows (we don't) but that's just how it is.
We are not supporting or testing with Windows Vista. We're going straight from Windows XP to Windows 7.
Until further notice, using 64-bit Windows is strongly discouraged. Bugs with 64-bit versions of Windows will have an extremely low priority.
The release is split into versions with and without Java. The non-Java version is only recommended for people who know what they're doing and have JDK 1.5 installed. If you have trouble getting Processing to run properly, one of the first things you should try is downloading the version that includes Java, rather than the one without.
If Processing does not start, try running it from a command prompt with the following:

    .\processing.exe --l4j-debug

This will create a launch4j.log file which will describe what's happening during the startup. Then you can post on the discourse section of the site to inquire for help, or the bugs database if you think it's a bug.
It's not possible to use Processing with Windows 98, ME, or 2000. Recent Server editions are not supported, though they should work. 64-bit versions of Vista or XP will likely work but we don't have resources to test and debug for them.

##### Mac OS X

Java on Mac OS X has always dragged behind other platforms. Unfortunately Apple management seems to have a completely arrogant attitude about Java and wants developers to build their applications using Cocoa, seemingly unaware of their current marketshare. For best performance, use Processing with Windows.

- If you're having trouble with Mac OS X, check the console. It's found in Applications → Utilities → Console.app. Information posted there may tell you what the problem is, or provide an error message that someone (perhaps from the discourse section of the Processing site) can help with.
- Processing requires OS X 10.5 or later. It may run on 10.4, but we won't be fixing bugs with OS X 10.4, because we only have so much free time.
- Processing is no longer supported PowerPC machines. I've sold my PowerPC Mac, and you should too.
- When using OS X, it's common to get errors in the console that read something like:
  `2006-03-30 15:27:47.118 java[1170] CFLog (0): CFMessagePort: bootstrap_register(): failed 1103 (0x44f), port = 0x11303, name = 'java.ServiceProvider'
  See /usr/include/servers/bootstrap_defs.h for the error codes.
  2006-03-30 15:27:47.119 java[1170] CFLog (99): CFMessagePortCreateLocal(): failed to name Mach port (java.ServiceProvider)`
  This is an Apple bug that shows up any time that more than one instance of Java is running. It's bizarre that they haven't fixed this issue.
- The ever-popular Sonia library needs an update for the new version of jSyn that is a Universal Binary. This can be found on the jSyn site. The default Sonia download includes the PowerPC-only version of jSyn.

More information about Java on OS X can be found at Apple's Java FAQ.

##### Linux

On Linux, the Processing application is just a shell script. If you set up a launcher (e.g. in Ubuntu), be sure to set the working directory to the folder that contains the shell script. It's not smart enough to find its own path. (If you can write a version that's smarter, please let us know).
Most problems on Linux come from the version of Java that's included in the download being incompatible with the OS. Replacing (or making a symlink to) the contents of the ‘java’ folder will let you tie in a preferred Java VM for your machine. This must be a symlink to a full JDK, not a JRE. Be sure that the symlink is set up relative to the ‘processing’ shell script such that ./java/bin/java points to the ‘java’ binary.
Note that the GNU Classpath, GCJ, GIJ combination will not work with Processing. You'll need a regular Java release downloaded from Sun. OpenJDK and IcedTea are also unlikely to work, however we'll update this as those projects progress.
If you get Processing to run properly, the Sketch → Show Sketch Folder command may not be available. Processing will attempt to find kde-open and gnome-open, and if neither is available, the menu item will be dimmed. To fix this, you must set a launcher for your platform. Add a line to ~/.processing/preferences.txt that specifies its location:
`launcher.linux = /path/to/launcher_app`

##### Other Platforms

Because Processing is written in Java, it should run on any platform that supports Java 1.5. If you'd like to get it running on BSD, Irix, AmigaOS, BeOS... whatever, do the following:

1. Download the Linux version, and replace the “java” folder and jikes application with versions that support your platform. The files can by symbolic links to your Java Runtime installation (note how the folder hierarchy works to make sure you're linking the right thing) or Jikes executable.
2. Next, mess with the shell script if necessary to get things up and running.
3. If you have success, share the details for others.

##### Java Versions

There are several versions of Java, each with a different story. The versions from 1.2 to 1.4 are also referred to with names like "Java 2 SDK 1.2" or "J2SE 1.4" (Java 2 Standard Edition 1.4). J2SE is different from the trimmed-down J2ME ("Micro Edition") which runs on mobile devices, and J2EE ("Enterprise Edition") which contains more "enterprise" related bloat. In a moment of further anti-user marketing genius, Sun decided to call the next release "Java 5.0" when promoting, but it's Java 1.5 to developers. Proving that they could outdo themselves in idiocy, the release that followed is called JDK 6.

- Java 1.5 is required to run the Processing Development Environment and projects created with Processing.
- It is not yet possible to use any of the new syntax introduced in Java 1.5 within Processing, even if you have 1.5 installed (the preprocessor and compiler used by Processing don't understand the 1.5 syntax). This includes the enhanced "for" loop, templates, generics, enums, varargs, and lots of other crap that Sun added because they felt that the older syntax was too simple and usable. A couple of these features are very useful (the for loop, some aspects of generics) so if you would like to help get things running with 1.5 syntax, please help us fix things. More information cane be found here.
- We will not be moving to Java 1.6 anytime soon because of Apple's lack of support for Java, and half our users are on Macs. (Releasing Java 1.6 two years later and only for 64-bit Intel machines running OS X 10.5.2 does not count as support). If this bothers you a fraction of as much as it annoys us, please complain to Apple.
- If you get an UnsupportedClassVersionError when using a library or other Java code, that means the code was compiled for a later version of Java than is supported by Processing. Recompile this code with an earlier Java release and you should be all set.