the java.nio.Path interface is recursively iterable on Path. This causes a stack-overflow in ST4's representation as it is never able to find an element that isnt iterable, so it calls convertAnythingIteratableToIterator all-the-way-down.
This really does not play nicely with convertAnythingIteratableToIterator: This behavior means, even if you supply a converter for java.nio.path, ST4 never identifies it as a POJO and so never asks for a renderer.
suggestions:
could rewrite the convertAnything to keep a stack of elements that it checks against, if it finds that asking for iterable conversions ever produces the same value => we're probably in an infinite loop => take some action
could try to restructure to ask if a representation exists for the object before trying to iterate over it.
a simple-ish fix would be to look for instances of Collection rather than Iterable; given that Iterable is used in some infinite sequences, this would likely help there too.
I'm swamped, but I need this so I could create a PR if needed. In the mean time I'm going to twiddle my thumbs for a while.
the
java.nio.Path
interface is recursively iterable on Path. This causes a stack-overflow in ST4's representation as it is never able to find an element that isnt iterable, so it callsconvertAnythingIteratableToIterator
all-the-way-down.java.nio.Path implements Iterable<java.nio.Path>
,eg:
and so on.
This really does not play nicely with
convertAnythingIteratableToIterator
: This behavior means, even if you supply a converter forjava.nio.path
, ST4 never identifies it as a POJO and so never asks for a renderer.suggestions:
Collection
rather thanIterable
; given thatIterable
is used in some infinite sequences, this would likely help there too.I'm swamped, but I need this so I could create a PR if needed. In the mean time I'm going to twiddle my thumbs for a while.