This discussion is archived
1 Reply Latest reply: Dec 4, 2002 3:16 AM by 843853 RSS

null metadata keyword -> JCP idea if enough support ?

843853 Newbie
Currently Being Moderated
Null Metadata Keywords,

In an ideal development world we apply proof of correctness algorithms to our source code to prove that we've handled all possibilities and there are no bugs. We need to ensure that all functional possibilities are handled. Ideally we need to tie all the various constraints into the specification and have the compiler prove that we've taken those constraints into account. Now, typically, the compiler cannot do everything. Alot of the future engineering tools generate stubs that pregenerate the complex constraints from uml diagrams, etc. That does not imply that everyone is using those tools.

Adding 'null metadata keywords' to improve proof of correctness by annotating the appropriate method interfaces with meta-data, we generate more appropriate warnings. This should either speed up development, or allow a team to minimise the possibilities of errors when following a solid development design. In addition, a team should be able to specify their appropriate interfaces and have certification by the compiler that dodgy situations have been appropriately handled.

In a nutshell:

// Consider four typical functions:
public Object zoo() { return new Object(); }
public Object ray() { return (cache != null):cache?null; }
public Object foo(Object bar) { return bar; }
public Object moo(Object baa) { return baa.ray(); }

// zoo's contract is to return a new object
// ray's contract is to return a new instance or null if a cached object is not available
// foo's contract is to take any object (or null) and return it
// moo's contract is to return the baa.ray() result
// We can all see the problem, what if baa==null

// With strict null keywords, the compiler would warn about moo
// The above code should become:

public Object zoo() { return new Object(); }
public null Object ray() { return null; }
public null Object foo(null Object bar) { return bar; }
public null Object moo(Object baa) { return baa.ray(); }

// moo(ray()) would return a compiler warning
// foo(ray()) would not

Effectively, we add a tiny bit of metadata to improve the contract specification that helps us prove all situations have been handled.


I think its a small pindrop in the ocean of compilers... but... can you think of a reason why it should not be an option to have null contract checking within a compiler tool?

Its obviously not a major feature - rather, its helps convert software development into software engineering. Having it as an optional compiler analysis option (eg: -contract:null or whatever) would be appropriate.

I would hazard to introduce the throwing of a NullPointerException in the event that a return value actually IS null. Possibly as a debug option, it might be quite usefull, identifying exactly where the contract was broken instead of where the effects are felt might be usefull.