I guess until either BeanValidation is used in connection with it to
prevent null values, or other future (EE8+ maybe) options like a similar
annotation on top of a JSR 308 style checker, it's probably up to the
implementation.
As soon as either BeanValidation (mostly runtime) or JSR 308 (then you
should even get a compiler warning or error) enforces it, I don't know, if
we could in JPA.
Regards,
--
Werner Keil | JCP Executive Committee Member | Eclipse UOMo Lead
Twitter @wernerkeil | #Java_Social | #EclipseUOMo | #OpenDDR
Skype werner.keil | Google+ gplus.to/wernerkeil
* Chip-to-Cloud Security Forum: September 19 2012, Nice, French Riviera.
Werner Keil, JCP Executive Committee, JSR-321 EG Member will present
"Trusted Computing API for Java™"
* Eclipse Day Delft: September 27 2012, Delft, Netherlands. Werner Keil,
Eclipse Committer, UOMo Lead, Mærsk Build Manager will present "Triple-E
class Continuous Delivery with Hudson, Maven and Mylyn"
* JavaOne: September 30-October 4 2012, San Francisco, USA. Werner Keil, JCP
Executive Committee will represent "Eclipse UOMo, STEM, and JSRs involved
in, e.g. 331 or JCP.next"
On Mon, Jul 23, 2012 at 3:44 PM, Matthew Adams <matthew_at_matthewadams.me>wrote:
> Hi all,
>
> Scenario: entity "app.domain.Profile" extends abstract mapped superclass
> "app.domain.AbstractEntity". If AbstractEntity defines a single string
> field as its @Id, should the IdentifiableType instance corresponding to
> app.domain.Profile guarantee that its getId(Class) method will never return
> null?
>
> In other words, is it up to the client of the JPA metamodel to go up the
> entity's type hierarchy until it finds the SingularAttribute for the id
> field, or should the JPA implementation do that?
>
> Thanks,
> Matthew
>
> --
> mailto:matthew_at_matthewadams.me <matthew_at_matthewadams.me>
> skype:matthewadams12
> googletalk:matthew_at_matthewadams.me
> http://matthewadams.me
> http://www.linkedin.com/in/matthewadams
>
>