Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (athena.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
Message-ID: <47B0CB0A.5090803@apache.org>
Date: Mon, 11 Feb 2008 14:24:10 -0800
From: Daniel John Debrunner <djd@apache.org>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: Reducing module dependencies
References: <2304A729-F547-443A-B95A-A0E0E8ECA664@mazumdar.demon.co.uk>
 <47AFD635.4060103@apache.org>
 <2B60F374-BCE9-43B9-B084-20464778F1CE@mazumdar.demon.co.uk>
 <47B0C48C.5070407@apache.org>
 <429CEEE8-11D2-4BEA-BB15-5266BF77F4DA@mazumdar.demon.co.uk>
In-Reply-To: <429CEEE8-11D2-4BEA-BB15-5266BF77F4DA@mazumdar.demon.co.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dibyendu Majumdar wrote:

>> 2) Such constants would probably no-longer be in-lined by the java 
>> compiler, leading to potentially slower code as a field lookup is needed.
> 
> Not sure about this, as a final value should be in-lined regardless of 
> how it is initialized. But this can be tested, I suppose.

I mean a final field in class A can only be in-lined in class B at 
compile (java source to byte-code) time if the compiler can determine 
its value. I think this is only currently true if the field is a literal 
(or set to another final field that is sourced from a literal). If the 
final value comes from file through a method call then the compile will 
not be able to in-line it.

At runtime the jit can probably in-line, but that's not what I meant.

Dan.