Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 80837 invoked from network); 23 Feb 2001 03:15:00 -0000 Received: from dnai-216-15-97-206.cust.dnai.com (HELO betaversion.org) (216.15.97.206) by h31.sny.collab.net with SMTP; 23 Feb 2001 03:15:00 -0000 Received: from [192.168.1.105] ([192.168.1.105]) by betaversion.org (8.9.3+Sun/8.9.3) with ESMTP id TAA05861; Thu, 22 Feb 2001 19:18:53 -0800 (PST) User-Agent: Microsoft-Entourage/9.0.2509 Date: Thu, 22 Feb 2001 19:15:00 -0800 Subject: Re: [report] Classloading problems between Catalina and Cocoon From: "Pier P. Fumagalli" To: Tom Reilly CC: James Duncan Davidson , , Cocoon , Tomcat , James Davidson , Servlet API Experts , JAXP Expert Group Message-ID: In-Reply-To: Mime-version: 1.0 Organization: Apache Software Foundation Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Tom Reilly wrote: > > +1 > > There's no reason going from .java to a Class object should be any > harder than going from .class to a Class object. If the compiler used > ClassLoader's instead of manually reading .class files in through the > file system, fast in-memory compilation becomes a possibility (and > your runtime classpath becomes the same as your compiler classpath). > > That said, I think javac is never going to be this compiler, at least > not any time soon. They just re-wrote it and I doubt they'll do it > again. A more mobile open source project like KJC is probably more > realistic. If someone can check out what JavaCC produces as an output, then it wouldn't be "that" hard to come up with a compiler, using InfoSeek's Trove Class File API (Check out for more info on it). The big hurdle to go across is definitely the parser... Pier -- ---------------------------------------------------------------------------- Pier P. Fumagalli