Change theme
Help
Press space for more information.
Show links for this issue (Shortcut: i, l)
Copy issue ID
Previous Issue (Shortcut: k)
Next Issue (Shortcut: j)
Sign in to use full features.
Vote: I am impacted
Notification menu
Refresh (Shortcut: Shift+r)
Go home (Shortcut: u)
Use Markdown for this comment
Set severity, which reflects how much the issue affects the use of the product
Change issue status back to 'Assigned'
Pending code changes (auto-populated)
[ID: 84651]
Select items in the list
[ID: 558956]
[ID: 874707]
Set the version(s) of the product affected by this issue (comma-separated list)
Set the version(s) of the product in which the issue should be fixed (comma-separated list)
Set the version(s) of the product in which the issue fix was verified (comma-separated list)
Set if this issue occurs in production
[ID: 85206]
Set Reporter
Set Type
Set priority, which reflects how soon the issue should be fixed
Set Status
Set Assignee
Set Verifier
View or edit staffing
View issue level access limits(Press Alt + Right arrow for more information)
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.