automake
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]