On 2012-12-17, at 11:12 AM, Werner Keil wrote:
Yep, see my comment before.
If we have other dependencies on java.io
, then Closeable seems fine. Only for cases where the java.io
package was not used (i.E. it might be optional in future, modular versions of Java, at least theoretically<329.gif>
) I would prefer the base interface AutoCloseable from java.lang instead.
JsonParserFactory presently depends on Reader and InputStream from java.io and Charset from java.nio. I don't think CharSequence could quite take the place of Reader here: it has charAt() and length() so it's no good for streaming sources of input. Unless there's another java.lang interface that can represent an input stream, I think we're stuck with the java.[n]io dependency.
On Mon, Dec 17, 2012 at 5:08 PM, Jonathan Fuerth <
On 2012-12-17, at 10:55 AM, wenshao wrote:
if jsr353 is a part of JDK 8, should AutoCloseable. if it is library, should not be AutoCloseable.
Yeah, sorry, I made a misleading comment about this. Jitu corrected me in a previous message: Closable extends AutoClosable, so everything works in ARM blocks as it exists today.
My apologies for incorrectly suggesting otherwise.
-+ wenshao +-
Date: Sat, 15 Dec 2012 10:21:20 -0800
Subject: [jsr353-experts] Re: JsonParser.close() and exceptions
On 12/15/12 9:45 AM, Werner Keil wrote:
Why would we target Java 6 with this release?
Java 7 is final, and I heard, 6 is phased out by March 2013 or so.
It would make great sense, to allow "try with resource" unless some users or developers insist on using Java 6 forever?
They can still take advantage of ARM blocks and use SE 7 features in the applications(It is just that we use Closeable instead of AutoCloseable in the API but that doesn't restrict them to use only wiht SE 6)
My preference is to use SE 7 as the base. We had the following discussion and some of them suggested the need to use SE 6, so we went with it. If that's not case, let me know. We can gladly use SE 7 as the base and AutoCloseable !
While leaving subsetting an option for later (AFAIK CLDC 8 also plans to support "try with resource" the main scope for this JSR is Java EE7 which is based on Java7 anyway.
Am 15.12.2012 18:39 schrieb "Jonathan Fuerth" <
JsonParser.close() documents that it closes the underlying input source if there is one. The underlying input source is wrapped in JsonTokenizer and JsonTokenizerReader, both of which declare IOException on their close() methods and let any exceptions pass through. But JsonParserImpl.close() chooses to wrap the IOException in an (unchecked) JsonException. This is not mentioned in the doc comment.
At first I was going to file a JIRA with a suggested rewording of the doc comment on JsonParser.close(), but I think this warrants discussion.
I guess the value of using the unchecked JsonException on JsonParser.close() is that it eliminates the need for exception handling when client code knows it is using the JsonStructureParser implementation, which never throws IOExceptions. On the other hand, leaving JsonParser.close() without a checked IOException tempts lazy developers (like me!) to leave off the try/catch around the call to close(), even when we know there might be a real InputStream underneath.
On the other other hand, none of this matters much when JsonParser is used together with try-with-resources in Java 7. In this case, close() will always be called with proper exception handling. But I guess we're still targeting JDK6 with this API.
I think my preference is still for IOException in JsonParser.close(). What does everyone else think?