This change was just discussed yesterday on the dev list. Jake said: > I have some concerns with using Properties in public APIs. The use of > Properties is not strongly typed. I can’ tell from one property to the next > what the type is. I can’t get compile time errors is the type is wrong. I > don’t know what goes into a Property based on the interface or any magic and > IDE could produce. I can’t get compile time failures because I am missing or > using an invalid property. The Property object is synchronized, so I am using > this object to get values frequently I am not serializing all threads through > this object. > > Let’s take this time, where we are already fixing a broken API to do it > right. Build into the API a configuration class that has what we think we > need right now. We can add to that class over time as needed.
So I am surprised it was merged anyway. > On May 8, 2020, at 3:23 PM, Robert Houghton <rhough...@pivotal.io> wrote: > > Hello all, > > This is a call for help. > > We have recently enabled an API check job on pull requests on Concourse. > You have likely seen it, since it is failing while comparing changes on > develop (not yet on support/1.13) to our latest release, v1.12.0. > > I have configuration changes to the tool itself to fix most of the reported > errors, but am stuck on what to do for > 'org.apache.geode.net.SSLParameterExtension', which has seen a change to > its default and signatures. Should I add an exemption to this particular > class since it is new? Do we need to revert the change for the sake of 1.13 > and 1.12 compatibility? > > Thanks for any guidance, > -Robert Houghton
