This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
While this could be considered an enhancement, I'm marking it as a defect because adding a module to the IDE can negatively impact other modules functionality. I see this as a design defect. I'm filing this bug based on Issue 19979. In this case, integrating IFDEV modules into the IDE changed the setting for a system option, impacting all of the IDE. At the very least, changing user settable options should only be done after warning the user, even if the user is just using the default.
Steve, I do not agree it is a core responsibility to prevent modules to change any system options. It is responsibility of the SO owner or better the module which wants to make a change to notify user. Closing the bug as invalid.
I think we're running against a long history of experience in building robust modular systems if we don't consider a protection architecture similar to JDK security or operating systems security. I can understand there may not be resources/priority to accomplish this soon, but I think the bug should be opened. If you wish to close the bug, I would like to see the limitation in our architecture documented in the OPENIDE docs first. Then I will be happy to see to closed.
One more thing you might consider... it seems like a minimum requirement would be to have an "uninstall" function that would easily restore the IDE to its previous state if installing a new module created problems for the user. I think part of the user challenge will be that IDE users (as opposed to module developers) will likely have no IDE how to fix their IDE if a module has caused problems by changing options. Do we have anything like this now? This would seem like a good workaround to me.
Ad. security - we have a basic security model - independent modules are loaded by independent classloaders. Ad. sharing code (also settings) - module can share code of another module if it depends on it. Ad. sharing only public parts of module - improvement to security of code sharing is being discussed in issue 19621 So we can see that core prevents modules from accessing resources that should not be accessible. Based on the above observations and on the problems in issue 19979 we have should identify what is wrong: Do two modules depend on shared code? Yes, they do. They depend on openide Do they have a right to modify settings in openide? Yes, they have. Should the changes to values of the settings be stored? Yes, otherwise the setting will be lost. My conclusion is that the core does permit illegal access to foreign code but it does not (and should not) prevent access to shared code. The only good solution is to remove settings from shared code. Which deserves its own issue - but is not easy to solve at all because of backward compatibility. Do the
Agreed with Yarda, there is no core defect here. The IFDEF module was wrong to modify this setting, but we cannot realistically prevent this so long as DataNode.setShowFileExtensions is a public API (which is my fault I admit :-)). If there is any architectural defect, it is that there is not a clean way for some piece of behavior (e.g. show file extensions? y/n) to be configurable by a user to act by default on all modules, without introducing an API complexity and without restricting modules from reinterpreting the setting for their own situations. In this case, modules can reinterpret showFileExtensions or just ignore it for their own files; but the static method call remains public, I don't see any straightforward way to avoid that other than introducing named but undocumented config properties etc. Re. uninstalling modules - delete all or parts of your user dir if you do not like your current settings. They will be reverted. Similar functionality is already available from the Options dialog. I do not consider it a goal to provide a general GUI for reverting evil settings changes made by modules, because the modules should be fixed to not do such things to begin with.
I hope your objections were cleared so I'm closing the bug.
Resolved for 3.4.x or earlier, no new info since then -> verified.
Resolved for 3.4.x or earlier, no new info since then -> closing.