• Hexadecima (unregistered) in reply to Reply to TRWTF
    Reply to TRWTF:
    The WTF article, is TRWTF.

    TRWTF is hiring an editor who can't handle basic English grammar. I mean, they have this problem on Slashdot, but at least they're native errors that are easy to skip over.

  • Norman Diamond (unregistered) in reply to Steve The Cynic
    ceiswyn:
    you should to avoid creation of many objects in the Java!
    The grammar in that sentence is not your only problem. You just used the word 'Java' as a noun.
    Yeah, besides the grammar problem of grammar rules, you also have the grammar problem of grammar laws.
    ceiswyn:
    I don't know what Oracle do to people who violate their directive about 'Java' being an adjective, but it's probably bad.
    You have asked the Oracle a question about trademarks. The Oracle answers that it will invade Greece and rain lawyers on all of Delphi for giving hospitality to a trademark violator.
    Steve The Cynic:
    Um, Java *is* a noun. It is the name of an Indonesian island, so it's actually not merely a noun, but a proper noun.
    The Javanese island consists of the Western Javanese province, Central Javanese provice, and Eastern Javanese province. The Oracular company's lawyers will sue all of them for trademark violations.

    And to everyone who continues to live in the light of the Sunny star after the Oracle company bought it, be warned: they're going to sue you too.

  • theJava (unregistered)

    "I’m surprised he used StringBuilder- after all, in big data procession, you should to avoid the creation of many objects in the Java, and StringBuilder is definitely an object in the Java."

    What alternative do you suggest? If you hadn't used the StringBuilder, more objects would have been created in the Java

  • Mathlete (unregistered)
    Remy Porter:
    I honestly don't understand why anyone- _anyone_ thinks it's a good idea to externalize symbols into constants. I mean, really, are you ever going to change what a CURLY_BRACKET_OPEN is? And even if you do, are you going to want to leave it called CURLY_BRACKET_OPEN, after that? You're going to have to find/replace or refactor one way or the other. Can someone explain to me what drives programmers to do that?

    The real issue in this case is that constants should have a name that reflects their semantic meaning, not one that describes their current value.

    CURLY_BRACKET_OPEN is a stupid constant name, it should be something that describes the purpose of the constant, like JSON_BLOCK_START. That way when the JSON spec changes and the block delimiters change to @ and ~, you can just change JSON_BLOCK_START to @ and JSON_BLOCK_END to ~ in one place!

  • Ru (unregistered) in reply to Steve The Cynic
    Steve The Cynic:
    Um, Java *is* a noun. It is the name of an Indonesian island, so it's actually not merely a noun, but a proper noun.

    You don't mess with The Java.

  • Martin (unregistered) in reply to Mathlete
    Mathlete:
    The real issue in this case is that constants should have a name that reflects their semantic meaning, not one that describes their current value.

    CURLY_BRACKET_OPEN is a stupid constant name, it should be something that describes the purpose of the constant, like JSON_BLOCK_START. That way when the JSON spec changes and the block delimiters change to @ and ~, you can just change JSON_BLOCK_START to @ and JSON_BLOCK_END to ~ in one place!

    Very much this. And as to why they would do this in the first place, probably all programmers have had spec's change on them halfway through a project, or after go-live, so the upshot is basically nobody trusts specs. Even the formally agreed ones, in some cases!

  • Pero Perić (unregistered) in reply to Mathlete
    Mathlete:
    Remy Porter:
    I honestly don't understand why anyone- _anyone_ thinks it's a good idea to externalize symbols into constants. I mean, really, are you ever going to change what a CURLY_BRACKET_OPEN is? And even if you do, are you going to want to leave it called CURLY_BRACKET_OPEN, after that? You're going to have to find/replace or refactor one way or the other. Can someone explain to me what drives programmers to do that?

    The real issue in this case is that constants should have a name that reflects their semantic meaning, not one that describes their current value.

    CURLY_BRACKET_OPEN is a stupid constant name, it should be something that describes the purpose of the constant, like JSON_BLOCK_START. That way when the JSON spec changes and the block delimiters change to @ and ~, you can just change JSON_BLOCK_START to @ and JSON_BLOCK_END to ~ in one place!

    Exactly. Reasoning that this is good in case JSON specs change is unnecessary. Clarifying constant strings such as ": [{ " is reason enough to use constants that describe semantics of the characters (such as BLOCK_START, BLOCK_END).

  • (cs) in reply to Pero Perić
    you should to avoid creation of many objects in the Java!

    Yeah, being an Object Oriented language don't seem to ring a bell on his little head.

    And just for the record if some future generations read this article, the correct way to do it would be to use a mutable singleton, not a stupid StringBuilder.

    Ah! And kids, do not try this at home, leave it for the cloud enterprise.

    TRWTF is that after six years or so, I just found out that the comments and the forum use different "text editors".

  • Wody (unregistered)

    To answer Remy: CURLY_BRACKET_OPEN and many other similar things are used instead of constants, is because printers could not print many computer-specific characters. This means, that they would often be printed as spaces instead, and somebody recreating the program from paper, would get errors because of these missing characters. Of course, these days this practice continues, not because much is printed, but because many fonts have the same issue and people tend to vary widely in what font they use to view a program, unaware that their font does not contain all characters, or makes i look the same as l, o the same as 0, and so on.

  • Chris A (unregistered) in reply to Brian Hsu
    Brian Hsu:
    I’m surprised he used StringBuilder- after all, in big data procession, you should to avoid the creation of many objects in the Java, and StringBuilder is definitely an object in the Java.

    Didn't this a common practice in Java? StringBuffer / StringBuilder is much more efficiency way to append String compared to using + operator?

    I think it depends on the context. As people have said (plus a bit of my own reading before I answered) - StringBuilder/StringBuffer probably have no performance gain over a one-liner like myStr=str1+str2+str3, because the compiler optimizes away any difference. (But this is not in the language spec, only a compiler's design.) SB/SB do become more efficient for multiple lines of concatenation, or concatenation within a loop, though you'd want to consider case-by-case the trade-off against making the code more verbose.
  • (cs) in reply to fffff
    fffff:
    I think 'the Java' is right up there with 'the Bat Man'. There's just something special about that phrasing...
    The Bat Man is, I suppose, a grown-up Bat Boy. "The Batman" ("Batman", here, is a solid string) is the Official, Teddibly Propah term for the DC Comics superhero....
  • Burst (unregistered)

    The Java, it burns!

  • hombre (unregistered)

    -Knock, knock. -Who's there? Very long pause. -Java.

  • Chelloveck (unregistered) in reply to fffff
    fffff:
    I think 'the Java' is right up there with 'the Bat Man'. There's just something special about that phrasing...

    And do not, under any circumstances, put objects in the Bat Man. He really, really hates that.

  • qbolec (unregistered) in reply to JimLahey
    JimLahey:
    We need to serialize some .net DataContracts into JSON, but the property names need to start with a lower case letter.
    How about using a standard JSON serializer, and then using RegExp to correct first letters? Just don't tell me that json is not a regular language.
  • (cs) in reply to qbolec
    qbolec:
    JimLahey:
    We need to serialize some .net DataContracts into JSON, but the property names need to start with a lower case letter.
    How about using a standard JSON serializer, and then using RegExp to correct first letters? Just don't tell me that json is not a regular language.

    We don't need to do any of that. Like I said, with WCF you can do this in a matter of seconds:

    do this in two seconds: [DataMember(Name="sameNameAsThePropertyJustStartingInLowerCaseLikeYouAsked")]

    You'd do well at our place with anti-productivity like that. They'd probably make you lead architect or something, while anyone who actually knows how to use the .net tools we have gets assigned to a Delphi project.

    If you reinvent the wheel enough times at some point those wheels will form part of the big truck of fuckup which will not only run you down, but reverse back over you a couple of times for good measure.

  • Nolo (unregistered) in reply to dgvid

    I'll be trying to work the phrase "the Java" into conversations at work all this month. Thanks, Daily WTF!

    I've got one such use for you. Next time someone builds something like this, tell him to quit pissing in the Java.

  • Andrew Au (unregistered)

    The optimization totally make sense for me, precondition on they have profiled and noticed garbage collection is an issue with the JSon Serializer library.

    Once I was in QCon and I heard about Twitter data analysis guys are doing exactly the same thing, going primitive, Flyweight pattern to avoid object creation, array instead of list, and much more.

    One thing they could have done better is to allocate memory in block, reserve a single buffer for building JSon strings and keep reusing it to avoid resizing, and if code bloat is an issue write a code generator instead of hand coding them.

  • SoleReasonForVisit (unregistered)
    When Matthew saw this attempt at a JSON serializer, he had one question: why didn’t you use one of the many libraries we already use in this application?
    The best part of a hundred comments, mostly from Java weenies as far as I can see, and only one addresses the actual issue.

    Look, I don't care how (in)efficient the damn code is. It's cretinous.

    You don't even need to use .Net decorations and such. There are perfectly good C# libraries into which you can feed JSON Objects, JSON Arrays, JSON Values, JSON Strings and JSON Numbers. Them things is all JSON is. And what do you get? JSON!

    That's kind of the reason JSON was designed that way.

    It was not designed with the intention that bit-headed lunatics would either (a) argue about the merits and demerits of deprecated or otherwise Java string concatenation constructs or (b) tack an endless number of terminator tokens onto a string inline without benefit of procedures, object-oriented programming, or (here's the bleeding obvious thing when you're talking about parsers) recursion.

    What is wrong with you people?

  • Sam (unregistered)

    This is a really good tip especially to those new to the blogosphere. Brief but very precise information… Thanks for sharing this one. A must read post! save refuges

Leave a comment on “Big-Data JSON”

Log In or post as a guest

Replying to comment #:

« Return to Article