Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Sender: kevinr
Message-ID: <38F263D4.BCA2F300@earthling.net>
Date: Mon, 10 Apr 2000 19:29:24 -0400
From: Kevin Riff <kevinr@earthling.net>
MIME-Version: 1.0
To: ant-dev@jakarta.apache.org
Subject: Re: Standard compilation JSR 
References: <20000408153300.62284.qmail@hotmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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
options.

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
slow.


Robin Green wrote:

> Jose Alberto Fernandez <jofernan@us.oracle.com> 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?