Community
Participate
Working Groups
I'm using build I200406092000. A little while ago, I worked on bug 59258 and implemented new preferences API in Cheetah (in stream JDK_1_5 for org.eclipse.jdt.core* projects). Every 2 days, I merge streams JDK_1_5 with HEAD in order to backport all 3.0 bug fixes in 3.1 version... Of course, after having made the merge, I run all JDT/Core tests to verify that stream JDK_1_5 is OK. Today, I did the merge and I was suprised to see that org.eclipse.jdt.core.tests.model.OptionTests failed its 6 first tests :( (I will attache failures and test class for information). Looking at test, it seems that after project.setOptions(null), we cannot access to parent preferences due to an IllegalArgumentException. As I haven't modified this code area since I released bug 59528 fix, I've made a try using RC1 and everything is OK with this version. Does something change in the API or is it bug? If former, then assign this bug to me against JDT/Core component to track the necessary change I have to do to comply with the new expectation, thx
Created attachment 11859 [details] OptionTests.java file Failing tests are test01 to test06
Created attachment 11860 [details] Failures while running OptionTests class
I don't believe that I've made any changes in this area in the last little while. If you call: node.clear() it should not remove the node from the hierarchy. I will investigate this afternoon after we get our noon build submission ready. How do I run your tests? Is there anything special I have to do? I presume that I just load them from HEAD? or are you working in a different stream? how do I set up the VM?
Created attachment 11882 [details] Launch file to use to run OptionTests Nothing special for config as soon as you get jdt-core tests projects from HEAD (get them all as they are prereq between them...).
Created attachment 11884 [details] Launch config for Sun JDK 1.5.0
Ok, I see the problem now, this new failure in your tests occurs after a change we made for bug 65068. Basically when you have project preferences and you delete the project, then we remove that preference node from the preference tree hierarchy. So clients who are caching that node will run into problems. It looks like the method JavaProject#getEclipsePreferences caches the project prefs node. I have already opened bug 54907 to talk about stale references to preference nodes. You can do a couple of things: - remove the caching - in the cache, check to see if the node exists and if not then try and retrieve it again -> node.nodeExists(""); - register a node change listener and when your node is removed, clear your cache Thoughts?
I don't think the problem is related to project deletion... We are not deleting the project. See test01 for example: ... // check project B custom options... assertEquals("projB:unexpected custom value for deprecation option", ...; assertEquals("projB:unexpected custom value for compliance option", ...; assertEquals("projB:unexpected inherited value for hidden-catch option", ...; // flush custom options - project A should revert to global ones projectA.setOptions(null); assertEquals("projA:unexpected reverted value for deprecation option", JavaCore.DISABLED, projectA.getOption(JavaCore.COMPILER_PB_DEPRECATION_IN_DEPRECATED_CODE, true)); assertEquals("projA:unexpected reverted value for compliance option", ...; assertEquals("projA:unexpected inherited value2 for hidden-catch option", ...; } finally { this.deleteProject("A"); this.deleteProject("B"); } There's effectively a project deletion, but the problem does not occur at this time. It happens on projectA.getOption(...) after the projectA.setOptions(null). So, as I do a preferences.clear() when parameter is null for setOption(Map) in JavaProject, it seems that the node is removed during this operation. In comment 3 you said it should not be the case, so either you fix this problem or I need to remove preferences from cache after having called clear() method... I'r rather prefer the first solution as remove preferences in the cache need synchronization which can theoretically imply dead-lock. Surely not the case but we never know... Let me know if it's possible to fix on your side or reassign the bug to me agains JDT/Core component, thx
FYI: I've tested cache reset in JavaProject.setOptions(Map) when param is null (ie. when I perform a preferences.clear()) and it works :)
Sorry, my mistake. Actually my annotation in comment #3 is incorrect. I've traced it a bit further and this is what happens: - you call node.clear() -> this removes all settings for that node - you call node.flush() -> this save the prefs to disk but since there are no settings then this deletes the file from disk - this causes a resource change event which I receive and then remove the node because the file has been removed Let me think about it for a sec....
The current behaviour for #flush() in the case where there are no preferences to write out, is the behaviour that we want. So I think the right answer would be for you to register a node change listener and when the node is removed, then re-populate your cache. This would also make your code fail-safe against other clients who decided to remove your referenced pref node from the tree.
Post 3.0
Reopen to change state...
State was not correct as I've already fixed it... Fixed and released in JDK_1_5 branch (since v_150_0611).
Verified in I200409230100.
