Maintaining order of properties in a properties file
Hello everyone,
I am dynamically creating .properties files based on the contents of one .properties file.
I first save the .properties file that contains only keys (not values) using file copy as illustrated here : http://www.exampledepot.com/egs/java.nio/File2File.html
The above method works well, the order of the keys doesn't change.
However, after creating a copy of the file, I load and store values dynamically to it as in the snippet below
Properties myProperties =new Properties();
myProperties .load(new FileInputStream("fileName") );
emailBeanProperties.setProperty("myKey","myValue" );
emailBeanProperties.store(new FileOutputStream("fileName"),"" );
When I run the above code the order of the keys in the properties files changes, also the lines in between the keys disappear.
Would anyone know how to retain the original order and blank lines in which the keys were first specified when storing values into properties files dynamically?
I will try to test if specifying all values solves this problem
Any help is appreciated.
[1357 byte] By [
appy77a] at [2007-11-27 9:28:20]
Properties extends Dictionary which is a hash table. Hash tables are not order-preserving. Preserving the order of a .properties file may be cosmetically nice but it is functionally unnecessary.
Preserving the comments, now that's another matter ... Anyway Properties doesn't do either.
ejpa at 2007-7-12 22:32:55 >
Thanks for your reply.
Well, I was trying to preserve the order of property keys and the blank lines between them so that I could read the .properties files manually and verify their contents.
I'm using JUnit to write test output to them from about 30 to 40 different test cases.
When the order is not preserved or if the blank lines disappear, it makes it difficult to read the .properties files.
May be I should try writing to XML files or some other solution. Well I don't have much flexibility at work to do whatever I want. So I guess I'll just leave it as it is.
I'll give you some dukes for your answer.
If you read them into a Properties object and just test that object it won't care about the order or the blank lines or the comments.You don't need to unit-test java.util.Properties itself. Sun do that for you.
ejpa at 2007-7-12 22:32:55 >
> If you read them into a Properties object and just
> test that object it won't care about the order or the
> blank lines or the comments.
>
> You don't need to unit-test java.util.Properties
> itself. Sun do that for you.
I am not unit testing java.util.Properties , I am looking at the actual contents of the .properties files and verifying that the data that is in them matches what I expect.
For example
username=xyz , I verify if username is xyz .
Similarly the .properties files has about 30 to 40 name value pairs, which I need to verify manually to see if the values are correct.
Those tests should be automated. Your test case should know what to expect (i.e. how many entries there should be and what each entry should be). Its then trivial for your test case to iterate over what it knows and verify that the Properties object contains them.matfud
> > If you read them into a Properties object and just
> > test that object it won't care about the order or
> the
> > blank lines or the comments.
> >
> > You don't need to unit-test java.util.Properties
> > itself. Sun do that for you.
>
> I am not unit testing java.util.Properties , I am
> looking at the actual contents of the .properties
> files and verifying that the data that is in them
> matches what I expect.
>
> For example
>
> username=xyz , I verify if username is xyz .
>
> Similarly the .properties files has about 30 to 40
> name value pairs, which I need to verify manually to
> see if the values are correct.
That's the point he was trying to make.
Read the .properties file into a Properties object. Then test that that Properties.equals(your manually constructed Properties). Properties implements Map, and Map's equals contract says that the two Maps have to contain the same keys and values. It says nothing about order, since maps aren't ordered. You could even construct a HashMap or TreeMap for your manual one to compare against.
jverda at 2007-7-12 22:32:55 >
> Those tests should be automated. Your test case
> should know what to expect (i.e. how many entries
> there should be and what each entry should be). Its
> then trivial for your test case to iterate over what
> it knows and verify that the Properties object
> contains them.
No need to iterate.
Just assertEquals(aManuallyConstructedMap, propsReadFromFile)
jverda at 2007-7-12 22:32:55 >
Or if you're not using junit, justpropsReadFromFile.equals(manuallyConstructedMap)
jverda at 2007-7-12 22:32:55 >
Yes, Although in many test cases (especially in this case, for Properties) you would probalby have a static String[][] (or possibly a method local) containing the keys/values you expect.
You can iterate over them and add them to a map or you can iterate over them and compare them. Not much difference really. Its just far easier to write test cases that do not require (when possible)
map.add("bla","bla");
map.add("foo","bla);
etc
matfud
Thank you for your replies jverd and matfud and everyone.
I clearly understand what you are saying regarding automating the tests.
I think it is my mistake for not giving the big picture of what I'm doing (in my first post).
I am automating the tests (not with .properties files) but, I'm first serializing objects and I'm using the serialized java objects as test objects and comparing the values stored in those with the actual data (obtained dynamically).
So for example I have about 10 instances of SomeBean , serialized on the hard disk as bean1, bean2..... and so on bean10
It makes it easier to write the assert statements. For example assertEquals(actualBean.getMyProperty(), bean1.getMyProperty())
I just wanted to verify that the serialized test objects do have the right test data, this is why I'm manually trying to test the test objects , by comparing whats stored in the properties files.
That's why it would help if the .properties files contents were easy to read (easy on the eyes).
But if .properties files are not meant to be processed the way I'm expecting them to be processed, then, I'll have to find another way.
For now, I'm just reading the .properties files manually, even though they're difficult to read.
Thanks.
I think Maps can provide predictable order with either TreeMap or LinkedHashMap: http://java.sun.com/j2se/1.4.2/docs/api/java/util/LinkedHashMap.html
Still not making any sense.
> It makes it easier to write the assert statements.
> For example assertEquals(actualBean.getMyProperty(),
> bean1.getMyProperty())
You can do this, certainly, but if you want to do it this way, why are you mucking with Properties?
It's really not clear to me what you're ultimately trying to test.
If your program stores data in a Properties or other Map, and you want to make sure it's storing the right data, all the data, and no extra data, then just use equals to compare that Map to your expected Map. Order doesn't matter.
If your program stores data in objects whose fields you're testing, then test those fields individually and explicitly, and forget the Map. I suppose you could use introspection in this case to generate the fields automatically, and compare them to values in a Map, but it seems like more trouble than it's worth, and now you're making your tests more complicated and hence more error-prone.
jverda at 2007-7-12 22:32:55 >
