ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Standard compilation JSR
Date Thu, 13 Apr 2000 02:52:41 GMT

Any reason why we should limit this to just java compilers? I think it
would be handy to have a standard "compiler" interface for any program that
takes a set of input files, generates output files, and has dependencies
between the two. This would make writing new taskdefs trivial, and would
also make life easier for IDE vendors.

JSR-000051 (New I/O APIs for the Java Platform ) recommends a "service
provider interface for pluggable filesystem implementations", which I
imagine will be similar to the FileSystem/FileObject interfaces in the
Forte4J OpenAPI. If all tools used these interfaces instead of manually
opening files (which should be a trivial change), we could implement
"callback" functionality by simply implementing the interfaces. That would
make it possible to read source files from a jar, or write output files to
a database. For speed, you could even keep temporary files in memory
without ever going to disk. Good stuff.

We'd probably also want the tool to be able to answer questions about which
files depended on what, which kinds of files it takes as input and output,
which icons to put in the toolbar...

I'm all for it. Let's make the tool vendors do all the work...

(BTW that JSR's at )

                    "James Duncan                                                        
                    Davidson"                 To:     <> 
                    <james.davidson@en        cc:                                     
          >                Subject:     Re: Standard compilation JSR
                    04/11/00 12:28 AM                                                    
                    Please respond to                                                    

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

True. Streams in.

> - Similarly, the compiler should invoke a callback to give the invoker
> 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.

... and streams out... Now, I don't necessarily agree that it needs to be
callbacks, but that's a detailed discussion.

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

Yes. Especially if you are generating code to feed to the compiler.

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

Actually, if you don't do it as a JSR, the most important compiler
available, the one that ships with each and every JDK, won't be compliant.
JSRs don't have to be any slower than any other approach. We're looking at
few months for the schedule from start to finish -- SAX2 took
longer than that and there wasn't any process to follow. And if you go too
fast, you'll probably (not necessarily, but probably) end up with a bad

Whomever wants to pull together this JSR, I'll be happy to help however I


View raw message