Hacker News Reader

Comment by worldsayshi | Hacker News Reader

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 reason for JavaScripts greatness to me is JSON. I couldn't understand how Java developers put up with such bulky ways to deal with data. After some time in Java land I've come back to appreciating its strengths again though. Code completion is nice. I'm kind of hoping for more typescript in the future.

View on HN

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.

Concepts borrowed (in a simplified form) from Scala.

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.

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.

JSON has its strengths and weaknesses, and while Java doesn't have first class support for it the Jackson libraries are excellent!

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.

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

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.

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.

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.

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

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.

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.

JSON is seldom JS now, as any language has had encoder/decoder built in for years.

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.

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.

Perhaps, but probably not. ES6 recognises the distinction, and includes native functions for serialisation. That's first-class treatment if anything is.

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.

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.

An advantage, however, is that you can directly encode Javascript data objects to JSON without having to annotate its fields or anything. I don't recall you being able to do that with Java.

You can't do that with javascript either unless your data objects are acyclic and if they are then using a JSON parser for Java is equally trivial.

You mean that if they are acyclic, you don't have to annotate the fields in Java either? Because the data objects I want to serialize usually are acyclic.

Isn't comparing JS to something like Java or Scala a bit misleading in this regard? They're completely different styles of language with different tradeoffs. I think it would be a lot more fair to compare to something like Python or Ruby, in which case this advantage become a lot less clear IMO.

Well you must compare a dynamic language with another dynamic language. It would be more fair to compare JS to Python or Ruby if you talk about ease of use.

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

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?

s/arrays/"collections of homogenous objects" and it's a fair point.

I was thinking of arrays of objects, where the keys are repeated for each object in the array.

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)

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.

IMHO, it sounds like the job of the compression algorithm, not the format.

Then use compression. gzipped json is highly efficient over the wire.

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.

That's what I said in my first comment, no?

If you don't need to exchange the data with other apps, serialization in Java is actually quite decent.

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

> 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?

> 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

This is the community that installs things by curl|sudo bash, remember

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

I'm still bitter about JSON not supporting comments.

That's why I use 'ini' format for config files despite not being standardized.

Try Python - JSON works very well with it and while Python has its flaws, I think it's a much better language to use.

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.

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?

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)

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)

Reply on news.ycombinator.com