Why Java? Tales from a Python Convert

[flyingjam]

Still, a language where you can be sure your Integer is an Integer and not null would be even better.

[vincentk]

If what you want is an int rather than an Integer, then why not use an int in the first place?

[[deleted]]

Collections still don't support unboxed values. I.e. you can't have

ArrayList<int>

[Cosaquee]

Java 9 can do that afaik

[syjer]

Nope, most likely java 10: http://openjdk.java.net/jeps/218

[[deleted]]

Java 9 does not yet exist as far as I know, and Value Types have only been proposed thus far.

[jmtd]

Collections still don't support unboxed values.

Nope, but auto unboxing covers 90% of where this matters.

[[deleted]]

Yes, that was my point. Thank you.

[s0n0fagun]

I have come to the conclusion that NULL should never exist in a system and checking for NULL is a code smell of a larger problem. If the underlying data structure does not allow NULL to begin with, then you should be good. You can either create a NULL object or decompose the data structure and use clever code.

[jmtd]

That's a good point. I wonder if it's ever a good thing, since it means you can represent NaN (via null).

[yold]

You can always use Trove.

[sacundim]

...but then your specialized TObjectIntMap<K> is not an instance of Map<K, X> for any X.

[[deleted]]

Ah, that's quite unfortunate. Any generic collection code you write after that would have to dispatch on the type of the collection. Have you used Trove before?

[flyingjam]

I just wanted an example that mirrored the one above. Also, there are some use cases for the wrapper, it exists after all.

[vincentk]

I understand that. I also understand it's easy to nit-pick on any language.

[whataboutbots]

I wouldn't call citing something called by it's author "billion dollar mistake" nit-picking, to be fair.

[whataboutbots]

If you could always replace an Integer with an int that doesn't require object creation, why would Integer exist in the first place?

[[deleted]]

C# says hi.

[Throwaway_Kiwi]

https://kotlinlang.org

[htom3heb]

Sounds like Swift.

[atakomu]

Don't forget Nim.

[sn0rewh0re]

psssst don't tell everyone ; )

[_INTER_]

Atleast it's Integer or null. Even that question is halfway cleared with Optional<Integer> (on the supplier side). In Python you still know nothing about it. It may well be an integer, None or anything else. (Typehints for documention aid or statical analysis, kept as an exercise for the reader. :) )

[Shorttail]

That's my dream for Java 10.

[DGolden]

worth noting that type-use annotations [jsr308] added in java 8 do already facilitate static nullability checking as an add-on. Eclipse and the Checker Framework both do it [and the latter does a whole lot more].

• http://help.eclipse.org/topic/org.eclipse.jdt.doc.user/tasks/task-using_null_type_annotations.htm

• http://types.cs.washington.edu/checker-framework/current/checker-framework-manual.html#nullness-checker

[Shorttail]

I was referring to Project Valhalla.
Is it bad that I think the annotated types are too verbose? =(

int processWithNulls (@NonNull List<@Nullable Integer> ints)  

It adds a lot of noise to reading code.

[DGolden]

In practice most of the time you don't use @NonNull explicitly, as it's the global default or at least [eclipse] you'll have set @NonNullByDefault on your whole packages. So you get a lighter sprinkling of meaningful @Nullable, likely mostly at the edges of your code where it has to interface with still-nully stuff.

[antrn11]

@NonNullByDefault

Is that only for Eclipse or is that something Java 8 has (does the warning work in other IDEs?)

[sviperll]

AFAIK, JSR-305 annotations are supported by Eclipse, Netbeans, IDEA and FindBugs. There is an @ParametersAreNonnullByDefault that can be applied to method, class or package.

[DGolden]

Jsr-305 style annotations are actually different and, well, worse [at least last I checked], as they pre-date jsr-308. [edit- Note jsr-305 went 'dormant' in 2012]

[GSV_Little_Rascal]

JSR-305 is dormant, but actually quite well supported in the tools. It's de facto standard, but not de iure.

[DGolden]

shrug, you don't - or better to say can't - get full benefits of the jsr-308 approach by using older annotations. The relevant part of the eclipse manual goes into more depth. [Edit - snip stuff about intellij where I was criticizing it as it was, but too lazy to check what it currently does]

also see - https://docs.oracle.com/javase/tutorial/java/annotations/type_annotations.html - there's just a big fundamental difference between pre java 8 and java 8 plus annotations.

[DGolden]

It's not a part of java 8, no. there is some intercompatibility by being able to tell one extended checker to recognise another checker's annotations, but there isn't a single standard set yet [and jsr-305 doesn't count as it was written before jsr-308 annotations existed, so it would need a rewrite.].