users@javaee-security-spec.java.net

[javaee-security-spec users] [jsr375-experts] Re: Identity Store Proposal

From: Werner Keil <werner.keil_at_gmail.com>
Date: Sat, 13 Jun 2015 17:47:42 +0200

Hi,

On Sat, Jun 13, 2015 at 5:29 PM, arjan tijms <arjan.tijms_at_gmail.com> wrote:

> Hi,
>
> On Sat, Jun 13, 2015 at 3:10 AM, Alex Kosowski <alex.kosowski_at_oracle.com>
> wrote:
>
>> Hi Arjan,
>>
>> Thanks for your comments! I just wanted to mention a subtlety. The
>> Identity Store proposal contains an SPI called an IdentityStore interface,
>> which is responsible for interacting with the persistence mechanism. I
>> think IdM or Identity Management system would really be a better name for
>> the proposal.
>>
>
> No issues with that term itself ;)
>
> But it looks to be a broader concept than just "identity store", which if
> I'm not mistaken is still pretty much what was discussed here, right?
>
>
>
> [Alex] After credential validation, the Credentials type returns both the
>> status of credential validation and the associated Account. The status
>> serves as a convenient result code to inform the caller why validation
>> failed. If the status is VALID, the Account is available. I suppose the
>> concern about mutability is that the caller and the credential handling may
>> be on different threads. Both Account and Status could be assigned
>> internally using volatile variables, so no locking would be needed although
>> there is a slight performance hit as shared memory is resolved. So I do not
>> see a big problem. Do you have a specific use case?
>>
>
> It's more a concern of API design and usability. In the last few years
> Java seems to be moving to a somewhat more functional style and putting
> less emphasis on mutable types. The old Data/Calendar versus the JSR 310
> types is maybe a good example. Although this was a concern of Jan, I share
> it, and think it's just cleaner and easier to understand to have a
> Credentials which only functions as an input type.
>
>
While JSR 310 does solve some issues like mutable objects, it is not an
example for "good" API design I'm afraid. Bloating and redundancies, just
take terms like Period vs. Duration, and worst of all, circular
dependendies between an anemic almost unrecognizable API (hidden in
"java.time.temporal") and its RI

with
https://docs.oracle.com/javase/8/docs/api/java/time/temporal/TemporalUnit.html
that has a getDuration() method, which returns a concrete RI type Duration,
that implements TemporalAmount which then again references TemporalUnit
(which references Duration, which references... you know where this goes,
any serious customer of ours would stone us to death if we did that in one
of their projects;-O)

Cheers,

Werner

>