> However, apparently there is no choice but to support them since Java > requires it. It really confuses me how a company like Sun could create > a language that is so difficult to use with standard UNIX tools. If > you're going to invent a language, why not make it easy to work with?
I may be able to help you on this. Java guys have a very different view of what portability is: try to avoid any tools which are not written in Java. Wow! now all you need to do to cover a new platform, is to port the JVM. No need to port each individual tool separately, nor to learn "portable functionality subsets" out of fear that a recent tool version may not run on the target platform. In fact, you may even extend most tools (in the sense of writing a make plug-in in Java to *save* labor) if you subscribe to this line of thinking, and it is frequently done. Thus, while most C/C++ projects with wide portability do use make, most Java projects with wide portability use ant in its place. Today, C/C++, Java, Unix, make etc. are so unbelievably common things that you may certainly want to support Java in make (for example for large-scale integration of legacy Java with C/C++, esp. in UNIX environment.) But it was not so when Sun was working on the support for inner classes (i.e. before Java 1.1). At that time, many people still saw Java as a (web) client-side programming language, and the dollars were thus seen to be primarily introduced into bytecode class names, rather than into filenames.) Jirka
