Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 28982 invoked from network); 20 May 2002 02:41:38 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 20 May 2002 02:41:38 -0000 Received: (qmail 18604 invoked by uid 97); 20 May 2002 02:41:42 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 18564 invoked by uid 97); 20 May 2002 02:41:42 -0000 Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 18552 invoked by uid 98); 20 May 2002 02:41:41 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Message-ID: <001601c1ffa7$957d9060$2ea1f40f@nordwand> From: "Steve Loughran" To: "Ant Developers List" References: <98D21B073202584C9125C860580DC4EDEC0308@lgchexch006.ad.lgc.com> <3CE84EF8.6060108@cortexebusiness.com.au> Subject: Re: FW: Problem with ANT classloader? Date: Sun, 19 May 2002 19:39:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N ----- Original Message ----- From: "Conor MacNeill" To: "Ant Developers List" Sent: Sunday, May 19, 2002 6:18 PM Subject: Re: FW: Problem with ANT classloader? > Dominique Devienne wrote: > > Don't any of the ANT experts out there have any clue what's going on here? > > --DD > > Sure, but sometimes I find other things to do on my weekend :-) > > Let me start by saying that it is not possible to safely execute any > arbitrary piece of Java code in Ant's VM. This is one reason why the > option to fork is provided. When java code is run within Ant's VM it is > going to be affected by Ant's environment, particularly the classpath, > as well as the requirements not to mess with that environment. A class > that sets System.out, for example, would cause trouble executing within > Ant's VM. > > This is why the option to fork is provided. You can run your Java class > in a clean VM. It is slower, as you say, but in general it is also safer. I havent found it to be that much slower. A fair amount of the java exe and runtime libraries are already in memory and disk cache when you spawn the new JVM, so although there is startup hit, you dont pay the penalty of loading all the stuff in from HDD again. I havent done enough rigorous experiments to say this is a consistent truth, so in ACM terminology this is "an observation", not "a finding". Its enough of an observation for me to always set fork=true and not worry about things. Also when you fork you get System.exit() handling, proper-like, and better leakage handling. > > Of course, even when trying to isolate you, some VM classes must still > be loaded by the parent loader. The classloader treats all classes from > the java and javax package spaces as such. This approach worked > reasonably well up until JDK 1.4 when the JDK started to include many > classes from outside these packages - notably the XML related classes. > > There are a few things that can be done > 1. Add the XML related classes into the "special" classes so they are > delegated > 2. Allow you to specify that you want the classloader to delegate via a > new attribute i.e. > > I'm not that happy with the first approach as the problem will just keep > growing. The second approach is OK but then the task will not > behave like you were running in your own VM. I have that patch to do (1) posted a few weeks ago, and a better solution, derived from Dominique's suggestions (move it all to JavaEnvUtils, return a String array of intrinsic classes). The problem doesnt grow very fast, only at the rate of new java versions, so is tractable. Indeed, we should add some of the org.omg classes and even sun.misc for various bits of code to work in-JVM,. The better solution is on the HDD of my now-defunct laptop; I can post/apply it once I have a replacement laptop, which means that once I have dealt with a crushing internal purchasing beaurocracy that -refuses to ship me the laptop to a different country (the US) than my nominal place of employ (the UK) -wont let me get one of those home user laptops with firewire, s-video out, camera memory stick reader and cd playback of 8+hours while the CPU is off, and costing so much less than the dull corporate systems that I could afford to stack it with 1GB ram and still have spare cash -wont ship it to me without windows pre-installed. That just niggles me. anyhows, that means that I wont get the files back for a few weeks; I may jsut dredge up my patch from the archive, apply them to a different box and then redo the refactoring. This time I will even write the tests, with our old friend -steve -Steve -- To unsubscribe, e-mail: For additional commands, e-mail: