Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Received-SPF: pass (hermes.apache.org: domain of gcaddd-derby-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: derby-dev@db.apache.org
From: RPost <rp0428@pacbell.net>
Subject: Re: Any ideas for debugging a byte code generation problem
Date: Sun, 20 Mar 2005 02:25:17 +0000 (UTC)
Lines: 31
Message-ID: <loom.20050320T031933-755@post.gmane.org>
References: <4239E139.7090106@sbcglobal.net>
 <6.0.0.22.2.20050317141118.03058120@pop.rcn.com>
 <423AE167.4070307@sbcglobal.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
User-Agent: Loom/3.14 (http://gmane.org/)
Sender: news <news@sea.gmane.org>


Kathey Marsden <kmarsdenderby@...> writes:

> 
> >
> > Another thing I would try is paring down the query to make it as small
> > as possible while still reproducing the problem.
> >
> >
> Aye, there's the rub.  In general with these byte code generation
> problems it is the size of the query that is the problem.  We are
> dealing with strict JVM specification  limits on things like method
> sizes.   So, we split methods into smaller methods and then we have too
> many constants.  Robbing Peter to pay Paul only works for so long.
> 
> 

I create a java class with 30,000 constants of the form:

int i1= 1,i2= 1,i3= 1,i4= 1,i5= 1,i6= 1,i7= 1,i8= 1,i9= 1,i10= 1;

Java 1.3.1 compiles it ok but jad 1.5.7g gives an error when trying to 
decompile it. A dialog box titled 'Program Error' with 'jad.exe has generated 
errors and will be closed by Windows. You will need to restart the program. An 
error log is being created.'

Couldn't find anything in the JVM spec about a limit on constants