Open squall2022 opened 8 years ago
We're working on adding nullability annotations to the SquiDB API (see #155 and #241). I'm not sure the package-info solution would do much in the short term, because neither the @ParametersAreNullableByDefault
or the @ParametersAreNonnullByDefault
are really "correct" for SquiDB on their own -- we'd need to add nullability annotations to the rest of the API for it to be correct, right? We're not using Swift with SquiDB yet so I'm not really familiar with what the implications here are.
Is the problem specifically that _Null_unspecified causes warnings, or that j2objc doesn't generate _Null_unspecified in the Swift interoperability code?
Yes, the correct way would be to add nullability annotations to the rest of the API, because not specifying it could cause runtime crashes, as explained here. At time of this Swift issue, compiler didn’t generate warnings when nullability was nor specified, but now it is the case. The warnings are nor really the problem, but it’s more to prevent runtime crashes.
For your second question, this is _Null_unspecified that causes warnings.
We've just released version 4.0 beta 2, which adds jsr305 @Nullable
and @Nonnull
to the squidb public API and generated code. Note that when compiling with j2objc, the translated code will import various classes from the jre_emul project, not all of which have nullability completeness, so it is likely that you will still see nullability warnings unless you use the -Wno-nullability-completeness flag. However, you should find that any calls to the squidb public API have nullability specifiers, which should make them safe to use. There are various other changes in this beta that might require code updates to use, but if you'd like to try out the latest code with these enhancements, you can check out this branch (and see the changelog for a list of everything else that has changed). Let us know if you have any issues!
Using j2objc and Swift 3 generate a lot of warnings because of nullability not specified, like explained here : https://groups.google.com/forum/#!topic/j2objc-discuss/zNt2eMcLvlY
Addind package-info.java files to squidb would be very helpful, see Tom Ball suggestion :
For your project's Java sources, you can define the correct nullability annotations and j2objc will translate them into Objective C annotations (be sure and include jsr305.jar to the j2objc classpath). This has the advantage of reducing the amount of casting that needs to be done when accessing Java classes in Swift. The Guava team recently did this, and simplified that effort by putting the default annotations in each package's package-info.java files (creating them, in many cases). That way, separate nullability annotations only needed to be added to individual source files when their API deviated from those defaults.
Thanks