Very low priority bug, but I'll report it anyways - I'm reporting this as
an OS X bug because that's the only place it's shown up for me.

Sometimes I've used Processing to drive Applescript calls on OS X, and the
first step there is to "import com.apple.cocoa.foundation.*;"

This used to work (as of at least 0142), but somehow the way the linking
works now, I get "The package com.apple.cocoa does not exist. You might be
missing a library." along with a message about how now libraries must be
put into the "libraries" folder in the sketches folder.

As far as I know, the com.apple.* hierarchy is "built in" on OS X, not a
dependency that you need to manually link up/drop in (at least in Eclipse
you don't need to do anything at all to get to it). I'm not sure if
there's a simple solution here, but something must have changed between
0142 and 0159 so that these classes are not seen anymore.

I removed the Apple Java extension paths from the Info.plist because they caused more problems than they helped: random versions of jogl or antlr installed there were horking up the app. Of course that has a downside, though in this particular case, all those Apple Cocoa classes are deprecated so I'm disinclined to change it.

k, np - I can easily work around it on the rare occasion that I need to (I
hate Applescript anyways, but it's sometimes the lowest fuss way to make
other apps do things in response to Processing code), just wanted to make
sure there was a good reason this happened.

Right, thanks for the report since it's this sort of thing that we need to
track with the 1.0 release being right around the corner.

Also fwiw, you can use exect() to call osascript (command line, see 'man
osascript') to execute applescript code and talk to other apps. osascript
shows no signs of disappearing and might be a bit less fragile as well.