9. Why?
Binary 45.71%
Non‐binary 54.29%
Binary vs. non‐binary distribution on a
random directory on my system
10. Why?
100%
Binary files only
...and on my wife's system
11. Challenges
● Decoding from bit stream not for the faint‐hearted
● Encoding to bit stream not for the faint‐hearted
● Hard to maintain
● Hard to extend
● Java doesn't help (Bug 4504839)
● Decoder and encoder easily go out of sync
● Documentation and software easily go out of sync
12. What if....
..this could all be
solved easily?
13. Preon Ambitions
● Declaratively map data structure to encoding
format
● Get the decoder/encoder/documentation,
free of charge
15. What just happened?
Create a Codec for instances of BitMap
01 File file = new File(...);
02 Codec<BitMap> codec = Codecs.create(BitMap.class);
03 BitMap bitmap = Codecs.decode(codec, file);
... and use it to decode a BitMap.
18. But what is actually happening?
Codec is nothing but a
facace to a chain of
Codecs.
Each Codec only
understands its own task.
Codecs will delegate to
other Codecs
27. References
Backward references only
Reference the “outer” object
addresses[1].street
outer.driversLicenses[1].state
driveresLicenses[nrDriverLicenses ‐ 1].state
28. Variable Introductions
@Bound int[] offsets;
@BoundList(offset=”offsets[index]”,...)
List<Node> nodes;
Introduction
● Preon will inject List implementation
● List implementation will load Nodes lazily, on demand
● Calling nodes.get(3) will cause the List implementation to
– Calculate the node's position: offsets[index=3] = 120
– Call Codec<Node> to start decoding from that point
31. Preon Layers
Data binding
A fluent interface for
generating documents.
(pecia.sourceforget.net)
An expression language capable of
BitBuffer abstractions rendering itself to human readable
text. (limbo.sourceforge.net)
33. If not Preon, then what else?
Declarative approach is not new:
– BSDL (Bitstream Syntax Description Language)
– Flavor (http://flavor.sourceforge.net/)
– XFlavor
– BFlavor (http://multimedialab.elis.ugent.be/bflavor/)
None of them would worked in our case:
– Overly complicated
– No solid implementation
– Assumptions are surreal:
● “everything will just fit in memory”
● “there will only be a single thread”
● “our current feature set is all you ever need”
34. The Preon Answer
“everything will just fit in memory”
Preon is capable of using memory‐mapped data. (Default
BitBuffer implementation wraps around ByteBuffer, and
hence also MappedByteBuffer.)
“there will only be a single thread”
In Preon, every thread can have its own reference to the
current position in the BitBuffer.
“our current feature set is all you ever need”
Preon has incredibly open: implement CodecFactory or
CodecDecorator to create your own codecs based on type
information or annotations.
35. CodecFactory
Annotations on the object expecting data
to be decoded by the Codec.
interface CodecFactory {
<T> Codec<T> create(AnnotatedElement metadata,
Class<T> type,
ResolverContext context);
}
The type of object to The object for constructing
be decoded. references.
returns null if it does not have a way to construct a Codec
36. CodecFactory Usage
● CodecFactories can be passed to Codecs.create(...)
● ... which will cause the Codecs class to consider
these factories when constructing the various
Codecs.
● Internally, a big chain of commands
37. Current Status
● http://preon.sourceforge.net/
● Interfaces fairly stable
● Current version 1.0‐SNAPSHOT
● Complete Java class example before first release
candidate
● Bugs...
● I want you
38. Future work
● The encode operation (after 1.0)
● Better debugging
● Annotation driven support for other compression
techniques
● More hyperlinking in the documentation
● Better algebraic simplification of expressions
● Descriptions from JavaDoc
39. If there is only a couple of things...
● XML is just a lame way of binary encoding
● Preon cuts out the Infoset model, preventing
unnecessary transformations
● Preon makes binary encoding easy
● Preon is extensible
● Preon (probably) scales quite well
● Preon is friendly to Java developers