Last active
          March 8, 2018 00:45 
        
      - 
      
- 
        Save oxbowlakes/8d13fae255412e00c59ae6f536a84773 to your computer and use it in GitHub Desktop. 
  
    
      This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
      Learn more about bidirectional Unicode characters
    
  
  
    
  | import java.util.Optional; | |
| import java.util.function.Function; | |
| class Main { | |
| public static void main(String[] args) { | |
| Optional<String> o = Optional.of("foo"); | |
| Function<String, String> f = s -> null; | |
| Function<String, String> g = String::valueOf; | |
| //lawless lolz | |
| System.out.println( o.map(g.compose(f)) ); //Optional[null] | |
| System.out.println( o.map(f).map(g) ); //Optional.empty | |
| //This is because | |
| System.out.println( o.map(f) ); //Optional.empty | |
| //Once again for clarity | |
| System.out.println( o.map(s -> null) ); //Optional.empty | |
| //And now for more lolz | |
| System.out.println( o.flatMap(s -> null) ); //throws NullPointerException | |
| } | |
| } | 
just for clarity?
That's correct. Optional has been designed to explicitly never be able to contain a null value. Arguably more correct behaviour would have been to have map to throw an NPE if the function application returned null - but you'd still have the issue that o map f map g and o map (g compose f) would be different.
Presumably one "advantage" for explicitly disallowing Optional(null) might raise its head when the JVM gets value classes.
FWIW, we tried this (failed) experiment about 12 years ago. The correct solution is to assume that null does not exist, at all.
  
    Sign up for free
    to join this conversation on GitHub.
    Already have an account?
    Sign in to comment
  
            
Just for clarity, the result of line 11 is an
Optionalof the String"null", not anOptionalofnull.