Warnings and collections

[Mike Schilling]

Perhaps the most frustrating Java programming assignment I ever did
was a classified ad system. I was handed code with hundreds of
collections all with Generic Map type, along with collection
assignment Had the code been done with Generics, it would have been a
snap.. Tracking down just what was supposed to go in each collection
was a nightmare.

On top of that there was the matter of null pointers. Where are they
valid and where do you need empty strings?

Off and on, I've been playing with the idea that there could be two kinds of
references in Java: those that can contain "null" as a value and those that
can't. Assigning null to a non-nullable reference would be illegal.
Assigning a nullable reference to a non-nullable one would require a cast
and might result in an NPE then and there, so that the NPE points to the
logical error, rather than occurring later when some perfectly innocent code
trips over the null pointer.

 

[Thomas Hawtin]

Off and on, I've been playing with the idea that there could be two kinds of
references in Java: those that can contain "null" as a value and those that
can't. Assigning null to a non-nullable reference would be illegal.
Assigning a nullable reference to a non-nullable one would require a cast
and might result in an NPE then and there, so that the NPE points to the
logical error, rather than occurring later when some perfectly innocent code
trips over the null pointer.

Nice does that. It gets a bit difficult with constructors - how do you
know if a member variable has been initialised yet? And then there's
threads...

Tom Hawtin

 

[Roedy Green]

Off and on, I've been playing with the idea that there could be two kinds of
references in Java: those that can contain "null" as a value and those that
can't. Assigning null to a non-nullable reference would be illegal.
Assigning a nullable reference to a non-nullable one would require a cast
and might result in an NPE then and there, so that the NPE points to the
logical error, rather than occurring later when some perfectly innocent code
trips over the null pointer.

I have had similar thoughts. I thought about using javadoc to at
least document which references are nullable.

 

[Thomas Hawtin]

I suppose you'd have to guarantee that all the non-nullable ones get
initialized. If thery're final, that already guaranteed.

Constructors can call methods before final variables are set. Certainly
the super constructor will have been called.

The one I can't see a good solution for is arrays. A newly constrcuted
array is full of null pointers, and you can initialize all of the members
perhaps 10% of the time. I think you have to accept that

Just insist on using collections instead...

Tom Hawtin

 

[Mike Schilling]

Nice does that. It gets a bit difficult with constructors - how do you
know if a member variable has been initialised yet?

I suppose you'd have to guarantee that all the non-nullable ones get
initialized. If thery're final, that already guaranteed.

And then there's threads...

I suppose you'd need to guarantee that objects gets flushed after
construction. Or just accept that odd behavior can result from
unsychronized access.

The one I can't see a good solution for is arrays. A newly constrcuted
array is full of null pointers, and you can initialize all of the members
perhaps 10% of the time. I think you have to accept that

~Object o = arr; // proposed syntax for non-nullable references

alwyas needs to be checked.

 

[Tony Morris]

Nice does that. It gets a bit difficult with constructors - how do you

know if a member variable has been initialised yet?

You are eluding to the formal invalidation of "OO as we know it" under a
given axiom (which I believe you are assuming). Care to continue the logic?
It's quite interesting - for myself and a few other interested parties at
least. Of course, like most religions, it's difficult for its subscribers to
swallow - but that's all part of the fun I can refer you to other
interested people if you like.

 

[Mike Schilling]

Constructors can call methods before final variables are set. Certainly
the super constructor will have been called.

The super constructor can't see the variables defined at the level of
"this". You're right that methods called from a constructor will have to be
careful about the state of the object being constrcted, but that's already
true.

My point about finals was probably unclear. I meant that the compiler
already knows how to check than finals get set from every constructor; they
can equally well check that any non-nullable field gets set from every
constrcutor.

Just insist on using collections instead...

And how does one implement the collections without using arrays?

 

[Mike Schilling]

The super constructor can't see the variables defined at the level of
"this". You're right that methods called from a constructor will have to
be careful about the state of the object being constrcted, but that's
already true.

Finalizers, which can see partially constructed objects, too.

 

[Thomas Hawtin]

The super constructor can't see the variables defined at the level of
"this". You're right that methods called from a constructor will have to be
careful about the state of the object being constrcted, but that's already
true.

They can. Normally through calling virtual methods. But this can be
casted as well.

My point about finals was probably unclear. I meant that the compiler
already knows how to check than finals get set from every constructor; they
can equally well check that any non-nullable field gets set from every
constrcutor.

You can all to easily see final variables before they are initialised.

And how does one implement the collections without using arrays?

Magic black box. I believe Eiffel does something similar.

Tom Hawtin

 

[Chris Uppal]

Nice does that.

More info here:
http://nice.sourceforge.net/manual.html#optionTypes
and here:
http://nice.sourceforge.net/cgi-bin/twiki/view/Doc/OptionTypes
(down at the bottom of the page).

It's not clear whether Nice has any special means to allow an instance field
with a non-nullable type to be initialised only in the ctor. I suspect that
you have to initialise it statically (as it were), and if necessary change the
default in the ctor.

AFAIKT, the Nice collections implementation is layered over the Java stuff, so
it's not possible to see how they'd solve the "the underlying array may contain
nulls but I know it's not null at this index" problem. I presume that it would
require logically unnecessary runtime checks in order to satisfy the compiler.

-- chris

 

[Mike Schilling]

AFAIKT, the Nice collections implementation is layered over the Java
stuff,

Kan?

 

[Mike Schilling]

They can. Normally through calling virtual methods. But this can be casted
as well.


You can all to easily see final variables before they are initialised.

True, but at least you can't leave them uninitialized.

Note that fields cause two sorts of problems.

1. It's possible to see them before they're initialized, thus you see a
null you're not expecting.

2. It's difficult if not impossible to prevent:

NN1 = this.NN2; // both declared non-nullable, but NN2 has not yet been
set.

The first can cause NPEs at that line. The second can result in NPEs
anywhere, which is much worse. In fact, it's exactly like Java today.

 

[Chris Uppal]

Mike Schilling wrote:

[me:]

Kan?

Aargh!

Would you believe me if I claimed: As Far As I Know Today ? No ? Oh, well....

-- chris

 

[Oliver Wong]

And how does one implement the collections without using arrays?

Remove all asymptotic runtime guarantees and implement everything using
linked lists and binary trees?

- Oliver