Re: The curse of constant fields

Mike Schilling wrote:
Arne Vajhøj wrote:
Mike Schilling wrote:
Arne Vajhøj wrote:
Patricia Shanahan wrote:
Juha Laiho wrote:
I got recently bitten by something I consider to be a rather nasty
feature in the Java language, and decided to write up about it.

I had to do a couple of simple changes to a relatively shaky and
not-so-testable codebase, so I chose to do the absolute minimum
required: change initialization values for a couple of String
fields
in a class, compile the changed class, and run the code manually
to
observe that I had achieved the desired change.
...

You have my sympathy for your frustration, but I would call this
story "The curse of manual builds".

Back in the 1970's, long before Java was invented, I worked on a
large project that avoided reassembling all the code by having a
team of programmer techs who constructed the list of modules that
needed to be assembled due to each change. The programmer techs did
their best, but it was a *very* error prone procedure.

Since then, I have seen complaints, for several languages, of the
form "I did a manual build, and got into trouble due to [some
aspect
of the programming language or environment]".

I am convinced that the only viable choices are rebuilding
everything
for every change or using language-appropriate automatic dependency
analysis.
And tools like ant make it easy.
Easy to get it wrong, I think you mean. Ant's dependency analysis
amounts to:

Compile A.java if A.class is either absent or older than A.java.

Ant will not recompile A.java on the grounds that it uses contants
from class B and B.java is newer than A.class. When accepting a set
of changes from elsewhere (say, when updating from an SCM system),
the only safe procedure is to do a full, clean rebuild.
I meant that ant make rebuilding everything easy.

Clean all dirs, extract from VCS, compile src->build, pack jars.

That's quite true, though of course it would be true of any scripting language. Back in C and C++ days, there were fairly simple tools to optimize builds: makemake scripts that analyzed source code to build dependency lists and generate make scripts, so you really could do a build that was both safe and minimal. Java (in particular, the fact that a .java file is the equivalent of both .c and .h files) makes this astonishingly difficult.

Huge C/C++ build often took a long time, because of the include thing,
optimizing by the compiler and because systems were slower back then.

Java doesn't use include, javac doesn't optimize and the systems are
fast.

I don't see full rebuild as a problem.

Arne
.

Relevant Pages

  • Re: Help me!! Why java is so popular
    ... byte-coded language outperform a binary language if they are doing the ... Garbage collection can have an advantage in multi threaded applications, and in Java we can have exact c. ... In a compiled language you can't optimise across the interface call whereas with Java you can. ... Even better you can generate byte code at run time (e.g. compile an expression typed by the user) and then the JIT can compile that to machine code and if it is simple enough inline it. ...
    (comp.lang.java.programmer)
  • Re: Comparing Lisp conditions to Java Exceptions
    ... All the ISO standards in the world will not make the world ... Nothing keeps you from annotating your program with exceptions based on what ... language should adhere to your theory. ... Curiously, although you don't say it, Java has the opposite problem. ...
    (comp.lang.lisp)
  • Re: Cpp Considered Harmful
    ... >> means of doing some of the things the CPP is currently used for. ... > syntax of #include for the language specified libraries. ... believe it would be trickier in C++ than in Java to accomplish what I'm ... there is often a need to compile a class before it can be ...
    (comp.lang.cpp)
  • Re: casts
    ... This is why most shit programmers refuse to learn languages including ... C Sharp and Java. ... compiler in a later edition of Visual Basic, ... language for processing data. ...
    (comp.lang.c)
  • Re: C, really portable?
    ... > Wait, is Java a modern language superior to C, or is it still ... It is a much better OO language than C++, ... It depends what you are doing, Java aims for rigorous portability - the same ... regardless of platform. ...
    (comp.lang.c)