Return-Path: X-Original-To: apmail-hc-dev-archive@www.apache.org Delivered-To: apmail-hc-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id B4A5A9A9E for ; Tue, 24 Apr 2012 20:25:37 +0000 (UTC) Received: (qmail 12348 invoked by uid 500); 24 Apr 2012 20:25:37 -0000 Delivered-To: apmail-hc-dev-archive@hc.apache.org Received: (qmail 12312 invoked by uid 500); 24 Apr 2012 20:25:37 -0000 Mailing-List: contact dev-help@hc.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "HttpComponents Project" Delivered-To: mailing list dev@hc.apache.org Received: (qmail 12303 invoked by uid 99); 24 Apr 2012 20:25:37 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 Apr 2012 20:25:37 +0000 X-ASF-Spam-Status: No, hits=0.7 required=5.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [217.150.250.48] (HELO kalnich.nine.ch) (217.150.250.48) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 Apr 2012 20:25:27 +0000 Received: from [192.168.1.110] (77-57-197-206.dclient.hispeed.ch [77.57.197.206]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by kalnich.nine.ch (Postfix) with ESMTPSA id 8A319B81377 for ; Tue, 24 Apr 2012 22:25:05 +0200 (CEST) Message-ID: <1335299105.6374.66.camel@ubuntu> Subject: Re: [VOTE] HttpComponents Core 4.2 release based on RC1 From: Oleg Kalnichevski To: HttpComponents Project Date: Tue, 24 Apr 2012 22:25:05 +0200 In-Reply-To: References: <1335007260.9203.5.camel@ubuntu> <1335265998.6374.14.camel@ubuntu> <1335279808.6374.26.camel@ubuntu> <1335284322.6374.35.camel@ubuntu> <1335288501.6374.44.camel@ubuntu> <1335292414.6374.50.camel@ubuntu> <1335296906.6374.56.camel@ubuntu> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.2- Content-Transfer-Encoding: 7bit Mime-Version: 1.0 On Tue, 2012-04-24 at 21:10 +0100, sebb wrote: > On 24 April 2012 20:48, Oleg Kalnichevski wrote: > > On Tue, 2012-04-24 at 20:30 +0100, sebb wrote: > >> On 24 April 2012 19:33, Oleg Kalnichevski wrote: > >> > On Tue, 2012-04-24 at 19:03 +0100, sebb wrote: > >> >> On 24 April 2012 18:28, Oleg Kalnichevski wrote: > >> >> > On Tue, 2012-04-24 at 18:07 +0100, sebb wrote: > >> >> >> On 24 April 2012 17:18, Oleg Kalnichevski wrote: > >> >> >> > On Tue, 2012-04-24 at 16:59 +0100, sebb wrote: > >> >> >> >> On 24 April 2012 16:03, Oleg Kalnichevski wrote: > >> >> >> >> > On Tue, 2012-04-24 at 15:18 +0100, sebb wrote: > >> >> >> >> >> On 24 April 2012 12:13, Oleg Kalnichevski wrote: > >> >> >> >> >> > On Tue, 2012-04-24 at 02:48 +0100, sebb wrote: > >> >> >> >> >> >> On 23 April 2012 14:33, sebb wrote: > >> >> >> >> >> >> > On 21 April 2012 12:21, Oleg Kalnichevski wrote: > >> >> >> >> >> >> >> Please vote on releasing these packages as HttpComponents Core 4.2. The > >> >> >> >> >> >> >> vote is open for the at least 72 hours, and only votes from > >> >> >> >> >> >> >> HttpComponents PMC members are binding. The vote passes if at least > >> >> >> >> >> >> >> three binding +1 votes are cast and there are more +1 than -1 votes. > >> >> >> >> >> >> >> > >> >> >> >> >> >> >> Packages: > >> >> >> >> >> >> >> http://people.apache.org/~olegk/httpcore-4.2-RC1/ > >> >> >> >> >> >> >> > >> >> >> >> >> >> >> Release notes: > >> >> >> >> >> >> >> http://people.apache.org/~olegk/httpcore-4.2-RC1/RELEASE_NOTES.txt > >> >> >> >> >> >> >> > >> >> >> >> >> >> >> Maven artefacts: > >> >> >> >> >> >> >> https://repository.apache.org/content/repositories/orgapachehttpcomponents-078/org/apache/httpcomponents/ > >> >> >> >> >> >> >> > >> >> >> >> >> >> >> SVN tag: > >> >> >> >> >> >> >> https://svn.apache.org/repos/asf/httpcomponents/httpcore/tags/4.2-RC1/ > >> >> >> >> >> >> >> > >> >> >> >> >> >> >> -------------------------------------------------------------------------- > >> >> >> >> >> >> >> Vote: HttpComponents Core 4.2 release > >> >> >> >> >> >> >> [ ] +1 Release the packages as HttpComponents Core 4.2. > >> >> >> >> >> >> > >> >> >> >> >> >> Sorry, I'm changing my vote: > >> >> >> >> >> >> > >> >> >> >> >> >> >> [X] -1 I am against releasing the packages (must include a reason). > >> >> >> >> >> >> > >> >> >> >> >> >> I've just noticed that Clirr reports several compatibility issues against 4.1. > >> >> >> >> >> >> > >> >> >> >> >> >> I've not investigated in any detail, but it looks as though at least > >> >> >> >> >> >> some of these are binary compatibility issues, and they appear to be > >> >> >> >> >> >> in public APIs. > >> >> >> >> >> >> > >> >> >> >> >> >> It may be that these are not actually a problem, but I think they need > >> >> >> >> >> >> to be investigated further. > >> >> >> >> >> >> If the errors are harmless - or perhaps only affect source builds - it > >> >> >> >> >> >> would be helpful to update the site (and ideally release notes) > >> >> >> >> >> >> accordingly. > >> >> >> >> >> >> > >> >> >> >> >> >> [No need to cancel the vote just yet, in case I'm wrong.] > >> >> >> >> >> >> > >> >> >> >> >> >> BTW, we recently added test jars to the Commons Maven output. > >> >> >> >> >> >> This should make it easier to run old tests against new releases. > >> >> >> >> >> >> > >> >> >> >> >> > > >> >> >> >> >> > Sebastian > >> >> >> >> >> > > >> >> >> >> >> > The reported differences in public APIs reported by Clirr are due to two > >> >> >> >> >> > things (1) upgrade from Java 1.3 to Java 1.5 (2) removal of code > >> >> >> >> >> > deprecated between 4.0-beta1 and 4.0 (that is, before 4.0 GA, more than > >> >> >> >> >> > two years ago) > >> >> >> >> >> > > >> >> >> >> >> > We had a discussion about pros and cons of upgrading to Java 1.5 and if > >> >> >> >> >> > I remember it correctly you were in favor of that idea [1]. The changes > >> >> >> >> >> > have also been announced early enough (several releases in advance) [2]. > >> >> >> >> >> > They do make 4.1 and 4.2 not fully binary compatible but I seriously > >> >> >> >> >> > doubt there will be a single user affected by incompatibility. > >> >> >> >> >> > > >> >> >> >> >> > I hope you will change your mind. > >> >> >> >> >> > >> >> >> >> >> I've been looking further at the changes. > >> >> >> >> >> The changes to NIO are all removals of deprecated methods, so not a > >> >> >> >> >> problem (or at least, not our problem). > >> >> >> >> >> > >> >> >> >> >> The removed methods in HttpCore are also deprecated methods, so not a problem. > >> >> >> >> >> > >> >> >> >> > > >> >> >> >> > Not only were they deprecated, they are deprecated two release cycles > >> >> >> >> > back (before 4.0 official release). > >> >> >> >> > > >> >> >> >> >> Not sure why the value definitions of HTTP.DEFAULT_CONTENT_CHARSET and > >> >> >> >> >> DEFAULT_PROTOCOL_CHARSET were changed. > >> >> >> >> >> Given that they are now deprecated, I would have thought the values > >> >> >> >> >> could have been left untouched. > >> >> >> >> > > >> >> >> >> > I think the case changed (by mistake). I'll fix it right away. > >> >> >> >> > > >> >> >> >> >> However AFAICT that does not affect compatibility. > >> >> >> >> >> > >> >> >> >> >> [BTW, in future we ought to document in which release items are deprecated] > >> >> >> >> >> > >> >> >> >> >> That just leaves the changed method signatures, which are due to > >> >> >> >> >> adding generics to Iterator in o.a.h.message.Basic*Iterator and to > >> >> >> >> >> AbstractMessageParser. > >> >> >> >> >> In the case of the MessageParser subclasses, these were also changed > >> >> >> >> >> to use more specific subclasses: > >> >> >> >> >> HttpRequest and HttpResponse instead of their common super-interface HttpMessage > >> >> >> >> >> > >> >> >> >> >> It's not obvious to me if these methods are likely to be called by 3rd > >> >> >> >> >> party code or whether they are only likely to be used internally. > >> >> >> >> >> > >> >> >> >> > > >> >> >> >> > You see, in any sane use case scenarios, especially as far as iterators > >> >> >> >> > are concerned, the type returned from those methods would always be cast > >> >> >> >> > to the expected subtype. In almost all cases regardless of how those > >> >> >> >> > methods are being used the changes will have no effect at the runtime > >> >> >> >> > behavior. > >> >> >> >> > >> >> >> >> The problem is that the return type of a method is part of the signature. > >> >> >> >> Java won't find the method at runtime if the signature changes between > >> >> >> >> compilation and run-time. > >> >> >> >> > >> >> >> >> This generally does not affect source compatibility, but it does > >> >> >> >> affect binary compat. > >> >> >> >> > >> >> >> >> We had this exact problem in Commons IO > >> >> >> >> We wanted to change a method return from void to something else; > >> >> >> >> however testing against pre-existing binaries showed that this broke > >> >> >> >> binary compat. > >> >> >> >> > >> >> >> > > >> >> >> > All right. I'll revert those changes. > >> >> >> > >> >> >> We are already making the assumption breaking the API is OK for > >> >> >> long-deprecated methods, i.e. that user applications have migrated > >> >> >> away from the deprecated methods. > >> >> >> > >> >> >> So if the methods in question are not likely to be used by 3rd party > >> >> >> applications - are they effectively internal ? - we could consider > >> >> >> releasing with such breaks in compat, provided that such changes are > >> >> >> clearly documented. > >> >> >> > >> >> > > >> >> > It is almost as easy just to deprecate the affected classes. > >> >> > >> >> Which classes need to be deprecated? > >> >> > >> >> > What is done is done. > >> >> > >> >> Not sure I follow what you mean here. > >> >> > >> > > >> > I already reverted the changes that made 4.2 binary incompatible with > >> > 4.1 with exception of removal of deprecated code. > >> > > >> >> >> > I always thought the return type did not matter for binary method calls. Obviously I was wrong. > >> >> >> > >> >> >> I originally thought the same. It was one of the long-time Commons > >> >> >> devs who pointed out the problem. > >> >> >> > >> >> >> It's particularly strange that changing void to non-void matters, but it does. > >> >> >> [Perhaps it was easier than making an exception for that particular case] > >> >> >> > >> >> > > >> >> > I am not sure I understand the point of including the return type in the > >> >> > method signature since there will always be ambiguity in case there is > >> >> > no assignment of the method return to a variable. > >> >> > >> >> Not possible, see below. > >> >> > >> >> > int i = obj.dostuff(); // returns int > >> >> > double d = obj.dostuff(); // returns double > >> >> > >> >> That's not possible; obj.dostuff() can only have a single return type (or void). > >> >> > >> >> Compiler complains about a "duplicate method" otherwise. > >> >> > >> > > >> > Precisely. So, what is the point of including the return type in the > >> > method signature? > >> > >> [I'm guessing here] > >> > >> The compiler checks that the caller of an API method is using the > >> correct return type. > >> It's obviously important that the same type is provided at run-time. > >> > >> If the return type were ignored by the loader when resolving method > >> references, the JVM would have to do additional run-time checks on the > >> return types. > >> This allows the error to be detected earlier (and it's cheaper). > >> > > > > That sounds plausible. Performance does seem to be a factor here. > > > >> >> > obj.dostuff(); // trouble > >> >> > > >> >> > That begs the question: what is the point of making things more complex > >> >> > than necessary. > >> >> > >> >> I don't think they did make things more complex. > >> >> > >> > > >> > See above. > >> > > >> >> > Anyway, as soon as you are happy with the content of the release notes, > >> >> > I'll cut another RC and call a vote. > >> >> > >> >> I've made some fixes to the parent pom, because unfortunately the > >> >> buildNumber plugin with javasvn implementation does not work with SVN > >> >> 1.7+ clients. > >> >> > >> > > >> > Yes, I am still on version 1.6.x > >> > > >> >> I assume you have not yet upgraded, because the "Implementation-Build" > >> >> headers are OK in the Manifests, so that can be fixed later. > >> >> > >> > > >> > Shall I go ahead and cut a new RC? > >> > >> OK. > >> > >> The remaining Clirr errors are for deprecated methods only, so I no > >> longer have objections on that score. > >> > >> I see you have created new versions of the AbstractMessageParser > >> sub-classes, so the old ones can be kept and deprecated. > >> Solves the compat. problem without losing the type improvements. Excellent. > >> > >> It would be great if there were a similar solution for the Iterator > >> classes that were reverted, but unfortunately that does not look > >> possible, and the classes might well have been used/extended by 3rd > >> parties. At least there are type-safe nextEntry() methods available > >> for use. > >> > > > > I think similar approach could easily be used for iterator classes. > > I had a look, and the problem is that at least some of the interfaces > are used elsewhere as return types. > I don't think it's possible to provide a parallel set of interfaces > and still maintain binary compat. elsewhere. > I can be wrong again, but as far as interfaces are concerned we would not need to replace them as their generic types get erased anyway. We would only have to avoid using old implementations that have Objects as the return type embedded in their method signatures. In fact as long as the old iterator classes were used through the Itertor interface there would be no binary compatibility issues at all. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org For additional commands, e-mail: dev-help@hc.apache.org