• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

advantage of using properties files

 
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


Hi ranchers,

Please tell me what are the advantages of using properties files in a web - applicaton
as compared to writing them as constants in a java class or interface?
 
Sheriff
Posts: 22821
132
Eclipse IDE Spring Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What if you need to change them? If you put them in a class or interface you would need to recompile not only that class, but the entire application because the constants are probably inlined* wherever they are used. By putting them in property files (or any other form of configuration files, e.g. XML) you can modify the file and restart your application, and all code will use the new values. This also allows non-programmers to modify them if needed.


* Compile time constants like numeric and String literals are stored as values inside byte code, not as the original constant variable name.
 
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Rob Spoor wrote:What if you need to change them? If you put them in a class or interface you would need to recompile not only that class, but the entire application because the constants are probably inlined* wherever they are used. By putting them in property files (or any other form of configuration files, e.g. XML) you can modify the file and restart your application, and all code will use the new values.


I totally agree if you're talking about values that really are part of a configuration, or that might change (which, in effect, means that they're not constants); but things like π or e or 'epoch date' do belong in the program.

I also worry a bit about "XML configuration madness" these days with all these distributed 'enterprise' containers around. Why should I have to write pages of finicky (and, it seems to me, largely undocumented) XML to do what I could do in half a dozen lines of properties? It seems we're headed towards a whole new subculture of "configurators" that operate in a world that doesn't have the same controls as a proper programming language.

But then again, maybe I'm just a cranky old fart.

This also allows non-programmers to modify them if needed.


See above.

Winston
 
Rob Spoor
Sheriff
Posts: 22821
132
Eclipse IDE Spring Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Winston Gutkowski wrote:

Rob Spoor wrote:What if you need to change them? If you put them in a class or interface you would need to recompile not only that class, but the entire application because the constants are probably inlined* wherever they are used. By putting them in property files (or any other form of configuration files, e.g. XML) you can modify the file and restart your application, and all code will use the new values.


I totally agree if you're talking about values that really are part of a configuration, or that might change (which, in effect, means that they're not constants); but things like π or e or 'epoch date' do belong in the program.


I fully agree.

I also worry a bit about "XML configuration madness" these days with all these distributed 'enterprise' containers around. Why should I have to write pages of finicky (and, it seems to me, largely undocumented) XML to do what I could do in half a dozen lines of properties? It seems we're headed towards a whole new subculture of "configurators" that operate in a world that doesn't have the same controls as a proper programming language.


I was actually thinking about files like web.xml when writing that. Unless I need the nesting that XML provides I would use a regular properties file instead. Even then you can sometimes mimic nesting using dots. For example, top.name, top.children.count, top.children.1.name, top.children.2.name, etc. This is a bit forced though.
 
RajivAwadhesh kumar
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Rob Spoor wrote:What if you need to change them? If you put them in a class or interface you would need to recompile not only that class, but the entire application because the constants are probably inlined* wherever they are used. By putting them in property files (or any other form of configuration files, e.g. XML) you can modify the file and restart your application, and all code will use the new values. This also allows non-programmers to modify them if needed.




Whats the meaning of " constants may be probably inlined" as said above..

also in case of properties file also we need to restart the application in order to reflect the changes, so is it a lot better than
maintaining those changes in a java file?
 
Rob Spoor
Sheriff
Posts: 22821
132
Eclipse IDE Spring Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

RajivAwadhesh kumar wrote:Whats the meaning of " constants may be probably inlined" as said above..


Suppose you have the following class:
If you compile this, the compiler will take the value of Math.PI and put that inside the byte code. Since it can even calculate 2 * Math.PI, the actual byte code will have generated this:
(This is what JAD actually makes of it when I decompile it.)

If Oracle would now change the value of Math.PI and you did not recompile class Circle, it would still have the old value.
 
Marshal
Posts: 80212
423
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You can verify Rob’s class like this:

[campbell@... java]$ javap -c Circle
Compiled from "Circle.java"
public class Circle {
public Circle(int);
Code:
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: aload_0
5: iload_1
6: putfield #2 // Field radius:I
9: return

public double getArea();
Code:
0: ldc2_w #3 // double 6.283185307179586d
3: aload_0
4: getfield #2 // Field radius:I
7: i2d
8: dmul
9: dreturn
}
[campbell@... java]$

And as Rob said, the area of a circle is now 2πr
 
Ranch Hand
Posts: 808
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

RajivAwadhesh kumar wrote:also in case of properties file also we need to restart the application in order to reflect the changes, so is it a lot better than
maintaining those changes in a java file?


Well, if our screen text is being written by a communications professional, it's likely they don't know how to edit a Java file. But they know how to edit a text file.
 
Hey, check out my mega multi devastator cannon. It's wicked. It makes this tiny ad look weak:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic