java.lang.IllegalArgumentException: Malformed \uxxxx encoding while mvn install

Question

While running mvn install in my project, I end up with this error. While a lot of answers and resources point out errors in / vs \, I want to mention that I have no local changes and this repo just works fine for others in my team. It worked fine for me as well before.

Running on Mac Os 10.15.7 with JDK 1.8.0_291

Please find the full stacktrace:

[ERROR] Malformed \uxxxx encoding.
java.lang.IllegalArgumentException: Malformed \uxxxx encoding.
    at java.util.Properties.loadConvert (Properties.java:672)
    at java.util.Properties.load0 (Properties.java:455)
    at java.util.Properties.load (Properties.java:408)
    at org.eclipse.aether.internal.impl.TrackingFileManager.read (TrackingFileManager.java:56)
    at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read (DefaultUpdateCheckManager.java:511)
    at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata (DefaultUpdateCheckManager.java:250)
    at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve (DefaultMetadataResolver.java:302)
    at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata (DefaultMetadataResolver.java:181)
    at org.apache.maven.repository.internal.DefaultVersionRangeResolver.getVersions (DefaultVersionRangeResolver.java:198)
    at org.apache.maven.repository.internal.DefaultVersionRangeResolver.resolveVersionRange (DefaultVersionRangeResolver.java:148)
    at org.apache.maven.repository.internal.DefaultModelResolver.resolveModel (DefaultModelResolver.java:197)
    at org.apache.maven.model.building.DefaultModelBuilder.readParentExternally (DefaultModelBuilder.java:1070)
    at org.apache.maven.model.building.DefaultModelBuilder.readParent (DefaultModelBuilder.java:846)
    at org.apache.maven.model.building.DefaultModelBuilder.build (DefaultModelBuilder.java:337)
    at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom (DefaultArtifactDescriptorReader.java:292)
    at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor (DefaultArtifactDescriptorReader.java:171)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.resolveCachedArtifactDescriptor (DefaultDependencyCollector.java:538)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.getArtifactDescriptorResult (DefaultDependencyCollector.java:523)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency (DefaultDependencyCollector.java:410)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency (DefaultDependencyCollector.java:362)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process (DefaultDependencyCollector.java:349)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.doRecurse (DefaultDependencyCollector.java:506)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency (DefaultDependencyCollector.java:458)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency (DefaultDependencyCollector.java:362)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process (DefaultDependencyCollector.java:349)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.doRecurse (DefaultDependencyCollector.java:506)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency (DefaultDependencyCollector.java:458)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency (DefaultDependencyCollector.java:362)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process (DefaultDependencyCollector.java:349)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.doRecurse (DefaultDependencyCollector.java:506)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency (DefaultDependencyCollector.java:458)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency (DefaultDependencyCollector.java:362)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process (DefaultDependencyCollector.java:349)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.doRecurse (DefaultDependencyCollector.java:506)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency (DefaultDependencyCollector.java:458)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency (DefaultDependencyCollector.java:362)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process (DefaultDependencyCollector.java:349)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.doRecurse (DefaultDependencyCollector.java:506)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency (DefaultDependencyCollector.java:458)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency (DefaultDependencyCollector.java:362)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process (DefaultDependencyCollector.java:349)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.doRecurse (DefaultDependencyCollector.java:506)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency (DefaultDependencyCollector.java:458)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency (DefaultDependencyCollector.java:362)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process (DefaultDependencyCollector.java:349)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.doRecurse (DefaultDependencyCollector.java:506)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency (DefaultDependencyCollector.java:458)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency (DefaultDependencyCollector.java:362)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process (DefaultDependencyCollector.java:349)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies (DefaultDependencyCollector.java:254)
    at org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies (DefaultRepositorySystem.java:284)
    at org.apache.maven.project.DefaultProjectDependenciesResolver.resolve (DefaultProjectDependenciesResolver.java:169)
    at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies (LifecycleDependencyResolver.java:243)
    at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies (LifecycleDependencyResolver.java:147)
    at org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved (MojoExecutor.java:248)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:202)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:78)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:567)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
[ERROR]

I have already tried the following:

Reinstalled java on my mac
Reinstalled maven
Tried to invalidate cache and restart IntelliJ multiple times.

I having similar issues. Rolled back all local changes and still got the issue. Worked earlier today and pretty sure I haven't had any updates. — Sebastian L, Jun 16 '21 at 14:33
Windows User: Search for resolver-status.properties files in entire .m2 folder using file-explorer then delete all those searched files and rerun maven command. It will start working — Ziaullhaq Savanur, Jul 14 '23 at 11:25

score 167 · Answer 1 · edited Jun 22 '22 at 07:15

167

For me it turned out to be a corrupted dependency as well.
I did not want to go through the process of setting up the debugger, so decided to look for files containing \u0000 in my ~/.m2 directory by running:

grep -rnw ~/.m2 -e '\u0000'

after that you will get the files which are corrupted, delete those files and then build the maven.

Note that you have to specify your repository folder if you configured it different to the default. Read your ~/.m2/settings.xml and use the value from localRepository instead. E.g.:

<settings>
  <localRepository>/else/where</localRepository>

use:

grep -rnw /else/where -e '\u0000'

and if you want all these files removed, pipe the file names to xargs rm:

grep -lrnw /else/where -e '\u0000' | xargs rm

edited Jun 22 '22 at 07:15

bebbo

2,830
1
32
37

answered Sep 15 '21 at 12:08

Roy van Santen

2,361
3
10
11

8

This is what worked for me. On macOS, I ran "grep -r -e '\u0000' ~/.m2" and it yielded the correct resolver-ststus.properties that, after deletion of the dependency, was replaced by a correct one and things worked. – Jubz Sep 24 '21 at 10:09
3

I need to brush up on `grep` options. This is more concise than what I did: ```find ~/.m2 -name "resolver-status.properties" -print -exec grep "u0" {} \;``` – triple.vee Dec 13 '21 at 03:30
For me it was one of the _remote.repositories files that was broken – mvmn Apr 29 '22 at 12:41
13

in case people are struggling in windows, you can run this command inside .m2 directory `FINDSTR /S /M "u0" resolver-status.properties` to findout corrupted files. – Manish Bansal Jun 09 '22 at 10:24
Thanks to Manish Bansal for his help, I was struggling w/ this issue on windows!! – jmuth Jul 19 '22 at 03:41
A combination of all these suggestions: `grep -lrnw ~/.m2/repository --include 'resolver-status.properties' -e '\u0000' | xargs rm` – Kristof Neirynck Aug 10 '22 at 17:56
sometime | xargs rm doesn't work so better manually delete the folders under ~/m2/com/xyz etc and rebuild the project can help. – Rohtash Lakra Mar 01 '23 at 19:34

score 79 · Answer 2 · answered Aug 31 '21 at 19:07

79

To find which file is malformed (as to not have to delete your entire Maven repository) you can debug it like so:

Add a breakpoint to the relevant line in java.util.Properties (as detailed in the error stack trace) and then run any Maven action in debug mode.

When the code hits that breakpoint, find and select TrackingFileManager.read(File) in the call stack.

Now find path of the file that caused the issue.

The file is indeed malformed... Delete the file (and Maven will re-download it during the next action).

The correct file (after having been deleted and re-downloaded):

answered Aug 31 '21 at 19:07

micycle

3,328
14
33

11

This is actually a great answer with the step by step details to find the exact file. Step 1 (adding a breakpoint in IntelliJ and using it with maven) can be setup using the following: https://spin.atomicobject.com/2020/08/20/maven-debugging-intellij/ – ghost Oct 07 '21 at 07:30
Does not work if you have compiled dependecies. – Tarnished-Coder Oct 19 '21 at 17:05
Java should consider adding option to reveal file path itself rather than debugging and putting breakpoints all the time. – Mohammad Faisal Apr 05 '23 at 10:05
That helped a lot, thank you so much – Ann Jun 06 '23 at 09:33
thank you very much for this great answer - it really helped a much to solve our problem. Spring Boot had a really strange error message but the maven build error leaded us to your answer! – Tobias Sporer Jul 07 '23 at 13:56

Alexey Poletaev · Answer 3 · 2021-06-30T11:07:00.770

25

In my case the problem was in the 3rd party library, incorrect charаcters somehow were saved to the resolver-status.properties file (example of incorrect line: maven-metadata-nexus-releases.xml.lastUpda\u0000\u0000\....) which is located under the ~/.m2/repository/path-to-the-library. Just removed the folder with the library and rebuilt the project.

edited Jun 30 '21 at 11:07

answered Jun 30 '21 at 10:59

Alexey Poletaev

351
2
7

1

How do these files get corrupted? Is it a bug with mvn or am I abusing mvn in a way that it shouldn't be used? – joseph Oct 22 '21 at 13:43
1

I get this problem over and over again! – Boris Brodski Oct 28 '21 at 05:28
2

It seems to be a bug in Maven 3.8.1. The issue reappeared again and again even after deleting the libraries from the local Maven repository. Upgrading to latest Maven 3.8.3 and rebuilding with that version fixed the problem. – Madjosz Nov 03 '21 at 10:19

Rafi · Answer 4 · 2022-04-05T10:01:23.857

Actually most of those answers are correct, but a little bit incomplete. Message shows up, because resolver-status.properties files get corrupted and they contain \u0000 as shown in micycle's answer. It sometimes helps to delete corrupted files and rerun maven command. Sometimes problem disappears and sometimes not. The question emerges WHY those files get corrupted. Well, it seems that maven contains a bug in resolver: https://issues.apache.org/jira/browse/MRESOLVER-216

It seems that synchronization of multiple threads responsible for resolving dependencies is broken and in some conditions multiple threads resolve the same artifact and they break resolver-status.properties as shown by micycle.

In case your build still does not complete successfully despite deleting broken files you might want to limit resolver threads to one. To do that use JVM property:

-Daether.metadataResolver.threads=1

If you are using IntelliJ Idea use Settings->Build,Execution,Deployment->Maven->Runner field VMOptions:

After making this change remember to delete broken files (or whole .m2 directory) because once the files become corrupted they won't be fixed. Then rerun your Maven build.

For me it was one of the _remote.repositories files that was broken — mvmn, Apr 29 '22 at 12:42
Please note that today I've found a file that was broken, because it contained just `\u`, so not only string `\u0000` may break your files. — Rafi, Jan 05 '23 at 13:46
@Rafi It's total crazy, in my case it breaks with c:\user\... while c:\temp\... is working only because there is this u check: if(aChar == 'u') in java.util.Property loadConvert() This is some kind of a bug is it???! — Perry45, Feb 09 '23 at 18:00

score 18 · Answer 5 · answered Jul 26 '21 at 14:56

18

I removed all artifacts from my ~/.m2 directory and re-ran mvn build. This time, build succeeded!

answered Jul 26 '21 at 14:56

Sagar

5,315
6
37
66

1

That could have worked but not a great choice if you already have a big repo to be downloaded again. – Mohammad Faisal Apr 14 '22 at 11:36
1

I would do this and wait for 5 minutes over spending whole day to pin-point the bad dependency!! – Sagar Sep 06 '22 at 14:19
Windows User: Search for resolver-status.properties files in entire .m2 folder using file-explorer then delete all those searched files and rerun maven command. It will start working – Ziaullhaq Savanur Jul 14 '23 at 11:28

score 18 · Answer 6 · answered Jan 24 '23 at 09:08

18

I wrote an answer for another Question, this is similar issue. Below Solution worked for me.

go to your .m2 directory in home directory and for every dependence delete the "resolver-status.properties". You can do that using

find ~/.m2/ -name resolver-status.properties -delete

It will find all "resolver-status.properties" and -delete flag will delete them.

Now reload maven project.

answered Jan 24 '23 at 09:08

mahipalkeizer

781
4
8

[FYI] I got malformed issue in one of my dependency while running install in Intellij, i deleted that one resolver-status.properties file. After that i got issue with same file in another dependency. So i ran this command to delete all such resolver-status.properties files and it worked – mahipalkeizer Feb 08 '23 at 15:28
1

Windows User: Search for resolver-status.properties files in entire .m2 folder using file-explorer then delete all those searched files and rerun maven command. It will start working – Ziaullhaq Savanur Jul 14 '23 at 11:28
wow, excellent. work for me – Sheldon Wei Aug 17 '23 at 07:12

score 6 · Answer 7 · answered Dec 10 '21 at 08:31

6

removing .m2 folder and re-installing the dependency worked for me.

answered Dec 10 '21 at 08:31

patel

99
2
6

1

That could have worked but not a great choice if you already have a big repo to be downloaded again. Also, this is same answer as https://stackoverflow.com/a/68532125/725306 – Mohammad Faisal Apr 14 '22 at 11:37
Windows User: Search for resolver-status.properties files in entire .m2 folder using file-explorer then delete all those searched files and rerun maven command. It will start working – Ziaullhaq Savanur Jul 14 '23 at 11:30

score 6 · Answer 8 · answered Jan 30 '23 at 09:41

6

Go to .m2 repository, then run the below cmd from there FINDSTR /S /M "u0" resolver-status.properties This will enlist all the corrupted resolver properties files, delete them and you are good to GO!

answered Jan 30 '23 at 09:41

Purba

61
1
2

Evghenii Racila · Answer 9 · 2022-12-21T14:55:09.763

4

You don't actually need to delete the whole local maven repo, just the resolver-status.properties files in there, for mac:

find .m2/ -name resolver-status.properties -delete

works as a charm. I've even added an alias, as I use it pretty frequently, once in a couple of weeks.

edited Dec 21 '22 at 14:55

answered Dec 21 '22 at 14:51

Evghenii Racila

56
4

score 3 · Answer 10 · answered Mar 09 '22 at 17:19

3

deleting "resolver-status.properties" under

.m2\repository\kr\motd\maven\os-maven-plugin

resolve problem for me

answered Mar 09 '22 at 17:19

fsimone

141
1
1
6

2

Your answer could be improved with additional supporting information. Please [edit] to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers [in the help center](/help/how-to-answer). – Community Mar 10 '22 at 06:27

viveknaskar · Answer 11 · 2023-08-11T09:11:29.880

Here is the solution for this issue for Windows users (didn't see any better solution for Windows users).

Open command prompt from .m2/repository/ folder and run the below FINDSTR command:

FINDSTR /S /M "u0" resolver-status.properties

This command will filter out the resolver-status.properties that has corrupt encoding.

Once you find the list of resolver-status.properties files, just delete them and then build your app.

score 2 · Answer 12 · answered Jul 28 '21 at 08:24

Problem is likely in one of your dependencies (same as suggested by Alexey). For me the issue was to find the right dependency that got resolver-status.properties corrupted. What helped was running mvn clean install in debug mode (using Intellig configuration debug) and putting th endpoint in Properties.java (exact line should be in a stacktrace when you run with -e or -X option). In debug you can easily find which dependency is corrupted and remove only this dependency instead of entire .m2 catalog

score 1 · Answer 13 · answered Jun 16 '21 at 16:23

Found out that the java version that maven was pointing to was different from the java version I was using. Seems like maven always points to the latest version of java.

First check if this is the issue by running mvn --version

If there is a mismatch in java version set JAVA_HOME by running

export JAVA_HOME=$(/usr/libexec/java_home)

Now run mvn --version. Maven should point to the right Java version.

When you run mvn install next time, maven automatically picks up the version set in JAVA_HOME

score 0 · Answer 14 · edited Sep 21 '22 at 21:40

0

In my case, when we build the project or run any Maven command for the first time, dependencies or properties are getting saved in the repository folder (default location: ~/.m2/repository).

I have used multiple Maven and Java versions in the past, so some files are corrupted or valid for those specific versions.

I deleted this "repository" folder then built the project with Maven, and this time it built successfully.

edited Sep 21 '22 at 21:40

Jesse

1,386
3
9
23

answered Sep 14 '22 at 14:16

SHRAWAN CHOUDHARY

1

Although very general answer it could written better to emphasize the solution. I am not sure f rebuild is an actual answer here – b10n1k Sep 20 '22 at 06:16

score 0 · Answer 15 · answered Jan 05 '23 at 17:51

0

Just do a Global search for resolver-status.properties and delete that file and restart the IDE. That should resolve the issue.

answered Jan 05 '23 at 17:51

Mukunda Gaddam

1

score -1 · Answer 16 · answered Dec 06 '22 at 09:50

-1

Upgrading from 3.8.1 to 3.8.6 fixed the problem.

answered Dec 06 '22 at 09:50

Shaolin

154
10

Regarding the downvote: I'm the only one who solved this problem with a newer version of maven. It's also mentioned by other people in comments in this question. The maven resolver was upgraded in 3.8.6 and it looks that it solved the problem. – Shaolin Jun 09 '23 at 14:11

java.lang.IllegalArgumentException: Malformed \uxxxx encoding while mvn install

16 Answers16

Linked

Related