Bug 73775 - Remove final from PropertiesDataLoader
Remove final from PropertiesDataLoader
Status: NEW
Product: utilities
Classification: Unclassified
Component: Properties
5.x
All All
: P3 (vote)
: TBD
Assigned To: Jan Peska
issues@utilities
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-20 17:39 UTC by charlweed
Modified: 2011-09-01 16:00 UTC (History)
0 users

See Also:
Issue Type: ENHANCEMENT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo