Community
Participate
Working Groups
In the following build output: http://fullmoon/eclipse/downloads/drops/N20060221-0010/testresults/consolelogs/macosx.carbon_consolelog.txt There are a large number of NPEs. These are caused by EclipsePreferences.put being called with a null parameter. Full stack trace: java.lang.NullPointerException at org.eclipse.core.internal.preferences.EclipsePreferences.put(EclipsePreferences.java:758) at org.eclipse.jdt.internal.core.JavaModelManager$EclipsePreferencesListener.preferenceChange(JavaModelManager.java:1006) at org.eclipse.core.internal.preferences.EclipsePreferences$2.run(EclipsePreferences.java:746) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.core.internal.preferences.EclipsePreferences.firePreferenceEvent(EclipsePreferences.java:749) at org.eclipse.core.internal.preferences.EclipsePreferences.put(EclipsePreferences.java:762) at org.eclipse.jdt.internal.core.JavaModelManager.variablePut(JavaModelManager.java:3918) at org.eclipse.jdt.internal.core.JavaModelManager.updateVariableValues(JavaModelManager.java:3810) at org.eclipse.jdt.core.JavaCore.setClasspathVariables(JavaCore.java:4306) at org.eclipse.jdt.core.JavaCore.setClasspathVariable(JavaCore.java:4271) at org.eclipse.jdt.core.tests.model.ClasspathInitializerTests$DefaultVariableInitializer.initialize(ClasspathInitializerTests.java:44) at org.eclipse.jdt.core.tests.model.VariablesInitializer.initialize(VariablesInitializer.java:43) at org.eclipse.jdt.core.JavaCore.getClasspathVariable(JavaCore.java:1584) at org.eclipse.jdt.core.tests.model.ClasspathInitializerTests.testVariableInitializer11(ClasspathInitializerTests.java:898)
Fixed and released in HEAD. To avoid polluting messages in console, I added a null check on option value before reset it. Olivier, if you have any time, I will be really interested in having feedback on reason why property value is null only on Mac/OS box, TIA
Changing title since this is not related to Mac. Same errors occur on Windows and Linux. This needs more investigation. Right now executing testVariableInitializer01 before testVariableInitializer02 is different from executing only testVariableInitializer02. testVariableInitializer01 has a side-effect when executing testVariableInitializer02. The javamodel.variablesWithInitializer field doesn't have the same value if testVariableInitializer02 is run alone or testVariableInitializer01 is executed first when running testVariableInitializer02. A test should not be dependant or affected by the execution of another test.
Problem comes from the fact that variables were not removed from JavaModelManager variablesWithInitializer cache when their value was reset. This was intentionally done as I thought that initializers may only be specified in extensions and so cannot be removed during an eclipse session. I was obviously wrong as users can use JavaCore API programatically (as we do in our tests!) and add/remove initializers... So, the fix is to remove the variable name from this cache when the value is set to null in putVariable(...) method in JavaModelManager.. Note that remove this variable name from cache before updating eclipse preferences also avoid to call preferences listener with a wrong value and avoid to refresh preferences unnecessarily (see fix for bug 125965). I keep null check as ultimate protection => in this case, variable name is removed from cache...
Fixed and released in HEAD.
Verified using I20060328-0010 for 3.2M6 since tests passed for a long time now.
