Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

"Nitpickers will complain that this isn’t the same as pickle.load(), since you have to pass a Class<T> token to choose what type of thing you want ahead of time. However, nothing is stopping you from passing Serializable.class and branching on the type later, after the object has been loaded."

Is that actually true in Java? It seems to me that the way that you'd implement that load() method is by using generics to inspect the class you were passed, figuring out what data it wants in what slot, and pulling that data in from the input. You could hold on to the input and return a dynamic proxy, and you would be able to see when someone calls a getFoo() on that proxy, but then you wouldn't know what the type of the foo it expects is. And I don't know whether you could even make your proxy assignable to T.



Hmm, that may be true for JSON, but I think that Java binary serialization holds enough information about the original types to allow deserialization without having to explicitly pass the expected class (though what the runtime system does behind the scenes may be equivalent).


Java will crash if type actually does not match at runtime. You can do whatever cast you want to it ,but it is not necessary to work.

And kotlin even includes a key word to say: if cast does not work, just return null.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: