JHPropertiesTyped - Why should I use this?

Properties properties = ClassLoader.getResource("app.properties");

int myint = 0;
try {
	myint = Integer.parseInt(properties.getProperty("myint"));
	if ((myint<22) && (myint>658)) {
		//should I use default value?
		//should I throw exception ?
		//throw new IllegalArgumentException("myint property is outside valid range [23-657]");
	}
} catch (NumberFormatException e) {
	//1. Should we use default.
	myint=55;
	//2. Should we just log the error.
	//3. Should we close application because of invalid property.
} catch (IllegalArgumentException e) {
	//1. Should we use default.
	myint=55;
	//2. Should we just log the error.	
	//3. Should we close application because of invalid property.
}

public interface MyPropertiesDef {
	public static final Property<Integer> MYINT = new Property<Integer>("myint",new IntegerPropertyType(23,657));
	//
	//All your property definitions here......
}

//Make this once
public class MyProperties extends PropertyStaticCollection implements MyPropertiesDef {

	private static MyProperties instance=null;
	
	public MyProperties() {
		super(new ResourceFilePropertyIO("app.properties"),new LoggingPropertyValidationHandler(true));
	}
	public MyProperties getInstance() {
		if (instance==null) {
			instance = new MyProperties();
		}
		return instance;
	}	
}

• Every application has its own property source code
• Applications has different ways of loading properties.
• Always a lot of code to ensure that each property was "valid"
• Difficult to get an overview of what properties is "defined", what is used, what is legacy but not used any more, but we don't delete in fear of breaking the code
• The question of what to do if a property wasn't valid was often not address, it was hoped they were not.
• On deployment it was not uncommon that a property was forgotten to be inserted, and was first discovered later because of dummy default values.

• A centralize place to define the properties your application needs.
• Complete overview of your properties, can use code inspection to see what is used or not.
• You get the property values as the type you intended.
• You can define a property with a strong type and give it restrictions, to ensure its value is with in valid bounds.
• A property definition is a one line job.
• You can load properties from many and multiple resources.
• You can add a validation handler, which takes proper action if any property isn't valid.
• You can make an uniform way to alter properties, through the GUI of your choice. The web demo is just one possibility.
• Complete java doc and tutorial documentation, with more to come as I find more use full information to write.
• Easy to convert legacy property definitions into this framework.

• Q:Why don't you detect changes in the properties data, an automatically reloads them?
• A:There is no need for this. You can always reload the properties, and change detection will give an overhead which in most cases is not needed. Either your properties is local or in an container loaded static.
  
  
• Q:What about hierarchical data structure?
• A:There is very few project I have seen this in, and I think in 99% there is no need to define this. It adds complexity which is not needed, simplicity is the key.
  
  
• Q:What about dynamically defining new properties?
• A:Why? In an application you want well defined properties, this little framework do not solve every property problem, but most of them. Again, simplicity is the key.
  
  

• Gratitude :-)
• Bug reports
• Code support.
• Java doc misconceptions, and english and/or modifications.
• Custom PropertyType implementation which others will find useful.
• PropertyIO implementation which others will find useful.
• Implementation of property management code.
• Suggestions
• Etc...