I also have these mixed feelings about this decision. I would prefer to
go for the second solution (copy the needed code) but if we are talking
about of copying dozens of classes then it makes more sense to add the
dependency.
PS: just for curiosity, does Guava have something similar to offer?
On 09/11/2015 11:18, Sebastien wrote:
Hi Martijn,
About the deserialization issue, I suppose you make reference to this:
http://news.softpedia.com/news/the-vulnerability-that-will-rock-the-entire-java-world-495840.shtml
I agree on your entire point of view: adding a dependency is bad, having
our own copied-classes is also bad. So is the dilemma, and I have no better
idea than Emond...
Just a concern: having our own copy has side effects in addition to the
fact we should maintain it. For instance with another case, the JSONObject
has been taken from json.org. It is boring me because I cannot use/transmit
it to the business tier, whereas having used org.json.JSONObject would have
been simpler to manage...
So I am mixed between having (and maintaining) less code and having a
dependency. But actually, apache commons are very convenient, widely used
and almost a standard; so I would prefer this option short before "taking
only what we need" one....
My 2 cents :)
Sebastien.
On Mon, Nov 9, 2015 at 10:34 AM, Martijn Dashorst <
[email protected]> wrote:
One of the problems we ran into while fixing 6021 was the ability to
use a Linked[Hash]Map. The default JDK version doesn't have any public
or protected API to give us the previous and next entries. We need
those to retrieve the next element when removing a child from a markup
container.
Unfortunately the JDK collections don't have any extensibility that
would allow us to graft those missing methods upon the existing
collections.
Commons Collections provides a LinkedMap class that does give us those
methods. Unfortunately this forces us to add a core dependency, or we
should copy the specific code into our project.
Adding a dependency is bad because it adds more stuff to track--not
just for us, but for our users as well--, provides additional
headaches (as you may have noticed, there's an deserialization issue
with commons-collections).
Moving the code from com-col to Wicket is also bad, as we take on the
maintenance burden, the code in question takes about 30-ish classes to
copy, and we duplicate code that is available from elsewhere
(duplication is bad mkay)
Emond's suggestion is to move the code, strip it of all that we don't
need and maintain that ourselves. I'd like to add that we should make
that code package private or name it such that it doesn't conflict
with com-col on a class name base.
But before we go on that path, we'd like to hear if folks have better
ideas?
Martijn
