[Tutor] Sun says: Don't use Java, use Python!

[alan.gauld@bt.com]

> > containing all of the classes in the original. We then have
> > multiple Jars some with A B C and some with A B and C+.
> > It becomes hard to know what has changed, what the impact is etc.

I didn't explain this well, sorry.
I meant let's assume C is modified but because of dependencies 
B needs to be modified to cope with the changes in C. So the 
Jar file *should* contain A B+ and C+ but accidentally gets 
shipped with only A B and C+

This kind of consistency error can and does happen and is very 
hard to detect if you don't have the original source files(in 
fact even if you do, because the modified B is in the source 
repository but the old B is in the JAR! If A B and C are all 
in one source file then this can't happen. Of course the file 
gets very big which is where tradeoff comes in. In C++ and some 
other languages(Modula etc) we can separate declaration from 
implementation and so keep the class declarations in one file 
and the implementations in separate ones - the best of both worlds.

> How does putting A B and C into a single source file ensure 
> that the person who made the modification has tested that it 
> is binary compatible with the rest of the package?

Provided they test the JAR and not the compiled source then its fine. 
Unfortunately experience tells me that very often developers test 
the source files then create a JAR and ship it. If the JAR creation 
step doesn't, for whatever reason, pick up the right source 
version then an error results. From hard experience with several 
vendors we have become very wary of JAR releases!

> production code, then I would hope that the developers would be using 
> an ant script to compile and assemble the JAR which 
> incorporates a test bed to ensure that everything inside the JAR 
> is to spec etc.  

You would hope so, but sadly you might be wrong...

> there is a lot of room for error here, but I think the same 
> is true of a Python module.

Sure but Python lets you choose your poison. Java dictates it.

> strategies for this, though.  I've never written code for public 
> distribution myself (only for the two companies I've worked for), 

I'm usually a customer, and suffer the pain. Weget far fewer of 
these kinds of issues from the C++ suppliers than from the Java 
guys.(Sometimes they are even the same vendor!)

C++'s header, body approach requires more upfront work but 
provides a powerful error catching mechanism IMHO.

Alan g.