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

Summary: Add a possibility of automatically looking up a ResourceBundle for SystemFileSystem annotations
Product: platform Reporter: Petr Nejedly <pnejedly>
Component: -- Other --Assignee: Petr Nejedly <pnejedly>
Status: RESOLVED WONTFIX    
Severity: blocker CC: jglick, jtulach, raccah
Priority: P3 Keywords: PERFORMANCE
Version: 3.x   
Hardware: All   
OS: All   
Issue Type: TASK Exception Reporter:
Bug Depends on: 13847    
Bug Blocks: 17597    

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.