| |||||||||||||
|
| |||||||||||||
uDig GIS: A First Look (Linux Journal)uDig GIS: A First Look (Linux Journal)Posted Oct 14, 2008 13:16 UTC (Tue) by anselm (subscriber, #2796)In reply to: uDig GIS: A First Look (Linux Journal) by frankie Parent article: uDig GIS: A First Look (Linux Journal)
This may have to do with one of the mantras of the Java community, »write once, debug everywhere«. There isn't much point in writing your code in a nominally very portable language based on a virtual machine if your code requires random unbundled libraries written in C or C++ to actually do anything useful. Hence you write something from scratch that will at least crawl, rather than not run at all because of library dependencies.
(Log in to post comments)
uDig GIS: A First Look (Linux Journal) Posted Oct 14, 2008 18:31 UTC (Tue) by flewellyn (subscriber, #5047) [Link]
Perhaps, but I question whether that mantra is actually useful. Portable languages based on VMs are thick on the ground these days; Java isn't unique in that regard. And I note that many of those languages, such as Python, Perl, Ruby, and so on, have no problem interfacing to libraries in other languages; in fact, it's one of the big selling points!
Granted, you can't deliver a byte-compiled binary as a blob to a customer this way, which is one thing that proprietary Java programs can do, but when the project is open source (like uDig), that shouldn't be a factor anyway.
If you want to deliver precompiled binaries for convenience, I think it's just fine to have one for Windows, one for MacOS X, and then let the other Unices (Linux and BSD) handle that themselves on a distribution basis.
Either way, there's no excuse for not being willing to interface with outside libraries if it would be more efficient, in programming time and in runtime performance, especially when those outside libraries are considered a standard for the field (GDAL/OGR being the "libc" of GIS).
|
|
||||||||||||