Fixed
Status Update
Comments
cm...@google.com <cm...@google.com> #2
Hi Ed, Thank you so much for these suggestions. I've been reviewing them and merging them in. Hopefully it should be live. I've included a thank you note too in the article.
hu...@google.com <hu...@google.com> #3
Great! Thanks a lot, I'll look for the live updates soon!
vm...@google.com <vm...@google.com> #4
The ag/9287177 removed the previous workaround after having this fixed on Jetifier mentioned commit. Having said that, we are going to mark this as fixed and reconsider the need of adding any lint check in the future if necessary.
Description
-----------
It is easy to see code written in this form: SomeClass.class.getResourceAsStream(someResource) (see
What's wrong with Class.getResourceAsStream()?
-------------------------------------------------------------------
Calling Class.getResourceAsStream() is roughly equivalent to calling Class.getClassLoader().getResourceAsStream().
The implementation of ClassLoader.getResourcesAsStream() is probably safe, but when the class loader is a URLClassLoader, then its overridden version URLClassLoader.getResourceAsStream() has a bug:
This bug can manifest when two subprojects are building in parallel in separate class loaders, and both call URLClassLoader.getResourceAsStream(). One subproject is finished first, and the corresponding class loader is closed. However, closing the class loader will also close the underlying jar file that the other project might be using when reading the stream returned by URLClassLoader.getResourceAsStream(). (This is what happened in
Note: Calling Class.getResourceAsStream() is okay if Class.getClassLoader() is not a URLClassLoader, and therefore does not suffer from this bug. However, because we usually don't check the ClassLoader type, it is better to simply avoid calling Class.getResourceAsStream().
What's the alternative?
------------------------------
One alternative is to use the default implementation of ClassLoader.getResourcesAsStream(), which is Class.getResource(someResource).openStream().
I've verified locally that using this alternative, closing the class loader doesn't close the underlying jar file, and it should be thread safe. (It fixes
I'm opening this bug to revise the code in AGP, data binding, and Jetifier with this new understanding.