The Daily WTF: Curious Perversions in Information Technology
Welcome to TDWTF Forums Sign in | Join | Help
in Search

Java deployment.properties WTF

Last post 01-27-2013 11:02 AM by Cassidy. 11 replies.
Page 1 of 1 (12 items)
Sort Posts: Previous Next
  • 01-23-2013 8:49 AM

    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

     

     

  • 01-23-2013 9:31 AM In reply to

    Re: Java deployment.properties WTF

    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

  • 01-23-2013 12:55 PM In reply to

    Re: Java deployment.properties WTF

    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.

  • 01-23-2013 12:56 PM In reply to

    Re: Java deployment.properties WTF

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

    Bang.

  • 01-23-2013 12:57 PM In reply to

    Re: Java deployment.properties WTF

    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.

    Signatures are stupid.
  • 01-23-2013 1:09 PM In reply to

    Re: Java deployment.properties WTF

    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.
  • 01-23-2013 4:27 PM In reply to

    Re: Java deployment.properties WTF

    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".

     

  • 01-24-2013 5:55 AM In reply to

    Re: Java deployment.properties WTF

    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.


     
  • 01-24-2013 11:28 AM In reply to

    Re: Java deployment.properties WTF

    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.

  • 01-24-2013 12:39 PM In reply to

    Re: Java deployment.properties WTF

    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).

  • 01-27-2013 6:16 AM In reply to

    • Zemm
    • Top 50 Contributor
    • Joined on 11-26-2007
    • Gold Coast, Australia
    • Posts 1,350

    Re: Java deployment.properties WTF

    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.
    Filed Under: Can you think of something that talks, other than a person?
  • 01-27-2013 11:02 AM In reply to

    Re: Java deployment.properties WTF

    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?

Page 1 of 1 (12 items)
Powered by Community Server (Non-Commercial Edition), by Telligent Systems