Java Null VS .NET Null

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

David Jessee - 10 Aug 2005 17:48 GMT

In Java, creating a class that represents a tuple in a database is relatively
simple because if you have a field for, lets say, "Quantity" that is an
integer, you can set it to null. Since .NET uses a stack for these Value
Types, the integer (Int32) has an initial value of 0 and you can't set it to
null.

So, what's the best way to approach this without having to jump through a
bunch of programmatic hoops? These are a couple of ways I've though of.

1) Create a constant that represents a null Int32, et and use that value
(problem: you'd have to constantly check that value if you're doing
calculations)
2) Make all of your properties be objects. That way you could set the
property to an integer, or a null (or DBNull.Value). (problem: performance
hit from boxing and potential errors when doing calculations)
3) Have a property for the field and then have an ancillary property names
"FieldXIsNull" (problem: classes get bulky and you end up having to check
the IsNull constantly)

So, what are the best ways to approach this?

Side Note, I'd like to stay away from using datasets because they're big
memory hogs. If I can have a class that I can instantiate that keeps track
of real values, I'll get better memory usage. As far as the overhead of
coding all of these classes, I can use/create code generators for that.

Reply to this Message

Nigel Norris - 10 Aug 2005 18:55 GMT

Java only allows you to use null if you are using the wrapper classes (i.e.
treating primitive values as objects) - just like .NET Java primitive types
('int' etc) are stored on the stack and can't be set to null. So this is
really your option 2.

If you can wait for C# 2.0, it has nullable types, that do exactly what you
want (a value type that supports a HasValue option). However the database
api's may take a while to catch up.

Unless you planning to handle lots of in-memory data, I would still give
DataSets a look. They effectively use your option 2 (since all values are
objects). However if you use the tools to generate a strongly typed wrapper,
this will provide an interface like your option 3. If you try and access a
null property an exception will be thrown, so failures to test for null
fail-fast. Given the basic cost of storing all values as objects (which you
may have to do anyway), I don't think the DataSet memory structures are too
bad or too expensive.

In any case, my preference would always be for option 3, at least in terms
of the interface. That way the storage can be implemented in different ways
without the caller knowing. You can make the behaviour of the property when
reading nulls vary according to requirements (throw an excpeiton or return a
default value).

My 2 cents, anyway.

------
Nigel Norris

> In Java, creating a class that represents a tuple in a database is
> relatively
[quoted text clipped - 25 lines]
> of real values, I'll get better memory usage. As far as the overhead of
> coding all of these classes, I can use/create code generators for that.

Reply to this Message

Java Null VS .NET Null

Free Magazines