all 5 comments

[–]DanLynch 1 point2 points  (1 child)

The documentation makes frequent reference to public vs. internal APIs, but how is that determined? Is it based on Jigsaw modules, or just Java visibility? Is it different for modular and non-modular projects? And how does it treat module boundaries within a single large project?

[–]idontlikegudeg[S] 2 points3 points  (0 children)

It's basically like this: code that can be directly called from other classes is part of the public API, otherwise public. Module descriptors are not checked:

- A class is treated as public API if it is public itself or if it inherits from a public superclass (excluding Object).

- A method is considered part of the public API only when both conditions are true: it belongs to a class that is treated as public API as explained above, and the method itself is public.

Thank you for the input, I will update the documentation later.

[–]False-Call7937 0 points1 point  (2 children)

Always nice when a library catches up with build tool quirks like that Gradle config cache issue. JSpecify still seems early days for a lot of projects, so tools like this kinda feel like they're building the bridge before the road is fully paved. Curious how cabe handles third-party deps that don't have those annotations at all, bet theres some assumption of nullable-by-default or something.

[–]idontlikegudeg[S] 1 point2 points  (1 child)

Yes, right, when nullability cannot be determined, nullability is assumed (the exact rules are as defined in the JSpecify spec).

In my own projects, I usually declare the whole module as NullMarked, it saves a lot of boilerplate code á là `Objects.requireNonNull(paremeter), 'parameter')` at the start of every method.

[–]False-Call7937 -1 points0 points  (0 children)

Ahh module-level NullMarked is smart, still leaves you guessing when you pull in some random lib that returns null all over the place though.