On 10 Jan 2014, at 16:36, Alan Bateman <alan.bate...@oracle.com> wrote:
> On 10/01/2014 15:08, Iaroslav Savytskyi wrote:
>> Hi, Alan,
>>
>> You are absolutely right. Unfortunately the things a little bit more
>> complicated. The reason why I’m fixing this now is, that some time ago I fix
>> this synchronization issue (synchronized setter without synchronized
>> getter). After that I got this bug. We had internal discussions if I can
>> leave my changes and the short answer is “no” :| Because it’s JAXB API and I
>> can’t change signatures within the same version. So I have to revert my
>> changes and leave it as it was before. We will fix this in the next MR for
>> JAXB API.
> It looks to me that JAXBException has always defined its SUID so I assume
> this means there isn't really any need to revert that, right?
Yes, JAXBException has SUID. The reason I’ve reverted my changes is that I’m
going to fix both files at once in MR.
>
> For TypeConstraintException then adding the SUID to the value that it has
> always been doesn't change anything except that it now appears in the
> serialization form that javadoc reports. So any implementation of this
> exception type would need to use that value. That might be why you need to do
> a MR. If it is required then your change is okay although I think it would be
> better if getLinkedException was synchronized. You can use synchronized
> (this) { ... } around the read to avoid changing the modifiers (and hence
> SUID).
>
> -Alan.
There are 3 possibilities:
1) Because it was my own initiative to fix this potential synchronization bug
and nobody didn’t report it, we can approve my fix and leave this 2 classes
without synchronized getters. And fix it in MR.
2) Fix it as you propose. But later we will definitely need to change it again
to volatile for performance reasons.
3) Leave classes with volatile as they are now. And only add SUID to
TypeConstraintException class.
—
Iaroslav
