ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Riff <>
Subject Re: Standard compilation JSR
Date Mon, 10 Apr 2000 23:29:24 GMT
I like it. The last project I was involved in could have benefited by having a
standard Java interface for invoking a compiler. I even spent some time
day-dreaming about what features I wanted to have. Here's a quick list:

- The compiler should use callbacks to the invoker to locate source files. This
leaves all source-path issues up to the invoker, not the compiler. Source files
could come from directories, jar files, databases or strands of DNA but the
compiler needn't know about such things.

- Similarly, the compiler should invoke a callback to give the invoker the
completed class file(s). This lets the invoker store the class as a file, as a
database entry or whatever. Again, the compiler needn't know a thing.

- There should be a way to get back other info that compilers routinely create.
Things like symbol tables and inter-class dependency info.

- It should be easy to implement as a wrapper around just about any compiler.
The basic options (such as whether to include debugging info) should be
standardized. There also needs to be a standardized way of setting non-standard

I'm sure there are plenty more good ideas out there...

I don't think this should be done as a JSR. There are plenty of projects (such
as the JavaC task) that need this now. I think the JSR process would be too

Robin Green wrote:

> Jose Alberto Fernandez <> wrote:
> >All this talk about javac and what should be visible and what should
> >not, just points out the need for the Java Specs to define a standardize
> >way to access a Java Compiler. With JSPs and other technologies
> >that require compilation of generated code it should be obvious that
> >we cannot continue using javap to try to solve this problem.
> >
> >Perhaps we need something similar to JAXP (the standarizd API for
> >XML parsers) that all Java compiler providers should support to make
> >tools portable to different environments.
> >
> >Anyone willing to make an JSR out of this?
> >
> V. Good idea!
> It would be useful if this spec would support advanced options only supplied
> by some compilers - such as dependency checking in Jikes (FOOTNOTE: -depend
> is buggy in Sun's javac, and was disabled in JDK1.3's new compiler), and
> (looking to the future) incremental compilation support, for integration
> into IDEs in particular. Otherwise the spec would not be much of an advance.
> Perhaps the best way to do this, allowing for any number of new features,
> would be to have a queryable feature-set mechanism, with a public registry
> of features on a web site. So, the feature "dependency checking" (suitably
> precisely defined) would be given a key of, say, "DEPEND", and any other
> compiler using this feature would also use that same key in its feature set,
> rather than defining its own. Some features, like incremental compilation,
> would perhaps have to have new APIs defined for them, but this would all be
> done through a standards process.
> Kind of like the concept of BeanInfo objects, but with public standards as
> to what the keys meant.
> Is this clear, or do I need to explain it further?

View raw message