commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sebb (JIRA)" <>
Subject [jira] [Commented] (COLLECTIONS-527) Please create a version commons-collections 3.x for jdk 8 compatibility
Date Fri, 16 May 2014 23:08:19 GMT


Sebb commented on COLLECTIONS-527:

If any dependency actually uses the current remove() method, removing it will break the application.
As this is a public method we cannot be sure that it is not being used anywhere, so dropping
the method is not an option if we are to retain binary compatibility.
It's not possible to have two different versions of the same class in the same class-loader,
which is why API breaks need a new package name (and new Maven coordinates).

> Please create a version commons-collections 3.x for jdk 8 compatibility
> -----------------------------------------------------------------------
>                 Key: COLLECTIONS-527
>                 URL:
>             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}
>[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

View raw message