On 11/14/06, Leichter, Jerry <[EMAIL PROTECTED]> wrote: > | > >> 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.
True, but that doesn't mean runtime portability isn't a good thing to aim for. -- mic _______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
