Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@jakarta.apache.org Received: (qmail 5772 invoked by uid 500); 20 Jul 2001 21:24:01 -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 5755 invoked from network); 20 Jul 2001 21:24:00 -0000 User-Agent: Microsoft-Entourage/9.0.1.3108 Date: Fri, 20 Jul 2001 14:24:03 -0700 Subject: Re: sun.tools.javac.Main will be removed from JDK1.4 From: Jon Stevens To: tomcat-dev Cc: "ant-dev@jakarta.apache.org" Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N on 7/20/01 10:53 AM, "Craig R. McClanahan" wrote: > There are some pretty intense discussions going on about this, and the > story hasn't yet been finished ... > > On the other hand, the "new" compiler entry point has an absolutely > horrible feature (from the point of view of Jasper) -- you have to modify > System.out and System.err to redirect the compiler output. Unless system > variables are unique per classloader (they weren't last time I checked), > that means we can only do one compile at a time :-(. > > An additional note of interest to Ant developers - there is evidence that > running the compiler (either old or new) leaves a fair amount of cruft > lying around in static variables, after the compile has completed. The > recommended solution is to load the compiler itself in its own class > loader, so that you can throw it all away afterwards. That's the approach > we'll take when modifying Jasper. > > Craig You have to be kidding me. Sun is essentially screwing itself by making Jasper harder to implement? Time to drop Javac and just use Jikes... -jon