• Tinkle (unregistered)

    I thought newline characters (and any whitespace characters) normalise to spaces when reading XML? That was probably what this was trying to work around.

    Still a dodgy way to do it.

  • Charles (unregistered)

    In my current gig, the last developer used comma separated values files (".csv") for configuration info No possibility for comments, and not documented beyond some janky header lines. It's a Python shop -- I'm of course using the configparser object, but she was apparently unaware of this class.

  • Rob (unregistered)
    It helpfully inherits from the HashMap class, letting you interact with those key/value pairs using a well understood API
    Except that Properties extends HashMap<Object, Object> and not HashMap<String, String>. In other words - you can put anything in there that's not null, and when you get stuff out if it you need to cast (or more safely convert) it to String. At least getProperty and setProperty work with Strings, but none of the Map methods do.

    I know that this was done because of binary compatibility - now it has methods like "Object get(Object)", with String as generic type it would have been "String get(String)". Any already-compiled code would need recompiling. That doesn't mean it's not really, really annoying.

  • holy shit now I'm actually commenting here... (unregistered)

    This code doesn't have a means of escaping the separator, so using \\n instead of just \n allows to use \n in the value.

    Maybe the topic of newlines was something that came up regularly in their config strings.

    Or, y'know, they just didn't understand escaping...

  • (nodebb)

    I'm entirely dissatisfied with the reasons for this code's existence.

    The way I understand this code, it basically replaces "\\n" with lineSeparator() - whatever it is, say, "\n". Doesn't Java BCL have something like someStringValue.Replace("find", "replace") method? Why not just do value.replace("\\n", String.lineSeparator())?

  • Gearhead (unregistered) in reply to Mr. TA

    it basically replaces "\n" with lineSeparator()

    It also has the Property that it creates an array of Strings.

  • ZZartin (unregistered)
    Comment held for moderation.
  • (nodebb) in reply to Mr. TA

    Why not just do value.replace("\n", String.lineSeparator())?

    Your guess is as good as mine; that method was added at the same time as StringBuilder which the code does use. Maybe the code predates that (split() is from 1.4, and that version was widely used for WebSphere for ages) and someone "modernized" part of it without noticing the provided method to do the whole thing in one go.

  • Adrian (unregistered)

    TRWTF is Java's Properties class. Nowadays if you want to configure a java application you parse a json or yaml file. Or, let's be honest, you let Spring handle that for you.

  • kolik (unregistered) in reply to Adrian

    Yeah, you could do it the fancy modern way. First it was XML, then JSON, now YAML and TOML are the "modern" formats. In 3 years it will be something new and your code will be old and outdated if you aren't using the FML69 format. But if you just need simple key/value pairs in your config, why overcomplicate it? Properties is fine for that. It's the right tool for that job.

  • Original Submitter (unregistered) in reply to Mr. TA
    Comment held for moderation.
  • (nodebb) in reply to Tinkle

    I thought newline characters (and any whitespace characters) normalise to spaces when reading XML?

    No, that's not the case for text within elements. And I think a lot of parsers will generate text nodes for white space/new lines between elements too.

  • leannacloe (unregistered)
    Comment held for moderation.
  • Leanna Cleo (unregistered)
    Comment held for moderation.
  • leannacleo (unregistered)
    Comment held for moderation.

Leave a comment on “Multiline Properties”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article