7 ms·

Switching back to Java after having spent a long time in JavaScript land with modern standards made me realize how great JavaScript had become. The biggest rea

• osrec 8y ago
  I too like JSON, however it is somewhat inefficient for arrays, where you end up repeating keys a lot. If you're gzipping, it probably doesn't matter as much...
  • tim333 8y ago
    I'm slightly puzzled. Array = [[1,2,3],[4,5,6]] seems valid json and I'm not sure what's inefficient or where the keys come in?
    • zinckiwi 8y ago
      s/arrays/"collections of homogenous objects" and it's a fair point.
    • osrec 8y ago
      I was thinking of arrays of objects, where the keys are repeated for each object in the array.
      • Secretmapper 8y ago
        I'm still a bit confused how this is a problem. Can you elaborate? Is there any serialisation standard that specifically addresses this? I know YAML and TOML doesn't at least (correct me if I"m wrong)
        • SigmundA 8y ago
          Something like Protobuf where there is a schema is defined means metadata like key name does not get repeated for every object, its only the values. No more trying to have short names to keep file size down.
          • egeozcan 8y ago
            IMHO, it sounds like the job of the compression algorithm, not the format.
      • imtringued 8y ago
        Then use compression. gzipped json is highly efficient over the wire. https://blog.octo.com/en/protocol-buffers-benchmark-and-mobile/ https://blog.octo.com/en/protocol-buffers-benchmark-and-mobi... The primary purpose of binary data formats is that they can be parsed quickly and some even allow direct access without a parsing step.
        • osrec 8y ago
          That's what I said in my first comment, no?
• sametmax 8y ago
  JSON is seldom JS now, as any language has had encoder/decoder built in for years.
  • alephnan 8y ago
    Sure, but there is boilerplate and abstractions that are needed in a language like Java or Scala. In JavaScript, it's a first-class citizen of the language.
    • Scarblac 8y ago
      It seems you're not talking about JSON (the serialization format) but rather about Javascript's object literal syntax that inspired JSON. They're really different things.
      • wyattpeak 8y ago
        Perhaps, but probably not. ES6 recognises the distinction, and includes native functions for serialisation. That's first-class treatment if anything is.
        • Scarblac 8y ago
          JSON.stringify and JSON.parse? They're standard library functions that many languages have, I don't see what's ES6 about them, they're much older. First class treatment would be if the language had JSON-typed objects with functionality, e.g. something like const myJson = j'{"key":"value"}'; const value = myJson['key']; const newJson = myJson.set("otherkey", "newValue"); (using the j'' notation for a hypothetical json-typed value) But AFAIK it doesn't, not even in ES6.
          • brlewis 8y ago
            https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Implementing j`{"key":"value"}`; as a tagged template literal is left as an exercise for the reader.
• noicebrewery 8y ago
  JSON has its strengths and weaknesses, and while Java doesn't have first class support for it the Jackson libraries are excellent!
  • rjbwork 8y ago
    Unfortunately given that java does type erasure, you don't get the kind of full featured JSON lib that Json.Net is in the .NET world. Presumably you'd have to somehow annotate to the deserializer what each individual list/array's generic type is for it to properly deserialize, separate from the type definition itself.
    • BlackFly 8y ago
      I'm not sure what scenario you are envisioning. Type erasure does not completely eradicate generic type information, reflection can still be used to infer generic usage for deserialization and dependency injection (and is done in Jackson and Spring). To make your life easier in doing so, there is: https://github.com/jhalterman/typetools https://github.com/jhalterman/typetools
• sgift 8y ago
  > Switching back to Java (...) I miss the "and a project which doesn't use modern standards"-part in your post. It's not as if JSON or other modern things are not used in many Java projects. Your project seems to be stuck in the past, as are many JS projects. Legacy code is no fun most of the time.
  • kybernetikos 8y ago
    I didn't read this as a json vs xml comment, although I suppose it could have been. Rather, I think it's a comment about how there is no convenient, lightweight syntax in Java for dealing with records/maps/trees/dictionaries.
    • worldsayshi 8y ago
      Yes this was closer to my point. Dealing with JSON (like data) is much less convenient in Java than JavaScript. Haven't had to deal with XML configuration in Java for a long time, which I'm thankful for.
• dvfjsdhgfv 8y ago
  If you don't need to exchange the data with other apps, serialization in Java is actually quite decent.
  • rusk 8y ago
    You still need to make `ObjectStream os = new ObjectInputStream(new FileInputStream(filename))); MyObject mo = (MyObject) os.readObject();` which is the most basic form I can think of (you've got to put in all them bloody `try/catches` as well don't forget, along with `public class MyClass { public static void main(String[] args) { ...` etc. etc.). Whereas javascript you can just go `require(myjsonfile)` I love java, but Javascript is indeed great for some of these kinds of things :-)
    • cpburns2009 8y ago
      > Whereas javascript you can just go `require(myjsonfile)` I'm not current on Node features, but that looks dangerous to do. Is that equivalent to reading the file and `eval()`ing it?
      • kbp 8y ago
        > I'm not current on Node features, but that looks dangerous to do. Is that equivalent to reading the file and `eval()`ing it? No: > const fs = require('fs') undefined > fs.writeFileSync('file.js', 'console.log("yes")'); require('./file') yes {} > fs.writeFileSync('file.json', 'console.log("no")'); require('./file.json') SyntaxError: file.json: Unexpected token c in JSON at position 0
      • gaius 8y ago
        This is the community that installs things by curl|sudo bash, remember
• realharo 8y ago
  You should try Kotlin. It solves exactly this pain point - creating classes for data structures is very terse and easy. You can have a one-liner class like class Person(val name: String, val email: String, val yearOfBirth: Int? = null) Or you can make it a `data class` and get automatic `equals` and other things.
  • sbalea 8y ago
    Concepts borrowed (in a simplified form) from Scala.
  • worldsayshi 8y ago
    Thank you for telling me. I've been hovering around this possibility since I'm using Intellij and am the primary owner of the code. Although I'm also keen on this code being as accessible as possible for the rest of the organisation and few has even heard of Kotlin. When I suggest switching to Kotlin everyone's always smiling dismissively like "ah, you with your crazy ideas again". Might do it though. Maybe.
    • ben509 8y ago
      Don't ask, do it. Asking is a great way to get shot down. Write something smaller in Kotlin, then show people what it looks like. It is heavily interoperable with Java, so you could move some of the boilerplate heavy classes over.
• tannhaeuser 8y ago
  I'm using JSON all the time, but it's hardly the be-all/end-all solution for even the basic use case of service payload serialization, let alone config file syntax or document syntax. To begin with, JSON lacks types for URLs, dates/times, and spatial data; it also lacks conventions for error messages and data graphs other than trees, etc. So I think Java not integrating JSON literals at the language level or some such actually is a plus.
  • hajile 8y ago
    I think that lack is a strength. Lists, Maps, Booleans, Numbers, Strings. With these powers combined, you can create basically anything you can think of. Dates can be unix timestamps or ISO strings which are universal. Spatial data is a compound datatype anyway (plus, there are quite a few data representations depending on number of dimensions, cartesian vs polar, etc). The one datatype that JS could potentially benefit from is a byte array type, but even that can be accomplished with base64 "strings" or Lists of numbers. To me, it's much better to let every company send error messages in the format that makes sense to them rather than having the One True Error that doesn't quite work for anyone. My biggest complaints about JSON are syntactic. Optional comments, multi-line strings, and trailing commas would do wonders for day-to-day readability without significantly bloating the specs.
    • tannhaeuser 8y ago
      Agree with your points regarding comments and multi-line strings; don't like optional commas, though. With respect to your "lack is strength" argument, I can't help but find this unconvincing. We all know JSON is derived from JavaScript object/array literal syntax; your argument is akin to retro-fitting the requirements for service payload serialization to the suboptimal de-facto situation with JSON.
• kaliades 8y ago
  The code completion in JAVA is probably the only way to write java. It is bit too bloated for my taste with all classes and subclasses that handle almost the same thing (speaking mainly from Android perspective)
• adjkant 8y ago
  Try Python - JSON works very well with it and while Python has its flaws, I think it's a much better language to use.
  • jrs95 8y ago
    Ehhhh...it works okay but the same fundamental serialization problem exists. The fact that dict can be roughly equivalent to JSON helps, but as soon as you start including more complex types you're going to have to use something to handle serialization/deserialization. Which really isn't that complex with Java if you're using a few convenience libraries: gson, orika/mapstruct, lombok all make it a lot less painful to write this kind of boilerplate serialization code.
    • chamilto 8y ago
      The most common issue I run into is with datetime objects, but there are well documented workarounds. For more complex objects such as ORM objects, I think a lot of people use Marshmallow. That being said, I don't have a lot of experience, so I could be missing something obvious. What issues have you had with Python JSON serialization?
      • jrs95 8y ago
        I wouldn't say I've had issues, I just don't think it's really been easier/quicker in Python than most other languages I've used except for the simplest use cases (when Flask jsonify does everything you need because your data is all just strings, numbers, and booleans already)
• mschuetz 8y ago
  I'm still bitter about JSON not supporting comments.
  • h1d 8y ago
    That's why I use 'ini' format for config files despite not being standardized.
• h1d 8y ago
  JSON has so many of these little but annoying limitations, I can't believe it's finalized like that. JSON5 is something that should've been. https://json5.org https://json5.org