|
|
|
| Authored by: greed on Saturday, April 21 2012 @ 07:46 PM EDT |
It's called a multi-pass compile.
If your syntax is simple enough, you can make a run through the source code
gathering method signatures, type declarations and so on. Then you go through
again looking at the rest, and actually turning the source into... the next
step.
That's the minimum needed for a get-it-done compile; code optimization can be
multiple passes all on its own--or even an unbound iterative process, that only
stops when time or memory runs out.
Even symbolic assemblers need multiple passes, two being the minimum, to support
replacing labels with offsets--otherwise, you can never go forward. I wrote one
in a weekend for the 68HC11 once, it was either write my own assembler or use
PC-DOS. Turned out I messed up... the official one for PC-DOS had a bug and
could generate bad branch offsets; mine didn't, so my team was the only one to
complete all the assignments....
Back to Java: it basically looks up symbols from everywhere it can: all the
.class files it can find in CLASSPATH, and all the .java files on the command
line. So you can have some grotty inter-class relationships and deal with it
just by shoving a whole pile of source into the compiler at once, crossing your
fingers, and turning the handle.
I'll be over here in "directed acyclic graph" world, if you don't
mind. I find circular dependencies result in brittleness and maintenance
issues.
(Oh, and to Java, .jar files are really just directories it can look in to find
.class files. There's some meta-stuff it will do with them, too, but class
loading is based on finding a file with a SuitableName.class in CLASSPATH,
whether it is in a directory or .zip I mean .jar file.)
[ Reply to This | Parent | # ]
|
|
|
|
|
