Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Using Properties instead of HashMap when dealing with Strings

 
Sonny Gill
Ranch Hand
Posts: 1211
IntelliJ IDE Mac
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All,

If I need a map from String keys to String values, is there any reason not to use Properties instead of HashMap to avoid having to do the cast?

The number of keys is not going to be more than 10-20, but the exact number is known only at runtime.

Sonny
[ August 23, 2004: Message edited by: Sonny Gill ]
 
Ko Ko Naing
Ranch Hand
Posts: 3178
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If the information does not need to be in persistance storage like file, I won't use Properties class, which might get I/O acessing overhead, compared to HashMap which is activated in runtime...

To prevent from null keys and/or null values, you might want to use Hashtable instead of HashMap....

Hope this helps...
 
somkiat puisungnoen
Ranch Hand
Posts: 1312
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think , HashMap and HashTable are have overhead very much,

I'm away use properties file , so i retrive all data from properties file only first call.

And properties file is flexible for your code. (If you want to add new data, you not recompile your code)
 
Ko Ko Naing
Ranch Hand
Posts: 3178
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by somkiat puisungnoen:
I think , HashMap and HashTable are have overhead very much,

Such as?

I'm away use properties file , so i retrive all data from properties file only first call.

And properties file is flexible for your code. (If you want to add new data, you not recompile your code)


That's what the trade-offs between I/O access and Heap object on-the-fly... As I mentioned before, if we do not need to store and retrieve the data to and from a file, I believe that objects on-the fly like Hashtable and HashMap would be better in performance than using properties...
 
Nicholas Cheung
Ranch Hand
Posts: 4982
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

I think , HashMap and HashTable are have overhead very much

Such as?

In Java, object creation and destruction are highly cost operations.


That's what the trade-offs between I/O access and Heap object on-the-fly... As I mentioned before, if we do not need to store and retrieve the data to and from a file, I believe that objects on-the fly like Hashtable and HashMap would be better in performance than using properties...

In fact, there are not much difference between Property object and HashMap because they use similar data structure.

Once you read in the data from the property files, the I/O issues gone.

Nick
 
Ko Ko Naing
Ranch Hand
Posts: 3178
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Nicholas Cheung:

In fact, there are not much difference between Property object and HashMap because they use similar data structure.

Once you read in the data from the property files, the I/O issues gone.


As for me, I won't trade heap object creation with I/O access... Will u?
 
Sonny Gill
Ranch Hand
Posts: 1211
IntelliJ IDE Mac
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the replies guys.

If the information does not need to be in persistance storage like file, I won't use Properties class, which might get I/O acessing overhead, compared to HashMap which is activated in runtime...

Looking at the source code for Properties, the I/O related streams only get initialized if you call the load, save or list methods, there are no instance variables to do that. So why would there be I/O overhead if I dont call those methods?

I think , HashMap and HashTable are have overhead very much,
I'm away use properties file , so i retrive all data from properties file only first call.


Somkiat, Properties is a subclass of HashTable, so it will also have any overhead associated with HashTable, which I believe is because of the synchronized methods. Infact, HashMap is probabely faster than Properties.


Again, the main reason I am thinking of using properties is to avoid having to cast the objects back to String, because I know that I will only ever be storing strings, both as keys and as values.

The only difference I can see, from the source code for Properties, is when getting an enumeration of keys




And the code for enumerate is



It creates an extra Hashtable() object, which I dont need because I am not using a defaults Properties in my constructor.

Of course, when we start using Generics in Tiger, all this wont be an issue.
 
Nicholas Cheung
Ranch Hand
Posts: 4982
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Since property file issue is a one time issue, which means, you will only encounter problems when the system starts. Of course, I wont refer to the property file everytime, instead, I will load it into the memory and then reuse it whenever needed.

Nick
 
Pradeep bhatt
Ranch Hand
Posts: 8933
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You cannot update Properties but you can do that using HashMap.
 
Ko Ko Naing
Ranch Hand
Posts: 3178
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Pradeep Bhat:
You cannot update Properties but you can do that using HashMap.


What if we write back to the Properties file? But as I mentioned before, if we do not need to store in the persistent storage like file, I prefer HashMap, which is gone after the application terminates, while Properties file is still existing in the system taking up some spaces...

Mmm... It seems like we are heading to the performance issue between HashMap and Properties....
 
Nicholas Cheung
Ranch Hand
Posts: 4982
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

You cannot update Properties but you can do that using HashMap.

I am sure we can update the entry inside the proerties file, because in SCJD, we need to read the content from the properties file as the default value, and if the user changes the values, the updated values will be saved in the properties file.

Nick
 
Nicholas Cheung
Ranch Hand
Posts: 4982
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

if we do not need to store in the persistent storage like file, I prefer HashMap

But defintely we needed. Otherwise, we may need to hardcode all things inside the program. If we dont wanna hardcode something, the data must be obtained by somewhere, from file, from URL, or other systems. But each of which is regarded as an I/O.

Nick
 
Ko Ko Naing
Ranch Hand
Posts: 3178
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Nicholas Cheung:

But defintely we needed. Otherwise, we may need to hardcode all things inside the program. If we dont wanna hardcode something, the data must be obtained by somewhere, from file, from URL, or other systems. But each of which is regarded as an I/O.

Nick


It's totally up to the requirement of the application... I used to develop an application that read the entries from logs generated by a web application. And count the number of user access by using that user name...

For example, if my applcation finds one access of a user, put it in an object like HashMap that key is the user's name and value is its access time... Finally my application writes the info to a file... Since the record will not be needed in the future, I don't need to use properties to read and update the value...

So in this case, using HashMap is definitely better than using properties... Actually it's up to the requirement of the application whether we need to use the info generated in the future or not...
 
Jeroen Wenting
Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A Properties Object according to the API docs IS a Hashtable that takes only Strings as keys and values.
So the overhead when using a Properties Object is essentially identical to that of using a Hashtable plus you have the direct capabilities for reading and writing it to persistent storage.

In situations where the latter isn't needed and thread safety is not an issue a HashMap would be faster, in all other situations there's no reason not to use it.
 
Pradeep bhatt
Ranch Hand
Posts: 8933
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Nick you are right that Properties can be updated.
I am going to


The method setProperty could be used to update the property, it actually calls the put method of Hashmap.

The requirements of the application dicate which is the better approach.
Using Properties store method to persist dats would not make sense in enterprise applications, since database would be a better option.

Sonny, the new feature in Java 5 will be useful to you.You could use

Hashmap <String,String> myMap= new HashMap<String,String>();
 
Ko Ko Naing
Ranch Hand
Posts: 3178
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Pradeep Bhat:
Nick you are right that Properties can be updated.
I am going to


The method setProperty could be used to update the property, it actually calls the put method of Hashmap.

You got one mistake again, Pradeep... It should be the put method of Hashtable class, not HashMap...
 
Sonny Gill
Ranch Hand
Posts: 1211
IntelliJ IDE Mac
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, unfortuately Generics are still some time away.
Anyway, I think I will just use a thin wrapper around HashMap for now. It looks like using Properties might confuse somebody trying to maintain the code later.
Thanks guys.
 
Ko Ko Naing
Ranch Hand
Posts: 3178
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Sonny Gill:
It looks like using Properties might confuse somebody trying to maintain the code later.


A good programmer's practice! Caring the feelings of the programmer who needs to maintain the code in the future...

BTW, does anyone know whether Generics feature of Tiger works the same way as template in C++(which is a generic feature in C++)?
 
Pradeep bhatt
Ranch Hand
Posts: 8933
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
BTW, does anyone know whether Generics feature of Tiger works the same way as template in C++(


It would be better than C++ in terms of performance.
 
Ko Ko Naing
Ranch Hand
Posts: 3178
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Pradeep Bhat:


It would be better than C++ in terms of performance.


Really? But I always think that C++ is better in performance than Java in most case... I'm not sure if Java beats C++ this time...
 
Nicholas Cheung
Ranch Hand
Posts: 4982
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I also wonder whether Java Generics will perform better than that of C++.

In old days, Java always being challenged in the aspect of performance!!!
It is normal because the program does not access resources directly, but via the JVM, which is expected to be slower.

Nick
 
Pradeep bhatt
Ranch Hand
Posts: 8933
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Read this good tutorial
http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf


Java generic are a compile thing unlike c++.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic