Test for JDK-5108778 Too many instances of java.lang.Boolean created in Java application

[Stuart Marks]

On 10/4/15 12:00 AM, Sebastian Sickelmann wrote:
>> (I believe that people are running Findbugs over the JDK regularly,
>> but we don't really have a workflow for processing diagnostics that it
>> generates.)
> That would be the best case. It checks the source-code and not the
> resulting classfiles. It would be much better if we could integrate
> Findbugs somehow.

OK. My main point here is that there are static analysis frameworks out there 
already, such as FindBugs, SonarQube, etc., so we needn't develop duplicate 
technology for static analysis and put it into the regression suite.

(Note that FindBugs analyzes bytecodes, not source code, but it still falls into 
the general category of static analysis tools.)

>> An interesting exercise would be to add the @Deprecated annotation to
>> the Boolean constructor and build the JDK and see how many warnings
>> result. That might be a quick way to find the code that needs to be
>> fixed.
> I have tried it, but i think i have done something wrong.
> I build via
>
>       make clean JAVAC_WARNINGS="-Xlint:all -Xmaxwarns 10000"
> DISABLE_WARNINGS="-Xlint:all" LOG=info images
> CONF=linux-x86_64-normal-server-release
>
> And looked at the resulting build.log but get only one warning: [...]

Hm, strange. I did

     make clean JAVAC_WARNINGS='-Xlint:deprecation -Xmaxwarns 10000' \
     DISABLE_WARNINGS='-Xlint:deprecation -Xmaxwarns 10000' images

and

     grep 'warning: \[deprecation\] Boolean' logfile

results in 94 matches. That's two more than your 92, since I added @Deprecated 
to the Boolean(String) constructor as well, and there are warnings for that. But 
my results match what you expected, which is good.

It could be that -Xlint:all adds so many other warnings that it hits the default 
limit of 100 very quickly, and the deprecation warnings are omitted.

>> 2. Boolean is a special case since there are exactly two boxed boolean
>> values. Possibly Byte as well, since all Byte values are cached. (See
>> spec for Byte.valueOf(byte).) There is a moderate preference for
>> valueOf() over the constructors of Character, Integer, and Short,
>> since those cache a subset of values. It's not clear to me these are
>> worth worrying about though. (Long, Float, and Double don't have caches.)
> I agree. Only Byte and maybe Character and Short should be considered. I
> have looked at all Wrappertypes and find that also Long has a Cache. I
> think Character is worth to think about, because i think in most cases
> the cached area is used.
>
> Is there a big downside of using autoboxing/valueOf for all Classes?

At this point I'd say that in an overwhelming number of cases, autoboxing is 
preferable to the explicit boxing and unboxing calls like Integer.valueOf() and 
Integer.intValue(). And both of autoboxing and explicit boxing are preferable to 
calling the constructors.

I can only think of a few cases where it *might* be useful to have explicit 
un/boxing calls, such as if the boxed object is nullable (as in one of the cases 
in your macosx-port-dev review), or if somebody does something that is truly 
sensitive to the identity of a box, such as synchronization. But I'd argue that 
such code is bad anyway and should be fixed.

A related point, which Stephen Colebourne has taken up on core-libs-dev, is 
whether and how many of the box constructors should be deprecated.

>> 3. I would say that it's more likely that future JDK enhancements
>> would be able to optimize auto-boxing than explicit method calls that
>> deal with boxed values.
> So Integer, Long, Float and Double and maybe Short should be changed not
> before we can say what is the best optimization strategy for those.

Sorry, I didn't really finish my thought. Suppose there's a call like this:

    Integer box = new Integer(17);

It provides an immediate benefit to convert this to

    Integer box = Integer.valueOf(17);

since the library can use its cache. But there's still a method call. If the 
code is converted to this:

    Integer i3 = 17;

there is an additional immediate benefit of reducing code clutter. Plus, there 
is a potential future benefit that the compiler might be able to optimize this 
more than an explicit method call. This is speculation on my part, though.

Anyway, since autoboxing reduces code clutter, and since it *might* enable 
better optimization in the future, I'd say that we should convert most code 
directly to autoboxing.

>> 4. Unfortunately, different portions of code are handled by different
>> groups, and are thus reviewed on different mailing lists. I think
>> asking on jdk9-dev, as you've been doing, about where things need to
>> be reviewed, is the right thing to do.
> That is no problem. Should we create multiple "sub-task" in JBS for each
> area ?

Once you've developed a patch for a particular area, you'll need a person to 
sponsor the change for you. This is the person who will handle the actual 
commit. Presumably that person could create JIRA sub-tasks for you.

If you eventually get the Author role, you can apply for a JIRA account, and at 
that point you can create and modify the sub-tasks yourself.

s'marks