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 183225 - Provide efficient K->long hash map implementation
Summary: Provide efficient K->long hash map implementation
Status: RESOLVED WONTFIX
Alias: None
Product: platform
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 6.x
Hardware: All All
: P2 normal (vote)
Assignee: Vladimir Voskresensky
URL:
Keywords:
Depends on:
Blocks: 181684
  Show dependency tree
 
Reported: 2010-03-30 21:00 UTC by Vladimir Voskresensky
Modified: 2010-03-31 08:42 UTC (History)
3 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Vladimir Voskresensky 2010-03-30 21:00:14 UTC 
Indexing API needs to use String->long hash map and consumes a lot of memory by using String->Long.toString(long) approach. There is an efficient LongHashMap<K> implementation in cnd. 
It can be used for hash maps where Value is 'long' and Key can be any type. No boxing/unboxing is used in that implemenation for storing values. Entries are memory efficient.
The proposal is to move it into org.openide.util and use in cnd and editor to prevent code duplication like:
http://hg.netbeans.org/jet-main/rev/a3f97829146c
Comment 1 Jaroslav Tulach 2010-03-31 07:44:45 UTC 
Should not you rather share some higher level functionality provided by parsing.api?
Comment 2 Vladimir Voskresensky 2010-03-31 08:13:13 UTC 
(In reply to comment #1)
> Should not you rather share some higher level functionality provided by
> parsing.api?
we can not depend on parsing api in our repository.
I'm fine to move it into other "ide" cluster utility module.
Comment 3 Jaroslav Tulach 2010-03-31 08:22:46 UTC 
So the purpose of introducing K->long map is to avoid duplication of the code. At the same you are saying that you do not use parsing.api and rather duplicate its functionality. A doublethink, don't you think?

Rather than sharing tiny bits (and sticking them into platform), please find a way to reuse parsing.api. Until the huge duplication is fixed, keep one class duplicated. I suggest won'tfix for the K->long map in the platform.
Comment 4 Alexander Simon 2010-03-31 08:42:16 UTC 
(In reply to comment #3)
> So the purpose of introducing K->long map is to avoid duplication of the code.
> At the same you are saying that you do not use parsing.api and rather duplicate
> its functionality. A doublethink, don't you think?
IMHO parsing API refuses CND requirements about multi threading at API review stage. It prevents CND to use parsing API.