Hi Gilles, Gilles Sadowski wrote:
> Hi Jorg. > >> > >> > From comments that were posted to the other thread, I gather the main >> > trend that, because some interfaces needed an upgrade, the "interface" >> > design tool is becoming "evil". Did I get this right? >> > >> > I guess that you refer to "RandomData" and "RandomDataImpl". This is >> > indeed the typical example of abusing the "interface" tool. When only >> > one implementation is meaningful, an "interface" need not be defined. >> >> No. It is about adding something to the interface, just like Phil said. >> If you add a method to an abstract class, the dervied ones are still >> binary compatible, the same does not apply for interfaces. >> >> We had discussions in *length* about this and I am not interested in >> starting over again. > > Well, I was not part of those discussions, and CM is _still_ full of Java > "interface"s; so I assume that it's acceptable that I give my > point-of-view now. > > As I said, I'm not in favour of creating interface for the sake of having > everything separated in "Foo" and "FooImpl". > I understand that having an abstract class has some definite practical > advantages. And for the things I had in mind and which I'm most concerned > about (coherent design), it might well be a non-issue: "interface" could > be changed to "abstract class". > > The problems might come from the one thing which you can do with interface > but cannot with classes, namely, multiple inheritance. I never said that using abtract classes over interfaces is a mantra, but for a common library you should always prefer abstract classes if in doubt. More on this later. > Did someone already analyze the situation in CM? > The issue might well be resolved similarly to the debate about checked > exceptions, i.e. within CM, "interface" may also prove to be an > unneccessary feature of the Java language. It is a case by case decision, but an interface can be a heavy burden. [snip] >> > So what's the problem? Is it the binary compatibility, again? This is a >> > configuration management issue. When the compatibility is broken, you >> > change the major version number and/or the base package name. That was >> > settled, or not? >> >> The point is that an interface should not be changed for a long time. >> Otherwise every new release is a major one. > > It is not a question of time but of major (incompatible) and minor > (compatible) releases. As I noted in the reply to Sebb, the real problem > is not supporting older releases. That's a policy issue. For common libraries this is a very bad policy. Again more on this later. >> > It would be a pity to sacrifice a tool aimed at improving the design >> > because of such considerations as keeping backward compatibility with >> > versions that nobody here is going to support. >> >> It's a pity for the user, because he will *never* be able to use the next >> version as drop in. > > I also answered that in other post. > >> > If some user is happy with version "M.m", he can use it forever. If he >> > wants to use a newer version "N.n", he should not expect it to be >> > compatible. It does not have to be! Non-compatible modifications are >> > not performed out of some urge for change but stem from the desire to >> > get a better product, bits by bits. >> >> If that were true, you would currently have 10 different commons-lang, 10 >> different commons-collections and so on in your classpath. > > No, it's the user's choice to select which version he wants. This is the whole point, because it is probably not. Again more on it later. > You cannot have multiple versions of Linux running at the same time, but > nevertheless the kernel developers make releases at a much higher pace > than Commons... Nice example, I remember that Linux has explicit stable kernel lines that are used in business environment and patches from newer kernel versions are backported. The stable API is also a business requirement for Linux. And this has nothing to do which kernel version *I* currently run on my box and how often I upgrade. >> > Yes, it's not easy to get the interfaces right; so what? If you find >> > that you can improve the design, you do it and bump the major verion >> > number. As someone pointed out, it's not as if we'll run out of >> > numbers. >> >> And people will stop using it, because they are annoyed when they are >> depending in the end on n different versions of math, simply because of >> transitive dependencies. > > I think that you reason on the basic assumption that CM is close to > stability. Many problems (some bugs but also design consistency) have > shown that it is not. No. There are always times, when too many stuff piled up that requires an API change. But then you may have more radical changes and combine it with e.g. new (incompatible) JDK features. New digester is a very good example of it. But you have to make very wise decisions about the new API to keep it stable again for a maximum time. > So, my opinion is that users will prefer a product > that continues to improve rather than something that is > backward-compatible. I'm one of those. If not, I'd be content with what is > there and would not feel the need to contribute. Problem is that it does not match the business requirement. See, when I am cleaning the apache stuff out of my local repo and start a complete build of or products and components, I end up with quite every available version of commons-lang, commons-io, commons-collection, etc. in my repo again. However, *we* do only use one of those versions i.e. all he other versions are pulled by 3rd party stuff. Therefore I have to praise my fellow committers here at Apache, who made it possible to upgrade all those artifacts and all the stuff will simply run regardless of the original version they were dependent on. Now, commons math might not have that wide-spread usage up to now, but the new version has been proposed and recognized and as soon as companies start to build products on top of it, you argumentation simply no longer applies. Not all of those products will upgrade at the same time, but a user might have to use two such products (depending on incompatible math releases). Therefore we have the policy to rename package and artifactId for major versions, at the price of annoying upgrades for our users. But they will at least not face the situation above. However, such annoying upgrades should not happen too frequently, because it is effort. >> > Part of the real problem (as shown by the amazing amount of done and >> > undone work for 2.2) is that you (collectively) want to do too many >> > things at the same time (lots of changes *and* few releases). To be >> > clear, the problem is not the "lots of changes" part (which you would >> > like to "solve" by vetoing future compatibility-breaking improvements). >> > Note that the following is not a criticism of CM (which has many >> > features etc.) but some of the code that I've seen (in the parts which >> > I've more closely looked at) do not make me think that it is mature >> > enough that one can say "That's it!" and stick with the design forever. >> > Again, all this (e.g. removing duplicate code and refactoring the >> > design) can be considered unimportant and swept under the carpet but >> > IMO *any* cleanup is good as it will contribute to the overall >> > robustness and maintainability. >> > Half-baked design will continue to itch. >> >> Half-baked upgrade strategies also. > > Unforunately CM currently does not have the resources of its ambitions > concerning the upgrade strategies! That implies that some expectations > must be dropped: IMHO, code improvement is, at this time, more important > than upgrade easiness. We disagree here obviously, but see also Phil's answer on this. - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
