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

Stuart Marks stuart.marks at oracle.com
Sat Oct 3 02:20:06 UTC 2015

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:

  1. 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.)

  2. 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.

  3. 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/test0/webrev/index.html

More information about the discuss mailing list