[
https://issues.apache.org/jira/browse/JOHNZON-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16865633#comment-16865633
]
Romain Manni-Bucau commented on JOHNZON-215:
--------------------------------------------
[~joerg1985] Well, the RI is not the source of truth, the spec is. There are a
lot of spec where different implementations behave differently because it is
not specified and it does not prevent to write portable code.
We are exactly in that case here since both implementation are compliant to the
spec so writing portable code is fine. So "At development / testing time there
might be another implementation used as in production, this might lead to
issues." assumption is not true here.
Implementing closeable also makes sense when you start decorating the API since
it gives you a hook which is useful even if the underlying stream is already
closed. So the API is well designed, the implementation respects it, it just
makes it less error prone from the user feedbacks we got.
Finally I would add that there is no reliable "lock" on the file, it is system
dependent and not something an user can rely on portably which is likely a
biggest concern in your code than the JsonReader itself IMHO.
In other words I tend to think your issue is not linked to johnzon on jsonp but
another implementation you rely on (windows file?). Is it accurate?
> JsonReader.readObject() calls Reader.close()
> --------------------------------------------
>
> Key: JOHNZON-215
> URL: https://issues.apache.org/jira/browse/JOHNZON-215
> Project: Johnzon
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.1.12
> Reporter: Jörg Sautter
> Priority: Major
>
> We try to use the JsonReader to read a Reader based on a channel holding an
> exclusive file lock and later on we truncate the channel, write the content
> and close the channel / release the lock.
> As soon as we call JsonReader.readObject() the reader and the channel is
> closed and the file locks are gone. This should - from our point of view -
> not happen at this point, only a explicit call to .close() should close the
> underlying resources.
> This is a code snippet to reproduce the issue:
> {{StringReader sr = new StringReader("{}");}}
> {{Reader wrapper = new Reader() {}}
> {{@Override}}
> {{public int read(char[] cbuf, int off, int len) throws IOException{}}
> {{return sr.read(cbuf, off, len);}}
> {{}}}
> {{@Override}}
> {{public void close() throws IOException{}}
> {{throw new UnsupportedOperationException("someone closed the stream!");}}
> {{}}}
> {{};}}
> {{Json.createReader(wrapper).readObject();}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
