In the permissions code I have to call close on all the ExtendedIterators because I have no idea what is behind them.
I tried to add Autoclosable as an interface using a dynamic proxy in the hopes that all those iterators that extend ExtendedIterator would still function properly. But there was a conflict between the close methods as you noted. I was unable to come up with a solution. Claude On Sat, Mar 6, 2021 at 8:33 PM Andy Seaborne <a...@apache.org> wrote: > Could give some details please? > > I have tried some things out and they don't give a warning unless close > is explicitly present, unlike InputStream. > > Current guess: because ExtendedIterator.close is not the same as > AutoCloseable.close due to throws. > > > It's a multi-facet area. Is this primarily for exceptions? Early exit of > a loop? Within jena-permissions - obviously you can do what you think is > the right thing. > > > What about ExtendedIterator.forEach? That closes on exception. > > Have you seen the "org.apache.jena.riot.other.G" library which is > functions to work with graphs that do the close thing. That was my > solution to making sure lcose was called. We could move (some of) that > to jena-core. > > Is there an interaction with "var"? > > Andy > > On 06/03/2021 17:56, Claude Warren wrote: > > I know that we had discussed adding autoclosable to the iterators but > > decided not to. I find that I am doing a lot of try/finally-close > > manipulation with extended iterators. Rather than rehashing the previous > > discussion (I'll assume we made the correct decision before), I would > like > > to suggest an AutoClosableExtendedIterator that extends both > > ExtendedIterator and AutoClosable. > > > > Is there a reason not to do this? > > > > Claude > > > -- I like: Like Like - The likeliest place on the web <http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
