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

Stephen Colebourne scolebourne at joda.org
Tue Oct 6 10:24:24 UTC 2015

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#DMBOOLEANCTOR (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/test0/webrev/index.html

More information about the core-libs-dev mailing list