Task :listProductsReleases creates empty file due to MalformedByteSequenceException #1389
Comments
|
After some more debugging, I found that the For some reason, the UTF8Reader is not reporting the error immediately, but corrupts the buffer and continues for one more iteration. This is why I initially thought the error would be at the |
|
Thank you for the investigation, @JojOatXGME! |
|
@hsz Thanks for the info. In my experience, Gradle unfortunately relies a lot on the default encoding when it isn't really appropriate. It looks like specifying the default encoding in the org.gradle.jvmargs=-Xms256m -Xmx512m -XX:MaxMetaspaceSize=384m -Dfile.encoding=UTF-8I guess it is probably a good idea to specify the default encoding anyway to archive consistent builds. See gradle/gradle#12538 for example. In the past, the |
|
I do not think this issue is Gradle-related. XML files should specify encoding in The one who creates xml file should ensure to add |
|
It looks like https://www.jetbrains.com/updates/updates.xml serves a file without |
|
@vlsi, the encoding defaults to Anyway, I agree that Gradle probably works as specified in this case. The expression I still don't like the API design of Gradle which uses the default charset and therefore causes the inconsistent behavior between Linux and Windows. I mean, using a platform dependent charset on files within a project repository is a bug of the build configuration in practically all cases I can think of, which makes it a questionable default. Anyway, that is probably nothing which will be changed as part of this ticket, especially since Gradle uses the default charset consistently at a lot of places. |
That's right. |
|
In fact, the. As the initial scenario failed to provide the proper bullet point character, the |
It is nice, however, imagine the xml Then it would be unfair to reencode the file as It is fine, if you save XML with XML APIs though. The XML writer would use a proper encoding (and/or it would add a proper However, it is just wrong to use |
|
I've filed gradle/gradle#25237 so |
|
Thank you — for now, I'll use the above solution as a workaround. |
|
@JojOatXGME fix is already available in the nightly snapshot. |
|
I tested the snapshot, and it works on my case as well (after removing my workaround above). |
|
FYI, I just noticed that due to adding I was running version 1.14.2. I noticed it because I got an exception after clicking Reload Gradle Project while the XML file was not reachable. It might not be that easy to reproduce because I got the impression that the file is cached by Gradle. Definitely not ideal, but not sure how relevant it is in praxis. I think the Reload still succeeded (not sure). I at least wanted to mention it here. Click to view the exception … |
|
Thanks for spotting! Fixed with 51b0e2b by moving |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
The task
:listProductsReleasescreates an empty file as the result on my system. A silentUnmarshalExceptionorMalformedByteSequenceExceptionis thrown during the task execution. Only a warning is printed. The exception is only visible in debug mode.Log and Stacktrace
To Reproduce
I try to build commit be20be95f16 of nix-idea (branch psicache) on my system. Unfortunatly, I don't know how to reproduce the issue on other systems. While the build fails on my system, it does work on the build server.
Expected behavior
I expected a build failure in
:runPluginVerifierdue to MP-5498, as I have observed it on the build server (https://github.com/NixOS/nix-idea/actions/runs/4975049272/jobs/8901858413?pr=63). However, the issue prevents the Plugin Verifier from beeing started.Also note that the Gradle task
:listProductsReleasesdoes not fail. I would also expect that an exception would fail the task since the result is not valid.Environment
Additional context
During debugging I found out that the plugin tries to parse
idea_product_releases.xmlwhen the exception occures. The plugin is parsingand fails when reading the
win"Download". For some reasonfBufferincom.sun.org.apache.xerces.internal.impl.io.UTF8Reader#read(char[], int, int)contains the char value-107(i.e. 149) instead of 119, which would be the right ASCII value forw.The text was updated successfully, but these errors were encountered: