Re: how to design a replacement for C++
On Jul 30, 11:08 pm, Daniel Pitts
So yes, a change inside a Java function body does not require
recompiling any other Java file, but for a correct incremental build
system, a change to a Java classes "exported interface" does require
recompiling all direct dependents.
That is mostly correct. I would qualify it with "exported interface"
with "used" exported interface. If the portion of the exported
interface which changed has not been used, then there need not be any
It seems to me that it wouldn't be too difficult at build-time to create
a dependency relationship among classes as part of the build. It may
reduce the speed of full builds, but that seems unlikely to matter as it
would be the less-common case.
There are many things that could be done to improve incremental
builds, but aren't. On all of the systems I've used, and all
but one I've heard about, the granularity of the build system is
the file. If you modify anything in a Java file, or at least
anything that changes the generated .class file (or causes it's
timestamp to be updated), then the build system will cause any
classes which depend on that .class file to be rebuilt; in
practice, the only information the build system has about the
..class file is its time stamp. The same problem occurs with
"benigne" changes (like adding comments, or a non-virtual
private member function) in a C++ header file.
At least one system I've heard about (but never used) tried to
do better. In C++, Visual Age C++ managed things at a much
lower level, maintaining meta-information concerning who really
used what, and how, and knew which changes affected what types
of use. (There was or is also a Visual Age Java, which I
suppose behaves similarly.)
FWIW, I work on some relatively large projects, and the unit
tests are what take the most time of the build.
A large project is (or should be) cut up into smaller
components. Normally, you're working on a single component, and
when you incrementally build during development, you'll only run
the unit tests for that component. (Before you commit your
changes, you'll run the unit tests for the entire project, but
if the unit tests for the component were complete, changes in
the component which pass those unit tests shouldn't cause
anything to fail elsewhere in the project.)