sebb wrote:
On 24/07/2009, Oleg Kalnichevski <[email protected]> wrote:
On Fri, Jul 24, 2009 at 03:01:34PM +0100, sebb wrote:
> On 24/07/2009, Oleg Kalnichevski <[email protected]> wrote:
> > On Fri, Jul 24, 2009 at 01:59:23PM +0100, sebb wrote:
> > > On 24/07/2009, Oleg Kalnichevski <[email protected]> wrote:
> > > > On Fri, Jul 24, 2009 at 01:07:35AM +0100, sebb wrote:
> > > > > Pressed send too soon:
> > > > >
> > > > > SSLSocketFactory is not inherently thread-safe, because of the
> > > > > [gs]etHostNameVerifier() methods.
> > > > > Is there a need to change the HostNameVerifier after construction,
or
> > > > > could the verifier be provided to the ctor? Alternatively, perhaps
the
> > > > > field could be made volatile?
> > > > >
> > > > >
> > > >
> > > >
> > > > I see no good reason for changing hostname verifier after
construction. Feel free to make the variable final and deprecate the setter.
> > > >
> > >
> > > Huh? There cannot be a setter if the field is final ...
> > >
> >
> >
> > The setter does not necessarily have to mutate any variable. It can simply
be
> > left empty. Feel free to throw a runtime exception
> > (UnsupportedOperationException for instance) if that makes you more
> > comfortable.
> >
>
> OK, I see. Keep the setter method for API compatibility, but disable
> (and deprecate) it.
>
> However, that would mean that existing code would only discover the
> problem at run-time, whereas removing the method would cause the
> change to be detected at compile-time.
>
> In both cases, client code will need to be changed.
>
> I would rather find out the problem at compile-time...
>
Same here. In my opinion full binary compatibility without full behavioral
compatibility is completely and utterly pointless. I rather have things break
on me at compile time than at runtime. But for some reason behavioral
incompatibility is often seen as less severe as binary incompatibility. There
is no point in trying to be a better catholic than Pope of Rome.
OK, but what is the way forward?
Feel free to make any changes you deem necessary. Anything that helps us
get the release rather sooner than later is OK with me.
Is it OK to break binary compatibility here?
I _personally_ would consider making the field final OK (given the fact
we have already made a few similar changes) but removing the public
method less so.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
