[
https://issues.apache.org/jira/browse/COMMONSRDF-49?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16237515#comment-16237515
]
Bruno P. Kinoshita commented on COMMONSRDF-49:
----------------------------------------------
>Relaying a question from sebb on the JIRA:
>https://issues.apache.org/jira/browse/COMMONSRDF-49#comment-16236065 including
>pointing out the long term restriction that comes with it.
There were other threads in the past discussing reducing/removing Serialization
from components (e.g. Commons Math) as it increased the complexity for
maintaining the component. Other components use Serialization to fulfil
interface contracts (e.g. Commons Collections). I think the concern is valid,
and unless we need to, we can avoid promising to maintain Serialization. But we
can make it easier for a component to support serialization...
>From my POV, serializing a parser is useful for very long or very large ETL
>when you may need to either pause and resume parsing (persisting the state of
>the task in between) or move parsing tasks from one portion of the execution
>environment to another. I'm not saying it's a no-brainer. :)
Indeed! And if you use classes in a context like Jenkins, or any other
distributed environment, you may have to serialize objects over a stream.
>From what I understood, we are working around a limitation in Java8 Optional's
>to be serialized. However, I don't see a serialVersionUID, and do't think the
>parser implements Serializable right now. I checked out the pull request code
>locally, looked at the AbstractRDFParser and RDFParser, and they don't seem to
>implement Serializable.
So if I understand correctly, instead of having Optional<SomeType> as the
instance type, after this pull request we will have SomeType as the instance
field, methods will be using the Optional<SomeType>, and we will keep backward
binary/API compatibility. The only difference being that users that want to
serialize the parser, will be able to do so without having to think too hard
how to bypass the Optional issue.
If that's correct, I think it's a good idea to make these changes in the class,
but perhaps change the title of the this ticket? Perhaps "Avoid using Optional
for instance fields" ? So that we can avoid any confusion.
> Make AbstractRDFParser serializable
> -----------------------------------
>
> Key: COMMONSRDF-49
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-49
> Project: Apache Commons RDF
> Issue Type: New Feature
> Components: simple
> Affects Versions: 0.3.0
> Reporter: Stian Soiland-Reyes
> Assignee: Andy Seaborne
> Priority: Major
> Labels: parser
> Fix For: 0.6.0
>
>
> Raised by [~p_ansell] in [pull request
> 25|(https://github.com/apache/incubator-commonsrdf/pull/25#discussion_r85436754]
> {quote}
> The use of optional here as a field type makes it impossible to serialise.
> Need to have the raw values stored in fields if you want to support
> serialisation in the future, which should otherwise be possible.
> {quote}
> The suggestion is to avoid {{Optional}} in the private fields of
> {{AbstractRDFParser}} so it can be serialized - it can still be {{Optional}}
> in the accessor methods.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
