RFR: 5108778 Too many instances of java.lang.Boolean created in Java application(core-libs)
lange.fabian at gmail.com
Thu Oct 8 17:30:18 UTC 2015
I am all for micro optimizations that do make sense, even if their impact
might be low, but I disagree with deprecating the Boolean constructor.
Using it, while not being the most efficient, is not a problem, and I would
say in almost all application and workloads not an issue worth discussing.
What I consider a problem is making the Wrapper types asymetric by removing
the constructor (that is the ultimate goal of deprecation).
I do realize Dr. Deprecator suggested doing this, but I do not agree this
Also this would be a spec change, right?
> Actually I am searching through the JBS for low hanging fruits.
> Right now i am looking through the openjdk-sources and try to evaluate
> if i can make something about JDK-5108778.
> Please find my webrevs for the jdk, jaxp, jaxws and corba repos at:
> I hope for jaxp,jaxws and corba this mailinglist is also the right place.
> The Boolean constructors are @Deprecated now so that we get
> compile-warnings for the uses. See also  and 
> For the change in XBoolean (jaxp) i thought it would be more readable
> than the autoboxing solution.
> The changes in jaxws are in a generated class. I would love to fix this
> in the source, but i have no clue where the real source could be.
> For all calls against
> com.sun.tools.corba.se.idl.constExpr.Expression.value(Object) i used the
> valueOf solution instead of the autoboxing for better readability.
> For some general discussion on regression-tests for this please find the
> thread in discuss and for the general suggestion to make more
> wrapper-type-constructors deprecated find  at core-libs-dev.
> -- Sebastian
More information about the core-libs-dev