[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I: adjust test suite for upcoming GNU Make 3.83
From: |
Jirka Hanika |
Subject: |
Re: I: adjust test suite for upcoming GNU Make 3.83 |
Date: |
Sun, 10 Jul 2005 18:14:46 +0200 |
User-agent: |
Mutt/1.4.1i |
> 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
Re: I: adjust test suite for upcoming GNU Make 3.83, Alexandre Duret-Lutz, 2005/07/01
Message not available