No workaround exists -> P2

I had the same problem yesterday and it was caused by a mismatch in
the execution settings. Basically the executor for the class itself
(which was a default setting) did not exist (I think it read
JavaExternalExecutor) but the entry in the options window was labelled
External Execution. After changing the executor for the class in
question everything worked fine.

Sounds to me like a bug in settings, not the compiler itself nor the
Java module. Just a guess. As I mentioned on nbusers, if you create an
executor with the correct cwd and assign it, all is well, so it is
probably ExecSupport getting some bogus object?

Honza, please have a look

[200111270100]
Jesse is right. There is some strange behavior of settings.
1. Set Working Directory for External Execution to c:\temp
2. execute
public class Main {
    public static void main (String args[]) {
       java.io.File f = new java.io.File("");
       System.out.println(f.getAbsolutePath());
    }
}
3. It prints $IDE_HOME/bin
4. set Executor of Main to Internal Execution and then back to 
External Execution.
5. execute Main again -> It prints c:\temp

Target milestone -> 3.3.1.

I think the setting support is innocent at least in this case ;-)

The culprit is JavaSettings class. Because it doesn't initialize a 
value  for the property PROP_EXECUTOR. If SystemOption doesn't find 
any assigned value it uses getter method when writing data down. But 
getExecutor returns Executor instead of ServiceType.Handle as it is 
assigned to PROP_EXECUTOR. So if JavaSettings are deserialized wrong 
executor is used (not from ServiceType.Registery).

I would propose to add following method to JavaSettings:
protected void initialize() {
 super.initialize();
 putProperty(PROP_EXECUTOR, new ServiceType.Handle(getExecutor()), 
false);
}

Unhappily it seems it affects more system options (AntSettings,...). 
Here is some kind of general workaround: it should be sufficient to 
check and use if not null the property value again after calling given 
getter in SystemOption.writeExternal. It is common way to initialize 
value to default in getters.

Any opinion, objection?

I object to the proposed workaround. What if a getter is written like
this?

Executor getFoo() {
   ST.H handle = getProp(PROP_FOO);
   if (handle != null) {
     return (Executor)handle.getServiceType();
   } else {
     return Executor.getDefault();
   }
}

The SCO property PROP_FOO will never be stored unless you call
setFoo(), getFoo() will not do it. So the workaround just defers the
problem to a smaller set of cases and makes the bug even harder to
guess the reason for.

It looks to me that JavaSettings is simply wrong and the bug is there.
SystemOption behavior is that the getter/setter will be used unless
the SCO prop exists and is not of the type given by the bean property.
Since JS initially leaves the SCO prop null, it is unable to guarantee
this and so its storage using SCO props is not guaranteed.
JS.initialize() should be fixed (according to the code snippet Jan
suggests) to store the proper default value as a handle, IMHO.

fixed in trunk, getter and setter for Executor and Debugger changed to
match getter and setter for Compiler property 

Checking in JavaSettings.java;
/cvs/java/src/org/netbeans/modules/java/settings/JavaSettings.java,v 
<--  JavaSettings.java
new revision: 1.48; previous revision: 1.47
done

fixed in release33 branch

Verified in [200111300330]

Workaround exists. See above comment from Jan Becicka dated 2001-11-27
04:47 PST. Decreasing priority.

[200201090331] Verified

Resolved for 3.4.x or earlier, no new info since then -> closing.