JPPF Issue Tracker
Please log in to bookmark issues
CLOSED  Enhancement JPPF-289  -  special strings should be constants
Posted Jun 30, 2014 - updated Oct 26, 2015
icon_info.png This issue has been closed with status "Closed" and resolution "RESOLVED".
Issue details
  • Type of issue
  • Status
  • Assigned to
  • Type of bug
    Not triaged
  • Likelihood
    Not triaged
  • Effect
    Not triaged
  • Posted by
     Roger Nell
  • Owned by
    Not owned by anyone
  • Category
  • Resolution
  • Priority
  • Targetted for
    icon_milestones.png JPPF 5.2
Issue description
JPPF uses special strings throughout the source code. These should be defined as constants so that they may be referenced programmatically and with compile-time checking.

For example, the string "jppf.local.execution.enabled" is embedded in the file and elsewhere. If my client wants to build a configuration in code it would also have this string.

Create one or more interfaces or classes to define these special strings:
public interface Constants {
 public final static String JPPF_LOCAL_EXECUTION = "jppf.local.execution.enabled";
My class before:
properties.put("jppf.local.execution.enabled", "true");
properties.put( Constants.JPPF_LOCAL_EXECUTION, "true");
On a side note, the API allows the following but the code fails.
properties.put("jppf.local.execution.enabled", true );  // no quotes around "true"

Comment posted by
Jul 01, 07:19
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).
Comment posted by
Oct 18, 08:06
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);
Comment posted by
Oct 26, 10:54
Implemented in trunk revision 3881