Details

      Description

      Projects are now starting to notice deprecations in JDK 9 EA builds. The first wave of deprecation warnings is from the deprecation of the boxed constructors.

      One point to re-emphasize is that deprecation doesn't imply imminent removal unless forRemoval=true. There seems to be some different reactions to new deprecations. One is apparent urgency at fixing up warnings, as if the deprecated APIs are going to be removed shortly. Another is resistance to deprecation because of the amount of work generated. Cleaning up warnings is a certain amount of work, but it might be that this is magnified by the assumption that the APIs will be removed (or be made "unstable") by the deprecation, which isn't true in most cases.

      There are some pitfalls in removing these warnings by editing the source code. There should be a recommendation about a set of steps to take. For example, for the box constructor deprecations:

      1) Disable deprecation warnings using -Xlint:-deprecation. Deprecation warnings are rarely the most important thing to deal with in migrating to JDK 9. This is only a temporary workaround, of course, but dealing with warnings needn't be in the critical path of migration.

      2) Suppress warnings with @SuppressWarnings("deprecation"). This is useful at particular call sites that use the box constructors. This does add clutter to the code, but it's called for in certain uncommon cases where the code really does want to use a box constructor instead of an alternative. These cases are typically where the identity of a boxed value is significant, for example, if they are compared using == or !=, or if they are stored in an IdentityHashMap.

      We are also considering other mechanisms for finer-grained warnings control.

      3) Replace the constructor call with a call to valueOf(). For example, instead of new Integer(x), call Integer.valueOf(x). This is the safest transformation, since it avoids pitfalls with autoboxing and overload resolution. It doesn't preserve identity semantics, though, as noted above.

      4) Converting to autoboxing is often safe but there are a number of "gotchas." For example, if 'list' is a List<Integer>, and 'x' is an int, then
          list.remove(new Integer(x))
      must not be changed to
          list.remove(x)
      because this changes overload resolution so that List.remove(int) is called instead of List.remove(Object).

      ==========

      In addition to enhancements to deprecation itself, the release notes should also cover features, APIs, and packages that have been deprecated. Issues relating to deprecation of those should be linked to this subtask.

        Issue Links

          Activity

          Hide
          smarks Stuart Marks added a comment -
          In a meeting today with Cliff Wayne, Iris Clark, Aurelio Garcia-Ribeyro, Roger Calnan, and myself, we decided that the existing Compatibility Guide has sufficient information about deprecated features and APIs, so having a separate deprecation list is no longer necessary. I'm closing this as Not an Issue.

          Material in this issue should be migrated to release notes for deprecation itself (JDK-8176334) and for the deprecation of boxed primitive constructors (JDK-8176335).
          Show
          smarks Stuart Marks added a comment - In a meeting today with Cliff Wayne, Iris Clark, Aurelio Garcia-Ribeyro, Roger Calnan, and myself, we decided that the existing Compatibility Guide has sufficient information about deprecated features and APIs, so having a separate deprecation list is no longer necessary. I'm closing this as Not an Issue. Material in this issue should be migrated to release notes for deprecation itself ( JDK-8176334 ) and for the deprecation of boxed primitive constructors ( JDK-8176335 ).

            People

            • Assignee:
              smarks Stuart Marks
              Reporter:
              smarks Stuart Marks
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: