So I'm having problems with a javaws app that is supposed to be able to run offline.  I went to look at the java documentation to see if there's any settings in the deployment.properties file and I came across this:

deployment.cache.enable  | String | false | Specifies if cache should be disabled. false means it should not be disabled. 

So enabled=true means cache disabled and enabled=false means it's enabled?

I'm thinking of doing this:

deployment.cache.enable=file not found

http://docs.oracle.com/javase/7/docs/technotes/guides/deployment/deployment-guide/properties.html

 

 

You've got to love double negatives. My favorite:

DON'T DO WHILE NOT - This loop is not executed if the test condition is not false (or if it's Friday afternoon). 

source: http://www.tlc-systems.com/babbage.htm

lizardfoot:

deployment.cache.enable  | Specifies if cache should be disabled.

 

I've come across many settings that aren't as obvious as the name suggests (or surrounding text would have you believe)[1] but that one takes the biscuit - actually being the reverse of what it seems.

Anyone else got any others?[2]

[1] Oracle Enterprise Manager, I'm looking at you. You could have easily clarified your purpose with better-written text in the web page. It's not hard. 

[2] /etc/ftpusers, /etc/passwd - even filenames can play too.

renewest:

DON'T DO WHILE NOT - This loop is not executed if the test condition is not false (or if it's Friday afternoon). 

 

Cassidy:

lizardfoot:

deployment.cache.enable  | Specifies if cache should be disabled.

 

I've come across many settings that aren't as obvious as the name suggests (or surrounding text would have you believe)[1] but that one takes the biscuit - actually being the reverse of what it seems.

In this case, I'd probably assume there was a mistake in the documentation rather than accept that the setting could be completely ass-backward.

joe.edwards:

Cassidy:

lizardfoot:

deployment.cache.enable | Specifies if cache should be disabled.

I've come across many settings that aren't as obvious as the name suggests (or surrounding text would have you believe)[1] but that one takes the biscuit - actually being the reverse of what it seems.

In this case, I'd probably assume there was a mistake in the documentation rather than accept that the setting could be completely ass-backward.

It's in code from Sun and Oracle, I'd be assuming mistakes when the settings aren't ass-backwards.

Cassidy:

lizardfoot:

deployment.cache.enable  | Specifies if cache should be disabled.

 

I've come across many settings that aren't as obvious as the name suggests (or surrounding text would have you believe)[1] but that one takes the biscuit - actually being the reverse of what it seems.

Anyone else got any others?[2]

[1] Oracle Enterprise Manager, I'm looking at you. You could have easily clarified your purpose with better-written text in the web page. It's not hard. 

[2] /etc/ftpusers, /etc/passwd - even filenames can play too.

 

"Suppress Incorrect Length Indicator".  A system switch with the following property: if this indicator is set to "true" or "on", operations encountering an incorrect length situation will not be reported; if the indicator is set to "false" or "off", operations encountering an incorrect length situation will report an error.

The full name of the switch is used only in the original documentation explaining this point.  Elsewhere, it's universally referred to as "the SILI bit".

 

DescentJS:

It's in code from Sun and Oracle, I'd be assuming mistakes when the settings aren't ass-backwards.

 

Sadly, true.

da Doctah:

"Suppress Incorrect Length Indicator".  A system switch with the following property:

• if this indicator is set to "true" or "on", operations encountering an incorrect length situation will not be reported;
• if the indicator is set to "false" or "off", operations encountering an incorrect length situation will report an error.

Slightly convoluted way of doing it - I would have preferred REPORT=[on|off] rather than SUPRESS=[off|on] - but the logic still holds: ON is supressing the indicator, OFF is not... which is the reverse of Lizardfoot's settings.

 

I always try to use a 'positive' approach to variables and parameters like these, so preferring 'feature.x.enabled' instead of 'feature.x.disabled'.

The only times I might make exceptions to that rule are cases when you need to default to a certain behaviour in the absense of that parameter. For instance, if I have a 'feature.x.enabled' parameter that isn't set, it would intuitively default to false, wherease calling it 'feature.x.disabled' means it defaults to enabled.

LoremIpsumDolorSitAmet:

For instance, if I have a 'feature.x.enabled' parameter that isn't set, it would intuitively default to false

 

That makes more sense to me: requires the key specified with a true value before the feature is enabled, off otherwise.

I encountered a similar WTF in an xinet.d/ config file: "disabled = true" was there by default to turn it off. I really couldn't understand why the developers preferred this method over "enabled = false" (or directive missed entirely).

Cassidy:

That makes more sense to me: requires the key specified with a true value before the feature is enabled, off otherwise.

My lead likes to do the disabled is false by default, "in case someone forgets to set it". Because we have a system used by hundreds of clients and we are actually in the process of adding restrictions via the config. So existing users should continue to have access to the feature and we make new clients pay extra for us to not change it.

Zemm:

My lead likes to do the disabled is false by default, "in case someone forgets to set it".

 

That works for booleans, but I still feel "you don't set it, you don't get it" is my preferred policy. Sometimes having many thing enabled by default can be dangerous, and I'd prefer to withhold until requested.

What does your lead do in the case of missing directives? Presume a default setting? Also, is there a way of extracting live settings from your apps - a diagnostic dump of sorts?