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

[Stephen Colebourne]

Moving to core-libs:

On 3 October 2015 at 03:20, Stuart Marks <stuart.marks at oracle.com> wrote:
> 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'd really like to see this. Specifically, adding @Deprecated to _all_
constructors on Boolean, Short, Integer, Long, Character, Float,
Double. This may require some additional factory methods to be added.

Doing this for Java 9 would be good preparation for value types. While
the Valhalla team are not currently talking about converting these
classes to values, they are clearly very value-like. Pushing users to
treat them more as values seems like a Good Thing. It might even tip
the balance towards making them actual value types.

Stephen


On 3 October 2015 at 03:20, Stuart Marks <stuart.marks at oracle.com> wrote:
> Hi Sebastian,
>
> Good to see you contributing to OpenJDK again!
>
> I'm not sure it's sensible to have a regression test for this sort of thing.
> This seems more like static code analysis to me. In fact, Findbugs already
> seems to have a pattern that detects calls to the Boolean constructor:
>
> http://findbugs.sourceforge.net/bugDescriptions.html#DM_BOOLEAN_CTOR
>
> (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.)
>
> Now, regression tests are there to prevent bugs from reappearing once
> they're fixed. So how would we do this? For cases like this, there's another
> approach, which is deprecation:
>
> https://bugs.openjdk.java.net/browse/JDK-4941777
>
> If the Boolean constructor is deprecated, then a warning will be issued
> wherever they're called. By default, the JDK build treats warnings as
> errors, so this will effectively prohibit any uses of Boolean constructors.
> (The two legitimate uses of the Boolean constructor can be annotated with
> @SuppressWarnings to prevent this.)
>
> 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.
>
> As for your other questions:
>
> 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.)
>
> 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.
>
> 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.
>
> I'll reply on macosx-port-dev on your specific changes there.
>
> s'marks
>
>
>
> On 9/30/15 12:43 PM, Sebastian Sickelmann wrote:
>>
>> Hi,
>>
>> a few days ago i started to investigate JDK-5108778[1] and started
>> discussions
>> for a small parts of it in macosx-port-dev[2] and hotspot-dev[3]. As
>> suggested by
>> Alexandr there should be a test that saves for regression for such
>> changes. I would
>> like to introduce a test like[4], what do you think?
>>
>> It scans for all jimage-files in <java.home>/lib/modules and opens every
>> classfile
>> and scans every-method for a NEW-bytecode to a Wrapper-Type Classname.
>> Every match that is not in the Wrapper-Type itself is reported and
>> counted.
>>
>>
>> I have some questions about this:
>> 1. Is there a good way to get rid of the "9.0" part for reading the
>> classes out of the jimage?
>> 2. What is with other Wrapper-Types (Byte,Short,Integer,Long, Character)
>> is it a good idea to also change such ctor of those? Would someone raise
>> an enhancement
>> for those?
>> 3. How are value-types related to such an issue. Is it counterproductive
>> to change to XYZ.valueOf Method uses, or should we change to autoboxing
>> where possible? I haven't changed to autoboxing where i thought it would
>> be much less readable.
>> 4. Should the changes be discussed in the group-lists? Or is there a
>> good place for discussion off central-changes?
>>
>>
>> -- Sebastian
>>
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-5108778
>> [2]
>>
>> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2015-September/006970.html
>> [3]
>>
>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-September/020018.html
>> [4]
>>
>> https://dl.dropboxusercontent.com/u/43692695/oss-patches/openjdk/jdk-5108778/test_0/webrev/index.html
>>
>