| > >> If there is some construct that NEEDS to be interpreted to gain
| > >> something, it can be justified on that basis. Using interpretive
| > >> runtimes just to link languages, or just to achieve portability
| > >> when source code portability runs pretty well thanks, seems
| > >> wasteful to me.
| > >
| > > You think source code portability is good enough such that runtime
| > > portability isn't really needed?
| >
| > Anything beyond source code portability tempts the customer into use
| > on a platform where the developer has not tested.
|
| But it has been tested, because if it runs on that jvm it has been
| tested for that JVM. a JVM version x on linux is the same as a JVM
| version x on windows. That's the point. Now maybe they try running it
| with a version x - 5 JVM, well fine, it may not work, but the response
| would be: "duh".
That would be nice, wouldn't it?
Unfortunately, painful experience says it's not so. At least not for
applications with non-trivial graphics components, in particular.
The joke we used to make was: The promise of Java was "Write once,
run everywhere". What we found was "Write once, debug everywhere".
Then came the Swing patches, which would cause old bugs to re-appear,
or suddenly make old workaround cause problems. So the real message
of Java is "Write once, debug everywhere - forever".
Now, I'm exagerating for effect. There are Java programs even quite
substantial Java programs, that run on multiple platforms with no
problems and no special porting efforts. (Hell, there are C programs
with the same property!) But there are also Java programs that
cause no end of porting grief. It's certainly much more common to
see porting problems with C than with Java, but don't kid yourself:
Writing in Java doesn't guarantee you that there will be no platform
issues.
-- Jerry
_______________________________________________
Secure Coding mailing list (SC-L)
[email protected]
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php