Just in general I find this a pretty annoying area. Pretty recently I went through a bunch of static methods I wrote that used Guavaisms on StmtIterators and rewrote them to respect the ClosableIterator and found I didn't need any Guavaisms because NiceIterator did almost everything I needed.
What has me steamed now is QueryExecution, which seems to me to be a third tit or fifth wheel -- a lot of times I want to write some function that just returns a ResultSet and lets the called do what it wants with it, but no you can't just close the ResultSet. It is one more thing (together with ConcurrentModificationExceptions) which gets me in the habit of putting ResultSet(s) into lists despite the cost of the copy and the risk that a big result set will blow up the garbage collector. ----- I don't disagree with making CloseableIterators AutoClosable, but I can say that try-with-resources leaves me a little unsatisfied in Java for reasons I haven't been able to articulate yet and this is funny because I thought it was the bee's knees when I was coding C#. Part of it is that I am writing different stuff than I used to and I am thinking about being able to provide comprehensible error messages a lot these days because a large number of otherwise attractive systems such as Drools and Inform7 have error handling so bad it is a killer fault. Exceptions in Java are orders of magnitude better than the bad old days in C where you had to bulk up you code 2 or 3 times to just get the program to shut down correctly on errors, but when you try to consider all of the situations where "encapsulation" means somebody got a filename wrong and it naturally manifests as a null point error someplace else -- retrofitting good error handling on vernacular Java probably means thinking about the call stack in a new way. I think of how Spring is cool because it avoids the structural instability involved in most of the simple ways to manage initialization and teardown of objects -- you make what looks like a simple change in the code but then the order of operations has to change, or it is not so easy to close something when you are done with it because you might not really be done with it, etc. -- Paul Houle [email protected] On Wed, Jul 27, 2016, at 05:39 AM, rwm wrote: > Github user rwm commented on the issue: > > https://github.com/apache/jena/pull/133 > > I would strongly vote for adding the AutoCloseable interface, at > least for StmtIterator. The sole purpose of AutoCloseable is to allow > developers to use the `try-with-resources` statement and it does not > cause any side effects. When it was introduced to Java, the interface > was added to all objects with a `close()` method. > > The javadoc for AutoCloseable says: > > > An object that may hold resources (such as file or socket handles) > until it is closed. The close() method of an AutoCloseable object is called > automatically when exiting a try-with-resources block for which the object > has been declared in the resource specification header. This construction > ensures prompt release, avoiding resource exhaustion exceptions and errors > that may otherwise occur. > >API Note: > > It is possible, and in fact common, for a base class to implement > AutoCloseable even though not all of its subclasses or instances will hold > releasable resources. For code that must operate in complete generality, or > when it is known that the AutoCloseable instance requires resource release, > it is recommended to use try-with-resources constructions. However, when > using facilities such as Stream that support both I/O-based and non-I/O-based > forms, try-with-resources blocks are in general unnecessary when using > non-I/O-based forms. > > > @afs do you have a list of the generated warnings and maybe could > attach them in a file so we can review them? > > In my experience, the warnings are mostly useful hints about missing > close statements. You can disable them via > `@SuppressWarnings("resource")` or by compiling with `-source 7`. > > See the following example: > ``` > private class C implements AutoCloseable{ > @Override > public void close() { > } > } > public void a(){ > C c = new C(); > // warning! never closed > Objects.requireNonNull(c); > } > public void b(){ > C c = new C(); > Objects.requireNonNull(c); > c.close(); > // no warning, the instance is closed > } > public C c(){ > C c = new C(); > Objects.requireNonNull(c); > // no warning, the instance is returned > return c; > } > public void d(){ > C c = new C(); > if( new Random().nextFloat() < 0.2 ){ > // warning! not closed at this location > return; > } > c.close(); > } > ``` > > The AutoCloseable interface should be used on any class with a > `close()` method, which may need to be called. Otherwise developers > are forced to use Java 6 code with manual exception handling for > resource. > > > --- > If your project is set up for it, you can reply to this email and have > your > reply appear on GitHub as well. If your project does not have this > feature > enabled and wishes so, or if the feature is enabled but not working, > please > contact infrastructure at [email protected] or file a JIRA ticket > with INFRA. > ---
