It would just return an empty object of that Type much like initializing an empty object with new(), but with no memory allocation. Allocation would only occur at the time of assignment.
The compiler, as well as the IDE, knows what the Object is composed of so it would be aware of what can be assigned or called on the object. But, if that object hasn't been allocated it would return empty regardless of the methods you called or variables you accessed.
For the compiler and the IDE to tell you anything, it's something that it's not happening at runtime, they can warn you of possible scenarios that would happen at runtime, but not all of them.
And what would happen if on the empty object a method is called? Can't return an empty object because the returned object might differ depending on the parameters of the method
But what kind of empty does it return? The method signature could be Object and the to be returned object could be dynamically loaded in. You could never resolve the stack of empties
That would be like saying calling methods on the `null` pointer would always return `null`. And then at some point you'd notice that your program does wierd things because a variable is null or empty when it shouldn't, but you have no idea where that null/empty originally comes from.
The much better strategy to deal with nulls is doing parameter checks and failing early and making sure no unexpected nulls sneak into your program flow. Your approach is exactly the opposite.
Something that encapsulates your core idea (I think?) but wouldn't break most aspects of Java are Promises, do you imagine something along those lines?
But objects also have methods with no return, voids, but we would still expect some action to happen, like invoking a method to set an attribute on that object
Then you'd have to keep checking for empty.
Like look null pointers are a feature, its null and that means something or its a problem. That its a problem is useful.
> IMO, the existence of null pointers in a memory safe language is contrary to its purpose.
Null pointers are memory safety. They prevent you from doing the memory unsafe thing of referencing unintialized memory.
I don't see how this would add any benefit. We all have been there of having that annoying null pointer because we have poorly written a method or forget to check for null or whatever, more often than not, null pointers are a symptom of poorly written code, but at least it gives us a clear direction of where your problem is coming from.
Since Java 17 you can even see exactly what point of the chain was null.
Having these "empty" objects would just mask the problem. How would trying to invoke a method on a "empty" would work? An EmptyObjectException? Or would that just return another empty object? What if the final response would be a primitive? Would we fallback to default values for the primitives? Would we get rid of primitives?
I don't want to shit in your idea, but I see it doing more harm then good, more potential for poorly written code and making it harder to troubleshoot.
Its basically just renaming null. Thats obviously not giving much benefit.
There are good reasons to not have `null` in your language *at all*, but I doubt thats a chance we will ever see in Java. But we might after Valhalla see `!` for types that are provably non-null.
An EmptyObjectException would just be an NPE under another name.
The method or variable wouldn't even be invoked or accessed because it's a non allocated object. It would just return empty instead of an NPE. And in the case of a primitive it would also return nothing, thus, invoking an exception as returning 0 isn't ideal.
Also, I consider poorly written code as having to check for null everywhere.
The thing is, You're making another set of problems for yourself.
You can argue that a null pointer is annoying, but what's more annoying is getting a no pointer because a runtime exception was detected, or not getting a pointer and having everything just continue with uninitialized memory, returning an empty object and then having logical issues that are even harder to find.
I might see this a bit differently because I started in COBOL, But you should never get a null point or exception because you shouldn't be dealing in nulls. Anything that hands back and no should be well documented. Under what circumstances it does hand back null, And the code should react to that accordingly. The more we demand our language to automatically be aware of things, the more declarative it becomes and the more logical errors arise. The less declarative, The more the onus is on the programmer to be explicit about what they want.
I think OP meant for the empty objects to return what's so called "smart nulls" in mocks. In a simplified universe, everything has a natural "0" value so for example return 0 for numbers, "" for string etc.
It *is* a much scarier world because now programming errors don't fail, devs don't get paged when stuff go wrong. You just silently break the world: like paying you $0 fund when you sell your house, then while we are there, start a nuclear war or something, because, oops, the system had a glitch.
> The method or variable wouldn't even be invoked or accessed because it's a non allocated object. It would just return empty instead of an NPE.
Then what would be the output of
MyClass foo;
foo.printAMessageToTheConsoleAndExit();
Note that there is no return value for the method call. Do you just silently fail and do nothing?
Interesting example. And yes, the method call would do nothing as it's an empty object. I really don't see that as an issue because getting to the cause of why
foo.printAMessageToTheConsoleAndExit()
printed nothing would be trivial. The IDE or compiler could even hint that you called an empty object.
> And yes, the method call would do nothing as it's an empty object
That’s so much worse than getting a NPE!
* Option 1 - I hit this button and it breaks.
* Option 2 - I hit this button and nothing happens.
You’re trading option 1 for option 2. But option 1 is trivial to find and debug. Option 2 is a nightmare to debug.
But let's think of a scenario where you need a group of Objects to setup another one, or a long user journey.
Please bear with me, as it doesn't necessarily will be the best example.
But let's say you tried to setup a connection with a database, but you got one of those empty objects for the connection or an empty repository object or an empty DAO.
Now you want to save an object using this DB connection, the connection is empty, and as you proposed if I try to invoke this save operation on an empty obj, it will return another empty, I got no errors, no problem, now let's assume this operation is in a long user journey, with lots of different steps, validations, etc, you don't see any error for this, as you are only getting these empty objects along the way. But someone reported that some data is not there properly.
it would be a nightmare to troubleshoot all of this.
And just to be clear, I'm not saying that logic errors don't happen in our current Java implementation, absolutely they do, my point is that from my perspective it's not making it better, maybe just shifting the problem.
One more thing to be clear, I think you didn't get my point on this part, I'm not saying you have to do null checks everywhere, there are techniques one can use to not having to check for null all the time, and still be null safe, I'm just saying that poor code is more prone to NullPointerExceptions or any kind of RuntimeExceptions. And I don't see this idea improving on this, but rather sweeping it under the rug.
So for a critical object that is necessary for data persistence I would check if a valid database connection was returned as common sense dictates that there's no point to continue processing if this has not been established. But, for arguments sake, let's say I'm lazy and didn't care to check for a valid database connection, called save to persist data and then checked the database to verify the data was saved and realized it wasn't.
You're right that pinpointing the exact cause of the failure would be more challenging, but the runtime could assist you in clearly telling you that you attempted to call save on an empty object. I do agree that in certain cases instant failure is probably the best course of action to allow you to fix the issue immediately especially when it comes to data persistence.
Yeah, as I said it wouldn't be the best example, but still possible, thank you for making the exercise of going with it.
>but the runtime could assist you in clearly telling you that you attempted to call save on an empty object
But what we also need to consider here is that the IDE and the compiler also try to tell you when you are trying to invoke a method on a potentially null reference, but it's very challenging for it to figure it out most times, and it would be just as challenging for this empty implementation.
if you have something like this:
final var myVar = someMethodThatCanEndUpReturningNull();
myVar.someOtherMethod();
The IDE can try to check for obvious null returns from the first method, but as soon as it starts to be a bit more complex, more validations, more logic, the IDE will not warn you about that, it's up to you to figure it out what you are doing is safe, implement validation, or use some other options.
The empty option would suffer from the the exact same problem, it would be up to the developer to always be prepared to have something empty and find a way to check it.
It seems like this is the heart of why this idea is a little flimsy as a feature: for it relies on devs to just do the right thing. I get the benefit, there are lots of situations where all I want to do if some value is null is to do nothing. But how is this different that a
```Objects.doIfNotNull(T obj, Consumer```?
You do realize that every call to an object eventually chains down to returning a primitive so everyone of your empty objects will trigger your new empty exception?
Because an empty object is not the same as a null?
And also, that would be a massively breaking change that would sever pretty much all backwards compatibility.
Okay but how do you differentiate between an empty object and nothing?
That's the purpose of null. I wouldn't say I'm studied enough to make a proper argument, But I don't think we want to go the JavaScript route and assume everything is everything and this is a stepping sale and that kind of jumps in that direction.
An empty object has no memory allocation and if you reference an empty object you get back nothing instead of an NPE.
But, then is there really a need to differentiate between empty and nothing? Empty and nothing are kind of synonymous.
You're assigning a value to the empty object so the VM picks up on that and memory allocation occurs, the object is instantiated and the value is assigned.
I get your point but i guess that wont work like you expect because of generics
List vehicles = new ArrayList();
Vehicle v = vehicels.get(0)
Do i get a empty Vehicle a empty Car (extends Vehicle) or what do i get?
And what about abstract classes and so on?
Edit: I like the idea its a good question but i guess you will reach some kind of dead end when you think it through.
Might be that this is not the dead end but i bet there is one
You've already instantiated the Vehicle object and allocated its memory so it ceases to be an empty object anymore and normal language rules apply.
I realize that it's an idea with holes, otherwise it would have been implemented in some form long ago.
class Car extends Vehicle {};
class Truck extends Vehicle {};
class Bus extends Vehicle {}
How do you decide what to return on vehicles.get(0) call when the list is empty?
Right, but there's a functional distinction between the two.
Empty and nothing are not synonymous, That's why null exists.
There is a difference between processing until the end of an empty list and not doing something because no list existed to begin with.
People get null pointer exceptions because they work with nulls in their code and they don't properly document when a null will arise.
If you're writing unit tests, you should always have a test for null and it should always work because there should be a null check in your code anywhere a null is possible. If you're null checking at the start, And not handing back nulls internally. You won't have an issue. That doesn't mean there's no argument to get rid of nulls but they're not synonymous.
A somewhat common idea that languages like Pony and to a lesser extent Rust have done already. I'd like to see this in java. Here are some concerns you need to think about:
* null is actually useful. __if__ properly semantically defined and used only for that. The useful definition is 'not a value / unknown'. You want the NPE __to be a good thing__. If I get the name of the logged in user (but, this is `null` as there is no logged in user) and I check if it starts with `admin_`, then the answer `true` __is just plain flat out wrong__, but, `false` __is just as wrong__. The question cannot be answered. The exception is what you want. SQL is much more clear on semantically defining null like this (as 'unknown'), and is properly infectuous (is `NULL = NULL`? The answer is NULL - because who knows if 'some unknown value is equal to some other unknown value'. Could be yes, could be no - note how java duplicates this: `null.equals(null)` throws an NPE, which is correct, semantically: neither `true` nor `false` is acceptable here).
* Context is relevant. Imagine the same situation but we do a better job at designing it: We have a User object. We also have a User object representing the 'not logged in user'. Now `.getUsername()` perhaps should still throw maybe, but certainly `.isAdmin()` should just return `false`. But, maybe we also need a user object that represents other notions, such as 'we are processing scripts from the server maintainer directly; there is no user object but context-wise, all operations are allowed. It's like OS safe mode. `isAdmin()` should now return `true`'. Java already supports this: Simply make these objects and initialize your fields accordingly. Or, even simpler: The 'empty' outputstream: Is that an outputstream that is already closed (so, any attempt to write to it throws), or that is a byte sink (you can write to it all day; the bytes are ignored).
* Other than 'context is relevant', some objects really truly do not have an 'empty' object. There's the empty string, and the empty list - so far, so good. We can even have an 'empty' `InputStream` (that is already closed). But is there such a thing as an empty `java.lang.Class`? I really don't think `Void.class` is right for that job. Nor anything else. Is there such a thing as an empty `Charset`? Maybe it should be possible for a type to decree that it _does not_ have an 'empty' instance, and for such types, initializing your fields is _mandatory_. This also makes it easy to introduce different takes on 'empty' (see previous bullet) - simply force initializing. Require that one writes `User user = User.notLoggedIn()`, you can't write `User user;` because `User` does not declare an empty object. Making it optional also makes it way, way easier to introduce this into the java ecosystem without a python2/python3 disaster.
* Writing empty objects is a bit of a drag. Should the language include tools for this?
* Should all types, including interfaces and abstract classes and even enums, have (optional) 'empty' instances? Bit of a drag to foist this requirement onto all library authors.
* Should there be a function that produces an empty object, or, should it be a single field? If the latter, that thing __must be__ immutable or all heck breaks loose. There's no real way to force that; the lang spec is just going to have to stipulate: "Hey, author of a type? If you're going to introduce an 'empty' value, it's on you to make it immutable or hoo boy, its all gonna go very pearshaped indeed'. Is that okay? I think so, but, it's something to think about. Note that if there's a single value, you don't have to worry about 'memory allocation'. Yes, memory is allocated: For each type loaded in your JVM, __one value__, ever. Sum total. For the entire JVM. This doesn't matter: very type _already_ occupies a bunch of memory (the code of that type has to be somewhere!). Adding a little more for an empty object is therefore not significant as per `O(n)` thinking.
As an aside, your treatise in the Lombok github repo, on Optional vs Null in language design, is a wonderfully-formulated argument against Optional, in addition to being a compelling read. Thank you for that.
No, I’m talking about Optional as a special type which can’t be null. then you can define your field as “Optional name” and you will be sure that there is always a value - Some or Empty. But as it’s implemented now you can make “name = null;” and we will have NPE again :(.
Yes you need a not initialized, empty value, and has value.
Lets say I have a JSON stream I may get no value JavaScript undefined, null value JavaScript null, or a string that may be empty but that is still a value. You need a way to communicate each of the three state potentials: undefined, empty, or a value, one of the only ways JavaScript is superior to languages. With Optional now I can do that inelegantly as: NULL, !isPresent, and get. If you require it to be a value then you need to add a notInitialized and an isInitialized.
What I’m getting at is that Optional is in itself deluded. We would have been far better off with Elvis and coalescing operators than with Optional. Worse than bad Optional is misused, I’ve seen sooo much code with fluent optional blocks layered on top of each other that really would be better as methods or even layered if statements because the mappings and orElse calls.
All really to pretend null doesn’t exist. So we can pretend we won’t get NullPointerExceptions. Unless we want them a’ la Objects.requireNonNull. Sooo ¯\_(ツ)_/¯
I dont really see the value. An exception would still be raised if you were expecting a non-empty object and you got an empty object.
Have you seen how kotlin handles this?
Take a look at Scala, Kotlin, Python, and JavaScript. There are different approaches that can be taken to represent an empty value.
Java's 'null' is actually pretty good when used with an IDE that will analyze code flows. Two huge benefits of null are performance and clarity. Nulls are understood all the way up to the hardware level and they never incur any of the penalties for being or looking like an object. Null means the same thing everywhere. Languages that hide nulls still encounter them, and they can be very unexpected.
So Valhalla has had to work through the question of what an uninitiated object should look like. You might want to consider if there is a real difference between what you are suggesting and a VM or language that replaces null with an Optional type.
For those asking what the difference would be between such an empty type and null - an empty object has a concrete type, and unlike null cannot be coerced to anything else.
Golang does pretty much exactly that with zero values https://yourbasic.org/golang/default-zero-value/ .
The memory is initialised, and has a default valid value for most uninitialised variables. Nil is used for pointer and related types though.
In practice, it's horrible. All ints default to 0. So you cannot tell if it's uninitialised, or actually zero.
It's even worse with structs, as everything can have a zero value.
Removing nulls is better done by being MORE explicit about non-present values with things like Option/Maybe types.
It's critical to be able to tell the difference between absent and present values.
Null pointer exceptions exist for a reason. If you expect an object to have been initialised, and attempt to perform operations on it or read values from that object, but the object has not been initialised, then you want to know. You want an exception to be thrown so that you know something has gone wrong.
The last thing you'd want is for the lack of initialisation to be hidden, you start performing operations on or reading values from an "empty" object that you expect to have been initialised and have valid values. Your application now has unintended state and you're blissfully unaware.
The solution you propose works on the assumption that all objects are initialised with empty state, and that it's acceptable for all objects to have an empty state. But that often isn't the case.
This feels like you're trying to big brain something but reaching the same issue you're trying to solve. Having an "Empty" object returned just causes the same issues that Null value does. It's still an uninstantiated thing that should never happen and is erroneous programming/behavior.
Not necessarily erroneous, see JavaScript not present, empty, and value. Those are 3 separate states that Java coalesces into 2 states (poorly in my opinion). Other than primatives those are valid states.
Technically, you have 3 states in Java. You can create a variable without assigning a value or null. The compiler just catches situations where it could be a problem and refuses to build since it should never happen.
JavaScript's way of handling also doesn't fit OPs idea of getting rid of the null state to remove NullPointerExceptions.
Bad idea. It’s better to fail as early as possible than to carry on as if nothing happened and deliver bogus results. NPEs are good at pinpointing the issue.
Another issue is the extra allocations. All those zero objects must be unique, at least the ones with mutable fields. More memory churn.
No, the billion dollar mistake is not null itself, nor the NPE, but the fact that nullability is not reflected in the type system, so it’s easy to over- or under-check for null, and the reader of your code has no idea whether a line will give off an NPE or not. That’s why null-safe languages have explicit unwraps
The fundamental problem with null is that it inhabits every reference type, so, for example, when a function has a return type that is a reference type you have no way of knowing whether it could ever return null or not. This forces you to either add null checks everywhere or risk NPEs.
Your Empty object proposal has the exact same problems.
This has the implication of that all objects must have a no-arg constructor.
We're not just talking about Integer etc if we're having to handle
complexObject.someComplexMethod().someAccessorOnReturnValue()
Also, i'd far rather have an exception, then pull hair out trying to work out why some data in production is zero legitimately, or because some random data was uninitialised.
There's worse things than a bug in production - and thats not knowing there's a bug in production.
If the object is not allocated then its hierarchy of complexity is irrelevant as it would just return empty.
As for debugging or bug tracking, the JVM could hint that an empty non allocated object was returned.
If only there is a language that lets you explicitly say whether a type is nullable and forces you to check it if it is. Oh wait, there is one, it’s called Kotlin.
That would cripple traceability.
If I have `a().b().c()`, and the output is EMPTY, how do I know which one returned the EMPTY? NPE would tell me, but your solution would not, because calling a method on an object whose value is EMPTY would just return EMPTY too.
It's a fun thought experiment, but it falls apart almost immediately.
Good idea. I saw a lot of people here dumping on it for some reason, but let me tell you, that's exactly how to did it. However, nil / null still exists in the language.
I think the best way to solve this might be what kotlin came up with
If we leave out the discussion about whether it makes sense, you'd have to basically define each object with non null default values, and when an object wasn't initialized, you'd simply pass the defaulted object. But you'd have to define defaults for everything that exists in your language, which would make it difficult sometimes to actually debug.
What if you could just do what Common Lisp does, and let you make methods that work on the null-value?
If we ignore a lot of the incoming problem, static methods are just methods with no instance object passed in right? So you could imagine something like this working:
public class BinaryTree {
BinaryTree left, right;
T val;
public int size() { 1 + left.size() + right.size(); }
public static size() { return 0; }
// Rest left to the reader
}
Or of course some other keyword, like public null int size() or what-have-you.
Now you could conceivably tell the JDK what to do when a method is called on a null value of some type, and you can write a lot of stuff without null-checks everywhere. Won't get rid of all NPEs, but would make a lot of the tedium go away.
What you're asking is something like [Groovy's Safe Navigation Operator](https://groovy-lang.org/operators.html#_safe_navigation_operator).
Maybe you should give groovy a try and you'll see the hell it can become, specially when debugging production.
There are NPE equivalents in Python, Node, C#, Ruby and probably every other language so i can't really see the point.
Have you used JS? If you have, you might have noticed that it allows you to do a lot of things that would be errors in other languages, instead just doing something unexpected. It's generally agreed upon that this avoiding of errors was a bad idea. If something unexpected happens in your program, you'd rather have it crash and tell you, instead of silently doing something unexpected.
````
Person p = empty;
var x = p.getName(); // what happens?
Widget w = empty;
w.frobnicate(); // what happens?
w.show(); // what happens?
````
Types form a lattice. Renaming the bottom element of the type lattice doesn't really bring you any benefit.
There are better options to explore, like `!` for non-empty types (`String! s = null;` would be an error) or a "strict" compilation mode that made the `!` the default and a `?` would mean ` | null`.
It is possible, and the pattern is call Null Object. The problem is - you can not implement it on a level of a language, because every class needs it's own custom implementations of NOP behaviour. But you can do it in your code and people do.
NullPointerExceptions are the best because they're so easy to fix and usually represent some sort of logic error.
Replacing with empty values, whatever that means, will likely mean these errors will pass unnoticed and you'll get bad behavior but won't find it very easy to track down the problem
Kotlin offers a solution kinda like what you are describing, but more rigorous. It's still possible to get an NPE in Kotlin, but you have to go out of your way to create the conditions that would cause one.
You’re close. Take it a step further. Disallow the creation of null objects, add syntax for an escape hatch, and then look at Kotlin because it’s already done and is awesome.
So we now have a new language what shall we call it “Jotlin?.” And how do we pronounce that and when will the new compiler be available? When is the conference? When is the UG meetings?
BTW Kotlin doesn’t disallow creating null it lives in the JVM so it has nulls it just has compiler/developer hints as to what operations tend to be safer. Oh I know “Jotlin!!”
But given reflection exists everything really depends on people most often do what they are supposed to. Like check for null.
Hence it’s all hyperventilation for naught.
If you don’t like NULL then use COBOL. If you want something fast and readable deal with NULL but the heavens forfend don’t rename it and say you’ve solved something because functionally you will always come back to something like what we now call null it’s just how much boilerplate you’re going to have to deal with to get there.
Null safety solves a runtime problem at compile time.
Having dealt with more than a few NPEs in my life, I’m happy for the feature in Kotlin. The only people that seem to complain about it are the only who lack experience with it and fail to understand its benefit.
No it hints at it. There is a big difference and it depends on playing nice. Hence the “Jotlin!!” remark. But if people played nice we wouldn’t have null issues in the first place. And in only hinting with the propaganda that it is accomplishing it causes a worse thing — over confidence.
Don’t get me wrong my preferred language is Kotlin, I just don’t believe in Santa Clause any more after dealing with NPEs and what came before them even in languages that professed to not have NPEs.
If you need a language that is fast enough there are ways to get NPEs full stop. The language has to allow it. Kotlin does a better job of providing hints and guide rails but someone who misbehaves will get around it. It is better to have coalescing operators (like Kotlin) so that you can work through those segments of code with less density and more clarity. And it’s better to expose the potential problems at declaration time as well as default to the non problematic variation.
But don’t try to sell me that the Easter Bunny came along and delivered a high performance language with the flexibility of the JVM without NPEs.
>And in only hinting with the propaganda that it is accomplishing it causes a worse thing — over confidence.
I disagree, but that's fine. Your opinion seems to be skewed to the side of massive pessimism, and that's fine too. My experience hasn't been some pendulum swung in the opposite direction, I just like that I have way less NPE possibilities with my Kotlin code and I am far more productive as a result. I wouldn't classify my viewpoint as "over confidence", I just don't get NPEs and I work a lot faster with Kotlin than Java.
Obviously anything that touches a java package can return null, and there's not much you can do about that except assume that it could be and use variables? that could be null.
I've worked in Java database internals for 12 years now and have dealt with numerous NPEs, and my Kotlin experience has been far better. I guess yours hasn't, that's a shame.
Have a good one.
So if we referenced the "empty" Object would we get an EmptyPointerException? Or maybe it would return the value empty?
It would just return an empty object of that Type much like initializing an empty object with new(), but with no memory allocation. Allocation would only occur at the time of assignment.
But how about Objects that only have constructors with parameters? How would the compiler or the jvm infer those values?
The compiler, as well as the IDE, knows what the Object is composed of so it would be aware of what can be assigned or called on the object. But, if that object hasn't been allocated it would return empty regardless of the methods you called or variables you accessed.
For the compiler and the IDE to tell you anything, it's something that it's not happening at runtime, they can warn you of possible scenarios that would happen at runtime, but not all of them.
And what would happen if on the empty object a method is called? Can't return an empty object because the returned object might differ depending on the parameters of the method
The empty object hasn't been allocated so everything returns empty regardless of what method or variable you tried to access.
But what kind of empty does it return? The method signature could be Object and the to be returned object could be dynamically loaded in. You could never resolve the stack of empties
That would be like saying calling methods on the `null` pointer would always return `null`. And then at some point you'd notice that your program does wierd things because a variable is null or empty when it shouldn't, but you have no idea where that null/empty originally comes from. The much better strategy to deal with nulls is doing parameter checks and failing early and making sure no unexpected nulls sneak into your program flow. Your approach is exactly the opposite.
Something that encapsulates your core idea (I think?) but wouldn't break most aspects of Java are Promises, do you imagine something along those lines?
But objects also have methods with no return, voids, but we would still expect some action to happen, like invoking a method to set an attribute on that object
That’s too dangerous, might complete a transaction with it’s not supposed to happen, were have to add more tests to make sure that doesn’t happen
Then you'd have to keep checking for empty. Like look null pointers are a feature, its null and that means something or its a problem. That its a problem is useful.
> IMO, the existence of null pointers in a memory safe language is contrary to its purpose. Null pointers are memory safety. They prevent you from doing the memory unsafe thing of referencing unintialized memory.
I don't see how this would add any benefit. We all have been there of having that annoying null pointer because we have poorly written a method or forget to check for null or whatever, more often than not, null pointers are a symptom of poorly written code, but at least it gives us a clear direction of where your problem is coming from. Since Java 17 you can even see exactly what point of the chain was null. Having these "empty" objects would just mask the problem. How would trying to invoke a method on a "empty" would work? An EmptyObjectException? Or would that just return another empty object? What if the final response would be a primitive? Would we fallback to default values for the primitives? Would we get rid of primitives? I don't want to shit in your idea, but I see it doing more harm then good, more potential for poorly written code and making it harder to troubleshoot.
Its basically just renaming null. Thats obviously not giving much benefit. There are good reasons to not have `null` in your language *at all*, but I doubt thats a chance we will ever see in Java. But we might after Valhalla see `!` for types that are provably non-null.
An EmptyObjectException would just be an NPE under another name. The method or variable wouldn't even be invoked or accessed because it's a non allocated object. It would just return empty instead of an NPE. And in the case of a primitive it would also return nothing, thus, invoking an exception as returning 0 isn't ideal. Also, I consider poorly written code as having to check for null everywhere.
The thing is, You're making another set of problems for yourself. You can argue that a null pointer is annoying, but what's more annoying is getting a no pointer because a runtime exception was detected, or not getting a pointer and having everything just continue with uninitialized memory, returning an empty object and then having logical issues that are even harder to find. I might see this a bit differently because I started in COBOL, But you should never get a null point or exception because you shouldn't be dealing in nulls. Anything that hands back and no should be well documented. Under what circumstances it does hand back null, And the code should react to that accordingly. The more we demand our language to automatically be aware of things, the more declarative it becomes and the more logical errors arise. The less declarative, The more the onus is on the programmer to be explicit about what they want.
I think OP meant for the empty objects to return what's so called "smart nulls" in mocks. In a simplified universe, everything has a natural "0" value so for example return 0 for numbers, "" for string etc. It *is* a much scarier world because now programming errors don't fail, devs don't get paged when stuff go wrong. You just silently break the world: like paying you $0 fund when you sell your house, then while we are there, start a nuclear war or something, because, oops, the system had a glitch.
> The method or variable wouldn't even be invoked or accessed because it's a non allocated object. It would just return empty instead of an NPE. Then what would be the output of MyClass foo; foo.printAMessageToTheConsoleAndExit(); Note that there is no return value for the method call. Do you just silently fail and do nothing?
Interesting example. And yes, the method call would do nothing as it's an empty object. I really don't see that as an issue because getting to the cause of why foo.printAMessageToTheConsoleAndExit() printed nothing would be trivial. The IDE or compiler could even hint that you called an empty object.
> And yes, the method call would do nothing as it's an empty object That’s so much worse than getting a NPE! * Option 1 - I hit this button and it breaks. * Option 2 - I hit this button and nothing happens. You’re trading option 1 for option 2. But option 1 is trivial to find and debug. Option 2 is a nightmare to debug.
But let's think of a scenario where you need a group of Objects to setup another one, or a long user journey. Please bear with me, as it doesn't necessarily will be the best example. But let's say you tried to setup a connection with a database, but you got one of those empty objects for the connection or an empty repository object or an empty DAO. Now you want to save an object using this DB connection, the connection is empty, and as you proposed if I try to invoke this save operation on an empty obj, it will return another empty, I got no errors, no problem, now let's assume this operation is in a long user journey, with lots of different steps, validations, etc, you don't see any error for this, as you are only getting these empty objects along the way. But someone reported that some data is not there properly. it would be a nightmare to troubleshoot all of this. And just to be clear, I'm not saying that logic errors don't happen in our current Java implementation, absolutely they do, my point is that from my perspective it's not making it better, maybe just shifting the problem. One more thing to be clear, I think you didn't get my point on this part, I'm not saying you have to do null checks everywhere, there are techniques one can use to not having to check for null all the time, and still be null safe, I'm just saying that poor code is more prone to NullPointerExceptions or any kind of RuntimeExceptions. And I don't see this idea improving on this, but rather sweeping it under the rug.
So for a critical object that is necessary for data persistence I would check if a valid database connection was returned as common sense dictates that there's no point to continue processing if this has not been established. But, for arguments sake, let's say I'm lazy and didn't care to check for a valid database connection, called save to persist data and then checked the database to verify the data was saved and realized it wasn't. You're right that pinpointing the exact cause of the failure would be more challenging, but the runtime could assist you in clearly telling you that you attempted to call save on an empty object. I do agree that in certain cases instant failure is probably the best course of action to allow you to fix the issue immediately especially when it comes to data persistence.
Yeah, as I said it wouldn't be the best example, but still possible, thank you for making the exercise of going with it. >but the runtime could assist you in clearly telling you that you attempted to call save on an empty object But what we also need to consider here is that the IDE and the compiler also try to tell you when you are trying to invoke a method on a potentially null reference, but it's very challenging for it to figure it out most times, and it would be just as challenging for this empty implementation. if you have something like this: final var myVar = someMethodThatCanEndUpReturningNull(); myVar.someOtherMethod(); The IDE can try to check for obvious null returns from the first method, but as soon as it starts to be a bit more complex, more validations, more logic, the IDE will not warn you about that, it's up to you to figure it out what you are doing is safe, implement validation, or use some other options. The empty option would suffer from the the exact same problem, it would be up to the developer to always be prepared to have something empty and find a way to check it.
It seems like this is the heart of why this idea is a little flimsy as a feature: for it relies on devs to just do the right thing. I get the benefit, there are lots of situations where all I want to do if some value is null is to do nothing. But how is this different that a ```Objects.doIfNotNull(T obj, Consumer```?
You do realize that every call to an object eventually chains down to returning a primitive so everyone of your empty objects will trigger your new empty exception?
Because an empty object is not the same as a null? And also, that would be a massively breaking change that would sever pretty much all backwards compatibility.
That's the point. There would be no null. Empty is the new null, but without the NPE.
Okay but how do you differentiate between an empty object and nothing? That's the purpose of null. I wouldn't say I'm studied enough to make a proper argument, But I don't think we want to go the JavaScript route and assume everything is everything and this is a stepping sale and that kind of jumps in that direction.
An empty object has no memory allocation and if you reference an empty object you get back nothing instead of an NPE. But, then is there really a need to differentiate between empty and nothing? Empty and nothing are kind of synonymous.
Let's go your way: You have an object. It's empty. You wanna assign object.name = "Amanda" on an empty object. What does the language do then?
You're assigning a value to the empty object so the VM picks up on that and memory allocation occurs, the object is instantiated and the value is assigned.
I get your point but i guess that wont work like you expect because of generics List vehicles = new ArrayList();
Vehicle v = vehicels.get(0)
Do i get a empty Vehicle a empty Car (extends Vehicle) or what do i get?
And what about abstract classes and so on?
Edit: I like the idea its a good question but i guess you will reach some kind of dead end when you think it through.
Might be that this is not the dead end but i bet there is one
You've already instantiated the Vehicle object and allocated its memory so it ceases to be an empty object anymore and normal language rules apply. I realize that it's an idea with holes, otherwise it would have been implemented in some form long ago.
But what if Vehicle is a abstract class?
class Car extends Vehicle {}; class Truck extends Vehicle {}; class Bus extends Vehicle {} How do you decide what to return on vehicles.get(0) call when the list is empty?
Right, but there's a functional distinction between the two. Empty and nothing are not synonymous, That's why null exists. There is a difference between processing until the end of an empty list and not doing something because no list existed to begin with. People get null pointer exceptions because they work with nulls in their code and they don't properly document when a null will arise. If you're writing unit tests, you should always have a test for null and it should always work because there should be a null check in your code anywhere a null is possible. If you're null checking at the start, And not handing back nulls internally. You won't have an issue. That doesn't mean there's no argument to get rid of nulls but they're not synonymous.
>and they don't properly document when a null will arise. Or they didn't bother to read the documentation.
A somewhat common idea that languages like Pony and to a lesser extent Rust have done already. I'd like to see this in java. Here are some concerns you need to think about: * null is actually useful. __if__ properly semantically defined and used only for that. The useful definition is 'not a value / unknown'. You want the NPE __to be a good thing__. If I get the name of the logged in user (but, this is `null` as there is no logged in user) and I check if it starts with `admin_`, then the answer `true` __is just plain flat out wrong__, but, `false` __is just as wrong__. The question cannot be answered. The exception is what you want. SQL is much more clear on semantically defining null like this (as 'unknown'), and is properly infectuous (is `NULL = NULL`? The answer is NULL - because who knows if 'some unknown value is equal to some other unknown value'. Could be yes, could be no - note how java duplicates this: `null.equals(null)` throws an NPE, which is correct, semantically: neither `true` nor `false` is acceptable here). * Context is relevant. Imagine the same situation but we do a better job at designing it: We have a User object. We also have a User object representing the 'not logged in user'. Now `.getUsername()` perhaps should still throw maybe, but certainly `.isAdmin()` should just return `false`. But, maybe we also need a user object that represents other notions, such as 'we are processing scripts from the server maintainer directly; there is no user object but context-wise, all operations are allowed. It's like OS safe mode. `isAdmin()` should now return `true`'. Java already supports this: Simply make these objects and initialize your fields accordingly. Or, even simpler: The 'empty' outputstream: Is that an outputstream that is already closed (so, any attempt to write to it throws), or that is a byte sink (you can write to it all day; the bytes are ignored). * Other than 'context is relevant', some objects really truly do not have an 'empty' object. There's the empty string, and the empty list - so far, so good. We can even have an 'empty' `InputStream` (that is already closed). But is there such a thing as an empty `java.lang.Class`? I really don't think `Void.class` is right for that job. Nor anything else. Is there such a thing as an empty `Charset`? Maybe it should be possible for a type to decree that it _does not_ have an 'empty' instance, and for such types, initializing your fields is _mandatory_. This also makes it easy to introduce different takes on 'empty' (see previous bullet) - simply force initializing. Require that one writes `User user = User.notLoggedIn()`, you can't write `User user;` because `User` does not declare an empty object. Making it optional also makes it way, way easier to introduce this into the java ecosystem without a python2/python3 disaster. * Writing empty objects is a bit of a drag. Should the language include tools for this? * Should all types, including interfaces and abstract classes and even enums, have (optional) 'empty' instances? Bit of a drag to foist this requirement onto all library authors. * Should there be a function that produces an empty object, or, should it be a single field? If the latter, that thing __must be__ immutable or all heck breaks loose. There's no real way to force that; the lang spec is just going to have to stipulate: "Hey, author of a type? If you're going to introduce an 'empty' value, it's on you to make it immutable or hoo boy, its all gonna go very pearshaped indeed'. Is that okay? I think so, but, it's something to think about. Note that if there's a single value, you don't have to worry about 'memory allocation'. Yes, memory is allocated: For each type loaded in your JVM, __one value__, ever. Sum total. For the entire JVM. This doesn't matter: very type _already_ occupies a bunch of memory (the code of that type has to be somewhere!). Adding a little more for an empty object is therefore not significant as per `O(n)` thinking.
Something like `Optional>` or `final volatile ...` 🤣
/s
As an aside, your treatise in the Lombok github repo, on Optional vs Null in language design, is a wonderfully-formulated argument against Optional, in addition to being a compelling read. Thank you for that.
short answer: no long answer: no, why do that? genuine question: are people running into a million null pointer exceptions and i’m in the minority?
There’s much simpler solution - make Optional a system type which can’t be null. And all problem will go away.
I would support this.
Optional as null is useful. Unless you add a not initialized, or a truly empty and even that would get us to the same place we are now.
No, I’m talking about Optional as a special type which can’t be null. then you can define your field as “Optional name” and you will be sure that there is always a value - Some or Empty. But as it’s implemented now you can make “name = null;” and we will have NPE again :(.
Yes you need a not initialized, empty value, and has value. Lets say I have a JSON stream I may get no value JavaScript undefined, null value JavaScript null, or a string that may be empty but that is still a value. You need a way to communicate each of the three state potentials: undefined, empty, or a value, one of the only ways JavaScript is superior to languages. With Optional now I can do that inelegantly as: NULL, !isPresent, and get. If you require it to be a value then you need to add a notInitialized and an isInitialized. What I’m getting at is that Optional is in itself deluded. We would have been far better off with Elvis and coalescing operators than with Optional. Worse than bad Optional is misused, I’ve seen sooo much code with fluent optional blocks layered on top of each other that really would be better as methods or even layered if statements because the mappings and orElse calls. All really to pretend null doesn’t exist. So we can pretend we won’t get NullPointerExceptions. Unless we want them a’ la Objects.requireNonNull. Sooo ¯\_(ツ)_/¯
why do people dislike null? i love null, i use it all the time as flags
I dont really see the value. An exception would still be raised if you were expecting a non-empty object and you got an empty object. Have you seen how kotlin handles this?
Take a look at Scala, Kotlin, Python, and JavaScript. There are different approaches that can be taken to represent an empty value. Java's 'null' is actually pretty good when used with an IDE that will analyze code flows. Two huge benefits of null are performance and clarity. Nulls are understood all the way up to the hardware level and they never incur any of the penalties for being or looking like an object. Null means the same thing everywhere. Languages that hide nulls still encounter them, and they can be very unexpected.
So Valhalla has had to work through the question of what an uninitiated object should look like. You might want to consider if there is a real difference between what you are suggesting and a VM or language that replaces null with an Optional type. For those asking what the difference would be between such an empty type and null - an empty object has a concrete type, and unlike null cannot be coerced to anything else.
Golang does pretty much exactly that with zero values https://yourbasic.org/golang/default-zero-value/ . The memory is initialised, and has a default valid value for most uninitialised variables. Nil is used for pointer and related types though. In practice, it's horrible. All ints default to 0. So you cannot tell if it's uninitialised, or actually zero. It's even worse with structs, as everything can have a zero value. Removing nulls is better done by being MORE explicit about non-present values with things like Option/Maybe types. It's critical to be able to tell the difference between absent and present values.
just do a try-catch and throw null pointer exception ;-)
Null pointer exceptions exist for a reason. If you expect an object to have been initialised, and attempt to perform operations on it or read values from that object, but the object has not been initialised, then you want to know. You want an exception to be thrown so that you know something has gone wrong. The last thing you'd want is for the lack of initialisation to be hidden, you start performing operations on or reading values from an "empty" object that you expect to have been initialised and have valid values. Your application now has unintended state and you're blissfully unaware. The solution you propose works on the assumption that all objects are initialised with empty state, and that it's acceptable for all objects to have an empty state. But that often isn't the case.
This feels like you're trying to big brain something but reaching the same issue you're trying to solve. Having an "Empty" object returned just causes the same issues that Null value does. It's still an uninstantiated thing that should never happen and is erroneous programming/behavior.
Not necessarily erroneous, see JavaScript not present, empty, and value. Those are 3 separate states that Java coalesces into 2 states (poorly in my opinion). Other than primatives those are valid states.
Technically, you have 3 states in Java. You can create a variable without assigning a value or null. The compiler just catches situations where it could be a problem and refuses to build since it should never happen. JavaScript's way of handling also doesn't fit OPs idea of getting rid of the null state to remove NullPointerExceptions.
Bad idea. It’s better to fail as early as possible than to carry on as if nothing happened and deliver bogus results. NPEs are good at pinpointing the issue. Another issue is the extra allocations. All those zero objects must be unique, at least the ones with mutable fields. More memory churn. No, the billion dollar mistake is not null itself, nor the NPE, but the fact that nullability is not reflected in the type system, so it’s easy to over- or under-check for null, and the reader of your code has no idea whether a line will give off an NPE or not. That’s why null-safe languages have explicit unwraps
The fundamental problem with null is that it inhabits every reference type, so, for example, when a function has a return type that is a reference type you have no way of knowing whether it could ever return null or not. This forces you to either add null checks everywhere or risk NPEs. Your Empty object proposal has the exact same problems.
A rose by any other name is still null just with a new name.
Isn't this like the Optional Design Pattern?
This has the implication of that all objects must have a no-arg constructor. We're not just talking about Integer etc if we're having to handle complexObject.someComplexMethod().someAccessorOnReturnValue() Also, i'd far rather have an exception, then pull hair out trying to work out why some data in production is zero legitimately, or because some random data was uninitialised. There's worse things than a bug in production - and thats not knowing there's a bug in production.
If the object is not allocated then its hierarchy of complexity is irrelevant as it would just return empty. As for debugging or bug tracking, the JVM could hint that an empty non allocated object was returned.
This line of thinking is what Optional is for
If only there is a language that lets you explicitly say whether a type is nullable and forces you to check it if it is. Oh wait, there is one, it’s called Kotlin.
And it would smell as sweet.
That would cripple traceability. If I have `a().b().c()`, and the output is EMPTY, how do I know which one returned the EMPTY? NPE would tell me, but your solution would not, because calling a method on an object whose value is EMPTY would just return EMPTY too. It's a fun thought experiment, but it falls apart almost immediately.
Use Optional
I'd rather have a NPE than what essentially undefined behaviour. Do not hide bugs from the dev.
Good idea. I saw a lot of people here dumping on it for some reason, but let me tell you, that's exactly how to did it. However, nil / null still exists in the language. I think the best way to solve this might be what kotlin came up with
If you get a NullPointerException, you have a mistake somewhere. If you instead of an exception get a default object, that mistake is still there.
If we leave out the discussion about whether it makes sense, you'd have to basically define each object with non null default values, and when an object wasn't initialized, you'd simply pass the defaulted object. But you'd have to define defaults for everything that exists in your language, which would make it difficult sometimes to actually debug.
What if you could just do what Common Lisp does, and let you make methods that work on the null-value? If we ignore a lot of the incoming problem, static methods are just methods with no instance object passed in right? So you could imagine something like this working: public class BinaryTree {
BinaryTree left, right;
T val;
public int size() { 1 + left.size() + right.size(); }
public static size() { return 0; }
// Rest left to the reader
}
Or of course some other keyword, like public null int size() or what-have-you.
Now you could conceivably tell the JDK what to do when a method is called on a null value of some type, and you can write a lot of stuff without null-checks everywhere. Won't get rid of all NPEs, but would make a lot of the tedium go away.
just make your things to never be null.
What you're asking is something like [Groovy's Safe Navigation Operator](https://groovy-lang.org/operators.html#_safe_navigation_operator). Maybe you should give groovy a try and you'll see the hell it can become, specially when debugging production. There are NPE equivalents in Python, Node, C#, Ruby and probably every other language so i can't really see the point.
Why is it so hard to always construct your objects?
We have `Optional`.
Have you used JS? If you have, you might have noticed that it allows you to do a lot of things that would be errors in other languages, instead just doing something unexpected. It's generally agreed upon that this avoiding of errors was a bad idea. If something unexpected happens in your program, you'd rather have it crash and tell you, instead of silently doing something unexpected.
They are both runtime exceptions you can should check for on an as needed basis.
```` Person p = empty; var x = p.getName(); // what happens? Widget w = empty; w.frobnicate(); // what happens? w.show(); // what happens? ```` Types form a lattice. Renaming the bottom element of the type lattice doesn't really bring you any benefit. There are better options to explore, like `!` for non-empty types (`String! s = null;` would be an error) or a "strict" compilation mode that made the `!` the default and a `?` would mean ` | null`.
It is possible, and the pattern is call Null Object. The problem is - you can not implement it on a level of a language, because every class needs it's own custom implementations of NOP behaviour. But you can do it in your code and people do.
NullPointerExceptions are the best because they're so easy to fix and usually represent some sort of logic error. Replacing with empty values, whatever that means, will likely mean these errors will pass unnoticed and you'll get bad behavior but won't find it very easy to track down the problem
Kotlin offers a solution kinda like what you are describing, but more rigorous. It's still possible to get an NPE in Kotlin, but you have to go out of your way to create the conditions that would cause one.
Are you referring to the Elvis operator?
One of Kotlin's design goals is to eliminate NPEs: [https://kotlinlang.org/docs/null-safety.html](https://kotlinlang.org/docs/null-safety.html)
Should we tell OP about divide by zero?
What does a Division by Zero exception have to do with an NPE?
You’re close. Take it a step further. Disallow the creation of null objects, add syntax for an escape hatch, and then look at Kotlin because it’s already done and is awesome.
So we now have a new language what shall we call it “Jotlin?.” And how do we pronounce that and when will the new compiler be available? When is the conference? When is the UG meetings? BTW Kotlin doesn’t disallow creating null it lives in the JVM so it has nulls it just has compiler/developer hints as to what operations tend to be safer. Oh I know “Jotlin!!” But given reflection exists everything really depends on people most often do what they are supposed to. Like check for null. Hence it’s all hyperventilation for naught. If you don’t like NULL then use COBOL. If you want something fast and readable deal with NULL but the heavens forfend don’t rename it and say you’ve solved something because functionally you will always come back to something like what we now call null it’s just how much boilerplate you’re going to have to deal with to get there.
Null safety solves a runtime problem at compile time. Having dealt with more than a few NPEs in my life, I’m happy for the feature in Kotlin. The only people that seem to complain about it are the only who lack experience with it and fail to understand its benefit.
No it hints at it. There is a big difference and it depends on playing nice. Hence the “Jotlin!!” remark. But if people played nice we wouldn’t have null issues in the first place. And in only hinting with the propaganda that it is accomplishing it causes a worse thing — over confidence. Don’t get me wrong my preferred language is Kotlin, I just don’t believe in Santa Clause any more after dealing with NPEs and what came before them even in languages that professed to not have NPEs. If you need a language that is fast enough there are ways to get NPEs full stop. The language has to allow it. Kotlin does a better job of providing hints and guide rails but someone who misbehaves will get around it. It is better to have coalescing operators (like Kotlin) so that you can work through those segments of code with less density and more clarity. And it’s better to expose the potential problems at declaration time as well as default to the non problematic variation. But don’t try to sell me that the Easter Bunny came along and delivered a high performance language with the flexibility of the JVM without NPEs.
>And in only hinting with the propaganda that it is accomplishing it causes a worse thing — over confidence. I disagree, but that's fine. Your opinion seems to be skewed to the side of massive pessimism, and that's fine too. My experience hasn't been some pendulum swung in the opposite direction, I just like that I have way less NPE possibilities with my Kotlin code and I am far more productive as a result. I wouldn't classify my viewpoint as "over confidence", I just don't get NPEs and I work a lot faster with Kotlin than Java. Obviously anything that touches a java package can return null, and there's not much you can do about that except assume that it could be and use variables? that could be null. I've worked in Java database internals for 12 years now and have dealt with numerous NPEs, and my Kotlin experience has been far better. I guess yours hasn't, that's a shame. Have a good one.
You can do that with a Monad like Maybe. The easiest in java is to just wrap everything in List and only access it using map and forEach.