Moving to core-libs: On 3 October 2015 at 03:20, Stuart Marks <stuart.ma...@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.ma...@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 >> >
