Re: Representation<T> and Entity<T>

From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Tue, 10 Apr 2007 14:14:44 -0400

On Apr 10, 2007, at 1:52 PM, Jerome Louvel wrote:
>> ... and therefore its important to provide a way to specify this
>> additional metadata. Again, I think the generic wrapper class is a
>> better solution than requiring developers to define their own
>> wrapper or subclasses whenever the metadata can't be statically
>> inferred.
> Expressed in this way and for this sole purpose, I don't have strong
> objections. I would just suggest to not rely on this wrapper class for
> default examples as it implies that this is the recommended way.
Understood. In examples there's always the temptation to throw in
everything to show all the features of the API but that can tend to
confuse rather than educate.

> Looking more closely at Entity<T> and Representation<T>, I don't
> see the
> need for Entity<T> interface. It also has the inconvenient of being
> fragile.
> Once we have a first public version of it, we can't add any method
> without
> breaking implementing classes (beside Representation that we
> control of
> course).
No, only JSR 311 implementations are expected to implement Entity<T>
so its OK to add new methods in a later revision of the API.
Representation<T> is concrete, so again its OK to add new methods
since a revised 311 impl will support them.

>> We can define classes and/or annotations for common headers but I
>> think we also need a general mechanism - I don't want to define an
>> annotation for every possible HTTP header.
> I fully agree.


Marc Hadley <marc.hadley at>
CTO Office, Sun Microsystems.