WAI
Status Update
No update yet.
Comments
tn...@google.com
I believe try with resources depends on the java.lang.AutoCloseable class at runtime, which I don't think is present prior to API 19 -- is it? (You're saying you've been using it on older platforms; have you confirmed that it actually closes up the resources there?)
en...@google.com
AutoCloseable was in ics. and it's just an interface; it's javac that emits code to actually do the closing. iirc there are fewer classes that are AutoCloseable in ics than we actually unhid. but you could check that (and if you really wanted to, you could have a per-api-level list of what classes actually supported AutoCloseable).
there were also changes to the implementation of suppressed exceptions, i think, which someone who actually looks at what happens might care about. it looks like 8033ba2bd4b8eab11e67738ba4d1390e1fb72111 was the last change in ics; kk had 56444c0884abdbd0946d4e601d534edda0bb2aac which affects serialization of Throwables and c2f2aaaae219c69d50eee6549d507c91e9a08519 which affects subclassing of Throwable (for people trying to avoid paying for a stack trace to be generated).
so "backwards compatible" is a bit misleading. "mostly works" is closer to the truth. that's okay for an individual app author, but i'm not sure whether you want to try going this route. (could you detect, for example, whether a Throwable from a try-with-resources gets serialized and warn that that's broken < 19?)
there were also changes to the implementation of suppressed exceptions, i think, which someone who actually looks at what happens might care about. it looks like 8033ba2bd4b8eab11e67738ba4d1390e1fb72111 was the last change in ics; kk had 56444c0884abdbd0946d4e601d534edda0bb2aac which affects serialization of Throwables and c2f2aaaae219c69d50eee6549d507c91e9a08519 which affects subclassing of Throwable (for people trying to avoid paying for a stack trace to be generated).
so "backwards compatible" is a bit misleading. "mostly works" is closer to the truth. that's okay for an individual app author, but i'm not sure whether you want to try going this route. (could you detect, for example, whether a Throwable from a try-with-resources gets serialized and warn that that's broken < 19?)
nc...@gmail.com
I can confirm that it closes the resources I'm using, which are mostly streams and readers of various kinds. I've used it everything from with URLConnection streams, ContentResolver streams, ParcelFileDescriptor streams, GZIP and deflate streams, file streams, print streams, readers, etc. I've also used it with my own Closeable implementations, without issue.
I am aware that there was a problem with Throwable's protected constructor implementation which was finally fixed in c2f2aaaae219c69d50eee6549d507c91e9a08519. But that constructor was hidden until KitKat, where it had already been fixed.
I'm not suggesting you open up any of the APIs, only the language feature itself. Any attempt to use any of the APIs directly (AutoCloseable, the Throwable protected constructor, etc) would still give you a Lint warning. The feature would only work with legacy Closeable resources (and Throwable instances). By design of the language feature, these are backwards compatible and the implementation available in 8033ba2bd4b8eab11e67738ba4d1390e1fb72111 is sufficient.
Desugared try-with-resources examples are available here:
http://www.oracle.com/technetwork/articles/java/trywithresources-401775.html
Going over this again, I see everything was already in place for API level 14.
I am aware that there was a problem with Throwable's protected constructor implementation which was finally fixed in c2f2aaaae219c69d50eee6549d507c91e9a08519. But that constructor was hidden until KitKat, where it had already been fixed.
I'm not suggesting you open up any of the APIs, only the language feature itself. Any attempt to use any of the APIs directly (AutoCloseable, the Throwable protected constructor, etc) would still give you a Lint warning. The feature would only work with legacy Closeable resources (and Throwable instances). By design of the language feature, these are backwards compatible and the implementation available in 8033ba2bd4b8eab11e67738ba4d1390e1fb72111 is sufficient.
Desugared try-with-resources examples are available here:
Going over this again, I see everything was already in place for API level 14.
en...@google.com
co...@gmail.com
As a C# developer and Android (java) developer I would prefer to use this feature but it is limiting me to KitKat or above targets. The IDisposable concept in C# is exactly as same as Closable (AutoClosable super) which will make things a bit better to read on streams specially.
cheers
cheers
an...@gmail.com
It seems though AutoCloseable is exposed only starting from APILevel19, it does exist in the rt for L14; here is the java.lang package for APILevel14 (Icecream Sandwich):
https://android.googlesource.com/platform/libcore/+/refs/tags/android-4.0.1_r1.2/luni/src/main/java/java/lang/
Maybe that explains even though we get a compile error if the app directly refers to it when APILevel < 19, it resolves correctly at runtime starting from APILevel >=14.
Maybe that explains even though we get a compile error if the app directly refers to it when APILevel < 19, it resolves correctly at runtime starting from APILevel >=14.
Description
Since it was unhidden in API level 19, try-with-resources is backwards compatible down to API level 15.
I have a reasonably successful app with around 600k users on APIs between 15 and 18, in which I use try-with-resources heavily, and never had a single issue with it.
My gradle configuration is as attached. However, Android Studio complains that try-with-resources requires API level 19, as you can see from the attachment.
Would you consider change this when minSdkVersion is 15 or greater, and targetSdkVersion is 19 or greater? It would make try-with-resources useable by a lot more projects.