Home > Archive > Java Help > July 2004 > Strings and Hashtables
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Strings and Hashtables
|
|
| Allan Bruce 2004-07-21, 3:59 pm |
| I have 2 questions to ask, both about Strings:
1) I have a few 'long' numers and want to display them using as little
digits as possible. I thought that this would be best using a String. Is
there a Java class to generate a UID from a long number or should I code my
own?
2) I want to store some Objects in a Hashtable using a String as the key. I
just noticed in my book (Deitel & Deitel) that there is a Properties class.
Will this be faster than a Hashtable? Also, if the key supplied to a
Hashtable (or Properties) is a String, is it case sensitive? Also, what is
the best load factor for storing Strings?
Thanks,
Allan
| |
|
| On Wed, 21 Jul 2004 16:21:05 +0100, "Allan Bruce"
<allanmb@TAKEAWAYf2s.com> wrote:
>I have 2 questions to ask, both about Strings:
>
the following is more than 1 question...
>2) I want to store some Objects in a Hashtable using a String as the key. I
>just noticed in my book (Deitel & Deitel) that there is a Properties class.
Used for different purposes.
>Will this be faster than a Hashtable?
No
>Also, if the key supplied to a
>Hashtable (or Properties) is a String, is it case sensitive?
Yes, to both (I think with Properties)
>Also, what is
>the best load factor for storing Strings?
Use Hashtable, that's what its for. Check the Collections
documentation.
--
now with more cowbell
| |
| Craven 2004-07-22, 8:57 am |
| String.valueOf(long l) will conert your long variables into Strings,
if I understand your post corretly.
Craven
| |
| Roedy Green 2004-07-22, 3:59 pm |
| On Wed, 21 Jul 2004 16:21:05 +0100, "Allan Bruce"
<allanmb@TAKEAWAYf2s.com> wrote or quoted :
>1) I have a few 'long' numers and want to display them using as little
>digits as possible. I thought that this would be best using a String. Is
>there a Java class to generate a UID from a long number or should I code my
>own?
I presume by UID you just mean the long as String.
See http://mindprod.com/jgloss/converter.html
--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
| |
| Roedy Green 2004-07-22, 3:59 pm |
| On Wed, 21 Jul 2004 16:21:05 +0100, "Allan Bruce"
<allanmb@TAKEAWAYf2s.com> wrote or quoted :
>
>2) I want to store some Objects in a Hashtable using a String as the key. I
>just noticed in my book (Deitel & Deitel) that there is a Properties class.
>Will this be faster than a Hashtable? Also, if the key supplied to a
>Hashtable (or Properties) is a String, is it case sensitive? Also, what is
>the best load factor for storing Strings?
it IS a Hashtable with some extra decoration.
--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
| |
| Allan Bruce 2004-07-22, 3:59 pm |
|
"Roedy Green" <look-on@mindprod.com.invalid> wrote in message
news:1ojvf01cotsvsi4ioqvvv41gcmsqrum187@
4ax.com...
> On Wed, 21 Jul 2004 16:21:05 +0100, "Allan Bruce"
> <allanmb@TAKEAWAYf2s.com> wrote or quoted :
>
Is[color=darkred]
my[color=darkred]
>
> I presume by UID you just mean the long as String.
> See http://mindprod.com/jgloss/converter.html
>
No I meant for creating a String that may represent 1000 as "x9" or
something. Its fine though, I have made my own.
Thanks
Allan
| |
| Roedy Green 2004-07-22, 3:59 pm |
| On Thu, 22 Jul 2004 16:20:27 +0100, "Allan Bruce"
<allanmb@TAKEAWAYf2s.com> wrote or quoted :
>No I meant for creating a String that may represent 1000 as "x9" or
>something. Its fine though, I have made my own.
perhaps base 36 numbers. See http://mindprod.com/converter.html
and use radix 36.
--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
| |
| Allan Bruce 2004-07-22, 3:59 pm |
|
"Roedy Green" <look-on@mindprod.com.invalid> wrote in message
news:4mnvf0l3sngnnmtqcoa5ddulr4bouf9p66@
4ax.com...
> On Thu, 22 Jul 2004 16:20:27 +0100, "Allan Bruce"
> <allanmb@TAKEAWAYf2s.com> wrote or quoted :
>
>
> perhaps base 36 numbers. See http://mindprod.com/converter.html
> and use radix 36.
>
That was what I was after, but I have coded my own now
Thanks
Allan
| |
| Dale King 2004-07-28, 9:08 pm |
| "Allan Bruce" <allanmb@TAKEAWAYf2s.com> wrote in message
news:cdm1kt$hkn$1@news.freedom2surf.net...
>
> 2) I want to store some Objects in a Hashtable using a String as the key.
I
> just noticed in my book (Deitel & Deitel) that there is a Properties
class.
Properties was designed for String to String mappings.
> Will this be faster than a Hashtable?
Properties is a subclass of Hashtable. That is an unfortunate design blunder
once again showing why composition should be favored over inheritance.
> Also, if the key supplied to a
> Hashtable (or Properties) is a String, is it case sensitive?
Yes
> Also, what is
> the best load factor for storing Strings?
The best load factor is independent of what is stored in the Hashtable.
--
Dale King
| |
| Roedy Green 2004-07-28, 9:08 pm |
| On Sun, 25 Jul 2004 21:20:20 -0500, "Dale King" <KingD@tmicha.net>
wrote or quoted :
>Properties is a subclass of Hashtable. That is an unfortunate design blunder
>once again showing why composition should be favored over inheritance.
how so?
--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
| |
| Christophe Vanfleteren 2004-07-28, 9:09 pm |
| Roedy Green wrote:
> On Sun, 25 Jul 2004 21:20:20 -0500, "Dale King" <KingD@tmicha.net>
> wrote or quoted :
>
>
> how so?
>
Because a HashTable is a class that allows you to map any Object to any
other Object, while Properties only should map Strings to Strings.
By inheriting HashTable, Properties now also has methods like put(Object o),
which it shouldn't have, since using that method goes against the contract
of Properties.
If the designers had just used a Map internally, and proxied the few
relevant Map methods, the Properties API would have been much cleaner /
correct.
--
Kind regards,
Christophe Vanfleteren
| |
| Dale King 2004-07-28, 9:09 pm |
| "Christophe Vanfleteren" <c.v4nfl3t3r3n@pandora.be> wrote in message
news:IN4Nc.195146$cq5.9695297@phobos.telenet-ops.be...
> Roedy Green wrote:
>
>
> Because a HashTable is a class that allows you to map any Object to any
> other Object, while Properties only should map Strings to Strings.
>
> By inheriting HashTable, Properties now also has methods like put(Object
o),
> which it shouldn't have, since using that method goes against the contract
> of Properties.
>
> If the designers had just used a Map internally, and proxied the few
> relevant Map methods, the Properties API would have been much cleaner /
> correct.
While I agree that is unfortunate as well, that wasn't quite what I was
referring to.
I am referring more to the fact that Properties will always be a Hashtable
and will always have exactly the characteristics of Hashtable, as in it is
synchronized, it is writable, and the order is undefined. With the
collections API we now have many other implementations of things that are
like Hashtable but have slightly different characteristics. We can be
unsynchronized, we can be read only, we can have a specific order to the
elements using a TreeMap or LinkedHashMap.
If they had used composition instead of inheritance they would have had a
member that referred to a Hashtable. When the collections API came out they
could have modified it so that instead of referring to a Hashtable they
would have it refer to an implementation of the Map interface (which is OK
since Hashtable was retrofitted to implement Map). They could add a
constructor where you passed in a Map instance you want to use which could
be a HashMap, a TreeMap, a LinkedHashMap, an IdentityHashMap (probably not a
good idea for properties, but might be usefull as an optimization when the
keys are singleton strings), some Map implementation wrapped using
Collections.unmodifiableMap, or some other Map implementation of your own
choosing.
But of course they didn't so we don't have all the flexibility we could
have.
So once again you should always favor composition over inheritance.
Sometimes you will use inheritance, but you should first consider
composition.
--
Dale King
|
|
|
|
|