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.
org.netbeans.modules.properties.PropertiesDataLoader is declared as a final class. This eliminates the ability to enhance the handling of properties files. It has no String constructor like its' superclass MultiFileLoader, so subclasses of PropertiesDataLoader could not be initialized correctly. I have made a module that allows property file templates to contain replaceable macros. My module adds the functionality of org.openide.loaders.FileEntry.Format to PropertiesFileEntry by subclassing PropertiesDataLoader, and if the FileObject is from a template, I use my new FileEntry.Format. Adding a String constructor to PropertiesDataLoader allows my subclass to be initialized correctly as a MultiFileLoader. The comment for PropertiesDataLoader says: * This class is final only for performance reasons, * can be unfinaled if desired. • Target milestone 5.5 • Dependencies on other issues and issues that depend on this one. This is a resolution for issue 73775. There are no other issues • An explanation of the change in architecture or API. This will make the PropertiesDataLoader constructible, and available for re-use. • A list of the interfaces impacted by the change that the module offers (imports) and depends on (exports). No other interfaces are impacted. • The specification (e.g. javadoc) and stability category (aka commitment level) for each interface. No other interfaces are impacted. • If there is an existing document with answers for Architecture Questions and the issue makes only a partial change to the architecture the architecture document needs to be updated to cover the proposed change in order to qualify for the fast-track review. No Changes need be made to the Architecture. The package is already public. However, the current version of the document is inaccurate and incomplete.
-1. I don't know why this module even exposes any public packages but it should not - a mistake somewhere that should be corrected when possible. No one should be subclassing PropertiesDataLoader. Anyway I think this request is unnecessary since 1. Anyone can create a wizard iterator that does whatever substitutions they desire with no changes to the module. (As I think I already mentioned on one or the other mailing list?) 2. Any useful changes such as making *.properties replace macros consistently with e.g. *.java files, insofar as they make sense, should simply be put directly in the properties module. Any comments anywhere in the nb.org source base reading "This class is final only for performance reasons, can be unfinaled if desired." should be ignored; they are ancient (predating HotSpot and any real understanding of performance on the part of NB engineers) and contradict our API policies which are to keep all classes and methods final unless there is an API justification for them not to be. Suggest this issue be closed as WONTFIX. Anyway it is to be hoped that the whole module will be rewritten soon - basically as soon as anyone has any time to work on it. The current design of the data loader is undesirable and could be greatly simplified along with an overhaul of the UI.
-1 from me as well. There should be no formal API for extending PropertiesData{Loader|Object|Node}.
No reply since May, so I guess this should be closed.