Java woes on compatibility

["Vladimir Z. Nuri" <vznuri@netcom.com>]

in a recent "PC Magazine" the story went into the compatibility problems
among different vendors versions of the Java language, predicting that
the problems may become worse. in short the vendors have a hard time
getting all the compliance exactly correct.

unfortunately, this same story happened with Unix and C such that the
libraries out there did not fully adhere to a standard, even when the
standard went into meticulous detail. is it the same insurmountable
problem all over again? can there ever really be a totally portable
language? java was invented to solve portability problems, but is
plagued with the same ones that other languages have.

what's the solution? it hasn't been implemented yet, but I believe the
solution is an extremely sophisticated verification package for the
correctness of the Java language. this type of idea is hinted in the
makefiles of some C programs that compile based on complex attempts
to avoid/workaround portability glitches. I saw one that did many
regression tests on "strcpy" trying to catch all the kinds of things
that can go wrong.

the idea is that you actually have code that tests all the key implementation
aspects of the library and language. it needs to be capable of being fully
automated. for example, you might have code that calls the java 
window kit and then actually verifies that a window is drawn correctly
by reading the screen or something like this. if you find that some things
are falling through the tests, you just add to your tests. the tests
don't need to be efficient-- you run them once and never again.

also, I think the solution would involve writing a lot of verification
routines for *every* feature of java that is implemented. the vendors
simply run the code on their own implementation and it gives a "pass or
fail" response. ideally, the java *user* could go through this process--
then the company cannot claim themselves that their implementation pass
it's all out in the open for customers to test themselves.

I would suggest that anything in the Java language that can't be 
tested like this, could be modified slightly to support this 
"testable" property, and that it would really pay off bigtime. in other
words, some part of the library that doesn't seem like it could be 
tested, could have extra little aspects added to its implementation that
support regression testing of the feature. (note that this is not
necessarily "regression" in the classic sense of software engineering,
but is very similar).

I've written software that has this property, that its verification 
routines are built into it and are accessable by the end user. I think
it represents a major new and important design consideration. and ultimately
I think it saves developers and users time in the long run, but perhaps
not the short run.

a lot of work? yes, but it's the only way in my opinion, and it can be
done in an elegant way. if it isn't I believe that portability problems
will *increase* as the article predicted, and the revolutionary possibilities
of Java will be forever handicapped and shortchanged.

note that some people think that you should have a certification process.
I don't like this at all because then the verification tools are caught
up inside the Java company when it makes sense to *distribute* these tools
so vendors can debug their own software without going through a 
bureacracy to get the stamp of approval. the verification suite is actually
an extremely powerful utility that can test Java conformance and should
be available to anyone trying to support the standard.

note also that it wouldn't have to be Sun that creates such a package.
in fact it might be better if someone not affiliated with the creation
of the Java language built such a package.

if anyone from Java/Sun is listening, I would be happy to consult on this.
<g>