sszuev commented on code in PR #1994:
URL: https://github.com/apache/jena/pull/1994#discussion_r1299369034
##########
jena-core/src/main/java/org/apache/jena/graph/GraphMemFactory.java:
##########
@@ -30,8 +30,17 @@
/**
* A factory class for creating memory Graphs.
* <p>
- * Apache Jena is migrating to term semantics graph for consistency across all
in-memory and persistent storage graphs
- *
+ * Apache Jena is migrating to term semantics graph for consistency across all
in-memory and persistent storage graphs.
+ * <p>
+ * All the graphs that this factory creates are <strong>not
thread-safe</strong>.
+ * Note that if the memory Graph is structurally modified at any time after
+ * the iterator has been created by any of the {@code find*} or {@code
stream*} methods, the iterator may throw
+ * a {@link java.util.ConcurrentModificationException
ConcurrentModificationException}
+ * if continued with it after this modification.
+ * This may happen even if the queried data does not relate directly to
modified data
+ * (i.e. when triple search pattern does not match added or deleted triple).
+ * The good practice is to explicitly close iterators immediately after a read
operation or
+ * use terminate operations such as {@link ExtendedIterator#toList()}.
Review Comment:
When we call `Stream.findFirst`, we can't use this stream anymore, so for
Graph-mem it seems safe even without explicit close. Although closing is a good
practice.
As far as I can see, there is still no
`org.apache.java.util.iterator.ExtendedIterator.findFirst` method and other
terminal methods. Such operations are available only in the form of utilities
(`org.apache.java.util.iterator.Iter.findFirst`) and they do not call close.
But, by the way, it makes them not so useful.
The existing `ExtendedIterator` materializing methods are also terminal. So
I don't see any logical error here.
In addition, `Graph` now supports Java Streams, so we also have to say a few
words about Streams.
I think some word could be added directly to the `Graph` interface, and
additional explanations could be added to `GraphMemFactory` as well, to make it
less ambiguous. (**UPD**: added)
By the way, why we use `org.apache.jena.atlas.lib.Closeable` instead of
`java.lang.AutoCloseable`?
I think we can do something like this:
```java
package org.apache.jena.atlas.lib;
interface Closeable extends java.lang.AutoCloseable {
@Override
void close(); // no exception
}
```
\+ In ONTAPI we also have Iteration utils, see
[com.github.sszuev.jena.ontapi.utils.Iterators](https://github.com/sszuev/jena-owl2/blob/main/src/main/java/com/github/sszuev/jena/ontapi/utils/Iterators.java).
What do you think about adding additional (missed) functionality to Jena's
`Iter`?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
