What is the general practice to set a flag that has a different value in production than it does in dev

Question

Supposed I have a flag public static final boolean FLAG. In development, I want it to be true, but in production, I want it to be false.

Should I just literally set it to true while developing, and when we build/release, someone would go in and change it to false?

I have a feeling that's so not the way to go, as it looks horrible.

What is the approach I should take?

Comfort

possible duplicate of Is there any way to define a constant value to Java at compile time – Groundspeed

Answer 1

Sounds like a good place for a system property, if not a properties file. -Dflag=true

Where -D is part of the line used to start the JVM. On Tomcat its in the JAVA_OPTS environment variable in setenv.sh under bin/

Camail

Answer 2

you can place a file in a place that only exists during development. during runtime the flag is initialized as

flag = file.exists();

Dedicated

Hmm... ok? sounds kind of hacky, but I guess it'd work, though I was hoping the value would be known at compiled-time. – Comfort

btw, don't you consider development and production to be mutually exclusive? And once you enter production there is no way back to development? In that case changing the flag and recompiling wouldn't be the worst option. – Dedicated

What I was concerned about was the fact that some human-being would have to manually change the flag. (Seriously, who still manually compile and release their software?!) – Comfort

Answer 3

From what I've seen, a properties file is used to handle environment and application-specific properties at runtime.

Let's say, for instance, that you have two properties files - one for development, and one for production. Here's what they'd look like:

Dev properties:

application.flag=true

Production properties:

application.flag=false

They're both the same filename, so you don't have to worry about reading in a "different" file.

You would then load the file in, and read that particular property:

Properties properties = new Properties();
InputStream inputStream = null;

try {
    inputStream = new FileInputStream("/path/to/application/app.properties");
    properties.load(inputStream);
    System.out.println(properties.getProperty("application.flag"));

} catch (IOException e) {
    e.printStackTrace();
}

If you had production's value set in that file, you'd get false. If you had development's value, you'd get true.

Peers

Answer 4

If it's a "non dangerous" property, externalise to a properties file - they are easy to manage and deploy:

myFlag=true

If it's a more important property, set the property on the command line. This makes it a conscious operation decision to set the flag, and means accidental copying of files from dev to production won't cause damage:

java -DmyFlag=true ...

If it's super important, use an environment variable, which are accessed via System.getEnv() and can't be overwritten by code.

export myFlag=true
java ...

Reviviscence

Answer 5

If the exact same code is running in prod and dev, a System Property is likely the easier choice to implement. When running in dev, just flag the property when invoking the JVM using the -D switch.

We use a well known external configuration file (a Java Properties file) which is available on the classpath and contains specific dev entries. The URL of the file can be easily recovered using getResource("wellKnownName") on the ClassLoader

If your are building a different version for prod and dev, an entry in the Manifest of the main jar or a bundled properties file are likely a better choice.

Here is a page that describes exactly how to do this with Maven.

Americana