This interface has two classes, which materialize the InputStream/Outputstream classes, plus DataIn/DataOut interfaces, over either reading from a ByteBuffer or writing to an optionally expandable ByteBuffer. I hink I’ve written or used 10 different approaches to this over the years. Also, there are primitives for reading/writing ByteBuffers directly to the stream, which is something missing from current stuff.
This is a very simple but pretty useful persistent ConcurrentMap implementation. At it’s core, it has an in-memory map of keys to disk locations, then an append-only log for storing key+value. The log on disk never gets smaller, though you can compact it to another file.
This is a utility class for drawing dotty/graphviz graphs programmatically. Find a tremendous overview of dotty graphs here: https://ncona.com/2020/06/create-diagrams-with-code-using-graphviz/ .
This has a bunch of core functionality that works, mostly around basic graphs, but then has a lot of non-core pieces not really finished. It is a work in progress, there is a lot more that can be done than the API here supports, but there is enough implemented to use it for its intended purpose: drawing visuals of data structures.
I find when developing complex data types, it is sometimes nice to be able to visualize them; this lets me do that.
Oh, lord, how many times do I need a quick and dirty CLI parser to throw together some one-off scripty Java tool. Well, here it is.
Single file JSON library. Parser, printer, JSON value objects for programmatic use. Not necessary in this world, but fun to write.
This was a challenge; Multi-Paxos and Raft are pretty dang complicated to implement, but Single Decree Paxos is pretty interesting, and not nearly as complicated. Lots and lots of credit to Denis Rystov for his blog posts and eventual paper on what he called CASPaxos.
This class is a paxos framework for KV storage, users have to provide network and storage objects to build a node.
This is fairly neat; taking inspiration from the Parboiled parser framework, it allows you to express a PEG grammar very easily and naturally in Java code directly. By using lambdas, you avoid all the needed bytecode manipulation, proxying, etc. By using lambdas for callbacks, you sidestep recursive issues as well.
By doing things directly in the code, you avoid generated files, learning a new syntax, adding another plugin in your build system.
See the doc in src/docs for more info.
This one is right up against the 1000 line limit, btw. Tension between commenting and not was very high.
Client and Server objects over Java blocking sockets. Expects to send, receive, or send-and-receive POJOs, using either java Serialization or a provided serialization strategy.
Reader class which allows infinite (memory constrained) pushback, and tracks line/column position. Not intended to be insanely efficient, but correct. Helpful for parsers and such.
Proxy an interface, and then provide a midpoint in the proxy chain where you can tap in and ship the invocation to the server site, and then ship the return value back and complete the operation. Stupid prototype RPC mechanism if you couple it with some network transport backplane.
Simple external disk sort, let’s you specify the max number of in-memory elements for the initial run creation pass, and separately the max number of elements for the merge passes. The reading and appending is abstracted to facilitate using arbitrary file data. Note that the run creation pass uses exactly 1 iterator and 1 appender, so the file buffering overhead would be small. In the merge pass, N many readers are used, so N many file buffering objects (whatever you implement). Hence the two controls.
Simple CSV parser for basic CSV parsing. Nothing special, but does handle multiline quoted fields properly, which can be painful. A personal answer to an age-old question, "How hard can it be?". And I avoided regex, which was the actual starting point. But like the man said, then you have 2 problems. So hard not to just do this with PegLeg! Would have been slower to run, but so easy to write.
This is a driver for defining Finite State Machines. You provide an enum of
events, then create your named FSM with those events. From the FSM, you can then
create named State objects. For each State, you define some number of
State+event transitions. Then you begin your FSM and fire (event, payload)
pairs at it. Single threaded transition processing makes things easier.
Often, in unit tests, you might want to compare the output of some thing with a file that was saved off. But sometimes, the files are merely close (line terminators are a fun example of this). Two ways I have solved this at various times, either a custom compare, which does useful canonicalizing, or custom conanicalizers which then allow for easy comparison. StringsCompare does the latter. Also allows for a predicate to denote lines to skip (commonly used for blank lines.)