3

I was looking for a way to parse a string to get an int out, and stumbled upon:

NumberUtils.toInt("blah",99);

I typed it into my IDE and it auto imported this for me:

import autovalue.shaded.org.apache.commons.lang.math.NumberUtils;

So I am curious to know, what is autovalue.shaded about and why is it 'shading' org.apache.commons?

And is it safe to use this to fulfil my need for NumberUtils?

I tried searching but I am not familiar with the assumed knowledge that search results brought up such as shaded jar and uber jar.

enter image description here

Tunaki
  • 132,869
  • 46
  • 340
  • 423
Mendhak
  • 8,194
  • 5
  • 47
  • 64

1 Answers1

1

"Shading" is the process of embedding dependency classes within your own jar file. AutoValue does this in part to limit the transient dependencies, but also to ensure version stability of their dependencies.

You can read more about Shading here: https://maven.apache.org/plugins/maven-shade-plugin/

I would highly recommend against using the shaded dependency in your code, as it means you no longer have control of the dependency version. You can simply add the dependency directly, giving you control of when it's updated.

You might also want to check your gradle dependencies to make sure you don't have AutoValue in your compile target. I see from your other dependencies that this is an Android project, and if AutoValue is on the compile target then you're going to have a far bigger APK then you want. It should be included on the Annotation Processor classpath, via apt, so that it's classes aren't included in your final product. Hugo Visser has a nice gradle plugin for enabling the apt target for Android projects.

rharter
  • 2,495
  • 18
  • 34
  • Thanks, this is making some sense. I haven't used `apt` but I'm using Proguard, would that accomplish the same thing - prevent the shady jars from appearing in the final APK? – Mendhak Mar 25 '16 at 23:55
  • 1
    Proguard might do some of it, but that's not really the right solution. It's adding more complexity and challenge (debugging, debug build complexity) to solve a problem that's simply including a dependency that shouldn't be there. It'd be kind of like putting espresso, or other testing libs in the compile scope, then using proguard to get rid of them. The right solution is to just put it where it goes. Hugo's android-apt plugin makes it 2 new lines (one in each build.grade file) and that's about it. – rharter Mar 27 '16 at 05:30
  • Thanks for the explanation(s) – Mendhak Mar 27 '16 at 21:10