Historically we had the javac launcher in com.sun.tools.javac.Main -
and, over time, as we got a compiler API, we also got JavacTask, which
is essentially a programmatic launcher. Right now the two paths are
completely separated - they obviously reuse some of the internal javac
components such as JavaCompiler and the logic for parsing command line
arguments - but they are essentially two distinct beasts. Talking with
Jan at the last Dublin meet up, we concluded that there's a good chance
that it might be possible to view c.s.t.j.Main as a 'client' of the
compiler API - in other words, maybe Main should simply get a JavacTask
and run some compilation.
Bringing this code paths together has advantages - right now there are
subtle differences in the way things are initialized in both paths (esp.
around file manager) - and some options work in one mode, but not in the
other (e.g. -XDignore.symbol.file never worked properly when using the
compiler API). So, by unifying those two paths, we make the code more
robust, more shared, and with less chances to introduce bugs in one
places but not in another.
and, over time, as we got a compiler API, we also got JavacTask, which
is essentially a programmatic launcher. Right now the two paths are
completely separated - they obviously reuse some of the internal javac
components such as JavaCompiler and the logic for parsing command line
arguments - but they are essentially two distinct beasts. Talking with
Jan at the last Dublin meet up, we concluded that there's a good chance
that it might be possible to view c.s.t.j.Main as a 'client' of the
compiler API - in other words, maybe Main should simply get a JavacTask
and run some compilation.
Bringing this code paths together has advantages - right now there are
subtle differences in the way things are initialized in both paths (esp.
around file manager) - and some options work in one mode, but not in the
other (e.g. -XDignore.symbol.file never worked properly when using the
compiler API). So, by unifying those two paths, we make the code more
robust, more shared, and with less chances to introduce bugs in one
places but not in another.