Request for approval for bug #8031488

Iaroslav Savytskyi iaroslav.savytskyi at oracle.com
Fri Jan 10 16:28:24 UTC 2014


On 10 Jan 2014, at 16:36, Alan Bateman <Alan.Bateman at 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




More information about the core-libs-dev mailing list