utilize @NotNull @Nullable annotations to benefit other languages (kotlin)

[sreich]

so, other languages as well as java itself (through IDE help), can make certain guarantees if these annotations are present on methods.

kotlin, which is what i'm interested in, when interoping with java code, will treat java values as 'platform types'. platform types wave away the guarantee of null safety, so you won't get compile time errors because you accessed a value that can be null.

kotlin will know though if external code is annotated via @NotNull, @Nullable, and give back that type safety when interacting with that java code.

i'd like to look into this matter, though i am not familiar with portability of these annotations.

they are in javax.validation (JSR-305) as far as i know. of course, it'd have to work well with various IDEs, desktop, android and GWT(the latter two are probably the biggest "if's")

[junkdog]

(Been a long day, so excuse my brevity).

i'd like to look into this matter

Plase do ;) Only good to have some extra compile-time/syntactic niceties and leverage other JVM-bound languages a bit.

i am not familiar with portability of these annotations.

javax.validation.**.NotNull sounds like the most safe approach, but I'm not speaking from experience.

android and GWT(the latter two are probably the biggest "if's")

GWT should be pretty easy - we already supply our "own" @SafeVarArgs in artemis-odb-gwt. It's mostly a matter of iterating through transpiler errors, if something breaks.

I've seen @NotNull etc in java code, but I think they reside in their annotation artifact. I'm pretty sure there's a x-platform way forward though.

[JesseTG]

Is there a way to fake it if you're stuck on Java 7?

[junkdog]

Is there a way to fake it if you're stuck on Java 7?

It shouldn't interfere. We're still java 6 compatible btw; used to be a necessity when compiling for android.

[sreich]

looks like we might have to use another dep(compile time, obviously). and even then, they only seem to be like 16 kiB

see http://justsomejavaguy.blogspot.com/2011/08/nullable-null-notnull-notnull-nonnull.html

or at least i can't figure out how to use it without any one. there's a lot of them, including:

com.google.code.findbugs

  <artifactId>jsr305</artifactId>
  <version>1.3.9</version>

(from what i could find)

[junkdog]

Compatibility with FindBugs is definitely a plus - I was playing around with it last week. JSR-305 and FindBugs have some overlap when it comes to authorship (according to something I read somewhere), but there's doesn't seem to be a lot of continued development.

FindBugs refers to JSR 305 in their API docs. Probably the best way forward(?).

[sreich]

i feel like i'm fine with closing this...after some different code handlings on my end, i don't think i'd benefit from this all that much, anymore.

also, i'm hoping the intellij guys will eventually add back in external annotations. asking everyone to verbosely modify their api is less ideal than i'd like

[junkdog]

i feel like i'm fine with closing this

just as I was being swooned by kotlin ;) are you sure about the external annotations?

[sreich]

Haha, well Artemis is one that seems to benefit the least (there's just not a whole lot of surprising methods going on, and it's mostly just ints and things like delegates and small wrapping extension functions make it feel at home in kotlin). Libgdx on the other hand could benefit more from them, I think.

No idea. External annotations existed at one point, but they removed them because it was tricky to keep up to date, apparently. But then again, their alternative requires modifying the original code which is more infeasible for all of one's libraries - except for Artemis ;)

In the end I've found so far it hasn't been making a significant difference either way for me, at least as far as Artemis is concerned.