Source code analysis: calls to wrapper class constructors

Brian Goetz brian.goetz at oracle.com
Mon Oct 26 17:28:24 UTC 2020


Overall, I find this data quite encouraging.  It says that when we 
finally deprecate something, the warnings get noticed, and a lot of uses 
are fixed within a few years.  Surely raising DepCon to FOR_REMOVAL will 
have additional effect.

On 10/23/2020 9:20 PM, Dan Smith wrote:
> One more data-gathering exercise: I took a closer look at some popular Maven projects to see how they've evolved in their use of wrapper constructors.
>
> -----
>
> junit:junit
> < 4.12 (<2014): many problems in junit.framework.Assert & org.junit.Assert
> 4.12-4.13 (2014-2020): a few problems in junit.framework.Assert
> 4.13.1 (2020): fixed
>
> org.ow2.asm:asm
> < 6.0 (<2017): many problems in org.objectweb.asm.ClassReader & Opcodes
> 6.0 (2017): problem in org.objectweb.asm.Opcodes
> 6.1+ (2018+): no problems
>
> commons-lang:commons-lang & org.apache.commons:commons-lang3
> < 3.0 (<2011): many problems
> 3.0 (2011): many problems
> 3.1+ (2011+): fixed
>
> com.fasterxml.jackson.core:jackson-databind
> < 2.9.0 (<2017): one call in com.fasterxml.jackson.databind.deser.std.NumberDeserializers
> 2.9.0+ (2017+): fixed
>
> javax.xml.bind:jaxb-api
> 1.0 (2006): two problems
> 2.0+ (2006+): fixed
>
> Log4j (log4j:log4j & org.apache.logging.log4j:log4j-core)
> < 2.0 (<2014): multiple problems
> 2.0+ (2014+): no issues
>
> org.mockito:mockito-core
> < 2.1.0 (<2016): many problems, including in repackaged ASM
> 2.1.0+ (2016+): fixed
>
> org.scala-lang:scala-library
> < 2.8.0 (<2010): problems in scala.Console$, scala.Predef$, scala.mobile.Code, scala.runtime.BoxesUtility
> 2.8.0-2.9.3 (2010-2013): one issue, scala.actors.threadpool.locks.ReentrantReadWriteLock
> 2.10.0+ (2012+): fixed
>
> org.hibernate:hibernate-core
> < 4.0 (<2011): many, many, problems
> 4.0.0-5.4.22 (2011-2020): a few problems
> 6.0.0+ (not yet released): fixed
>
> ch.qos.logback:logback-classic
> < 1.0.7 (<2012): lots of problems
> 1.0.7+ (2012): fixed
>
> org.clojure
> < 1.10.0 (<2018): repackages ASM, a few other problems
> 1.1.0.0+ (2018+): fixed
>
> com.google.code.gson
> < 1.4 (<2010): problems in com.google.gson.DefaultInstanceCreators & JsonParser
> 1.4+ (2010+): fixed
>
> org.jetbrains.kotlin:kotlin-stdlib
> < 1.3.0 (<2018): no problems
> 1.3.0+ (2018+): new problems in kotlin.coroutines.jvm.internal.Boxing
>
> No problems:
> org.junit.jupiter:junit-jupiter-api (earliest release 2017)
> com.google.guava:guava (earliest release 2011)
> org.apache.commons.commons-collections4 (earliest release 2013)
> com.fasterxml.jackson.core:jackson-core (earliest release 2012)
> org.slf4j:slf4j-api (earliest release 2006)
> org.slf4j:slf4j-log4j12 (earliest release 2006)
> org.apache.logging.log4j:log4j-core (earliest release 2014)
> commons-io:commons-io (earliest release 2005)
> javax.servlet:javax.servlet-api (earliest release 2011)
> org.apache.httpcomponents:httpclient (earliest release 2009)
>
> -----
>
> It does seem like the deprecation warnings introduced in 9 are working—lots of projects have responded by changing their code.
>
> A few cases worth special attention:
>
> - JUnit 4 was only very recently fixed (and it's in maintenance mode, must clients use 4.11 or 4.12, not 4.13)
>
> - Hibernate still has problems until its coming 6.0 release
>
> - Kotlin added (!) some constructor calls in 2018, and they're still there
>
> - Clojure and ASM were fixed pretty recently
>
> Still, it's a positive sign that only one of these projects is making wrapper constructor calls in its latest sources.
>



More information about the valhalla-spec-observers mailing list