[jira] Updated: (MATH-247) Add MathUtils method to check equality given some error bounds
[ https://issues.apache.org/jira/browse/MATH-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin McCann updated MATH-247: - Attachment: compareTo.patch Adding a compareTo function to go along with the equals function submitted earlier. Add MathUtils method to check equality given some error bounds -- Key: MATH-247 URL: https://issues.apache.org/jira/browse/MATH-247 Project: Commons Math Issue Type: New Feature Reporter: Benjamin McCann Attachments: compareTo.patch, MathUtils.java.patch, MathUtilsTest.java.patch It would be nice to have a utility method that tests for equality given some range of allowed error to account for floating point error. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (MATH-247) Add MathUtils method to check equality given some error bounds
[ https://issues.apache.org/jira/browse/MATH-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin McCann reopened MATH-247: -- I added a path for a compareTo to go along with the equals method added earlier. Add MathUtils method to check equality given some error bounds -- Key: MATH-247 URL: https://issues.apache.org/jira/browse/MATH-247 Project: Commons Math Issue Type: New Feature Reporter: Benjamin McCann Attachments: compareTo.patch, MathUtils.java.patch, MathUtilsTest.java.patch It would be nice to have a utility method that tests for equality given some range of allowed error to account for floating point error. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-207) Implementation of GeneticAlgorithm.nextGeneration() is wrong
[ https://issues.apache.org/jira/browse/MATH-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin McCann updated MATH-207: - Attachment: geneticalgorithm.patch Patch to improve the API. Implementation of GeneticAlgorithm.nextGeneration() is wrong Key: MATH-207 URL: https://issues.apache.org/jira/browse/MATH-207 Project: Commons Math Issue Type: Bug Affects Versions: 2.0 Reporter: David Stefka Assignee: Phil Steitz Fix For: 2.0 Attachments: geneticalgorithm.patch, genetics_impl.zip, patch Original Estimate: 0.17h Remaining Estimate: 0.17h The implementation of GeneticAlgorithm.nextGeneration() is wrong, since the only way how a Chromosome can get into the new generation is by mutation. Enclosed, I am sending a patch for this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-480) StringEscapeUtils.escapeHtml incorrectly converts unicode characters above U+00FFFF into 2 characters
[ https://issues.apache.org/jira/browse/LANG-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-480: --- Description: Characters that are represented as a 2 characters internaly by java are incorrectly converted by the function. The following test displays the problem quite nicely: import org.apache.commons.lang.*; public class J2 { public static void main(String[] args) throws Exception { // this is the utf8 representation of the character: // COUNTING ROD UNIT DIGIT THREE // in unicode // codepoint: U+1D362 byte[] data = new byte[] { (byte)0xF0, (byte)0x9D, (byte)0x8D, (byte)0xA2 }; //output is: amp;#55348;amp;#57186; // should be: amp;#119650; System.out.println(' + StringEscapeUtils.escapeHtml(new String(data, UTF8)) + '); } } Should be very quick to fix, feel free to drop me an email if you want a patch. was: Characters that are represented as a 2 characters internaly by java are incorrectly converted by the function. The following test displays the problem quite nicely: import org.apache.commons.lang.*; public class J2 { public static void main(String[] args) throws Exception { // this is the utf8 representation of the character: // COUNTING ROD UNIT DIGIT THREE // in unicode // codepoint: U+1D362 byte[] data = new byte[] { (byte)0xF0, (byte)0x9D, (byte)0x8D, (byte)0xA2 }; //output is: #55348;#57186; // should be: #119650; System.out.println(' + StringEscapeUtils.escapeHtml(new String(data, UTF8)) + '); } } Should be very quick to fix, feel free to drop me an email if you want a patch. StringEscapeUtils.escapeHtml incorrectly converts unicode characters above U+00 into 2 characters - Key: LANG-480 URL: https://issues.apache.org/jira/browse/LANG-480 Project: Commons Lang Issue Type: Bug Affects Versions: 2.4 Environment: doesn't matter Reporter: Alexander Kjäll Priority: Minor Fix For: 3.0 Attachments: lang-480.patch Characters that are represented as a 2 characters internaly by java are incorrectly converted by the function. The following test displays the problem quite nicely: import org.apache.commons.lang.*; public class J2 { public static void main(String[] args) throws Exception { // this is the utf8 representation of the character: // COUNTING ROD UNIT DIGIT THREE // in unicode // codepoint: U+1D362 byte[] data = new byte[] { (byte)0xF0, (byte)0x9D, (byte)0x8D, (byte)0xA2 }; //output is: amp;#55348;amp;#57186; // should be: amp;#119650; System.out.println(' + StringEscapeUtils.escapeHtml(new String(data, UTF8)) + '); } } Should be very quick to fix, feel free to drop me an email if you want a patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (LANG-480) StringEscapeUtils.escapeHtml incorrectly converts unicode characters above U+00FFFF into 2 characters
[ https://issues.apache.org/jira/browse/LANG-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed LANG-480. -- Resolution: Fixed svn ci -m Applying Alexander Kjall's patch from LANG-480; along with a unit test made from his example. Fixes unicode conversion above U+00 being done into 2 characters Sendingsrc/java/org/apache/commons/lang/Entities.java Sendingsrc/test/org/apache/commons/lang/StringEscapeUtilsTest.java Transmitting file data .. Committed revision 749095. StringEscapeUtils.escapeHtml incorrectly converts unicode characters above U+00 into 2 characters - Key: LANG-480 URL: https://issues.apache.org/jira/browse/LANG-480 Project: Commons Lang Issue Type: Bug Affects Versions: 2.4 Environment: doesn't matter Reporter: Alexander Kjäll Priority: Minor Fix For: 3.0 Attachments: lang-480.patch Characters that are represented as a 2 characters internaly by java are incorrectly converted by the function. The following test displays the problem quite nicely: import org.apache.commons.lang.*; public class J2 { public static void main(String[] args) throws Exception { // this is the utf8 representation of the character: // COUNTING ROD UNIT DIGIT THREE // in unicode // codepoint: U+1D362 byte[] data = new byte[] { (byte)0xF0, (byte)0x9D, (byte)0x8D, (byte)0xA2 }; //output is: amp;#55348;amp;#57186; // should be: amp;#119650; System.out.println(' + StringEscapeUtils.escapeHtml(new String(data, UTF8)) + '); } } Should be very quick to fix, feel free to drop me an email if you want a patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (LANG-11) Depend on JDK 1.5+
[ https://issues.apache.org/jira/browse/LANG-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed LANG-11. - Resolution: Fixed Probably 1.5. 1.6 wasn't that special. Depend on JDK 1.5+ -- Key: LANG-11 URL: https://issues.apache.org/jira/browse/LANG-11 Project: Commons Lang Issue Type: Bug Affects Versions: 3.0 Environment: Operating System: other Platform: Other Reporter: Henri Yandell Fix For: LangTwo 1.0 Compile under Java 5. Or go straight to 6? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-478) StopWatch does not resist to system time changes
[ https://issues.apache.org/jira/browse/LANG-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-478: --- Attachment: LANG-478.patch Attaching patch to move to nanoTime. StopWatch does not resist to system time changes Key: LANG-478 URL: https://issues.apache.org/jira/browse/LANG-478 Project: Commons Lang Issue Type: Bug Affects Versions: 2.3 Environment: all operating systems. Reporter: Regis Desgroppes Fix For: 3.0 Attachments: LANG-478.patch org.apache.commons.lang.time.StopWatch seems to be relying on wall clock, i.e. by calling java.lang.System.currentTimeMillis() to sample current time. When a system time change occurs (user action, NTP synchronization...) between 2 calls to StopWatch.getTime(), the difference between the 2 samples is wrong: the measured duration may noticeably differ from the real one. Moreover, should the system time change consist in a backward adjustment, the difference could be negative. In order to make StopWatch resistant to system time changes, would it be possible to use the process time, i.e. by making implementation calling java.lang.System.nanoTime() -multiplied by appropriate factor, of course. Thanks a lot, Regis. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (LANG-478) StopWatch does not resist to system time changes
[ https://issues.apache.org/jira/browse/LANG-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed LANG-478. -- Resolution: Fixed svn ci -m Applying my patch from LANG-478 - moving StopWatch to using nanoTime under the hood. Sendingsrc/java/org/apache/commons/lang/time/StopWatch.java Transmitting file data . Committed revision 749114. StopWatch does not resist to system time changes Key: LANG-478 URL: https://issues.apache.org/jira/browse/LANG-478 Project: Commons Lang Issue Type: Bug Affects Versions: 2.3 Environment: all operating systems. Reporter: Regis Desgroppes Fix For: 3.0 Attachments: LANG-478.patch org.apache.commons.lang.time.StopWatch seems to be relying on wall clock, i.e. by calling java.lang.System.currentTimeMillis() to sample current time. When a system time change occurs (user action, NTP synchronization...) between 2 calls to StopWatch.getTime(), the difference between the 2 samples is wrong: the measured duration may noticeably differ from the real one. Moreover, should the system time change consist in a backward adjustment, the difference could be negative. In order to make StopWatch resistant to system time changes, would it be possible to use the process time, i.e. by making implementation calling java.lang.System.nanoTime() -multiplied by appropriate factor, of course. Thanks a lot, Regis. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (LANG-484) Create changes-report xml file from history
Create changes-report xml file from history --- Key: LANG-484 URL: https://issues.apache.org/jira/browse/LANG-484 Project: Commons Lang Issue Type: Task Reporter: Henri Yandell Fix For: 3.0 It'll take a while, but we need to start a Maven changes report. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-332) EqualsBuilder to alternatively use method properties
[ https://issues.apache.org/jira/browse/LANG-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12677850#action_12677850 ] Henri Yandell commented on LANG-332: +1, I'd like this too. EqualsBuilder to alternatively use method properties Key: LANG-332 URL: https://issues.apache.org/jira/browse/LANG-332 Project: Commons Lang Issue Type: Improvement Affects Versions: 2.3 Reporter: Paul Benedict Fix For: 3.0 While it is very nice reflection can be used to build a nice equals method, the strategy to focus on private properties is non-negotiable. This strategy is incompatible with CGLIB proxies which rely on method invocations to delegate to the properties of the inner target. I would prefer a switch to dynamically invoke public get* methods over direct property access. PS: Same thoughts on ReflectionToStringBuilder and HashCodeBuilder -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-417) ClassUtils: method for turning FQN into resource path
[ https://issues.apache.org/jira/browse/LANG-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12677851#action_12677851 ] Henri Yandell commented on LANG-417: PackageUtils sounds good. Code something Paul :) ClassUtils: method for turning FQN into resource path - Key: LANG-417 URL: https://issues.apache.org/jira/browse/LANG-417 Project: Commons Lang Issue Type: New Feature Reporter: Paul Benedict Fix For: 3.0 I commonly need a FQ path to a resource within the same location as a class file. I recommend the addition of this method: public String getPackageResourcePath(Class clazz, String resourceName) StringBuffer buf = new StringBuffer(); buf.append(ClassUtils.getPackageName(getClass()).replace('.', '/')); buf.append(/); buf.append(resourceName); return buf.toString(); } -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MATH-247) Add MathUtils method to check equality given some error bounds
[ https://issues.apache.org/jira/browse/MATH-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-247. Resolution: Fixed Assignee: Luc Maisonobe applied patch with minor changes to obey javadoc html fixed in subversion repository as of r749139 thanks for the patch Add MathUtils method to check equality given some error bounds -- Key: MATH-247 URL: https://issues.apache.org/jira/browse/MATH-247 Project: Commons Math Issue Type: New Feature Reporter: Benjamin McCann Assignee: Luc Maisonobe Attachments: compareTo.patch, MathUtils.java.patch, MathUtilsTest.java.patch It would be nice to have a utility method that tests for equality given some range of allowed error to account for floating point error. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (NET-258) Implement A Keepalive Mechanism
Implement A Keepalive Mechanism --- Key: NET-258 URL: https://issues.apache.org/jira/browse/NET-258 Project: Commons Net Issue Type: Improvement Affects Versions: 2.0 Reporter: Rory Winston Assignee: Rory Winston For routers/firewalls that terminate idle connections, a separate heartbeat mechanism may need to be implemented to keep the control connection active. Some potential issues: * Synchronization between a heartbeat write and a __getReply() on an active control connection command; * Should use the NOOP command as a heartbeat signal; * Make the timeout configurable; * Default SocketImpl::setKeepAlive() wont do here. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (LANG-424) Improve Javadoc for StringUtils class
[ https://issues.apache.org/jira/browse/LANG-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed LANG-424. -- Resolution: Fixed Javadoc added. Not sure why it behaves that way, but probably not worth trying to change now. svn ci -m Adding javadoc per LANG-424 to point out what happens in substringLast/substringBefore methods when substring is not found src Sendingsrc/java/org/apache/commons/lang/StringUtils.java Transmitting file data . Committed revision 749151. Improve Javadoc for StringUtils class - Key: LANG-424 URL: https://issues.apache.org/jira/browse/LANG-424 Project: Commons Lang Issue Type: Improvement Affects Versions: 2.4 Reporter: Denise Fernandez Fix For: 3.0 In the StringUtils class it would be helpful if in the following methods, the Javadoc is improved: substringAfter substringAfterLast I think there should be better documentation in the case where the separator string is not found in the search string: It should be explicity noted that in this case an empty string will be returned. In the following methods: substringBefore substringBeforeLast It should be documented that if the separator is not found in the search string, the search string is returned. I realise there are examples for both these cases, but I think that they should be separately and explicity documented as special cases. I had expected that substringAfterLast would return the original string if the separator was not found in it and this caused me some trouble. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-290) EnumUtils for JDK 5.0
[ https://issues.apache.org/jira/browse/LANG-290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-290: --- Fix Version/s: (was: LangTwo 1.0) 3.0 EnumUtils for JDK 5.0 - Key: LANG-290 URL: https://issues.apache.org/jira/browse/LANG-290 Project: Commons Lang Issue Type: Improvement Affects Versions: 2.2 Reporter: Henri Yandell Fix For: 3.0 Below is an EnumUtils for JDK 1.5. It's also found in the enums.EnumUtils javadoc: import java.util.*; public class EnumUtils { public static Enum getEnum(Class enumClass, String token) { return Enum.valueOf(enumClass, token); } public static Map getEnumMap(Class enumClass) { HashMap map = new HashMap(); Iterator itr = EnumUtils.iterator(enumClass); while(itr.hasNext()) { Enum enm = (Enum) itr.next(); map.put( enm.name(), enm ); } return map; } public static List getEnumList(Class enumClass) { return new ArrayList( EnumSet.allOf(enumClass) ); } public static Iterator iterator(Class enumClass) { return EnumUtils.getEnumList(enumClass).iterator(); } } -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-482) Enhance StrSubstitutor to support nested ${var-${subvr}} expansion
[ https://issues.apache.org/jira/browse/LANG-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12677897#action_12677897 ] Rob Walker commented on LANG-482: - Cool - I just need to make time to fix the tests Oliver reported as not working. The code in the patch does work for basic use cases though, so feel free to try it. Will hopefully get around to looking at a better version sometime this week. Enhance StrSubstitutor to support nested ${var-${subvr}} expansion -- Key: LANG-482 URL: https://issues.apache.org/jira/browse/LANG-482 Project: Commons Lang Issue Type: Improvement Reporter: Rob Walker Priority: Minor Fix For: 3.0 Attachments: StrSubstitutor.java.nested.patch t would be really handy of StrSubstitutor could support nested variable interpolation: org.osgi.framework.system.packages=org.osgi.framework; version=1.4.0, \ org.osgi.service.packageadmin; version=1.2.0, \ org.osgi.service.startlevel; version=1.1.0, \ org.osgi.service.url; version=1.0.0, \ org.osgi.util.tracker; version=1.3.3 \ ${jre-${java.specification.version}} The process being to expand innermost variable references first and work outwards - this allows for very advance config, such as the above, which can dynamically detect the Java version and expand a JRE version specific property into the property being defined. Looking at the implementation, it seems it might be a fairly straightforward enhancement to: private int substitute(StrBuilder buf, int offset, int length, List priorVariables) The code already has the cyclic map in place. I already have code that achieves this within Apache Felix, so I will see if I can retro-fit a similar model to the above and if so submit a patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-332) EqualsBuilder to alternatively use method properties
[ https://issues.apache.org/jira/browse/LANG-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12677909#action_12677909 ] Joerg Schaible commented on LANG-332: - I am quite sure, that we break a lot of code if we change the behavior of this method. However, it would be really nice if we had both - ReflectionEqualsBuilder and JavaBeanEqualsBuilder. It simply depends on the situation where the functionality is used. EqualsBuilder to alternatively use method properties Key: LANG-332 URL: https://issues.apache.org/jira/browse/LANG-332 Project: Commons Lang Issue Type: Improvement Affects Versions: 2.3 Reporter: Paul Benedict Fix For: 3.0 While it is very nice reflection can be used to build a nice equals method, the strategy to focus on private properties is non-negotiable. This strategy is incompatible with CGLIB proxies which rely on method invocations to delegate to the properties of the inner target. I would prefer a switch to dynamically invoke public get* methods over direct property access. PS: Same thoughts on ReflectionToStringBuilder and HashCodeBuilder -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.