Bugzilla – Full Text Bug Listing
| Summary: | FrameworkProperties very difficult to debug | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Krzysztof Daniel <krzysztof.daniel> |
| Component: | Framework | Assignee: | equinox.framework-inbox <equinox.framework-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | krzysztof.daniel, remy.suen, tjwatson |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | stalebug | ||
This is an internal class so I am a bit surprised that someone outside of the framework is using this class. (In reply to comment #0) > It is an evil pattern, because f.e. following code > FrameworkProperties.getProperties().setProperty("os.name", null); I suspect something else must be going on. Properties.setProperty("os.name", null) call should result in an NPE because value cannot be null here. I suspect FrameworkProperties.clearProperty("os.name") is getting called perhaps from calling EclipseStarter.setInitialProperties(Map<String, String>) which is reflectively called from org.eclipse.equinox.servletbridge.FrameworkLauncher.start() If the initialPropertyMap has a "os.name"->null entry then the "os.name" value would get cleared out. Thanks for the attention. I did not want to bring here the real problem that I am working on - it is not clear yet whether it is Eclipse or not. I just wanted to indicate that returning a modifiable collection is not a very good pattern and can cause problems (like mine). (In reply to comment #3) > Thanks for the attention. I did not want to bring here the real problem that I > am working on - it is not clear yet whether it is Eclipse or not. > > I just wanted to indicate that returning a modifiable collection is not a very > good pattern and can cause problems (like mine). I agree if the class is a public API. But I will point out that System.getProperties() is very similar and is what FrameworkProperties is ultimately trying to mimic. That does not mean I think the System properties is a good design pattern by any means, it is just what we are trying to mimic ;-) This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. FrameworkProperties not longer exists since refactoring the framework in Luna. |
I am trying to solve a problem in which some unknown evil code is altering os.name value. It is very difficult because FrameworkProperties exposes static method getProperties which returns writeable underlying Properties. It is an evil pattern, because f.e. following code FrameworkProperties.getProperties().setProperty("os.name", null); leaves absolutely no trace anywhere, and it is impossible to discover it without significantly altering the FrameworkProperties class. I believe that the getProperties method should return a read-only properties/collection.