I suspect the issue is the same as with 6.5.1, see http://www.netbeans.org/issues/show_bug.cgi?id=167188
Don't know if the scripting-api.jar is still included with 6.7 though since I'm using 6.5.1

*** Issue 167268 has been marked as a duplicate of this issue. ***

Please review the patch for jsr223.jar

ScriptEngineManager.java
136a137,146
>                 } catch (UnsupportedClassVersionError err) {
>                     if (DEBUG) {
>                         err.printStackTrace();
>                     }
>                     continue;
>                 } catch (NoClassDefFoundError ncdfe) {
>                     if (DEBUG) {
>                         ncdfe.printStackTrace();
>                     }
>                     continue;

Verified in custom build by QE, please transplant into release_67.

Fixed in core-main and release67.
http://hg.netbeans.org/core-main/rev/2c89ca25465f
http://hg.netbeans.org/release67/rev/f5e6c212c0fb

The patch does not explain what was really wrong on the Mac. A full explanation belongs here in IZ.

Would this be better fixed by adding to libs.jsr223/manifest.mf:

OpenIDE-Module-Hide-Classpath-Packages: javax.script.**

?

Integrated into 'main-golden', will be available in build *200906190201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/2c89ca25465f
User: Milan Kubec <mkubec@netbeans.org>
Log: #167240: catching and ignoring NCDFE in javax.script.ScriptEngineManager

The problem on Mac is that JDK 5 and JDK 6 both see /System/Library/Java/Extensions/AppleScriptEngine.jar and this jar
when NB scripting module (running on JDK 5) wants to load all impls. for javax.script will be loaded by boot
classloader, but this classloader cannot see javax.script package on JDK 5 because only NB module classloader can see
it. We already had this problem, but it was manifested by "UnsupportedClassVersionError: Bad version number in .class
file" (see issue #129227), because that jar was compiled by JDK 6, so out first fix was to ignore that error. With
recent JDK update this jar has been updated but this time already compiled by JDK 5, so our catch stopped working, so I
added other catch, this time for NCDFE.

I cannot say whether "OpenIDE-Module-Hide-Classpath-Packages: javax.script.**" in manifest would fix the problem.

Sources for the javax.script are on http://libs.netbeans.org/servlets/ProjectDocumentList

Patch file for these sources will be attached.

Created attachment 83790 [details]
Patch

Created attachment 83791 [details]
jar file with the fix (platform/modules/ext/script-api.jar)

Attached patch file contains also change already applied when fixing issue #129227.

Verified in release67 build by QE.

Please at least try OIDE-M-H-C-P to see if it works. This would seem to me a cleaner fix than patching the Script API JAR.

The effect would be for NB's module class loader to ignore the specified packages if they happen to be on the
bootclasspath, always using its own. From your description perhaps what you really want is to also/instead ignore the
packages contained in AppleScriptEngine.jar, whatever those are.

From your description it would probably work, but I don't know if it's what we want to do. The fix you are proposing
would change also loading of scripting frameworks for JDK 6 and above and I'm not sure we want to do it. 

The fix is only because of JDK 5, but it will reach its End of Service Life on October 30th, 2009. So it's highly
probable that we won't support JDK 5 after this date.

Yes, of course when we drop JDK 5 support then we can simply delete libs.jsr223, so it will no longer be an issue.

> Please at least try OIDE-M-H-C-P to see if it works.

I can bet five beers that it does not work.

*** Issue 167617 has been marked as a duplicate of this issue. ***

*** Issue 167685 has been marked as a duplicate of this issue. ***

*** Issue 167722 has been marked as a duplicate of this issue. ***

*** Issue 168645 has been marked as a duplicate of this issue. ***

One of the things that occurs to me, is that perhaps there is not the correct classloader mechanisms involved here.  The
Jini platform, along time ago, starting providing the PreferredClassLoader and PreferredClassProvider (for the SPI) that
allows jar files to contain META-INF/PREFERRED.LIST as a list that indicates preferred packages and classes.  What this
provides, is the ability for a jar to substitute "working" for "broken" platform classes so that the jar can guarantee
that it gets the correct version of a class that it knows will provide the proper implementation.

This really helps tremendously in making sure that platforms are platforms and that impls can be provided for particular
Jars to use so that things that are not shared beyond a particular class loader root can be provided by jars that need
specific implementations with no worries about class name conflicts.

This would also help compartmentalize the platform module mechanism to allow modules to truly be standalone.

What greggwon describes is essentially OpenIDE-Module-Hide-Classpath-Packages, I think. We decided that we will not
bother with this since the issue becomes moot once JDK 5 support is dropped.

*** Issue 168719 has been marked as a duplicate of this issue. ***

*** Bug 184986 has been marked as a duplicate of this bug. ***