swing app with JVM arguments

[kazoobrewer]

I'm running a swing application with WindowTester, and the recorder seems to be ignoring JVM and application arguments. Am I missing some required configuration?

Details:
Eclipse 3.5.1 Galileo on Windows
WindowTester components are version 6.0.0.r35
Project runtime JRE: 1.6.0_20

In the Record Configurations dialog, I have the following for my launch configuration:
Program Arguments:
-debug

VM Arguments:
-Xmx512m -Djava.library.path=./libraries -Djava.security.manager -Djava.security.policy=./java.policy
-Dsun.awt.disableMixing=true

Output from the first line of main shows no program arguments:
public static void main(String[] args) {
System.out.println("main: " + args.length);
...
gives output:
> main: 0

and I'm getting security errors suggesting VM args are also being ignored. The initial console output from WindowTester is:

Configuration location:
file:/C:/workspace/.metadata/.plugins/org.eclipse.pde.core/tmp_workbench_launch_config/
Configuration file:
file:/C:/workspace/.metadata/.plugins/org.eclipse.pde.core/tmp_workbench_launch_config/config.ini loaded
Install location:
file:/C:/eclipse/
Framework located:
file:/C:/eclipse/plugins/org.eclipse.osgi_3.5.1.R35x_v20090827.jar
Framework classpath:
file:/C:/eclipse/plugins/org.eclipse.osgi_3.5.1.R35x_v20090827.jar
Debug options:
file:/C:/workspace/Project/.options not found
Time to load bundles: 18
Starting application: 20371

[keertip]

This should not be the case. Will look into this and see if we can reproduce this issue at our end.

[kazoobrewer]

A little more investigation:

It appears that the program argument "-debug" is eaten, but if the argument is something else, it's passed on. So a small annoyance, but not critical.

VM arguments appear to work in general--I can check defined system properties. Not sure why I'm getting the security errors (the defined policy file does a grants java.security.AllPermission for the development environment). They look like this:

java.lang.IllegalAccessError: class sun.reflect.GeneratedSerializationConstructorAccessor4 cannot access its superclass sun.reflect.SerializationConstructorAccessorImpl
class sun.reflect.GeneratedSerializationConstructorAccessor4 cannot access its superclass sun.reflect.SerializationConstructorAccessorImpl

during a routine deserialization, and

java.lang.ExceptionInInitializerError
Caused by: org.apache.commons.logging.LogConfigurationException: java.lang.IllegalAccessError: class sun.reflect.GeneratedConstructorAccessor16 cannot access its superclass sun.reflect.ConstructorAccessorImpl (Caused by java.lang.IllegalAccessError: class sun.reflect.GeneratedConstructorAccessor16 cannot access its superclass sun.reflect.ConstructorAccessorImpl)

when creating a commons LogFactory. I'm also getting NoClassDef errors initializing a commons HttpParser, so there may be something afoot with classpaths...

[keertip]

Would it be possible to modify your application to print out the classplath? That way you could check if the classpath is missing something while recording.