I have had a lot of success with nippy https://github.com/ptaoussanis/nippy, which is quite well documented. We had problems with fressian round tripping Clojure collections, as you've described.
It has a number of other features (compression, encryption) that I may end up using. It has given attention to backwards compatibility, and there is a mode to turn this backwards compatibility off if it is not required. Lucas > On 16 Mar 2015, at 09:40, Ryan Schmitt <rschm...@u.rochester.edu> wrote: > > I'm the author of dynamic-object, an open source library that makes Clojure's > data modeling power available to Java programmers. This includes features > like serialization and deserialization. I'll copy this small usage example > from the README to give you a sense of how it works: > > public interface Album extends DynamicObject<Album> { > @Key(":artist") String getArtist(); > @Key(":album") String getAlbum(); > @Key(":tracks") int getTracks(); > @Key(":year") int getYear(); > } > > String edn = "{:artist \"Meshuggah\", :album \"Chaosphere\", :tracks 8, :year > 1998}"; > Album album = DynamicObject.deserialize(edn, Album.class); > album.getArtist(); // => "Meshuggah" > > dynamic-object has always been opinionated about using Edn as the primary > data language on the wire, for a number of reasons. For a long time, I also > thought about adding Fressian support to dynamic-object, and I've recently > done so on an experimental basis. (It looks like this.) Some time after I > initially released dynamic-object, Transit was also released, with support > for various encodings (JSON, JSON-Verbose, MessagePack). > > In working (to different extents) with these data languages, I've had some > apprehensions about all of them. > There is a lack of tooling available for Edn, such as validators and > pretty-printers. I spent a while looking for an Edn equivalent of python > -mjson.tool and never found one. Clojure's built-in pprint function does not > work out-of-the-box to pretty print arbitrary values, and also appears to > handle some data structures, such as records, incorrectly. (pprint omits > reader tags when printing records.) pprint's underlying implementation, > cl-format, is extremely powerful and could almost certainly be used to build > a validating Edn pretty-printer, but it would have an unacceptably long > startup time. > There is a lack of high-quality Edn implementations for different languages. > Because the Edn spec is not very formal or complete, there seems to be some > uncertainty regarding what constitutes an Edn implementation in the first > place. For instance, clojure.edn parses the Ratio type as a builtin, even > though it is mentioned nowhere in the spec. (Issue.) There are also oddities > such as the recommended C++ implementation describing itself as > "experimental." > Fressian's reference Java implementation is almost totally undocumented. This > is a problem, because I'm writing a library that targets Java developers; > they won't be going through the Clojure bindings (which are decently > documented). Fressian's source code is outstanding, but it's still not > documentation. > Due to the lack of documentation, it's not clear which parts of Fressian are > actually stable. Stuart Halloway's data.fressian talk included some > parentheticals about the extension points being subject to change, which so > far they haven't, but that might only be because of the following point... > Fressian does not seem to have gotten any attention since the initial launch. > People have submitted GitHub issues, including one surprisingly high-quality > bug report, but they have all been ignored. The JIRA is mostly tumbleweeds. > The Clojure bindings for Fressian, namely data.fressian, are essentially > incomplete. With the exception of maps, Clojure collection types do not round > trip, and in at least one case (vectors) that is because of a blocking issue > in the underlying Fressian implementation. > There are no documented best practices for the use of Fressian or some of its > more advanced features like chunking. It is not clear how to read and write > Fressian in a way that facilitates (for instance) ranged reads from the > middle of a resource. It is not clear when checksums should be used and how > they should be validated. It is not clear whether tags should be namespaced, > or how. The only namespaced tag in data.fressian is for IRecord; none of the > other type tags are namespaced. It's not clear whether this is due to > bugwards compatibility. > Transit is advertised as a work-in-progress. This is the main reason I > haven't seriously considered adding Transit support to dynamic-object. > However, what happens when Transit is stabilized (if that ever happens)? > Since Transit offers a msgpack encoding, will Fressian then be irrelevant > (except for legacy use cases)? There's a FUD aspect here--I like Fressian and > I want dynamic-object to support it, but I don't want to back the wrong pony > and end up having to support HD-DVD and Betamax for all time (so to speak). > Can these formats be unified? Can Edn and Fressian encodings for Transit be > offered? Would that even accomplish anything? > I realize that none of these data languages will have the same extent of > support and tooling as JSON or XML, but I want to ensure that > dynamic-object's supported data languages all have attentive stewardship and > bright futures. It's distressing that a lot of the issues with Edn and > Fressian have not gotten much traction. Are these languages still actively > being supported and fostered? If so, how much development activity is taking > place on internal forks? Are any public updates planned for these languages > any time soon? > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.