I just wanted to say that the way Sponge has embraced Optional and other parts of Java 8 is amazing. It took a lot of adjusting, though not much[*], and the amount of if statements, boiler plate, and anonymous classes that have gone missing from my code is incredible. Working with an interface that eschews null as fanatically as Sponge is really amazing.
Now, if I can just stop spending 15 minutes flailing every time I get “Cyclic Inference” from the java compiler. -_-
Great job guys.
[*]YMMV on this. I’ve been to Scala Land, do JRuby/Ruby for a paycheck, started in Perl, and did a lot of LISP work, for my undergrad, so filter, map, lambda-esque syntax, function templates, etc. are kinda my jam.
I know this is a bit off topic, but what is “cyclic inference”?
Essentially, when you call map or flatMap on an optional or collection and your lambda doesn’t return the right type you get this error.
A contrived example to trigger the problem:
String result = stringOptional.map(s -> s.charAt(0));
This can get particularly messy when doing stuff like this code snippet. flatMap() on an Optional is expected to return some type of Optional, and map of course can completely change the type you’re working with. If the types coming back from your calls don’t line up, you get that error message.
public class A implements A.B {
public interface B {
}
}
This code does not make any sense and wont be compiled for obvious (logical) reasons which you can find somewhere here The Java® Language Specification
Optional is probably the best you’re going to get as a replacement for null. Some way of making null.isNull() or null.map() work would’ve been nice, but something something backwards compatibility.
Honestly, Optional’s implementation aspires to Scala’s nil, but really lands somewhere between there and Ruby’s nil.
Its not replacemenet, only abstraction. Yes it may look nice in the code for beginners who dont understant what null means, its idiot-proofness is only advantage.
“But, but optional helps you to avoid nullpointers” - To be honest NPE is easiest exception you can avoid/fix, and more experienced programmers do those mistakes rarely.
And if something returns null if a problem occurs and you from some reasons dont want to return null - well we have checked exceptions just for that.
This practice is very common when it comes to enterprise frameworks and works well, for me even this kind of code looks much cleaner than optional. eg.: Spring security UserDetailsService (Spring Security 3.2.3.RELEASE API)
tldr: obj != null is the best approach how you can check if an object is really null. If you want to prove me wrong compare bytecode instructions of optional, obj == null conditional, and checked exception approaches :^)
I’ve been writing Java for more than 3 years, and null pointers still trip me up from time to time. Generally it just stems from the fact that you don’t always remember to do a null check, especially when you’re tweaking code you’ve already written. With the concept of Optionals, you’re forced to consider that case and avoids having to work past NPEs altogether.
Completely false, especially in the minecraft world. When a developer sees a return type Optional, they immediately know that the method “may” return null and add the required checks for it. I can’t event count how many bugs I’ve had to fix due to a mod and/or plugin causing an NPE.
Not that I dislike optional in any way, but @blood you just fought for the other guys case…
Under the section titled “What’s the Point” the first sentence is Besides the increase in readability that comes from giving null a name, the biggest advantage of Optional is its idiot-proof-ness.
Just me appreciating the irony…
######(All hail Optional! Hail to thee, who shall be king hereafter)
Deleted last post because it was rather flamey in tone.
Simply put in more neutral words:
Optional is something I wish JAXB would use since I regularly have to traverse very deep into object trees generated by XSDs provided by other teams. Checking for null at every level is tedious and frustrating. The object trees in SpongeAPI (and other games) are very similar to this and it is extremely appropriate to the domain.
NPE’s in the Camel side of our event driven system at work are the bane of my existence. Due to all sorts of Camel-ey things, you end up writing a crap ton of boiler plate code over and over and over to handle every error ever since we are consuming JMS messages and there’s no one to tell that a message is messed up. Trying to debug a single message that only fails in production on an EC2 instance is definitely unfun. Anything that helps prevent those exceptions is most welcome.
Exceptions are computationally expensive and should be used a LOT less than is currently acceptable. Forcing try/catch/catch/catch on your callers is annoying.
That said, the last thing I wanted to do was step into a flame war. I’m moving on now. Thanks for the work Sponge Devs.