Closed GoogleCodeExporter closed 9 years ago
I'm fully for these changes, but would rather they wait for 2.0. Changes that
break
binary compatibility should only happen at major release number increases.
Original comment by heue...@gmail.com
on 13 Oct 2009 at 5:14
[deleted comment]
Breaking binary compatibility is only a problem in this particular case if the
user
of the library is changing the value of constants. I'd almost bet money that
this
won't break any client code.
If we were changing method signatures, I'd absolutely push for 2.0, but this
isn't
that. The only user story this would break is the deviant one. I'm all for that.
Original comment by allain.lalonde
on 13 Oct 2009 at 5:43
> I'd almost bet money that this won't break any client code.
Agreed, and if it did, the client would simply receive an IllegalAccessException
where they tried to set the value of the static final field.
I think of it as more of a marketing thing. You can't say your bread is
certified
organic if you put any one non-organic ingredient in it. Likewise, we can't
claim
1.3 is binary compatible with 1.2.1 if we break even once.
Original comment by heue...@gmail.com
on 13 Oct 2009 at 6:43
Funny. I'd be willing to replace certified binary compatible, to certified not
to
brake sane client code :)
Original comment by allain.lalonde
on 13 Oct 2009 at 6:50
I completely go with michael when it comes to "stick to the rules".
BUT.
Mind the frequency of our releases. When do we expect to release a new major?
Is agreed-on ill-written (most possibly not) existing client code really so
dear to us, that we'll rather not make
significant style improvements NOW?
I'd say no and make 'em final, feeling even less happy with the other option.
Original comment by mr0...@mro.name
on 13 Oct 2009 at 7:04
And: getting meaningful checkstyle reports, namely ones with near zero
complaints, has a value by itself.
I see this as crucial for using such tools at all.
But don't get me wrong - it's not checkstyle against binary comp. It's
conserving bad coding errors vs. binary
comp.
Original comment by mr0...@mro.name
on 13 Oct 2009 at 7:13
A workaround that retains binary compatibility would be to
1) create new static final fields where necessary
2) re-implement internal code to use only the new fields
3) mark the static non-final fields as @deprecated in version 1.3
4) remove the static non-final fields in version 2.0
The problem with this approach is that there are a lot of these, and we'd be
making
the API uglier before we would be able to make it nicer.
I vote for doing nothing in version 1.3 and making them all final in version
2.0.
Original comment by heue...@gmail.com
on 21 Oct 2009 at 2:23
Seconded and done.
Original comment by allain.lalonde
on 21 Oct 2009 at 2:42
Fixed in r935
Original comment by allain.lalonde
on 19 Jan 2010 at 9:09
Original comment by allain.lalonde
on 19 Jan 2010 at 9:13
Moving status back to Accepted, needs to be done on trunk.
Original comment by heue...@gmail.com
on 9 Apr 2010 at 9:43
Commit #1003 adds the final keyword where appropriate.
Original comment by allain.lalonde
on 16 Apr 2010 at 1:49
Original comment by heue...@gmail.com
on 2 Mar 2011 at 4:10
Original issue reported on code.google.com by
allain.lalonde
on 13 Oct 2009 at 4:55