3 ms·

Static analysis can go only so far. The Intellij has been helpful, but far from sufficient. One of the fundamental problems is also that static analysis won't h

Static analysis can go only so far. The Intellij has been helpful, but far from sufficient. One of the fundamental problems is also that static analysis won't help you differentiate between an intent (the method should not return null) and a mistake (it returns null anyway).

kaba0 4y ago
@NotNull/@Nullable is not part of the standard lib, but is a de facto standard nonetheless. I found that defaulting to everything non-nullable (there is a setting in these tools which should be the default, implicit nullable or non-nullable) and providing the few places where you want to use null explicitly gives you effectively the same null safety as Kotlin (note that the standard lib is annotated by these tools)
- The_Colonel 4y ago
  > @NotNull/@Nullable is not part of the standard lib, but is a de facto standard nonetheless. Which one is the standard, the dormant JSR-305, the IntelliJ annotations or the checker framework (I guess that's the best candidate since it was actually accepted)? > I found that defaulting to everything non-nullable (there is a setting in these tools which should be the default, implicit nullable or non-nullable) Does this have a good cross-IDE support? > gives you effectively the same null safety as Kotlin "effectively", just ergonomically way worse. But the main issue I have with this is that it requires you to actively seek null safety, pick a particular "standard" and push it through, ruthlessly enforce it during a code review. Which mostly doesn't happen. I've never seen a large codebase (which I would work on) which would use such annotations consistently. Yet unsurprisingly, all Kotlin code bases I've seen were in fact null safe.
  - kaba0 4y ago
    > Which one is the standard, the dormant JSR-305, the IntelliJ annotations or the checker framework (I guess that's the best candidate since it was actually accepted)? Hence “de facto”. All of these tools understand all of them. And I do have to agree with your last paragraph, it is not as good as native support, but nor is it as big of a pain point as it used to be/as some people think it still is.
    - The_Colonel 4y ago
      > but nor is it as big of a pain point as it used to be/as some people think it still is. It's a big enough pain point that I resigned myself on null-safety in existing Java projects. I rarely have the opportunity to start projects from scratch, and for those I'd rather use Kotlin.
- foverzar 4y ago
  > I found that defaulting to everything non-nullable (there is a setting in these tools which should be the default, implicit nullable or non-nullable) and providing the few places where you want to use null explicitly gives you effectively the same null safety as Kotlin Not really, I'd say not even close. In Java you would be trying to avoid nulls whenever possible, but in Kotlin nulls elegantly become a flow control feature.

kaba0 4y ago

@NotNull/@Nullable is not part of the standard lib, but is a de facto standard nonetheless. I found that defaulting to everything non-nullable (there is a setting in these tools which should be the default, implicit nullable or non-nullable) and providing the few places where you want to use null explicitly gives you effectively the same null safety as Kotlin (note that the standard lib is annotated by these tools)

The_Colonel 4y ago
> @NotNull/@Nullable is not part of the standard lib, but is a de facto standard nonetheless. Which one is the standard, the dormant JSR-305, the IntelliJ annotations or the checker framework (I guess that's the best candidate since it was actually accepted)? > I found that defaulting to everything non-nullable (there is a setting in these tools which should be the default, implicit nullable or non-nullable) Does this have a good cross-IDE support? > gives you effectively the same null safety as Kotlin "effectively", just ergonomically way worse. But the main issue I have with this is that it requires you to actively seek null safety, pick a particular "standard" and push it through, ruthlessly enforce it during a code review. Which mostly doesn't happen. I've never seen a large codebase (which I would work on) which would use such annotations consistently. Yet unsurprisingly, all Kotlin code bases I've seen were in fact null safe.
- kaba0 4y ago
  > Which one is the standard, the dormant JSR-305, the IntelliJ annotations or the checker framework (I guess that's the best candidate since it was actually accepted)? Hence “de facto”. All of these tools understand all of them. And I do have to agree with your last paragraph, it is not as good as native support, but nor is it as big of a pain point as it used to be/as some people think it still is.
  - The_Colonel 4y ago
    > but nor is it as big of a pain point as it used to be/as some people think it still is. It's a big enough pain point that I resigned myself on null-safety in existing Java projects. I rarely have the opportunity to start projects from scratch, and for those I'd rather use Kotlin.
foverzar 4y ago
> I found that defaulting to everything non-nullable (there is a setting in these tools which should be the default, implicit nullable or non-nullable) and providing the few places where you want to use null explicitly gives you effectively the same null safety as Kotlin Not really, I'd say not even close. In Java you would be trying to avoid nulls whenever possible, but in Kotlin nulls elegantly become a flow control feature.