Web / Apache Axiom Interview questions
Why doesn't Axiom fully build the tree by default when parsing large documents?
Eagerly materializing an entire large document up front would reintroduce exactly the cost that deferred building exists to avoid - the CPU work of converting every StAX event into an object, and the memory to hold the resulting full tree, whether or not any given part of it ends up actually being used.
Many real consumers of a large message genuinely don't need the whole thing: a routing intermediary might only ever inspect a small header to decide where to forward a message, a logging component might only need the top-level element name, and a security filter might only need to check a signature block - in each case, building the rest of a potentially large payload would be pure waste.
By defaulting to "build only what's touched," Axiom optimizes for this common case without penalizing the less common case where the whole document genuinely is needed - that scenario is still fully supported, just via an explicit opt-in (build(), or simply navigating the entire tree, which has the same net effect) rather than being forced on every consumer regardless of their actual access pattern.
This design reflects a broader principle worth recognizing in interviews: Axiom's laziness isn't a limitation to work around, it's a deliberate default chosen because most consumers in Axiom's core use case - web-services message processing - only need part of what they receive.
More Related questions...