Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jdo-dev@db.apache.org
Received-SPF: pass (athena.apache.org: domain of cbeams@gmail.com designates
 209.85.132.249 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:mime-version:in-reply-to:references:content-type:message-id:from:subject:date:to:x-mailer;
        b=PTbgzYxXWT/IaL90XZd+KIa0MbbuTQaWF/IM70shr2NsaCAaKu1CwVtKl9WQPKMzcb2CP7EPqNRZPp1wGSj1fe39wApKFt39wkY05ujapbJ7rNGDGcjRHlBZwLI0C5I7W6X3qJChzblY5wYN6SmFevdJIo6X6x3AVWMF1PXoM8I=
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <4977A5C9-6283-4C9D-977A-0E98CAB670BF@gmail.com>
References: <4977A5C9-6283-4C9D-977A-0E98CAB670BF@gmail.com>
Content-Type: multipart/alternative; boundary=Apple-Mail-12--499644572
Message-Id: <02F2CA02-D259-442D-93AF-FC8C3086EB47@gmail.com>
From: cbeams <cbeams@gmail.com>
Subject: Re: Support for final modifier on fields
Date: Fri, 21 Sep 2007 14:00:36 -0700
To: jdo-dev@db.apache.org,
 JDO Expert Group <jdo-experts-ext@Sun.COM>

--Apple-Mail-12--499644572
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=WINDOWS-1252;
	delsp=yes;
	format=flowed

A bit more on this topic.  It looks like the post-construction =20
mutability of final fields was a change made in Java 5 per JSR-133.

Heinz Kabutz goes deeply into it here: http://www.javaspecialists.eu/=20
archive/Issue096.html

He even specifically calls out:

	"It makes sense to allow updates to final  fields. For example, =
we =20
could relax the requirement to have fields non-final in JDO."

Definitely give the article a read... interesting stuff.

- Chris


On Sep 21, 2007, at 1:31 PM, cbeams wrote:

> I'd like to point out a minor inconsistency in the spec (that =20
> actually caused me some trouble), as well as suggest a change:
>
> Section 6.2, "Goals" reads:
>
> 6.2 Goals
> The JDO Object Model has the following objectives:
> =95 All class and field modifiers supported by the Java language =20
> including private,
> public, protected, static, transient, abstract, final, =20
> synchronized, and volatile, should be supported by JDO
> instances.
>
> Having read this, I expected that I should be able to define fields =20=

> within my PC classes as final, and everything would be OK.
>
> This, however, is not true because of section 18.15:
>
> Fields with modifier final: none. Accessors will be generated for =20
> these fields during
> enhancement, but they will not delegate to the StateManager.
>
> And is further explained in 22.10.2:
>
> 22.10.2 Final
> A20.10.2-1 [Final fields are treated as non-persistent and non-=20
> transactional by the enhancer.] Final
> fields are initialized only by the constructor, and their values =20
> cannot be changed after construction
> of the instance. [Therefore, their values cannot be loaded or =20
> stored by JDO; accesses are not medi-
> ated. This assertion is duplicated in chapter 18.]
> This treatment might not be what users expect; therefore, final =20
> fields are not supported as persistent
> or transactional instance fields, final static fields are supported =20=

> by ignoring them.
>
>
> "Bummer", thought I.
>
>
> So, first of all, I'm suggesting that we at least modify 6.2 to =20
> call out the exception to the rule, explicitly stating that final =20
> fields are not supported.
>
> Preferably, however, I suggest we change the spec to support final =20
> fields.  The statement in 22.10.2 that reads "final fields are =20
> initialized only by the constructor, and their values cannot be =20
> changed after construction of the instance" is actually incorrect.  =20=

> Reflecting on a final field and calling setAccessible(true) does in =20=

> fact render it mutable to the caller.  This is all an =20
> implementation needs to do!
>
> There's also the question of bytecode enhancement and the addition =20
> of a no-arg constructor; it would be reasonable for the enhancer to =20=

> simply create a constructor that sets all the final fields to null; =20=

> it's going to write over them anyway.
>
>
> Perhaps I've missed something here, but I think the spec is just =20
> incorrect on this matter, and it would serve users well to support =20
> final on fields.  It was a huge disappointment for me when I first =20
> found out JDO didn't allow for this, as I use final liberally to =20
> ensure proper object construction.
>
>
> Thanks,
>
> - Chris Beams


--Apple-Mail-12--499644572--