Bug 47645

Only if you set the 'permissions' attribute, I presume.

Sorry, there is no way to fix this currently; <java fork="false"
permissions="..."> as implemented is simply incompatible with Ant
being run in a container, as it assumes it can set the security
manager for the whole VM. Would need a new API in Ant to permit a
container to manage permissions on behalf of Ant, by temporarily
registering lists of permissions with the active thread.

Ant's Permissions has methods setSecurityManager and
restoreSecurityManager, but these are inherently unsafe, as the
security manager is VM-global and Ant is generally running in only one
thread group, while other activity may be occurring in other thread
groups. (Including other Ant runs - and since Permissions does not
include checks for overlapping dynamic scopes, it is possible for
P1.sSM to run, followed by P2.sSM which remember's P1's SM, followed
by P1.rSM which restores the original SM, followed by P2.rSM which
installs P1's now-obsolete SM for the whole VM, causing who knows what
kind of damage!)

Workarounds: remove the explicit permissions, if that is safe; or run
the commands forked, if that is possible.

There are no 'permissions' attributes set for these tasks.  Just
straight java invocations of a class which generates source code based
on the arguments passed.

In that case can you please attach a complete test case to reproduce
the problem, including any Ant script and any source files or data it
may need to run, and reopen? The smaller the better, but anything that
can be reproduced from scratch works.

Created attachment 17056 [details]
test case

attached reproducible test case... run default ant target from within 
netbeans, get securityException... run from commandline, builds 
successfully

BTW for the future please avoid unusual packaging formats such as
RAR... I did manage to find a Linux unpacker for it that seems to
work, but ZIP is much more universal (especially in the Java world).

Yes, I can reproduce with your script.

Turns out setting failonerror='true' also forces there to be a
security manager, just like setting explicit permissions. (Since it
needs to trap System.exit.)

I will make a note to file a patch for Ant, perhaps it will be
possible to get this fixed in a future Ant release.

Keeping open since it may be possible to fix using a future version of
Ant, TBD.

This should be mentioned in release notes that it's not possible to
run target with <java> task that has 'failonerror=true' inside IDE.
The same script runs without problems outside of IDE. There is not
workaround in IDE, user has to rewrite the script (change semantics)
or run the script  from command line.

Workaround (other than setting fork="true" on <java>): create a
separate build script that forks a new copy of Ant that you point to
from a freeform project.xml, or you can even put this stuff in the
regular build script if you want. Example contents:

<macrodef name="forkant">
    <element name="args" implicit="true"/>
    <sequential>
        <java classname="org.apache.tools.ant.Main" fork="true"
failonerror="true">
            <classpath>
                <fileset dir="${ant.home}/lib">
                    <include name="*.jar"/>
                </fileset>
                <!-- Path may need tweaking on non-Sun JDKs: -->
                <fileset dir="${java.home}/../lib">
                    <include name="*.jar"/>
                </fileset>
            </classpath>
            <arg value="-emacs"/> <!-- needed for err hyperlinking -->
            <arg value="-f"/>
            <arg file="build.xml"/> <!-- or whatever it is -->
            <args/>
        </java>
    </sequential>
</macrodef>
<target name="run"> <!-- example delegating target -->
    <forkant>
        <arg value="run"/>
        <!-- can also add delegate properties, e.g.
        <arg value="-Dsomething=${something}"/>
        -->
    </forkant>
</target>

Cumbersome, and output formatting is slightly different than for in-VM
Ant, but should allow you to run those scripts which would conflict
with the IDE's runtime, without physically leaving the IDE, and while
still getting IDE error hyperlinking and so on.

Note that in-VM special tasks such as <nbbrowse> and <nbjpdastart>
cannot be placed in the delegated-to script, since that will be in
another VM; but you can keep those tasks in the initial script and
still delegate to another script in another VM for the rest of the build.

If there is a workaround, it is likely not P2? Downgrading to P3.

Will be worse with Ant 1.7 unless addressed:

http://issues.apache.org/bugzilla/show_bug.cgi?id=33361

Cf. Ant bug:

http://issues.apache.org/bugzilla/show_bug.cgi?id=34229

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

NB 6.0 has a custom <java> task impl anyway (from the fix of issue #56341), so I have set this to always run with
fork="true". This prevents the SE from being thrown. It can change semantics a bit but I think in most cases people
either omitted fork="true" out of forgetfulness (false is the default for historical reasons), or were just adding it
for a minor performance optimization (skips process spawn overhead). For these cases, people should see a fix. For
people who really wanted fork="false" (typically to use <permissions>), this was never working inside NB anyway, so the
fix should make things no worse.

Checking in ForkedJavaOverride.java;
/shared/data/ccvs/repository/ant/src-bridge/org/apache/tools/ant/module/bridge/impl/ForkedJavaOverride.java,v  <-- 
ForkedJavaOverride.java
new revision: 1.4; previous revision: 1.3
done