Your memory on limitations of the JLS vs JVM is correct Andrew. We still maintained wire compatibility so if someone has a specific issue with being able to recompile their client code for 2.4.0 they could always keep using 2.3.z clients to work with an updated server.
The release note on HBASE-25242 could do with a small adjustment to note that folks should recompile any application code that called the impacted method. I'll go do that now; I don't think it's critical for the RC. On Fri, Dec 4, 2020 at 11:15 AM Andrew Purtell <andrew.purt...@gmail.com> wrote: > > This is a borderline change so I left it in but expected this discussion. > Changing the return type of a method causes a binary incompatibility but not > a source incompatibility. Making a compatibility method is difficult in this > case because although the return type is considered part of the method > signature the Java compiler only looks at parameters when deciding if a > method duplicates another. So we can’t have the old method returning void and > the new one returning Result in the same interface. The new method returning > Result must also define additional parameters or accept a parameter of a > different type. (At least, this is what I recall from earlier work, would be > great if I’m wrong.) RowMutations is I would expect relatively uncommonly > used. Finally, as an API improvement project this is important work. So I > come down on the side of considering this an allowable change. That said, if > the consensus is that it is not, it should be straightforward to change this > method’s return type back to void and spin a new RC. > > > > On Dec 3, 2020, at 11:04 PM, 张铎 <palomino...@gmail.com> wrote: > > > > I think for a minor release, we do not expect a drop-in replacement, so > > changing the return value from void is fine? You do not need to change your > > code, just need to recompile it. > > > > Thanks. > > > > Stack <st...@duboce.net> 于2020年12月4日周五 下午1:58写道： > > > >> +0 for now until my question below gets an answer. > >> > >> Signature is good, hash is good. CHANGES and RELEASENOTES look good too. > >> Built from the src tgz. Artifact looks right when I untar it. > >> Started it in standalone mode. > >> UI looks good w/ nice 2.4.0 version on it (noticed new 'procedure time > >> statistics'... nice). > >> Loaded 10M rows w/ pe. Read them back out again. > >> I've been running unit tests over the last few days. There are flakies that > >> I've been trying > >> to fix as I see them (HBASE-25353 is latest). I'll keep at it but don't see > >> the last few as > >> cause to hold up the RC (NIghtlies on branch-2 have been pretty good of > >> late, see > >> > >> https://ci-hadoop.apache.org/view/HBase/job/HBase/job/HBase%20Nightly/job/branch-2/ > >> ). > >> > >> Here is my question (Tosihrio?): > >> > >> Looking at API changes, this change looks problematic for a minor release: > >> > >> hbase-shaded-client-byo-hadoop-2.3.0.jar, Table.class > >> package org.apache.hadoop.hbase.client > >> [−] Table.mutateRow ( RowMutations rm ) *:* void 1 > >> > >> org/apache/hadoop/hbase/client/Table.mutateRow:(Lorg/apache/hadoop/hbase/client/RowMutations;)V > >> > >> ChangeEffect > >> 1 Return value type has been changed from *void* to *Result*. This method > >> has been removed because the return type is part of the method signature. A > >> client program may be interrupted by *NoSuchMethodError* exception. > >> > >> Done here.... > >> > >> commit 3775464981b473599c6d1bb24a7eea3badf0ed03 > >> Author: Toshihiro Suzuki <brfrn...@gmail.com> > >> Date: Fri Nov 27 03:53:19 2020 +0900 > >> > >> HBASE-25242 Add Increment/Append support to RowMutations (#2711) > >> > >> Signed-off-by: Duo Zhang <zhang...@apache.org> > >> Signed-off-by: Andrew Purtell <apurt...@apache.org> > >> > >> The issue is called out as an incompatible change. I don't see discussion > >> on why this is ok in the PRs. Was I looking in right place? > >> > >> S > >> > >>> On Thu, Dec 3, 2020 at 4:05 PM Andrew Purtell <apurt...@apache.org> wrote: > >>> > >>> Please vote on this Apache hbase release candidate, hbase-2.4.0RC1 > >>> > >>> The VOTE will remain open for at least 72 hours. > >>> > >>> [ ] +1 Release this package as Apache hbase 2.4.0 > >>> [ ] -1 Do not release this package because ... > >>> > >>> The tag to be voted on is 2.4.0RC1: > >>> > >>> https://github.com/apache/hbase/tree/2.4.0RC1 > >>> > >>> The release files, including signatures, digests, as well as CHANGES.md > >>> and RELEASENOTES.md included in this RC can be found at: > >>> > >>> https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/ > >>> > >>> Customarily Maven artifacts would be available in a staging repository. > >>> Unfortunately I was forced to terminate the Maven deploy step after > >>> the upload ran for more than four hours and my build equipment > >>> needed to be relocated, with loss of network connectivity. This RC has > >>> been delayed long enough. A temporary Maven repository is not a > >>> requirement for a vote. I will retry Maven deploy tomorrow. I can > >>> promise the artifacts for this RC will be staged in Apache Nexus and > >>> ready for release well ahead of the earliest possible time this vote > >>> can complete. > >>> > >>> Artifacts were signed with the apurt...@apache.org key which can be > >> found > >>> in: > >>> > >>> https://dist.apache.org/repos/dist/release/hbase/KEYS > >>> > >>> The API compatibility report for this RC can be found at: > >>> > >>> > >>> > >>> > >> https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/api_compare_2.4.0RC1_to_2.3.0.html > >>> > >>> The changes are mostly added methods, which conform to the compatibility > >>> guidelines for a new minor release. There is one change to the public > >>> Region interface that alters the return type of a method. This is > >>> equivalent to a removal then addition and can be a binary compatibility > >>> problem. However to your RM's eye the change looks intentional and is > >>> part of an API improvement project, and a compatibility method is not > >>> possible here because Java doesn't consider return type when deciding if > >>> one method signature duplicates another. > >>> > >>> To learn more about Apache HBase, please see > >>> > >>> http://hbase.apache.org/ > >>> > >>> Thanks, > >>> Your HBase Release Manager > >>> > >>
