Java deployment.properties WTF



  • 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 said:

    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 said:

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

    Bang.


  • Considered Harmful

    @Cassidy said:

    @lizardfoot said:

    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 said:

    @Cassidy said:

    @lizardfoot said:

    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 said:

    @lizardfoot said:

    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 said:

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

    Sadly, true.

    @da Doctah said:

    "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 said:

    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 said:

    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 said:

    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?


Log in to reply