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.

Bug 73775

Summary: Remove final from PropertiesDataLoader
Product: utilities Reporter: charlweed <charlweed>
Component: PropertiesAssignee: Jan Peska <JPESKA>
Status: NEW ---    
Severity: blocker    
Priority: P3    
Version: 5.x   
Hardware: All   
OS: All   
Issue Type: ENHANCEMENT Exception Reporter:

Description charlweed 2006-03-20 17:39:36 UTC
I have made a module that effectivly adds the functionality of
org.openide.loaders.FileEntry.Format to PropertiesFileEntry. This allows
troperty file templase to contain replaceable macros. I do this by subclassing
PropertiesDataLoader, and if the FileObject is from a template, I use my new
FileEntry.Format.

Sublassing PropertiesDataLoader required me to remove the "final" from its
declaration. However, the comment for this class says:

   * This class is final only for performance reasons,
   * can be unfinaled if desired.

So I think it should be no problem to make this chage in the trunk.
Comment 1 Marian Petras 2006-03-20 22:40:34 UTC
There is a problem. PropertiesDataLoader is not part of any official API. It is
part of a "friend" API between modules Properties and I18n and is declared as
such (see file properties/arch/arch-properties.xml). So the only acceptable
reason for making an API change (and removing a 'final' token is an API change)
would be if it was required for cooperation between these two "friend" modules.
Or I could declare your module as another "friend" and then make the API change...

The truth is that even the unofficial API of these two modules (Properties,
I18n) is kind of messy and should be cleaned up.

What about adding the new functionality to the current PropertiesDataLoader class?
Comment 2 charlweed 2006-04-24 17:50:54 UTC
I’m investigating just adding the tag-replace functionality to the “Resource
Bundles” module, and while it is technically simple, I think it would be a bad
idea to hard-code my replaceable tags into the module. For example, my tag
__MFFE_FULL_NAME__ is of no interest to any other module. Making the list of
tags dynamic can be done many ways, but all the techniques I can think of
require SOME kind of public interface for communication, even if it is using Lookup.

For example a good way to specify tags would be for my patch to lookup tag
providers via Lookup.getDefault().lookup(new
Lookup.Template(ReplaceableTagProvider.class))

This requires either 
A)	ReplaceableTagProvider to be defined as a public interface in Resource
Bundles module.
B)	ReplaceableTagProvider to be defined in a separate module, and Resource
Bundles depends upon it.

Which is preferable? Are there other options? 

CH