New answers tagged

1

If you're going to serialize a class, it needs a serialVersionID. Your exception classes should always be serializable. You have no idea where the exception might be used, and if it gets marshaled across an app domain, you may lose debugging information or even lose the entire exception altogether. Exceptions are intended to be usable anywhere, and if ...


0

Separate writes and reads. Below is a way to allow both to occur at the same time to the same file. Maybe you need for writing or changing the state of the media. It has a list of writers and a parallel list of states. If the write fails beacuse it violates an invaraint, change the state. It would notify observers list with the state. The medium state ...


0

Is it possible and feasible to split the serialised data into parts? One part containing the stable part of the state and one small part containing the changing part of the state. This way you have several options: you can serialise the small changing part last; you can use events, observer pattern or reactive paradigm to serialise the changing part of ...


1

XML and to a lesser extent JSON is probably the best options out there if you want a human readable format. However, human readable also means human editable, which in turn means having people make changes that are invalid and then having to provide support to allow these humans to figure out their mistakes. Both XML and JSON do not solve the format ...


2

Ignoring the specific CAD issue, but taking into account that this use case could potentially generate rather large files, I would recommend looking into protobuf. It's a rather compact binary format with easy versioning for your future needs: ... language-neutral, platform-neutral, extensible mechanism for serializing structured data – think XML, but ...


7

I've had great success using SQLite databases as a file format for graphics applications. Its both very reliable, and being a standard format, its contents are easily viewed/converted by external programs.


5

JSON is simple and portable. External tools won't have any problems reading or writing it. You won't have any problems yourself reading and writing the data on any architecture, which is very nice. It is also very easy to be compatible with older and newer version, often just by ignoring items that you don't understand. JSON is a bit verbose if you store a ...


6

First thing I would check is if using an existing CAD format would not be sufficient. That would not only prevent you from reinventing the wheel, but also improve the interoperability with other CAD programs. Moreover, adapting the terms of such a format like "Layers" and "Entities", instead of using terms like "layouts" and "patterns" (which have typically ...



Top 50 recent answers are included