[ 
https://issues.apache.org/jira/browse/COLLECTIONS-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14000526#comment-14000526
 ] 

Joerg Schaible commented on COLLECTIONS-527:
--------------------------------------------

And let's come back to the facts. cc-3 *runs* on Java 8, you simply cannot 
compile with it (or against its runtime). And since anything that uses 
MultiMap.remove must have been compiled with an earlier runtime too, binary 
runtime compatibility stays fine.

Only people are affected that try to compile with Java 8 against cc-3. However, 
since they will have to adjust their source code, they can do directly the 
proper way. Most of the stuff will simply compile by replacing the import 
statements with the new package of cc-4 (actually for minimal changes it is 
enough to upgrade the code using MultiMap and depend on both cc versions). And 
if the source has been upgraded, the dependencies that still use cc-3 are 
completely happy and the new code running with cc-4 is also. And we, too, since 
we did not introduce an incompatible version into the cc-3.x namespace.

I know very well that that some Linux distros try to use that patch (actually I 
am using Gentoo for more than a decade), because they tend to build anything on 
their own, but if they insist on creating a version hell with their distro, 
they may do so - unless they do not blame us later on for incompatibilities.

> Please create a version commons-collections 3.x for jdk 8 compatibility
> -----------------------------------------------------------------------
>
>                 Key: COLLECTIONS-527
>                 URL: https://issues.apache.org/jira/browse/COLLECTIONS-527
>             Project: Commons Collections
>          Issue Type: Bug
>            Reporter: Ignat Alexeyenko
>            Priority: Blocker
>              Labels: java8, jdk8
>         Attachments: COLLECTIONS_3_2_BRANCH_COLLECTIONS_527.patch
>
>
> Could you make a 3.x or 3.2.x release compatible with JDK8 ?
> {code}
> org.apache.commons.collections.MultiMap {
>    public Object remove(Object key, Object item);
> }
> {code}
> is not compatible with JDK's 8 Map
> {code}
> java.util.Map {
>    boolean remove(Object key, Object value);
> }
> {code}
> This causes bugs in projects, who run jdk8 and even compilation failures - 
> for these, who implement common's MultiMap.
> *Compilation Error*
> If anyone implement MultiMap in their code, compilation fails with the error:
> {code}
> MyMultiHashMap.java:[11,7] error: remove(Object,Object) in MultiHashMap 
> cannot implement remove(Object,Object) in Map
> [ERROR] return type Object is not compatible with boolean
> {code}
> *Reasoning*
> JDK 8 is here and being adopted. collection-commons are not yet compatible 
> with Java 8. For many big project switch to commons-collections 4.x is not an 
> option - some transitional release version needs to be required.
> Alternative would be for companies to fork commons-collections and create 
> their internal artifact. Why do it if the official compatibility version can 
> be created?
> Thanks!



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to