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.