Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8197791

[lworld] Javac's treatment of statically discernible nulls mixed with value types.


    • Type: Bug
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: repo-valhalla
    • Component/s: tools
    • Labels:
    • Subcomponent:
    • CPU:
    • OS:


      Where statically discernible, should javac disallow null being cast into a value type ?

      This topic is still being discussed.

      In http://mail.openjdk.java.net/pipermail/valhalla-dev/2018-February/003801.html, it is stated:

      The current design allows null references for value types, as long as they are not stored
      in a container (field or array) declared as flattenable. This is a significant change from
      previous design. So, casting null to a value class type is now legal.

      In http://mail.openjdk.java.net/pipermail/valhalla-dev/2018-February/003803.html it is stated:

      There might be an option here: Maybe we could get away with having checkcast
      throw NPE if the target class is a value type. After all, the checkcast instruction resolves
      its class operand. Remember that we *must* allow polluting nulls in fields which
      are not explicitly marked as flat, but *only* because of binary compatibility requirements.
      We *do not* allow polluting nulls to be stored into arrays, because arrays *must*
      resolve their element types before the first array is constructed. I think we could
      put checkcast into either of these two categories: Allowing polluting nulls for
      compatibility, or forbidding them (throwing NPE).

      Hmm… The more aggressive choice (throwing NPE on checkcast) would make would
      prevent instances of generic code (such as List<DoubleComplex>) from accepting

        List<DoubleComplex> xs = new ArrayList<>();
        xs.add(null); // to NPE or not to NPE?

      This is not really a JVM question, but a language question: Should
      the above code throw NPE if freshly recompiled? Yes, probably.
      What if it is inside a legacy classfile, and is not freshly recompiled?
      It would break if it threw NPE. This argues for two slightly different
      versions of checkcast. Argh: An option turns into a two-sided mandate.
      The checkcast might need a flat-bit. (Stay away, you Q-types.)
      Or the checkcast could throw NPE only in newer classfile versions.

      These considerations also apply to Class::cast.




            • Assignee:
              sadayapalam Srikanth Adayapalam
              sadayapalam Srikanth Adayapalam
            • Votes:
              0 Vote for this issue
              2 Start watching this issue


              • Created: