[
https://issues.apache.org/jira/browse/COLLECTIONS-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14000368#comment-14000368
]
Ignat Alexeyenko commented on COLLECTIONS-527:
----------------------------------------------
In Maven world one probably gets something like:
{code}
Project
`-- dependency A
`-- commons-collection-3.2.1
`--dependency B
`--commons-collections-3.3.0
{code}
Where Maven resolves version of 3.3.0 and if *dependency A* uses some of
commons-collection's remove(Object, Object) values they must receive runtime
exceptions. This situation can be solved either by:
* using patched version of dependency A, that is compatible with
commons-collections 3.3.0
* loading dependencies in different class loaders
Consider the other case, there's only commons-collection 3.2.1 in project:
{code}
Project
`-- dependency A
`-- commons-collection-3.2.1
`--dependency B
`--commons-collections-3.2.1
{code}
The same *dependency A* still uses some of commons-collection's remove(Object,
Object) and we run Java 8. Again, they must receive same runtime exceptions -
even without single change in commons-collection 3.2.1.
*Adopting Java 8*
So projects are already doomed if they need to run Java 8 with
commons-collections 3.2.1. Transition to commons-collections4 might not be an
option, as there are too much code changes required in projects. Even more code
changes in other libraries (like *dependency A*)!
*More options*
Finally, developers aren't forced to upgrade to commons-collections 3.3.
Developers may be happy with older Java or they're fortunate to avoid
exceptions in remove(Object, Object) invocations on MultiMaps.
In any case, having a new compatibility release leaves more options for other
projects and developers to react, then having no compatibility release at all.
As mentioned earlier, this must have a coherent impact on other libraries (like
*dependency A*) - much better then just a custom project fork.
Thanks [~joehni] for your time.
> 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)
