Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@jakarta.apache.org Received: (qmail 17377 invoked by uid 500); 21 Jul 2001 17:41:25 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: tomcat-dev@jakarta.apache.org Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 17322 invoked from network); 21 Jul 2001 17:41:24 -0000 Message-ID: <3B59BEDD.30506@stinky.com> Date: Sat, 21 Jul 2001 10:41:49 -0700 From: Alex Chaffee Reply-To: alex@jguru.com Organization: jGuru User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010701 X-Accept-Language: en-us MIME-Version: 1.0 To: ant-dev@jakarta.apache.org, tomcat-dev Subject: Re: sun.tools.javac.Main will be removed from JDK1.4 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Sam Ruby wrote: >Craig R. McClanahan wrote: > >>>Would there be a value in a commons-javac? Several Apache projects seem to >>>have need for this function... >>> >>That would be an interesting approach, but also a non-trivial amount of >>work. Any compiler hackers out there? >> > >I guess I wasn't clear. > >It seems that more than one Apache project has a need to wrapper java >compilers (classic, modern, jikes). It also seems that the amount of logic >for dealing with the ideosyncracies with the various releases (1.2 only has >classic, 1.3 has both, 1.4 may only have modern) continues to grow, >particularly if now a classloader is recommended... > >Perhaps we could come up with a single set of common code which can be used >by multiple projects? > That's an excellent idea. An interface encapsulating "compile this" would be great. Especially if we could have a flag for in-process vs. fork, and the ability to pass an InputStream even to compilers that insist on compiling from the file system (the library would deal with temporary files in a compiler-dependent and platform-friendly way), and the ability to get the class file as an OutputStream... While we're on the topic of new projects, I've been thinking about writing a Java Gestalt object. Basically it would implement a hell of a lot of "has" methods, like "hasJava2Collections()" or "hasRMI()", in a way that's easier to code to than catching ClassNotFound exceptions... It would make it somewhat easier to write code that runs on multiple VMs. Would anyone else find this interesting? - A