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 18310 - Add a possibility of automatically looking up a ResourceBundle for SystemFileSystem annotations
Summary: Add a possibility of automatically looking up a ResourceBundle for SystemFile...
Status: RESOLVED WONTFIX
Alias: None
Product: platform
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 3.x
Hardware: All All
: P3 blocker (vote)
Assignee: Petr Nejedly
URL:
Keywords: PERFORMANCE
Depends on: 13847
Blocks: 17597
  Show dependency tree
 
Reported: 2001-12-03 17:01 UTC by Petr Nejedly
Modified: 2008-12-22 19:43 UTC (History)
3 users (show)

See Also:
Issue Type: TASK
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Petr Nejedly 2001-12-03 17:01:56 UTC
SystemFileSystem uses SFS.localizingBundle and SFS.icon attrributes
for i18n of files in SFS. Authors of module XMLFS's have to specify
the attributes explicitely for each file, although the SFS.localizingBundle
is pointing to the same Bundle most of the times.

Add a possibility of looking up an implicit filesystem localizing bundle
and use it unless there is explicitely specified bundle for a file.

Very similar thing could be done for icons, as most of the files on SFS
will have custom icon.

It requires a smarter ResourceBundle implementation that would
provide hasKey(String key) functionality for better performance.
Comment 1 Petr Nejedly 2001-12-03 17:18:28 UTC
See original discussion at:
http://www.netbeans.org/servlets/ReadMsg?msgId=122418&listName=nbdev

It is in fact in core (SystemFileSystem implementation),
it is a bit of performance issue (less data to parse, less data
to hold in memory, probably less lookups for Bundle)

Also increasing priority - we'd like to see it in the next release.

Adding dependency on NbBundle rewrite because of hasKey()
Comment 2 Jesse Glick 2002-03-01 10:11:43 UTC
I was thinking about this recently, and I don't exactly see how we are
going to save any parse time if we are merging layers... after all, if
you merge layers together, you still need to keep track of which
module each file came from just in order to be able to decide which
bundle to look for the filename in! This would take even more XML
space. So the only advantage I can see for doing this at all is for
the convenience of module authors, in the case that we cache layers
using a different format (e.g. b-tree) in which there is no startup
penalty for keeping additional information for each file.
Comment 3 Marek Grummich 2002-07-22 09:17:12 UTC
Target milestone was changed from '3.4' to TBD.
Comment 4 Petr Nejedly 2002-07-24 12:55:23 UTC
It is incompatible with current way of merging layers so we'll
probably abadon this idea. For now it won't bring any performance
improvement and if we'd head towards simplicity for layer writers,
we can solve it differently.