As far as I know, configuration properties are used, in a vast majority, within configuration files. Programmatic use is supported but is essentially an edge case, and I'm not sure it justifies the effort of 1) creating the correpsonding Java constants definitions and, most importantly, 2) maintaining them. Consequently, I am postponing this enhancement to version 5.

Regarding your side note, using Properties.put() is definitely not a good practice. A property must have a String key and a String value, and this is not enforced through the Map methods. JPPF uses an extension of Properties, TypedProperties, which provides getXXX() and setXXX() wrapper methods for primitive types (and a few others).

I'm currently experimenting with an extension to the configuration API, trying to unify the JPPF predefined properties with a simple API that provides more information than just the name of a property, for instance default value and aliases (i.e. other names given to that same property, for instance when the name changes in a later version but we still want to handle the legacy name so existing config files still work).

The idea is to have something like:

public interface ConfigProperty<T> extends Serializable {
  public String getName();
  public T getDefaultValue();
  String[] getAliases();
  public String toString(T value);
  public T valueOf(String value);
}

then define an imeplementation for each type:

public class IntProperty implements ConfigProperty<Integer> {
  ...
}

then add get and set methods with type inference to TypedProperties:

public <T> T get(ConfigProperty<T> property);
public <T> TypedProperties set(ConfigProperty<T> property, T value);

finally, we can define constants for the documented JPPF properties, for instance:

public interface PredefinedProperties {
  ConfigProperty<Integer> SERVER_PORT = new IntProperty("jppf.server.port", 11111);
  ...
}

Implemented in trunk revision 3881