Return-Path: Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 12485 invoked from network); 11 Apr 2000 05:21:29 -0000 Received: from mercury.sun.com (192.9.25.1) by locus.apache.org with SMTP; 11 Apr 2000 05:21:29 -0000 Received: from shorter.eng.sun.com ([129.144.252.35]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA02928 for ; Mon, 10 Apr 2000 22:21:34 -0700 (PDT) Received: from ionic (d-ucup02-124-65 [129.144.124.65]) by shorter.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with SMTP id WAA29019 for ; Mon, 10 Apr 2000 22:21:32 -0700 (PDT) Message-ID: <03ff01bfa376$c87f5640$417c9081@ionic> From: "James Duncan Davidson" To: References: <20000408153300.62284.qmail@hotmail.com> <38F263D4.BCA2F300@earthling.net> Subject: Re: Standard compilation JSR Date: Mon, 10 Apr 2000 22:28:34 -0700 Organization: Why? MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N > - 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. True. Streams in. > - 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. ... 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 create. > 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 (such > as the JavaC task) that need this now. I think the JSR process would be too > 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 a few months for the JAXP.next 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 design. Whomever wants to pull together this JSR, I'll be happy to help however I can. .duncan