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.
(just recording this thought so it doesn't get lost) I am modifying my module's former SystemOption class to use the new Registry API to get some practice with it. The simplest way to do it is to simply replace putProperty() and getProperty() with calls to the Registry API. This got me thinking - there might be some performance/memory benefits to modifying SharedClassObject to use the Registry API, and this could benefit older modules. Something as follows: - Make the dataEntry map in SharedClassObject lazy - replace all references with a getter call - On property lookup, see if a context exists. If not, read the legacy settings and put them into the registry. If yes, simply read from the registry At least this could eliminate the DataEntry object and its associated map from every SystemOption instance in the IDE. CC'ing Jesse, who might be better able to say if there's some reason this couldn't work or would be a bad idea.
Might be a good idea. I think there are many potential incompatibilities though.
Perhaps. Should be considered. I agree with Jesse that it could cause incompatibilities. Frankly speaking I would like to get rid of SystemOption at all. But it depends on how the OptionsDialog redesign end up.
Well, even with the options dialog, there will need to be some way to access settings of legacy modules. So it can't go away entirely. Basically, if it can save some memory or improve performance for existing SystemOption classes, it might be worth it. If not, don't bother.
"Well, even with the options dialog, there will need to be some way to access settings of legacy modules. So it can't go away entirely." - well for compatibility reasons it can't be just deleted, but it could e.g. be moved into openide-deprecated.jar. "Basically, if it can save some memory or improve performance for existing SystemOption classes, it might be worth it. If not, don't bother." - maybe. It is worth noting that every time anyone has done anything to SystemOption to "improve" its integration into newer APIs (e.g. Lookup especially), its performance has gotten worse and its bugs multiplied. Originally all it did was read in some (serialized) data from a big old serialized stream, and write it back out, which was relatively fast, not counting class loading. Now, I don't really know how it works any more; not sure anyone does. Last I checked, for some obscure reason all SystemOption's were loaded into memory when the IDE *shut down*.
That's what I thought, that it is can of worms and any improvement results in armful of troubles and that it is not worth improving.
"well for compatibility reasons it can't be just deleted, but it could e.g. be moved into openide-deprecated.jar." - as long as it's okay for openide-deprecated to be installing menu items (the Tools | Options item on the menu). Just pointing out that there will need to be *some* way to expose existing options for the forseeable future, otherwise there will be no UI at all for settings on older modules. Sounds like the current condition of SystemOption is pretty messy.
SystemOption does not inherently display anything. If a module adds some node to UI/Services/, then it will appear in Tools -> Options. If we redesign Options then we will need to keep a "Compatibility" tab which shows the current UI/Services/ tree, so you can configure old modules. Re. messy - yeah. Issue #17711 is typical.
Obsolete.