On Tue, 9 Apr 2024 22:02:56 GMT, xxDark <d...@openjdk.org> wrote: > This does not solve the problem though. Source compatibility would still be > broken as one would still need to add casts everywhere, or am I > misinterpreting something?
The code you have provided in example is still valid and non-ambigous, even without cast. The default behaviour of java compiler is to choose method where parameter at corresponding position is closest type upwards in class hierarchy. null is considered "bottom" type, which means it is at the bottom of simultaneously every class hierarchy. Compiler looks upward in class hierarchy and first class it encounters is Predicate, as Object is superclass of Predicate, and chooses indexOf(Predicate) as method to invoke. When casting null to type, compiler treats null as object of casted type rather then bottom type. However, if changes are delivered as is, default behaviour of indexOf(null) will be changed, which is not desired, of course, and, although delegation to indexOf(Object) in case of null as passed value is counterintuitive, it will preserve the current state of things. > See > [this](https://github.com/search?q=%22indexOf%28null%29%22+language%3AJava+&type=code) > and > [that](https://github.com/search?q=%22lastIndexOf%28null%29%22+language%3AJava+&type=code) > query. Thats a valid point, haven`t though about qurying where null is valid value. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2046174903
