[JavaHL] Reported incompatibility
Hi All,
I came across a bug in one of the Atlassian tools that suggests that there
was an API compatibility break in the JavaHL between versions 1.6 and 1.7.
I am not sure when/if I get time to look more into it, therefore I am
sharing with the group meanwhile. The following comment is from the issue:
https://jira.atlassian.com/browse/FE-4679
Conor MacNeill
[Atlassian]https://jira.atlassian.com/secure/ViewProfile.jspa?name=cmacneill
added
a comment - 04/Jun/13 8:26 PM
This is caused by an incompatible class change made to the ProlistCallback
interface by the Subversion project. In the Subversion 1.6 version of the
call back the interface is defined as:
public interface ProplistCallback
{
/**
* the method will be called for every line in a file.
* @param paththe path.
* @param properties the properties on the path.
*/
public void singlePath(String path, Map properties);
}
In Subversion 1.7, the org.apache.subversion package was introduced and the
interface definition changed to
public interface ProplistCallback
extends org.apache.subversion.javahl.callback.ProplistCallback
{
}
This change is not backward compatible since the actual callback definition
from the super interface in the new package is typed
public void singlePath(String path, MapString, byte[] properties);
Older versions (1.6 and older) of the native javahl library making the call
back do not pass a map containing byte[] values but a map containing
Strings. When FishEye iterates the map, there is an implicit cast to
(byte[]) to re-introduce the type information from the map. Old native code
calls will generate a ClassCastException as they are passing Strings.
Regards,
Vladimir
Re: [JavaHL] Reported incompatibility
On 12.06.2013 14:42, Vladimir Berezniker wrote: Hi All, I came across a bug in one of the Atlassian tools that suggests that there was an API compatibility break in the JavaHL between versions 1.6 and 1.7. I am not sure when/if I get time to look more into it, therefore I am sharing with the group meanwhile. The following comment is from the issue: https://jira.atlassian.com/browse/FE-4679 I would argue that this counts as a bug fix, since property values are in general not strings. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: [JavaHL] Reported incompatibility
On 06/12/2013 07:07 AM, Branko Čibej wrote: On 12.06.2013 14:42, Vladimir Berezniker wrote: Hi All, I came across a bug in one of the Atlassian tools that suggests that there was an API compatibility break in the JavaHL between versions 1.6 and 1.7. I am not sure when/if I get time to look more into it, therefore I am sharing with the group meanwhile. The following comment is from the issue: https://jira.atlassian.com/browse/FE-4679 I would argue that this counts as a bug fix, since property values are in general not strings. Even if its a bug fix, the normal way to fix it would be to add a new ProplistCallback2 interface with the proper signature, but since we have org.apache.subversion.javahl.callback.ProplistCallback, there isn't a point to do that, but to keep the original signature. However, given this is released code and 1.7 has been out there a while and the new signature is correct and people may have compiled against that, it seems we're in a tough spot. Blair
Re: [JavaHL] Reported incompatibility
On 12.06.2013 19:18, Blair Zajac wrote: On 06/12/2013 07:07 AM, Branko Čibej wrote: On 12.06.2013 14:42, Vladimir Berezniker wrote: Hi All, I came across a bug in one of the Atlassian tools that suggests that there was an API compatibility break in the JavaHL between versions 1.6 and 1.7. I am not sure when/if I get time to look more into it, therefore I am sharing with the group meanwhile. The following comment is from the issue: https://jira.atlassian.com/browse/FE-4679 I would argue that this counts as a bug fix, since property values are in general not strings. Even if its a bug fix, the normal way to fix it would be to add a new ProplistCallback2 interface with the proper signature, but since we have org.apache.subversion.javahl.callback.ProplistCallback, there isn't a point to do that, but to keep the original signature. However, given this is released code and 1.7 has been out there a while and the new signature is correct and people may have compiled against that, it seems we're in a tough spot. We should be able to fix the org.tigris version back to the original signature, IMO. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
