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.247 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:mime-version:to:message-id:content-type:cc:subject:from:date:x-mailer;
        b=iVI8fbrg2ubi05NGRhiZpgv2hOFvdmSU1ikarLENuh7GU/Cys+/0M+YpmFgO77tF55F6sD9hzaTrtINt4MTplsgu7H4MwzfhjOSC9ux+SGy1u50GrDherhdRXX5XbN7rvD2PU0gWiSXouY4SfU6zHh0hthjKsoTRLyHov7YF13Y=
Mime-Version: 1.0 (Apple Message framework v752.3)
To: jdo-dev@db.apache.org
Message-Id: <4977A5C9-6283-4C9D-977A-0E98CAB670BF@gmail.com>
Content-Type: multipart/alternative; boundary=Apple-Mail-11--501366554
Cc: JDO Expert Group <jdo-experts-ext@Sun.COM>
Subject: Support for final modifier on fields
From: cbeams <cbeams@gmail.com>
Date: Fri, 21 Sep 2007 13:31:54 -0700

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

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, synchronized, =20
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 stored =20
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 call =20
out the exception to the rule, explicitly stating that final fields =20
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 implementation =20
needs to do!

There's also the question of bytecode enhancement and the addition of =20=

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-11--501366554--