I would also prefer to add dependency On Mon, Nov 9, 2015 at 4:18 PM, Sebastien <[email protected]> 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 > > > -- WBR Maxim aka solomax
