aspose file tools*
The moose likes Java in General and the fly likes When to stop using a properties file? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "When to stop using a properties file?" Watch "When to stop using a properties file?" New topic
Author

When to stop using a properties file?

Chris Harris
Ranch Hand

Joined: Sep 21, 2003
Posts: 231
Hi all,

I have started to take a different approach when it comes to declaring constants. Originally, probability just like everyone does, I started declaring all constants within my classes.

After talking to some fellow developer I moved my constants into an interface. However I found that this was not the best idea as people start misusing the interface.

I then moved my constants into a utility class. This works BUT I still have to make changes to the code every time the spec changes and am told that the value should be changed.

So in order to reduce the amount of code changes I have started to declare all constants in a properties file. I find this great :-) All values I want to user to be able to change I put in a properties file outside the jar file. If there are values that I don't want the user to change I make a properties file in side the jar.

I have come to think that: A constant is never a constant as you never know what that spec will say tomorrow.

However not everyone sees the advantage of the properties file. Recently I was questioned on the advantage of using a properties file if it is within the jar. As in order to make a change I would change the properties file as required and then re-package the jar. In their option this loses all advantage the properties file can give you. Their argument comes from the idea that it is just as easy for a developer to change the actual class.

My option is that it is far easier to maintain properties file compared to classes.

I would like to hear the option around the ranch about when you should use and just as important when you should not use a properties file.

Thanks

Chris


SCJP 1.2, SCWCD, SCBCD
Stefan Wagner
Ranch Hand

Joined: Jun 02, 2003
Posts: 1923

Don't use it for passwords.
(At least: not for YOUR passwords )


http://home.arcor.de/hirnstrom/bewerbung
Brian Pipa
Ranch Hand

Joined: Sep 29, 2003
Posts: 299
I use Properties files for all of my user-configurable variables. I use OrderedProperties instead of a regular Properties object though: http://filenabber.com/free-java-classes (bottom of page). I need to update that class - I made another change so that the list() method were sorted too.

Brian


My Java Freeware:<br />MACCC - <a href="http://maccc.pipasoft.com" target="_blank" rel="nofollow">http://maccc.pipasoft.com</a><br />Nator - <a href="http://nator.pipasoft.com" target="_blank" rel="nofollow">http://nator.pipasoft.com</a>
Mark Vedder
Ranch Hand

Joined: Dec 17, 2003
Posts: 624

I have come to think that: A constant is never a constant as you never know what that spec will say tomorrow.
I whole-heartedly agree. I have often kicked myself in hindsight for not putting something in a properties file because I thought "it'll never change" only to have it change and thus require a change to and a recompile of a class.

However not everyone sees the advantage of the properties file. Recently I was questioned on the advantage of using a properties file if it is within the jar. As in order to make a change I would change the properties file as required and then re-package the jar. In their option this loses all advantage the properties file can give you. Their argument comes from the idea that it is just as easy for a developer to change the actual class.

My option is that it is far easier to maintain properties file compared to classes.


Again, I agree with your thoughts and actually implement a similar (if not the exact same) strategy. My arguments back to your critics are:
  • placing the properties file in the jar gives you advantages of both worlds; fairly easy configuration changes while at the same time keeping casual users from making changes (as well as being easier to distribute, assuming no outside properties files).
  • it is a lot easier and faster to:
  • unjar an app
  • edit a plain text file
  • rejar the app

  • then it is to change and recompile a class - the classpath issues alone can be a time consuming sometimes. Granted if you are following good practices and using something like Ant, this is not as big of an issue.
  • your strategy allows for a non-developer (such as a power-user, system admin, or operations person) to make the change.
  • using the properties file in a jar file does not require the source code to make the change. As such:
  • it can be done on the system at hand rather then needing to be done on a development system
  • Tech support can walk someone through it if needed
  • It better facilitates emergency changes that may only be temporary and as such saves you from a 3am page waking you up to recompile some code for a simple config change.
  • Sometimes you don't want to make a change, but simply want to see what something is set to. Again, it is much easier to unjar a properties file and read it then it is to decompile a class or tracking down the source code.


  • In my humble opinion, your strategy is a sound one. The only caveat is to make sure any changes you make to the properties file make it into your version control repository� you do use version control, don�t you

    Regards,
    Mark
    [ June 03, 2004: Message edited by: Mark Vedder ]
    Jeroen Wenting
    Ranch Hand

    Joined: Oct 12, 2000
    Posts: 5093
    Creating the jar is a deployment operation, creating a class or properties file is a development operation.
    As the task of creating the jar doesn't change deployment doesn't change while development load is decreased.
    Sounds like a win-win situation to me...

    The time you stop using properties files is when the data becomes multi-dimensional as such data doesn't map well to properties files.
    Such dat should be mapped to other data formats like XML instead.


    42
    Tim West
    Ranch Hand

    Joined: Mar 15, 2004
    Posts: 539
    A strategy used in the project I'm working on is to have an override properties file outside the JAR. This has two uses. Firstly, it allows for easy configuration of properties that legitimately change at run-time (eg, database connection stuff). Secondly, it allows fast, easy fixing of other properties that shouldn't change at run-time, but have. This provides an immediate, simple workaround until you can either edit the internal properties file (as we do), or edit your class and recompile. The code for doing properties-file lookups first loads the property inside the JAR, and then checks for an override outside it.

    This method creates a slight overhead: it requires every property to be prefixed by it's package-location. I'd say this is OK. We use multiple properties files on a "one per package" basis. Each properties file is stored in the package it applies to. This prevents both potential dodgy "package" dependancies, and problems caused by one properties file becoming too massive.

    Anyway, this isn't strictly what you asked, but there it is anyway


    --Tim
    fred rosenberger
    lowercase baba
    Bartender

    Joined: Oct 02, 2003
    Posts: 11318
        
      16

    A constant is never a constant as you never know what that spec will say tomorrow.

    I can't just let this one go by without comment - all those Math classes i took in college are just screaming at me.

    A constant is, well, constant. Pi. e. Avagadro's number... these are all constants, and will NEVER change.

    Since what you are talking about CAN change, then by definition, they are NOT constants.



    (FYI - my wife's nickname for me is Captain Literal, afterall)


    There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: When to stop using a properties file?