I noticed that UtilMisc.toSet method has been refactored by replacing Javolution's FastSet with Java's HashSet.
But there's at least one thing worthy noted: FastSet keeps insertion order, HashSet not. So I think it's better to use LinkedHashSet instead of HashSet. One issue I know that was introduced by refactoring and caused by "insertion order" explained above is that GenericDAO.selectCountByCondition() will return unpredictable result if you : 1. set distinct option 2. call eli = delegator.find(entityName, whereEntityCondition, havingEntityCondition, fieldsToSelect, orderBy, findOptions); 3. eli.getPartialList(start, number) 4. int resultSize = eli.getResultsSizeAfterPartialList(); // it will then call GenericDAO.selectCountByCondition() which will generate counting sql like "COUNT(DISTINCT " + firstSelectField + ")" to get the result size. Note that the type of "fieldsToSelect" parameter of delegator.find method is "Set". When use FastSet, the firstSelectField mentioned above is exactly same as the first one defined by "fieldsToSelect". But for HashSet, there's NO FIRST one since it has no order. -- View this message in context: http://ofbiz.135035.n4.nabble.com/Removing-Javolution-tp4640229p4644284.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
