Sorry, sent unfinished message
my version of priorities is:
1) Correct
2) Attractive to users
3) Easy to maintain
Thanks,
Mikhail
2006/7/25, Mikhail Loenko <[EMAIL PROTECTED]>:
2006/7/25, Alex Blewitt <[EMAIL PROTECTED]>:
> On 25/07/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
> > In general
2006/7/25, Alex Blewitt <[EMAIL PROTECTED]>:
On 25/07/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
> In general before we get rid of that class or decide to keep it, I think
> we should work out an approach to performance optimizations.
>
> It's a rare case when perofmance might be significantly
On 25/07/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
In general before we get rid of that class or decide to keep it, I think
we should work out an approach to performance optimizations.
It's a rare case when perofmance might be significantly improved for free,
a regular price is: additional c
If I understood you idea correctly, that would be thread-unsafe
In general before we get rid of that class or decide to keep it, I think
we should work out an approach to performance optimizations.
It's a rare case when perofmance might be significantly improved for free,
a regular price is: add
Hello,
* As Alex and other have mentioned, just use a simple wrapper object with
correct equals/hashCode.
There can be a single instance of such object - not creation of a new
key before lookup but assigning two keys' values :)
--
Regards,
Anton Luht,
Intel Middleware Products Division
-
On 7/23/06, Alex Blewitt <[EMAIL PROTECTED]> wrote:
This sounds like premature optimisation to me. After all, how many
lookups are being performed in the crypto framework? If it's just a
pairing of (say) provider/hash algorithm, how frequently is it being
used? Do we have any stats that show the
age-
> From: Alex Blewitt [mailto:[EMAIL PROTECTED]
> Sent: Sunday, July 23, 2006 3:22 AM
> To: harmony-dev@incubator.apache.org
> Subject: Re: Re: [classlib] TwoKeyHashMap
>
> I don't think that it makes sense to maintain a completely separate
> data structure just bec
mized further by keeping the array sorted and using binary
searches.
-Nathan
> -Original Message-
> From: Alex Blewitt [mailto:[EMAIL PROTECTED]
> Sent: Sunday, July 23, 2006 3:22 AM
> To: harmony-dev@incubator.apache.org
> Subject: Re: Re: [classlib] TwoKeyHashMap
>
> I
used. Also, I
> > believe the actual keys were just Strings, so concatenated Strings could
> > even be used.
> >
> > -Nathan
> >
> >> -Original Message-
> >> From: Tim Ellison [mailto:[EMAIL PROTECTED]
> >> Sent: Friday, July 21,
erface methods won't even work correctly if used. Also, I
> believe the actual keys were just Strings, so concatenated Strings could
> even be used.
>
> -Nathan
>
>> -Original Message-
>> From: Tim Ellison [mailto:[EMAIL PROTECTED]
>> Sent: Friday,
PROTECTED]
>> Sent: Friday, July 21, 2006 11:52 AM
>> To: harmony-dev
>> Subject: [classlib] TwoKeyHashMap
>>
>> Does anyone know why we have a TwoKeyHashMap [1] utility class?
>>
>> I've only looked at it briefly, but I'm left wondering why the autho
ings could
even be used.
-Nathan
> -Original Message-
> From: Tim Ellison [mailto:[EMAIL PROTECTED]
> Sent: Friday, July 21, 2006 11:52 AM
> To: harmony-dev
> Subject: [classlib] TwoKeyHashMap
>
> Does anyone know why we have a TwoKeyHashMap [1] utility class?
>
Does anyone know why we have a TwoKeyHashMap [1] utility class?
I've only looked at it briefly, but I'm left wondering why the author
chose to write all that rather than use a regular HashMap with an object
that combines the 'TwoKey's?
There may be a subtlety I missed. Anyone know?
[1]
http://s
13 matches
Mail list logo
