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:

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

Huckster

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. – Chicken

@SebastianL Please find my answer, it worked for me – Huckster

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 – Gustation

Answer 1

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

If you have a large amount of files in your .m2 repository, you can fasten the removal by using the find command:

find  ~/.m2 -name "resolver-status.properties" -exec grep -H -e '\u0000' {} \; | sed -r 's/:.*$//g' | xargs rm

Neuron

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. – Extant

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" {} \; – Mcgough

For me it was one of the _remote.repositories files that was broken – Christianly

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. – Andi

Thanks to Manish Bansal for his help, I was struggling w/ this issue on windows!! – Persistent

A combination of all these suggestions: grep -lrnw ~/.m2/repository --include 'resolver-status.properties' -e '\u0000' | xargs rm – Axes

sometime | xargs rm doesn't work so better manually delete the folders under ~/m2/com/xyz etc and rebuild the project can help. – Unwilled

Answer 2

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

1. 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.

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

3. Now find path of the file that caused the issue.

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

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

Epexegesis

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: spin.atomicobject.com/2020/08/20/maven-debugging-intellij – Heflin

Does not work if you have compiled dependecies. – Flood

Java should consider adding option to reveal file path itself rather than debugging and putting breakpoints all the time. – Fakir

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! – Landes

Answer 3

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.

Kelter

[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 – Kelter

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 – Gustation

Answer 4

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.

Barbwire

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? – Schnorrer

I get this problem over and over again! – Parsec

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. – Blakely

Answer 5

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.

Malapropism

For me it was one of the _remote.repositories files that was broken – Christianly

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. – Malapropism

@Malapropism 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???! – Malnourished

Answer 6

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

Pau

That could have worked but not a great choice if you already have a big repo to be downloaded again. – Fakir

I would do this and wait for 5 minutes over spending whole day to pin-point the bad dependency!! – Pau

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 – Gustation

Answer 7

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.

Shewchuk

Answer 8

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

Unharness

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://mcmap.net/q/181761/-java-lang-illegalargumentexception-malformed-uxxxx-encoding-while-mvn-install – Fakir

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 – Gustation

Answer 9

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!

Laudation

Answer 10

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.

Osteoclast

This finds and deletes the files in one (powershell command): Get-ChildItem -Recurse -Filter "resolver-status.properties" | Select-String -Pattern "u0" | Select-Object -Unique Path | Foreach-Object { Remove-Item $_.Path } – Epexegesis

Answer 11

deleting "resolver-status.properties" under

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

resolve problem for me

Goddamn

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. – Arboreal

Answer 12

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

Legra

Answer 13

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

Huckster

Answer 14

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.

Pinetum

Although very general answer it could written better to emphasize the solution. I am not sure f rebuild is an actual answer here – Phototelegraphy

Answer 15

Upgrading from 3.8.1 to 3.8.6 fixed the problem.

Seattle

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. – Seattle

Answer 16

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

Lessee

Answer 17

First, switch to directory

cd ~/.m2

then execute command line :

find ./ -name resolver-status.properties |xargs -I {} ls -l {}

it will delete error files which was created by error building, then it works.

Whippersnapper

Answer 18

Some missing info while trying to fetch dependency. Steps to fix:

1. You can get more info about the dependency with issue by running this-

mvn clean install -e -X

2. Just before the final build failure error, you'll find dependency with the issue. Msg would be like-

Could not find metadata com.xx1.xx2.service-clients::1.0.0-SNAPSHOT/maven-metadata.xml in local (/Users/<user.name>/.m2/repository)

3. Go to /Users/<user.name>/.m2/repository, and delete the dependency path-

cd /Users/<user.name>/.m2/repository

rm -r com.xx1.xx2.service-clients

4. On rerun of mvn clean install, same dependency will be downloaded from source to local.

Hamza

Answer 19

1. In my case, I execute the command mvn -X clean, after that, go to ~/.M2/repository location. I have deleted the all the previous files in the repository.

2. Again execute the mvn clean install command then project build successfully.

Pianette

Answer 20

A quick fix method:

grep -rl --include="*.properties" "u00" . // check file to delete.

grep -rl --include="*.properties" "u00" .|xargs rm // do delete malformed file.

Excute it in your m2 repository dir, then re-run maven cmd.

Wollastonite