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 >
