-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JSONTokener should implement java.io.Closeable #718
Comments
Shall I work on this? If yes, please assign |
Its completed & reviewed at commit e1eabc9 |
And reverted before getting merged. 🙁 |
Closed due to lack of activity. Please post here if you think it should be reopened. |
Should I spam you with “what’s going on?” messages every few weeks? Doing so would just waste time of both of us. Lack of activity is not the same as lack of interest or usefulness. Please don’t close the issue until it gets implemented and released; especially not as “completed”, which is simply not true. |
@jtotht Thanks for the feedback. Historically, issues have been left open on this repo for an extended period, which has led to its own set of problems. I am making an effort to better manage the project by closing issues that are unlikely to be acted upon in the near term. The label "completed" that GitHub applies when an issue is closed with a comment is just GitHub behavior and does not necessarily mean that the requested feature or fix has been implemented. Given that the project is now primarily in maintenance mode, I am cautious about making major changes to the API, such as making |
For things that may once be fixed/implemented, but unlikely to happen in the near term, you could introduce a label that makes this situation clear and allows hiding them in the issues list (example: hide in-progress issues) without closing the issue.
Recently (a few months ago, if I remember correctly) GitHub introduced a new feature allowing closing issues as “not planned”. With this new feature, the default of closing as “completed” does communicate that you believe that the requested feature has been implemented.
In my servlet application, I use JSON.org to parse JSON request bodies sent by the frontend. I do so by constructing
As I stated in the description, it’d be 100% backward-compatible: if one doesn’t call |
It is not 100% backwards compatible. Adding the closable api makes integration with the android namespace implementation harder. Code that uses the new iclosable would not be dropin to android, and that would need to be discussed. |
Re-opened per request |
While
JSONTokener(java.io.Reader)
andJSONTokener(java.io.InputStream)
constructors have explicit notes about JSONTokener not closing the reader/stream, I’d like to have it close the reader/stream. Implementingjava.io.Closeable
isn’t backward-incompatible (if the library user doesn’t explicitly close it, nothing happens), and for those who use try-with-resources construct, having to keep a separate reference for the reader/stream is a pain. Although try-with-resources itself is Java 7+, thejava.io.Closeable
interface is@since 1.5
, so implementing the interface can be done without losing Java 6 compatibility.The text was updated successfully, but these errors were encountered: