Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 54977 invoked from network); 6 Mar 2002 00:19:03 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 6 Mar 2002 00:19:03 -0000 Received: (qmail 26622 invoked by uid 97); 6 Mar 2002 00:19:07 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 26604 invoked by uid 97); 6 Mar 2002 00:19:06 -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 26593 invoked from network); 6 Mar 2002 00:19:06 -0000 Message-Id: <200203060019.g260J4U08572@mail004.syd.optusnet.com.au> Content-Type: text/plain; charset="utf-8" From: Peter Donald To: "Ant Developers List" Subject: Re: cvs commit: jakarta-ant/proposal/sandbox/embed ProjectHelperImpl.java Date: Wed, 6 Mar 2002 11:15:12 +1100 X-Mailer: KMail [version 1.3.2] References: In-Reply-To: X-Wisdom-Cookie: . MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Wed, 6 Mar 2002 10:11, costinm@covalent.net wrote: > On Wed, 6 Mar 2002, Peter Donald wrote: > > > I manually did what the compiler would do - now it should work > > > with any compiler. > > > > > > ( the runtime exception was a "Verifier error, expecting object/array > > > on stack" ) > > > > Jikes1.15 is completely and utterly busted. I would highly recomend you > > don't use it as your "reference" compiler. > > I had similar problems with gcj. I know jikes1.15 has problems, and I > assume other compilers will likely be tricked by inner classes. Maybe. > What happens at compile time to support inner classes is very tricky and > unexpected ( by most people ). The compiler removes 'private' and adds > parameters to methods - the first one does have security implications > ( not an issue for ant ). I think it is far better to avoid the magic and > pass the parameters explicitely - and as a benefit the code will compile > and work with more compilers. Yep. I generally have have a no-innerclasses policy unless they are static and don't access any variables from parent class. Too many things that people don't understand - I think your only the 4th person who has ever struck me as knowing how inner classes really behave (and 2 of the others were JVM implementors). -- Cheers, Pete ---------------------------------------------- Money is how people with no talent keep score. ---------------------------------------------- -- To unsubscribe, e-mail: For additional commands, e-mail: