Office content and metadata · Java · Apache POI
Typed structure out of Office files.
grPOIc wraps Apache POI and puts it behind gRPC. A client streams the bytes of a Word, Excel, or PowerPoint file in, modern or legacy, and gets back typed events: the document's metadata, then its paragraphs, tables, sheets, and slides in order. It reads content and metadata. It does not render or convert anything.
One event per thing, in document order.
The stream opens with the document's information and then delivers its content the way it appears in the file.
The first event describes the document. After that, each paragraph, table, sheet, and slide arrives as its own typed event, in order, and a final status event closes the stream and reports whether the parse was complete or partial. A caller works with real structure rather than a flat block of text it has to pull apart again.
Metadata is typed too. The core properties a document actually carries become first-class fields, and anything else is preserved in a lossless tail rather than dropped. Nothing is inferred from the shape of a string.
The bytes decide the format, not the label.
grPOIc looks at what the file is, not what the request claims it is.
Uploaded chunks accumulate in memory and the parse runs from that buffer. There is no temp file and no subprocess, and the container runs with a read-only root filesystem so nothing can be written even by mistake. To decide what it is holding, the service reads the file's own magic bytes and dispatches on that. An advisory content type on the request is never trusted, because a mislabelled upload is exactly the case where trusting the label goes wrong.
Spreadsheet cells keep the type POI stored them as, so a number stays a number, a date stays a date, and a boolean stays a boolean rather than collapsing to text. Formulas are a good example of the service's restraint: it hands back the formula's source and the cached result that POI already has, and it never evaluates the formula itself.
Bounded because POI is heavy.
A POI document is single threaded and holds its whole model in the heap, so the service is careful about how many it opens at once.
Each parse runs on its own virtual thread, and a semaphore caps how many run at the same time. That keeps a burst of large uploads from exhausting the heap, since every open document is a full in-memory model until it is done. Uploads past the size limit are refused with a clear resource-exhausted status rather than being allowed to run the process out of memory, and a file that is not an Office document comes back as unimplemented rather than as a confusing internal error.
Read it and run it.
The protobuf contract and the Java server are in the repository, and the tests build their fixtures with POI itself in memory rather than committing binary sample files. The service reports the exact POI version it is running so a caller always knows what produced the output.