[jira] [Commented] (IO-819) Commons IO v2.15.0 is breaking android builds
[
https://issues.apache.org/jira/browse/IO-819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783792#comment-17783792
]
Stephan Markwalder commented on IO-819:
---
Or better: I think there is no reason for Android's Jetifier to process the JAR
file of Commons IO. As far as I know, Jetifier is used to rewrite some
Android-specific API calls in libraries built for older Android versions. Since
Commons IO does not use any Android APIs, you should be safe to put it on
Jetifier's ignore list. Search for "android.jetifier.ignorelist" to find more
information about this.
> Commons IO v2.15.0 is breaking android builds
> -
>
> Key: IO-819
> URL: https://issues.apache.org/jira/browse/IO-819
> Project: Commons IO
> Issue Type: Bug
>Affects Versions: 2.15.0
> Environment: java --version
> openjdk 11.0.21 2023-10-17 LTS
> OpenJDK Runtime Environment Zulu11.68+17-CA (build 11.0.21+9-LTS)
> OpenJDK 64-Bit Server VM Zulu11.68+17-CA (build 11.0.21+9-LTS, mixed mode)
>
> Mac OS 14.1 on Apple Silicon
>Reporter: Pranshu
>Priority: Major
> Attachments: Screenshot 2023-10-27 at 00.07.46.png, stacktrace.txt
>
>
> Hey we are using commons +commons-io:commons-io+ java package in out React
> Native app on the android side.
> Apparently the recently releases version v2.15.0 is breaking android builds,
> whereas versions <= v2.14.0 works well.
> Steps to Repro
> 1. Create a RN app
> npx react-native init CommonsIORepro
> 2. Add commons-io dep android/{*}app{*}/build.gradle
> dependencies{
> implementation "commons-io:commons-io:2.15.0"
> }
>
> 3. yarn run start
> 4. In a new terminal - yarn run android
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IO-819) Commons IO v2.15.0 is breaking android builds
[
https://issues.apache.org/jira/browse/IO-819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783789#comment-17783789
]
Stephan Markwalder commented on IO-819:
---
I'm not an expert for Android and its build tools, but maybe the following
information helps someone else with more know-how.
Looking a little bit deeper into the stacktrace, there is this information:
{code:java}
Caused by: com.android.tools.r8.CompilationFailedException: Compilation failed
to complete, origin:
/Users/pranshu/.gradle/caches/transforms-3/7cdc58ab883977f6fa537449bff40fa0/transformed/jetified-commons-io-2.15.0.jar:org/apache/commons/io/FileCleaningTracker$Reaper.class
at Version.fakeStackEntry(Version_4.0.52.java:0)
at
com.android.tools.r8.internal.vk.a(R8_4.0.52_5a340ca2823c7e792fe09805c75f749b9d398d230bc0518bb54ae9b6b50addbe:75)
at [...] {code}
The issue seems to be related to processing the class file
{{{}org/apache/commons/io/FileCleaningTracker$Reaper.class{}}}.
The inner class {{Reaper}} in {{FileCleaningTracker}} is rather simple:
[https://github.com/apache/commons-io/blob/rel/commons-io-2.15.0/src/main/java/org/apache/commons/io/FileCleaningTracker.java#L53-L82]
The last change to this file was done almost 5 months ago in June 2023. This
was before the release of Commons IO 2.14.0 in September 2023. If I decompile
the class files from Commons IO 2.14.0 and 2.15.0, the source code looks
identical.
But the binary class files are not identical. The one for 2.14.0 is 1614 bytes
in size, while the one for 2.15.0 has a size of 1644 bytes (+30 bytes). This
could be explained by the fact that the build for 2.14.0 was running Maven on
Java 17 and the build for 2.15.0 on Java 21, both presumably using the Java
compiler shipped with these Java versions. However, both builds were correctly
targeting Java 8 (class file version 52).
If I use {{javap}} to dump the content of the class files (with all extra flags
to include as much information as possible), the constructor for inner class
{{Reaper}} seems to have some extra metadata associated with its method
parameters.
2.14.0:
{noformat}
org.apache.commons.io.FileCleaningTracker$Reaper(org.apache.commons.io.FileCleaningTracker);
descriptor: (Lorg/apache/commons/io/FileCleaningTracker;)V
flags: (0x)
Code:
[...]{noformat}
2.15.0:
{noformat}
org.apache.commons.io.FileCleaningTracker$Reaper(org.apache.commons.io.FileCleaningTracker);
descriptor: (Lorg/apache/commons/io/FileCleaningTracker;)V
flags: (0x)
Code:
[...]
MethodParameters:
Name Flags
final synthetic{noformat}
If you look at the source code, you can see that the inner class has only a
no-arg constructor. But the binary code actually expects the method to receive
a reference to an instance of the outer class. I assume this is how instances
of inner classes get to know their parent/outer instance. This is a synthetic
parameter without a defined name (see the "" above). I assume that
this "missing" name is what breaks your Android build. If Android's Jetifier
tries to process the content of the class file, it doesn't expect to find a
nameless parameter. Similar issues have been reported for other tools, even for
components of the JDK itself (see
[JDK-8304837|https://bugs.openjdk.org/browse/JDK-8304837] for an example). If
my assumption would be true, you will have to wait for an update of Android's
Jetifier to have this issue fixed.
> Commons IO v2.15.0 is breaking android builds
> -
>
> Key: IO-819
> URL: https://issues.apache.org/jira/browse/IO-819
> Project: Commons IO
> Issue Type: Bug
>Affects Versions: 2.15.0
> Environment: java --version
> openjdk 11.0.21 2023-10-17 LTS
> OpenJDK Runtime Environment Zulu11.68+17-CA (build 11.0.21+9-LTS)
> OpenJDK 64-Bit Server VM Zulu11.68+17-CA (build 11.0.21+9-LTS, mixed mode)
>
> Mac OS 14.1 on Apple Silicon
>Reporter: Pranshu
>Priority: Major
> Attachments: Screenshot 2023-10-27 at 00.07.46.png, stacktrace.txt
>
>
> Hey we are using commons +commons-io:commons-io+ java package in out React
> Native app on the android side.
> Apparently the recently releases version v2.15.0 is breaking android builds,
> whereas versions <= v2.14.0 works well.
> Steps to Repro
> 1. Create a RN app
> npx react-native init CommonsIORepro
> 2. Add commons-io dep android/{*}app{*}/build.gradle
> dependencies{
> implementation "commons-io:commons-io:2.15.0"
> }
>
> 3. yarn run start
> 4. In a new terminal - yarn run android
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (FILEUPLOAD-294) Link "Source repository" is broken on project website
[ https://issues.apache.org/jira/browse/FILEUPLOAD-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17343111#comment-17343111 ] Stephan Markwalder commented on FILEUPLOAD-294: --- Hi [~arturobernalg] The issue indeed has be fixed. Thanks! Ste PS: Now the "Team" link is broken :). It links to [https://commons.apache.org/proper/commons-fileupload/team-list.html] which does not exist. If the strategy is the same (to link to the page below "Project Documentation > Project Information"), the link should be [https://commons.apache.org/proper/commons-fileupload/team.html] . > Link "Source repository" is broken on project website > - > > Key: FILEUPLOAD-294 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-294 > Project: Commons FileUpload > Issue Type: Bug >Reporter: Stephan Markwalder >Priority: Minor > > The link behind "Source repository" is broken: > [https://commons.apache.org/proper/commons-fileupload/source-repository.html] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FILEUPLOAD-295) DiskFileItem: getStoreLocation() may return non-existing file
[
https://issues.apache.org/jira/browse/FILEUPLOAD-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16775950#comment-16775950
]
Stephan Markwalder commented on FILEUPLOAD-295:
---
Hi Jochen,
I'm ok if this bug is not fixed. It is indeed an edge case. We have been
running into it after upgrading from version 1.3.3 to version 1.4 (in which
FILEUPLOAD-258 has been fixed).
Before, we have been using a sizeThreshold of 0 for a very long time, assuming
that this would cause DiskFileItem to always store data on disk, never in
memory. This was our fault no 1. Unfortunately, the JavaDoc for DiskFileItem's
constructor is not very precise:
{quote}{{sizeThreshold}} - The threshold, in bytes, below which items will be
retained in memory and above which they will be stored as a file.
{quote}
But what happens when the item size is equal to the threshold? :)
Our fault no 2 then was that people have used the return value of
DiskFileItem.getStoreLocation() without a check of DiskFileItem.isInMemory()
upfront (because of the assumption made above).
Together, those two faults have lead to NullPointerExceptions in our code after
the upgrade to version 1.4.
When analyzing the issue, I though that it would be sufficient to set
sizeThreshold to -1. No matter what the actual file size will be, it is for
sure 0 or greater. According to JavaDoc, this then should guarantee that items
will be stored as files on disk. But when writing some tests for DiskFileItem
to explore how it deals with empty files, we noticed that it behaves
differently depending on whether/how data is written into the DiskFileItem's
OutputStream. In some cases, an empty file is created, in others not.
Unfortunately, DiskFileItem then somehow is in an inconsistent state.
isInMemory() returns false, getStoreLocation() returns a File object, but the
file does not exist. As a result, we have seen FileNotFoundExceptions in some
of our components, even the ones where people have thought about an upfront
check with isInMemory(). Our "fix" now is to not trust DiskFileItem and the
information it returns for isInMemory() or getStoreLocation(), but always go
for an extra check whether the file actually exists.
If this bug is not fixed, it has at least been filed once. If other people run
into the same or a similar issue when upgrading to 1.4, they at least now have
a chance to find this ticket and maybe get some insights in how to solve them
for themselves.
> DiskFileItem: getStoreLocation() may return non-existing file
> -
>
> Key: FILEUPLOAD-295
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-295
> Project: Commons FileUpload
> Issue Type: Bug
>Affects Versions: 1.4
>Reporter: Stephan Markwalder
>Priority: Minor
>
> *How to reproduce*
> # Create a DiskFileItem with threshold set to -1 (force save to disk).
> # Get OutputStream from DiskFileItem.
> # Close OutputStream without calling any write(...) method (e.g., because
> the uploaded file is empty).
> # Test the return value of the following methods:
> ** isInMemory() --> returns false (OK)
> ** getSize() --> returns 0 (OK)
> ** getStoreLocation() --> returns a File object (OK), but the file does not
> exist (FAILURE).
> I think this is an inconsistency. If isInMemory() returns false adn
> getStoreLocation() returns a File object, the file should also exist.
> Java code (run with -ea to enable assertions):
> {code:java}
> // create a DiskFileItem
> int sizeThreshold = -1; // always store to disk
> File repository = null; // use temporary folder
> DiskFileItem item = new DiskFileItem("file", "text/plain", false, "file.txt",
> sizeThreshold, repository);
> OutputStream outputStream = item.getOutputStream();
> // do not write to stream <-- IMPORTANT
> outputStream.close();
> // assert that data has been stored to disk
> assert !item.isInMemory(); // pass
> assert item.getSize() == 0; // pass
> assert item.getStoreLocation() != null; // pass
> assert item.getStoreLocation().isFile(); // fails
> {code}
> When adding a call to outputStream.write(new byte[0]), the behavior changes
> and the empty file is created on disk.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (FILEUPLOAD-295) DiskFileItem: getStoreLocation() may return non-existing file
Stephan Markwalder created FILEUPLOAD-295:
-
Summary: DiskFileItem: getStoreLocation() may return non-existing
file
Key: FILEUPLOAD-295
URL: https://issues.apache.org/jira/browse/FILEUPLOAD-295
Project: Commons FileUpload
Issue Type: Bug
Affects Versions: 1.4
Reporter: Stephan Markwalder
*How to reproduce*
# Create a DiskFileItem with threshold set to -1 (force save to disk).
# Get OutputStream from DiskFileItem.
# Close OutputStream without calling any write(...) method (e.g., because the
uploaded file is empty).
# Test the return value of the following methods:
** isInMemory() --> returns false (OK)
** getSize() --> returns 0 (OK)
** getStoreLocation() --> returns a File object (OK), but the file does not
exist (FAILURE).
I think this is an inconsistency. If isInMemory() returns false adn
getStoreLocation() returns a File object, the file should also exist.
Java code (run with -ea to enable assertions):
{code:java}
// create a DiskFileItem
int sizeThreshold = -1; // always store to disk
File repository = null; // use temporary folder
DiskFileItem item = new DiskFileItem("file", "text/plain", false, "file.txt",
sizeThreshold, repository);
OutputStream outputStream = item.getOutputStream();
// do not write to stream <-- IMPORTANT
outputStream.close();
// assert that data has been stored to disk
assert !item.isInMemory(); // pass
assert item.getSize() == 0; // pass
assert item.getStoreLocation() != null; // pass
assert item.getStoreLocation().isFile(); // fails
{code}
When adding a call to outputStream.write(new byte[0]), the behavior changes and
the empty file is created on disk.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (FILEUPLOAD-294) Link "Source repository" is broken on project website
Stephan Markwalder created FILEUPLOAD-294: - Summary: Link "Source repository" is broken on project website Key: FILEUPLOAD-294 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-294 Project: Commons FileUpload Issue Type: Bug Reporter: Stephan Markwalder The link behind "Source repository" is broken: [https://commons.apache.org/proper/commons-fileupload/source-repository.html] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
