[jira] [Created] (LANG-833) ToStringBuilder should use StringBuilder
Shevek created LANG-833: --- Summary: ToStringBuilder should use StringBuilder Key: LANG-833 URL: https://issues.apache.org/jira/browse/LANG-833 Project: Commons Lang Issue Type: Bug Components: lang.* Affects Versions: 3.1 Reporter: Shevek Rewriting as lang3 but still using StringBuffer (synchronized) looks like a missed opportunity. Please use StringBuilder. Suggest audit for uses of StringBuffer in lang3 overall. No cause for it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MODELER-30) Correct SVN repository links on the Modeler source repository page
Steve Westwood created MODELER-30: - Summary: Correct SVN repository links on the Modeler source repository page Key: MODELER-30 URL: https://issues.apache.org/jira/browse/MODELER-30 Project: Commons Modeler Issue Type: Task Reporter: Steve Westwood Priority: Minor If you visit, http://commons.apache.org/modeler/source-repository.html, note that the SVN repositories have not been updated to reflect the current (2012) structure. Hence http://svn.apache.org/viewvc/commons/proper/modeler/trunk should be http://svn.apache.org/repos/asf/commons/proper/modeler/trunk -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (LANG-829) FastDateParser could use Calendar.getDisplayNames for all text fields
[ https://issues.apache.org/jira/browse/LANG-829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb reopened LANG-829: --- Assignee: Sebb (was: Charles Honton) The change does not address the original issue. The Map returned from getDisplayNames() is specifically designed to be used for looking up the names in order to return their index values, so we should use that. FastDateParser could use Calendar.getDisplayNames for all text fields - Key: LANG-829 URL: https://issues.apache.org/jira/browse/LANG-829 Project: Commons Lang Issue Type: Improvement Components: lang.time.* Reporter: Sebb Assignee: Sebb Priority: Minor Fix For: 3.2 FastDateParser could use Calendar.getDisplayNames for all text fields. This returns a map of names to indexes, which would be easier to search - no need to sort the symbols, and no need for the KeyValue instances. Also, the nameValues entries are only used by the TextStrategy, so could be saved in the instance. Overall this should reduce memory and be quicker. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LANG-829) FastDateParser could use Calendar.getDisplayNames for all text fields
[ https://issues.apache.org/jira/browse/LANG-829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved LANG-829. --- Resolution: Fixed Assignee: (was: Sebb) URL: http://svn.apache.org/viewvc?rev=1390937view=rev Log: LANG-829 FastDateParser could use Calendar.getDisplayNames for all text fields Remove unnecessary KeyValue instances Modified: commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/time/FastDateParser.java FastDateParser could use Calendar.getDisplayNames for all text fields - Key: LANG-829 URL: https://issues.apache.org/jira/browse/LANG-829 Project: Commons Lang Issue Type: Improvement Components: lang.time.* Reporter: Sebb Priority: Minor Fix For: 3.2 FastDateParser could use Calendar.getDisplayNames for all text fields. This returns a map of names to indexes, which would be easier to search - no need to sort the symbols, and no need for the KeyValue instances. Also, the nameValues entries are only used by the TextStrategy, so could be saved in the instance. Overall this should reduce memory and be quicker. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-833) ToStringBuilder should use StringBuilder
[ https://issues.apache.org/jira/browse/LANG-833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13464619#comment-13464619 ] Sebb commented on LANG-833: --- bq. No cause for it. [i.e. StringBuffer] StringBuffer may still be needed for snchronisation purposes. Also if used in APIs, it may not be possible to change to StringBuilder without breaking compatibility. But if it is possible to replace Buffer with Builder it would be sensible to do so. ToStringBuilder should use StringBuilder Key: LANG-833 URL: https://issues.apache.org/jira/browse/LANG-833 Project: Commons Lang Issue Type: Bug Components: lang.* Affects Versions: 3.1 Reporter: Shevek Rewriting as lang3 but still using StringBuffer (synchronized) looks like a missed opportunity. Please use StringBuilder. Suggest audit for uses of StringBuffer in lang3 overall. No cause for it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-830) FastDateParser could use \Q \E to quote regexes
[ https://issues.apache.org/jira/browse/LANG-830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13464625#comment-13464625 ] Sebb commented on LANG-830: --- The Pattern.quote() method can be used for this. FastDateParser could use \Q \E to quote regexes --- Key: LANG-830 URL: https://issues.apache.org/jira/browse/LANG-830 Project: Commons Lang Issue Type: Improvement Components: lang.time.* Reporter: Sebb Priority: Minor The escapeRegex method relies on knowing exactly what all the meta-characters are when excaping text. This is potentially fragile. It would be a lot simpler to use the \Q \E quoting mechanism. There would need to be special handling for unquote==true. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-833) ToStringBuilder should use StringBuilder
[ https://issues.apache.org/jira/browse/LANG-833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13464649#comment-13464649 ] Sebb commented on LANG-833: --- I don't think it makes sense to use StrBuilder in the API, but for internal-only use that would be OK where sync is not needed. There may be some methods which would benefit from using AbstractStringBuilder so the user could provide either. But this needs to be done without breaking the API and thread-safety guarantees. ToStringBuilder should use StringBuilder Key: LANG-833 URL: https://issues.apache.org/jira/browse/LANG-833 Project: Commons Lang Issue Type: Bug Components: lang.* Affects Versions: 3.1 Reporter: Shevek Rewriting as lang3 but still using StringBuffer (synchronized) looks like a missed opportunity. Please use StringBuilder. Suggest audit for uses of StringBuffer in lang3 overall. No cause for it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LANG-830) FastDateParser could use \Q \E to quote regexes
[ https://issues.apache.org/jira/browse/LANG-830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved LANG-830. --- Resolution: Fixed Fix Version/s: 3.2 URL: http://svn.apache.org/viewvc?rev=1390954view=rev Log: LANG-830 FastDateParser could use \Q \E to quote regexes Modified: commons/proper/lang/trunk/src/changes/changes.xml commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/time/FastDateParser.java FastDateParser could use \Q \E to quote regexes --- Key: LANG-830 URL: https://issues.apache.org/jira/browse/LANG-830 Project: Commons Lang Issue Type: Improvement Components: lang.time.* Reporter: Sebb Priority: Minor Fix For: 3.2 The escapeRegex method relies on knowing exactly what all the meta-characters are when excaping text. This is potentially fragile. It would be a lot simpler to use the \Q \E quoting mechanism. There would need to be special handling for unquote==true. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LANG-470) Add containsAll methods to ArrayUtils
[ https://issues.apache.org/jira/browse/LANG-470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved LANG-470. --- Resolution: Won't Fix Fix Version/s: (was: 3.x) Using ArrayUtils.nullToEmpty() solves the NPE issue. Add containsAll methods to ArrayUtils - Key: LANG-470 URL: https://issues.apache.org/jira/browse/LANG-470 Project: Commons Lang Issue Type: New Feature Components: lang.* Affects Versions: 2.4 Reporter: Maarten Coene Attachments: ArrayUtilsContainsAll.pat The ArrayUtils class contains several contains methods. It could be usefull to add the corresponding containsAll(Object[] array1, Object[] array2) methods (and corresponding for primitive types). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LANG-777) jar contains velocity template of release notes
[ https://issues.apache.org/jira/browse/LANG-777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved LANG-777. --- Resolution: Fixed Log: LANG-777 jar contains velocity template of release notes Merge releases notes into standard location Removed: commons/proper/lang/trunk/src/main/resources/templates/release-notes.vm Modified: commons/proper/lang/trunk/RELEASE-NOTES.txt commons/proper/lang/trunk/src/changes/changes.xml commons/proper/lang/trunk/src/changes/release-notes.vm jar contains velocity template of release notes --- Key: LANG-777 URL: https://issues.apache.org/jira/browse/LANG-777 Project: Commons Lang Issue Type: Bug Components: General Affects Versions: 3.1 Reporter: Joerg Schaible Priority: Trivial Labels: build Fix For: 3.2 The released Java archive of 3.1 contains the velocity template release-notes.vm (claiming to be for 3.0.1 anyway) in the Java package templates. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-794) SystemUtils.IS_OS_WINDOWS_2008, VISTA are incorrect
[ https://issues.apache.org/jira/browse/LANG-794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated LANG-794: -- Fix Version/s: (was: 3.2) SystemUtils.IS_OS_WINDOWS_2008, VISTA are incorrect --- Key: LANG-794 URL: https://issues.apache.org/jira/browse/LANG-794 Project: Commons Lang Issue Type: Bug Components: lang.* Affects Versions: 3.1 Environment: Windows Server 2008 R2, Rackspace Cloud Instance Reporter: Tyler Hobbs On Windows Server 2008 R2 (a Rackspace Cloud Instance), the values of SystemUtils.IS_OS_WINDOWS_2008 and SystemUtils.IS_OS_WINDOWS_VISTA are incorrect: the former is false and the latter is true. I'm not sure how to fix the VISTA flag (as I don't have an instance to test against), but the cause of WINDOWS_2008 being set to false is that the match explicitly requires the version to be 6.1, where 6.0 can apparently also be the version number for 2008 R2. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-815) DurationFormatUtils.formatPeriod() mis-calculation
[ https://issues.apache.org/jira/browse/LANG-815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated LANG-815: -- Summary: DurationFormatUtils.formatPeriod() mis-calculation (was: DurationFormatUtils.formatPeriod() miss-calculation) DurationFormatUtils.formatPeriod() mis-calculation -- Key: LANG-815 URL: https://issues.apache.org/jira/browse/LANG-815 Project: Commons Lang Issue Type: Bug Components: lang.time.* Affects Versions: 3.1 Environment: JDK 1.7 Reporter: Naoya Sugioka Attachments: duration-format.diff Original Estimate: 1h Remaining Estimate: 1h Hello, I just encountered an issue with DurationFormatUtils.formatPeriod() and here I suggest the patch. The problem is found when calcurating a duration between June 30 to August 8. Duration must be 1 month and 9 days (June 30 + 1 month = July 30, July 30 + 9 Days = August 8) but current logic tells this duration is 1 month and 8 days. then I found out the logic to adjust days value if it was negative by initial estimate. it uses start date (June in above case) but must use prev month of end date (July in above case). then days value was wrong since getActualMaximum() will return a wrong number. thank you, -Naoya -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-811) Improve event detection by selecting g function slope
[ https://issues.apache.org/jira/browse/MATH-811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yannick TANGUY updated MATH-811: Attachment: JIRA-811_slope_selection_V2.patch Improve event detection by selecting g function slope - Key: MATH-811 URL: https://issues.apache.org/jira/browse/MATH-811 Project: Commons Math Issue Type: Improvement Affects Versions: 3.1 Reporter: Yannick TANGUY Attachments: JIRA-811_slope_selection.patch, JIRA-811_slope_selection_V2.patch, JIRA-811_slope_selection_with_spaces.patch We would like to select g function slope in CommonsMath event detection feature. This would improve event detection for the final user (the possibility to ignore some events, and less computation time) and also correct a bug found while using OREKIT (see https://www.orekit.org/forge/issues/104) in our applications. The modification consists in adding a method (getSlopeSelection() : int) in EventHandler, and modifying one conditionnal in the method evaluateStep (class EventState). We can provide modified code and unitary tests for this feature. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-811) Improve event detection by selecting g function slope
[ https://issues.apache.org/jira/browse/MATH-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13464686#comment-13464686 ] Yannick TANGUY commented on MATH-811: - Here is a new version of the patch (JIRA-811_slope_selection_V2.patch). I implemented an enum in EventHandler, modified the conditionnal tests in EventState.evaluateStep, in order to avoid XOR operators. I also added some comments. In the EventState class, the g0positive field was only used once in evaluateStep to know if an event has occured. I modified the test in order to use ga sign (ga is g(ta), at the beginning of the step) because when a step is larger that maxCheckInterval value, g0positive was not updated. The test class (EventStateTest) contains two new unitary tests, that cover the 8 different combinations of the criteria. Improve event detection by selecting g function slope - Key: MATH-811 URL: https://issues.apache.org/jira/browse/MATH-811 Project: Commons Math Issue Type: Improvement Affects Versions: 3.1 Reporter: Yannick TANGUY Attachments: JIRA-811_slope_selection.patch, JIRA-811_slope_selection_V2.patch, JIRA-811_slope_selection_with_spaces.patch We would like to select g function slope in CommonsMath event detection feature. This would improve event detection for the final user (the possibility to ignore some events, and less computation time) and also correct a bug found while using OREKIT (see https://www.orekit.org/forge/issues/104) in our applications. The modification consists in adding a method (getSlopeSelection() : int) in EventHandler, and modifying one conditionnal in the method evaluateStep (class EventState). We can provide modified code and unitary tests for this feature. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LANG-818) FastDateFormat's z pattern does not respect timezone of Calendar instances passed to format()
[
https://issues.apache.org/jira/browse/LANG-818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved LANG-818.
---
Resolution: Fixed
Fix Version/s: 3.2
Thanks for the code patch and test case.
Test case fails before code patch is applied and succeeds afterwards (as it
should!).
Applied:
URL: http://svn.apache.org/viewvc?rev=1390980view=rev
Log:
LANG-818 FastDateFormat's z pattern does not respect timezone of Calendar
instances passed to format()
Modified:
commons/proper/lang/trunk/src/changes/changes.xml
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/time/FastDatePrinter.java
commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/time/FastDatePrinterTest.java
FastDateFormat's z pattern does not respect timezone of Calendar instances
passed to format()
---
Key: LANG-818
URL: https://issues.apache.org/jira/browse/LANG-818
Project: Commons Lang
Issue Type: Bug
Components: lang.time.*
Affects Versions: 3.x
Reporter: Dan Collens
Fix For: 3.2
Attachments: commons-lang3-LANG-818.patch
The work on LANG-462 has introduced a time zone formatting bug in
FastDateFormat in commons-lang3.
The problem can be seen by this snippet:
{code}
// Always prints timezone name of machine's default timezone, ignoring TZ
// set on calendar, even though the printed time itself respects calendar's
TZ.
Calendar myCal = Calendar.getInstance(TimeZone.getTimeZone(US/Central));
System.out.println(FastDateFormat.getInstance(h:mma z).format(myCal));
{code}
If you happen to be in US/Central, this will print the right thing, but just
try it with US/Eastern, US/Pacific, etc. It will print the time in the
correct timezone, but the timezone name at the end (the z pattern) will
always be the system default timezone. This is a regression against
commons-lang 2.x.
Basically, when the forced time zone code was removed, the TimeZoneNameRule
class stopped respecting the Calendar instance's timezone, and instead now
always uses the mTimeZone of the FastDateFormat instance itself (which is
only supposed to be used when formatting timezone-less objects such as Date
or long).
The removal of the forced time zone stuff is surely the right thing to do (it
was a mess). I think the fix is to change the TimeZoneNameRule inner class
to not take a TimeZone instance, but rather to use the TimeZone on the
Calendar instance passed into appendTo(), just like TimeZoneNumberRule does.
Presumably then for efficiency, one would use the getTimeZoneDisplay()
package-static method to quickly retrieve the required timezone's display
name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LANG-820) TypeUtils.normalizeUpperBounds broken?
[
https://issues.apache.org/jira/browse/LANG-820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved LANG-820.
---
Resolution: Not A Problem
Thanks for the test case, added:
URL: http://svn.apache.org/viewvc?rev=1390984view=rev
Log:
LANG-820 TypeUtils.normalizeUpperBounds broken?
Added test to show it works OK
Modified:
commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/reflect/TypeUtilsTest.java
TypeUtils.normalizeUpperBounds broken?
--
Key: LANG-820
URL: https://issues.apache.org/jira/browse/LANG-820
Project: Commons Lang
Issue Type: Bug
Components: lang.reflect.*
Affects Versions: 3.0.1
Reporter: Shevek
I looked at TypeUtils.normalizeUpperBounds, and I think (from code review)
that:
normalize(new Class[] { String.class, String.class }) == { String.class,
String.class }
which is not normalized. Didn't prove it with junit.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-811) Improve event detection by selecting g function slope
[ https://issues.apache.org/jira/browse/MATH-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13464711#comment-13464711 ] Luc Maisonobe commented on MATH-811: The fact we use g0positive and not g(ta) is intentional and should NOT be changed without knowing the reasons why it is there! Improve event detection by selecting g function slope - Key: MATH-811 URL: https://issues.apache.org/jira/browse/MATH-811 Project: Commons Math Issue Type: Improvement Affects Versions: 3.1 Reporter: Yannick TANGUY Attachments: JIRA-811_slope_selection.patch, JIRA-811_slope_selection_V2.patch, JIRA-811_slope_selection_with_spaces.patch We would like to select g function slope in CommonsMath event detection feature. This would improve event detection for the final user (the possibility to ignore some events, and less computation time) and also correct a bug found while using OREKIT (see https://www.orekit.org/forge/issues/104) in our applications. The modification consists in adding a method (getSlopeSelection() : int) in EventHandler, and modifying one conditionnal in the method evaluateStep (class EventState). We can provide modified code and unitary tests for this feature. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-811) Improve event detection by selecting g function slope
[
https://issues.apache.org/jira/browse/MATH-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13464732#comment-13464732
]
Yannick TANGUY commented on MATH-811:
-
Hello Luc,
Ok, but could you explain a little bit please ?
As I understand the code, this value is true when g0 0, and is updated in
stepAccepted method. There's no getter for this value, and it's only used once
in the test if (g0Positive ^ (gb = 0)), so I guess it could be replaced by a
test on ga.
One thing I don't understand (and it may be the point you notice in the comment
Simulated sign of g0 (we cheat when crossing events). is the following code
in stepAccepted :
{noformat}
if (pendingEvent (FastMath.abs(pendingEventTime - t) =
convergence)) {
// force the sign to its value just after the event
previousEventTime = t;
g0Positive= increasing;
nextAction= handler.eventOccurred(t, y, !(increasing ^
forward));
} else {
g0Positive = g0 = 0;
nextAction = EventHandler.Action.CONTINUE;
}
{noformat}
- the value increasing relates to g function, and not to g0 value.
If removing g0positive field is a problem, we could put it again, but I don't
understand the reasons yet.
Improve event detection by selecting g function slope
-
Key: MATH-811
URL: https://issues.apache.org/jira/browse/MATH-811
Project: Commons Math
Issue Type: Improvement
Affects Versions: 3.1
Reporter: Yannick TANGUY
Attachments: JIRA-811_slope_selection.patch,
JIRA-811_slope_selection_V2.patch, JIRA-811_slope_selection_with_spaces.patch
We would like to select g function slope in CommonsMath event detection
feature.
This would improve event detection for the final user (the possibility to
ignore some events, and less computation time) and also correct a bug found
while using OREKIT (see https://www.orekit.org/forge/issues/104) in our
applications.
The modification consists in adding a method (getSlopeSelection() : int) in
EventHandler, and modifying one conditionnal in the method evaluateStep
(class EventState).
We can provide modified code and unitary tests for this feature.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-871) math3 SecantSolver can return Double.INFINITE
Anthony Maidment created MATH-871: - Summary: math3 SecantSolver can return Double.INFINITE Key: MATH-871 URL: https://issues.apache.org/jira/browse/MATH-871 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Anthony Maidment Priority: Minor In doSolve(), I had a situation in which f0 and f1, from computeObjectiveValue() on lines 77 78, were the same value. Then when it calculates the next appromixation at line 101: final double x = x1 - ((f1 * (x1 - x0)) / (f1 - f0)); The denominator is then zero, and the next approximation is Double.INFINITE. I was able to work around this in this particular instance by relaxing the accuracy requirements of the solver, although I haven't yet fully tested the downstream implications of this change. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-871) math3 SecantSolver can return Double.INFINITE
[ https://issues.apache.org/jira/browse/MATH-871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Maidment updated MATH-871: -- Description: In SecantSolver.doSolve(), I had a situation in which f0 and f1, from computeObjectiveValue() on lines 77 78, were the same value. Then when it calculates the next appromixation at line 101: final double x = x1 - ((f1 * (x1 - x0)) / (f1 - f0)); The denominator is then zero, and the next approximation is Double.INFINITE. I was able to work around this in this particular instance by relaxing the accuracy requirements of the solver, although I haven't yet fully tested the downstream implications of this change. was: In doSolve(), I had a situation in which f0 and f1, from computeObjectiveValue() on lines 77 78, were the same value. Then when it calculates the next appromixation at line 101: final double x = x1 - ((f1 * (x1 - x0)) / (f1 - f0)); The denominator is then zero, and the next approximation is Double.INFINITE. I was able to work around this in this particular instance by relaxing the accuracy requirements of the solver, although I haven't yet fully tested the downstream implications of this change. math3 SecantSolver can return Double.INFINITE - Key: MATH-871 URL: https://issues.apache.org/jira/browse/MATH-871 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Anthony Maidment Priority: Minor In SecantSolver.doSolve(), I had a situation in which f0 and f1, from computeObjectiveValue() on lines 77 78, were the same value. Then when it calculates the next appromixation at line 101: final double x = x1 - ((f1 * (x1 - x0)) / (f1 - f0)); The denominator is then zero, and the next approximation is Double.INFINITE. I was able to work around this in this particular instance by relaxing the accuracy requirements of the solver, although I haven't yet fully tested the downstream implications of this change. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-811) Improve event detection by selecting g function slope
[ https://issues.apache.org/jira/browse/MATH-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13464765#comment-13464765 ] Luc Maisonobe commented on MATH-811: This is exactly the point. The code snippet you show solves a difficult bug that did occur before we introduced g0Positive. The problem is that you cannot trust the sign of a value which was explicitely been found as being a zero. First, we cannot yet force users to use a bracketing solver. So users may experience convergence on the wrong side of a zero, i.e. when they have a decreasing function, they may converge before the zero and have g(ta) still positive (very small but positive). Then if g(tb) is negative because it is slightly after the zero, the algorithm will detect a sign change, trigger the solver, and finally converge again to the one that has already been handled earlier! And of course, the second convergence will not always be on the same point as the first one, only close enough to let you wonder if it is really a new event or not. In fact, even if we were able to force users to use bracketing solvers, this would not be safe enough, and we would still need the g0Positive field. There is still the rare case when the solver finds exactly a root. What sign should be used if g(ta) = 0? Once initialized at integration start (or when we know we are away from roots, just like in the else part above), the g0Positive is really a stable flip-flop. bq. - the value increasing relates to g function, and not to g0 value. Yes, of course! A function becomes positive after its root when it is increasing around this root. bq. If removing g0positive field is a problem, we could put it again, but I don't understand the reasons yet. Yes, it is an important problem. It would reactivate a very nasty bug that took a long time to analyze, understand and fix. Please put this field back. Improve event detection by selecting g function slope - Key: MATH-811 URL: https://issues.apache.org/jira/browse/MATH-811 Project: Commons Math Issue Type: Improvement Affects Versions: 3.1 Reporter: Yannick TANGUY Attachments: JIRA-811_slope_selection.patch, JIRA-811_slope_selection_V2.patch, JIRA-811_slope_selection_with_spaces.patch We would like to select g function slope in CommonsMath event detection feature. This would improve event detection for the final user (the possibility to ignore some events, and less computation time) and also correct a bug found while using OREKIT (see https://www.orekit.org/forge/issues/104) in our applications. The modification consists in adding a method (getSlopeSelection() : int) in EventHandler, and modifying one conditionnal in the method evaluateStep (class EventState). We can provide modified code and unitary tests for this feature. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DBUTILS-101) QueryRunner fails to detect broken pmd
Sébastien Le Ray created DBUTILS-101: Summary: QueryRunner fails to detect broken pmd Key: DBUTILS-101 URL: https://issues.apache.org/jira/browse/DBUTILS-101 Project: Commons DbUtils Issue Type: Improvement Affects Versions: 1.5 Reporter: Sébastien Le Ray Priority: Minor I recently fall across a strange issue with SQLServer JDBC driver and DBUtils. PreparedStatement#getParameterMetadata sometimes throw an SQLException which is not caught in fillParameter. The issues arises with pagination queries like SELECT * FROM ( SELECT ROW_NUMBER() OVER ( ORDER BY field1 ASC) AS RowNum, field1 as id, field2 as reference FROM MY_TABLE WHERE 1 = 1 AND field1 LIKE ?) as toPaginate WHERE RowNum = 1 AND RowNum = 50 the query is fine but getParameterMetaData throw an esception complaining about a syntax error near WHERE. Passing pmdKnownBroken to true solves this but stmt.getParameterMetaData(); should be wrapped to catch the exception to adjust pmdKnownBroken. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DBUTILS-101) QueryRunner fails to detect broken pmd
[ https://issues.apache.org/jira/browse/DBUTILS-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sébastien Le Ray updated DBUTILS-101: - Description: I recently fall across a strange issue with SQLServer JDBC driver and DBUtils. PreparedStatement#getParameterMetadata sometimes throw an SQLException which is not caught in fillParameter. The issue arises with pagination queries like SELECT * FROM ( SELECT ROW_NUMBER() OVER ( ORDER BY field1 ASC) AS RowNum, field1 as id, field2 as reference FROM MY_TABLE WHERE 1 = 1 AND field1 LIKE ?) as toPaginate WHERE RowNum = 1 AND RowNum = 50 the query is fine but getParameterMetaData throw an exception complaining about a syntax error near WHERE. Passing pmdKnownBroken to true solves this but stmt.getParameterMetaData(); should be wrapped to catch the exception to adjust pmdKnownBroken. was: I recently fall across a strange issue with SQLServer JDBC driver and DBUtils. PreparedStatement#getParameterMetadata sometimes throw an SQLException which is not caught in fillParameter. The issues arises with pagination queries like SELECT * FROM ( SELECT ROW_NUMBER() OVER ( ORDER BY field1 ASC) AS RowNum, field1 as id, field2 as reference FROM MY_TABLE WHERE 1 = 1 AND field1 LIKE ?) as toPaginate WHERE RowNum = 1 AND RowNum = 50 the query is fine but getParameterMetaData throw an esception complaining about a syntax error near WHERE. Passing pmdKnownBroken to true solves this but stmt.getParameterMetaData(); should be wrapped to catch the exception to adjust pmdKnownBroken. QueryRunner fails to detect broken pmd -- Key: DBUTILS-101 URL: https://issues.apache.org/jira/browse/DBUTILS-101 Project: Commons DbUtils Issue Type: Improvement Affects Versions: 1.5 Reporter: Sébastien Le Ray Priority: Minor Original Estimate: 10m Remaining Estimate: 10m I recently fall across a strange issue with SQLServer JDBC driver and DBUtils. PreparedStatement#getParameterMetadata sometimes throw an SQLException which is not caught in fillParameter. The issue arises with pagination queries like SELECT * FROM ( SELECT ROW_NUMBER() OVER ( ORDER BY field1 ASC) AS RowNum, field1 as id, field2 as reference FROM MY_TABLE WHERE 1 = 1 AND field1 LIKE ?) as toPaginate WHERE RowNum = 1 AND RowNum = 50 the query is fine but getParameterMetaData throw an exception complaining about a syntax error near WHERE. Passing pmdKnownBroken to true solves this but stmt.getParameterMetaData(); should be wrapped to catch the exception to adjust pmdKnownBroken. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (LANG-834) Validate: add inclusiveBetween(long start, long end, long value) methods
Sebb created LANG-834: - Summary: Validate: add inclusiveBetween(long start, long end, long value) methods Key: LANG-834 URL: https://issues.apache.org/jira/browse/LANG-834 Project: Commons Lang Issue Type: Improvement Components: lang.* Affects Versions: 3.1 Environment: Validate.inclusiveBetween() is often going to be used with primitives, so it might make sense to add inclusiveBetween(long start, long end, long value) and inclusiveBetween(long start, long end, long value, String message) This would avoid the overhead of using boxing and compareTo() for the primitive number types. Note: I tried adding inclusiveBetween(long start, long end, long value, String message, Object ... values) but that causes the compiler to complain about ambiguous methods. However, that's unlikely to be needed much. Reporter: Sebb -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-834) Validate: add inclusiveBetween(long start, long end, long value) methods
[ https://issues.apache.org/jira/browse/LANG-834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated LANG-834: -- Attachment: LANG-834.patch Sample implementation Validate: add inclusiveBetween(long start, long end, long value) methods Key: LANG-834 URL: https://issues.apache.org/jira/browse/LANG-834 Project: Commons Lang Issue Type: Improvement Components: lang.* Affects Versions: 3.1 Environment: Validate.inclusiveBetween() is often going to be used with primitives, so it might make sense to add inclusiveBetween(long start, long end, long value) and inclusiveBetween(long start, long end, long value, String message) This would avoid the overhead of using boxing and compareTo() for the primitive number types. Note: I tried adding inclusiveBetween(long start, long end, long value, String message, Object ... values) but that causes the compiler to complain about ambiguous methods. However, that's unlikely to be needed much. Reporter: Sebb Attachments: LANG-834.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-811) Improve event detection by selecting g function slope
[ https://issues.apache.org/jira/browse/MATH-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13464817#comment-13464817 ] Yannick TANGUY commented on MATH-811: - Ok, thanks for the explanation. I put back that field and also add some comments. I make some more tests with our tools before submitting the patch again. Is there a unitary test that can show the bug you mention ? Improve event detection by selecting g function slope - Key: MATH-811 URL: https://issues.apache.org/jira/browse/MATH-811 Project: Commons Math Issue Type: Improvement Affects Versions: 3.1 Reporter: Yannick TANGUY Attachments: JIRA-811_slope_selection.patch, JIRA-811_slope_selection_V2.patch, JIRA-811_slope_selection_with_spaces.patch We would like to select g function slope in CommonsMath event detection feature. This would improve event detection for the final user (the possibility to ignore some events, and less computation time) and also correct a bug found while using OREKIT (see https://www.orekit.org/forge/issues/104) in our applications. The modification consists in adding a method (getSlopeSelection() : int) in EventHandler, and modifying one conditionnal in the method evaluateStep (class EventState). We can provide modified code and unitary tests for this feature. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-811) Improve event detection by selecting g function slope
[ https://issues.apache.org/jira/browse/MATH-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13464834#comment-13464834 ] Luc Maisonobe commented on MATH-811: When the bug was fixed, yes there was a test dedicated to it. However, this test does not trigger the bug anymore due to other changes (both changes in the solvers convergence and changes in the events framework). Improve event detection by selecting g function slope - Key: MATH-811 URL: https://issues.apache.org/jira/browse/MATH-811 Project: Commons Math Issue Type: Improvement Affects Versions: 3.1 Reporter: Yannick TANGUY Attachments: JIRA-811_slope_selection.patch, JIRA-811_slope_selection_V2.patch, JIRA-811_slope_selection_with_spaces.patch We would like to select g function slope in CommonsMath event detection feature. This would improve event detection for the final user (the possibility to ignore some events, and less computation time) and also correct a bug found while using OREKIT (see https://www.orekit.org/forge/issues/104) in our applications. The modification consists in adding a method (getSlopeSelection() : int) in EventHandler, and modifying one conditionnal in the method evaluateStep (class EventState). We can provide modified code and unitary tests for this feature. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-833) ToStringBuilder should use StringBuilder
[ https://issues.apache.org/jira/browse/LANG-833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13464850#comment-13464850 ] Sebb commented on LANG-833: --- Actually, one cannot use AbstractStringBuilder as that is not visible. The problem is twofold: - there's no suitable common interface or class for StringBuilder and StringBuffer - changing to use StringBuilder would break compatibility, and might cause some applications that rely on the sync. to fail I don't see how it's possible to use StringBuilder without either: - breaking compatibility and some apps, OR - duplicating the API ToStringBuilder should use StringBuilder Key: LANG-833 URL: https://issues.apache.org/jira/browse/LANG-833 Project: Commons Lang Issue Type: Bug Components: lang.* Affects Versions: 3.1 Reporter: Shevek Rewriting as lang3 but still using StringBuffer (synchronized) looks like a missed opportunity. Please use StringBuilder. Suggest audit for uses of StringBuffer in lang3 overall. No cause for it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-833) ToStringBuilder should use StringBuilder
[ https://issues.apache.org/jira/browse/LANG-833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13464855#comment-13464855 ] Sebb commented on LANG-833: --- Unfortunately, the Appendable interface throws IOException which does not help. ToStringBuilder should use StringBuilder Key: LANG-833 URL: https://issues.apache.org/jira/browse/LANG-833 Project: Commons Lang Issue Type: Bug Components: lang.* Affects Versions: 3.1 Reporter: Shevek Rewriting as lang3 but still using StringBuffer (synchronized) looks like a missed opportunity. Please use StringBuilder. Suggest audit for uses of StringBuffer in lang3 overall. No cause for it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-833) ToStringBuilder should use StringBuilder
[ https://issues.apache.org/jira/browse/LANG-833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13464872#comment-13464872 ] Shevek commented on LANG-833: - I did the same analysis and I agree with it. That's why I called it a missed opportunity on the change to lang3. ToStringBuilder should use StringBuilder Key: LANG-833 URL: https://issues.apache.org/jira/browse/LANG-833 Project: Commons Lang Issue Type: Bug Components: lang.* Affects Versions: 3.1 Reporter: Shevek Rewriting as lang3 but still using StringBuffer (synchronized) looks like a missed opportunity. Please use StringBuilder. Suggest audit for uses of StringBuffer in lang3 overall. No cause for it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-833) ToStringBuilder should use StringBuilder
[ https://issues.apache.org/jira/browse/LANG-833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated LANG-833: -- Issue Type: Improvement (was: Bug) Not a bug; it's a possible enhancement for a future version. ToStringBuilder should use StringBuilder Key: LANG-833 URL: https://issues.apache.org/jira/browse/LANG-833 Project: Commons Lang Issue Type: Improvement Components: lang.* Affects Versions: 3.1 Reporter: Shevek Rewriting as lang3 but still using StringBuffer (synchronized) looks like a missed opportunity. Please use StringBuilder. Suggest audit for uses of StringBuffer in lang3 overall. No cause for it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (LANG-835) StrBuilder should support StringBuilder as an input parameter
Sebb created LANG-835: - Summary: StrBuilder should support StringBuilder as an input parameter Key: LANG-835 URL: https://issues.apache.org/jira/browse/LANG-835 Project: Commons Lang Issue Type: Improvement Components: lang.text.* Environment: Although StrBuilder supports CharSequence (and thus StringBuilder), it does so by converting it to a String temporarily. This is a bit wasteful. It would be useful to support StringBuilder directly, as that provides the getChars() method which does a direct copy of the buffer contents. This would involve adding two new methods: getChars(StringBuilder) getChars(StringBuilder, int, int) which can be a direct copy of the StringBuffer methods. Sadly there is no accessible interface or super-class that would allow the methods to share code. Reporter: Sebb -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (LANG-836) StrSubstitutor does not support StringBuilder or CharSequence
Sebb created LANG-836: - Summary: StrSubstitutor does not support StringBuilder or CharSequence Key: LANG-836 URL: https://issues.apache.org/jira/browse/LANG-836 Project: Commons Lang Issue Type: Bug Reporter: Sebb -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (LANG-837) ObjectUtils.identityToString does not support StringBuilder or StrBuilder or Appendable
Sebb created LANG-837: - Summary: ObjectUtils.identityToString does not support StringBuilder or StrBuilder or Appendable Key: LANG-837 URL: https://issues.apache.org/jira/browse/LANG-837 Project: Commons Lang Issue Type: Improvement Reporter: Sebb -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-833) ToStringBuilder should use StringBuilder
[ https://issues.apache.org/jira/browse/LANG-833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13464943#comment-13464943 ] Sebb commented on LANG-833: --- ToStringStyle would also need to be converted/duplicated ToStringBuilder should use StringBuilder Key: LANG-833 URL: https://issues.apache.org/jira/browse/LANG-833 Project: Commons Lang Issue Type: Improvement Components: lang.* Affects Versions: 3.1 Reporter: Shevek Rewriting as lang3 but still using StringBuffer (synchronized) looks like a missed opportunity. Please use StringBuilder. Suggest audit for uses of StringBuffer in lang3 overall. No cause for it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-833) ToStringBuilder should use StringBuilder
[ https://issues.apache.org/jira/browse/LANG-833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13464947#comment-13464947 ] Sebb commented on LANG-833: --- Also ReflectionToStringBuilder ToStringBuilder should use StringBuilder Key: LANG-833 URL: https://issues.apache.org/jira/browse/LANG-833 Project: Commons Lang Issue Type: Improvement Components: lang.* Affects Versions: 3.1 Reporter: Shevek Rewriting as lang3 but still using StringBuffer (synchronized) looks like a missed opportunity. Please use StringBuilder. Suggest audit for uses of StringBuffer in lang3 overall. No cause for it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (MODELER-30) Correct SVN repository links on the Modeler source repository page
[ https://issues.apache.org/jira/browse/MODELER-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MODELER-30. -- Resolution: Won't Fix Assignee: Dennis Lundberg No, the viewvc link is the correct one. Correct SVN repository links on the Modeler source repository page -- Key: MODELER-30 URL: https://issues.apache.org/jira/browse/MODELER-30 Project: Commons Modeler Issue Type: Task Reporter: Steve Westwood Assignee: Dennis Lundberg Priority: Minor If you visit, http://commons.apache.org/modeler/source-repository.html, note that the SVN repositories have not been updated to reflect the current (2012) structure. Hence http://svn.apache.org/viewvc/commons/proper/modeler/trunk should be http://svn.apache.org/repos/asf/commons/proper/modeler/trunk -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-801) Util for conversion between primitive types
[ https://issues.apache.org/jira/browse/LANG-801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13465087#comment-13465087 ] Sebb commented on LANG-801: --- There aeems to be a lot of unnecessary conversion to/from Integer/Short etc. instead of sticking to primitive types. For example: Short bits = (short)(0xff (src shift)); dst[dstPos + i] = bits.byteValue(); could be expressed as dst[dstPos + i] = (byte) (0xff (src shift)); etc. Util for conversion between primitive types --- Key: LANG-801 URL: https://issues.apache.org/jira/browse/LANG-801 Project: Commons Lang Issue Type: New Feature Components: lang.* Reporter: Sebastien Riou Assignee: Joerg Schaible Priority: Minor Attachments: patch_Conversion.txt A utility class to convert data from one primitive type to another, in the most commonly used fashions (big endian/little endian byte order, lsb first or msb first). It also deals with arrays of primitive types and String containing hexadecimal numbers. Such conversions are needed when dealing with embedded software or hardware modeling/design. I attach a initial version which deals with the default encoding, the one which seems the most natural on the JVM: little endian byte ordering, and, within a byte, lsb first. I plan to implement the other encoding I need: - big endian, lsb first - big endian, msb first So far I implemented about half of the methods needed to cover the default encoding: - methods to convert a large data type into an array of a smaller data type (longToBytes for example) - methods to convert an array of a small data type into a larger data type (bytesToLong for example) The remaining half consist of the methods to convert from an array of a data type into an array of another data type (bytesToLongs, LongsToBytes) Once this is available for different encodings, the most useful part can be done: the bridge methods to convert from one encoding to another -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-801) Util for conversion between primitive types
[ https://issues.apache.org/jira/browse/LANG-801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13465102#comment-13465102 ] Joerg Schaible commented on LANG-801: - Actually I simply applied this for use with LANG-778. There's for sure room for improvement. However, it would be nice, if as long as the status is In progress only one of us would touch the files. Util for conversion between primitive types --- Key: LANG-801 URL: https://issues.apache.org/jira/browse/LANG-801 Project: Commons Lang Issue Type: New Feature Components: lang.* Reporter: Sebastien Riou Assignee: Joerg Schaible Priority: Minor Attachments: patch_Conversion.txt A utility class to convert data from one primitive type to another, in the most commonly used fashions (big endian/little endian byte order, lsb first or msb first). It also deals with arrays of primitive types and String containing hexadecimal numbers. Such conversions are needed when dealing with embedded software or hardware modeling/design. I attach a initial version which deals with the default encoding, the one which seems the most natural on the JVM: little endian byte ordering, and, within a byte, lsb first. I plan to implement the other encoding I need: - big endian, lsb first - big endian, msb first So far I implemented about half of the methods needed to cover the default encoding: - methods to convert a large data type into an array of a smaller data type (longToBytes for example) - methods to convert an array of a small data type into a larger data type (bytesToLong for example) The remaining half consist of the methods to convert from an array of a data type into an array of another data type (bytesToLongs, LongsToBytes) Once this is available for different encodings, the most useful part can be done: the bridge methods to convert from one encoding to another -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COMPRESS-202) Document EOF behavior of TarArchiveInputStream
Paul Burrowes created COMPRESS-202: -- Summary: Document EOF behavior of TarArchiveInputStream Key: COMPRESS-202 URL: https://issues.apache.org/jira/browse/COMPRESS-202 Project: Commons Compress Issue Type: Wish Components: Documentation Reporter: Paul Burrowes Priority: Minor When reading from a tar stream getNextEntry() returns null to signify EOF after reading the first EOF record. This leaves the second EOF record in the stream unread potentially confusing subsequent readers or blocking the writer trying to flush the stream in a piped configuration e.g. network streaming. The solution to this is to, if you care about subsequent data or true EOF, read from the underlying InputStream until EOF or a protocol record marker. It would be nice to have the documentation of TarArchiveInputStream mention that it does not read the stream fully but stops at the first EOF record. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-801) Util for conversion between primitive types
[ https://issues.apache.org/jira/browse/LANG-801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13465156#comment-13465156 ] Joerg Schaible commented on LANG-801: - Removed a lot of useless conversions now. Should replace more with JDK functionality? E.g. conversion to hex can be done with Long.toHexString(long) - just that the resulting string has lowercase characters. Util for conversion between primitive types --- Key: LANG-801 URL: https://issues.apache.org/jira/browse/LANG-801 Project: Commons Lang Issue Type: New Feature Components: lang.* Reporter: Sebastien Riou Assignee: Joerg Schaible Priority: Minor Attachments: patch_Conversion.txt A utility class to convert data from one primitive type to another, in the most commonly used fashions (big endian/little endian byte order, lsb first or msb first). It also deals with arrays of primitive types and String containing hexadecimal numbers. Such conversions are needed when dealing with embedded software or hardware modeling/design. I attach a initial version which deals with the default encoding, the one which seems the most natural on the JVM: little endian byte ordering, and, within a byte, lsb first. I plan to implement the other encoding I need: - big endian, lsb first - big endian, msb first So far I implemented about half of the methods needed to cover the default encoding: - methods to convert a large data type into an array of a smaller data type (longToBytes for example) - methods to convert an array of a small data type into a larger data type (bytesToLong for example) The remaining half consist of the methods to convert from an array of a data type into an array of another data type (bytesToLongs, LongsToBytes) Once this is available for different encodings, the most useful part can be done: the bridge methods to convert from one encoding to another -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-158) Add Codec, StringCodec, and BinaryCodec interfaces that extend both encoder and decoder
[
https://issues.apache.org/jira/browse/CODEC-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13465218#comment-13465218
]
Sebb commented on CODEC-158:
It might well be useful to have a common super-interface, so if you have some
code you can provide, please attach it to this issue.
Add Codec, StringCodec, and BinaryCodec interfaces that extend both encoder
and decoder
---
Key: CODEC-158
URL: https://issues.apache.org/jira/browse/CODEC-158
Project: Commons Codec
Issue Type: Improvement
Affects Versions: 1.7
Reporter: Mirko Raner
Priority: Minor
Original Estimate: 1h
Remaining Estimate: 1h
Currently, there are no common interfaces that extend both the encoder and
the decoder interfaces. This makes it hard to deal with a codec as a single
entity and requires separate treatment of encoder and decoder parts.
For example, let's say you want to develop a storage abstraction that uses an
encoding. Right now, you would need to write
class Storage
{
@Inject Encoder encoder;
@Inject Decoder decoder;
//...
}
In practice, encoder and decoder need to match, and most likely both encoder
and decoder would be bound to the same implementation, like Base64 or
URLCodec. Because of the lack of a common superinterface they need to be
specified separately. There are some classes like BaseNCodec that can be used
to unify some of the encoders and decoders, but they are too specific and
restrictive.
Ideally, I would like to write:
class Storage
{
@Inject Codec codec;
//...
}
Assuming that combined encoder/decoder classes like Base64 would implement
that Codec interface, this could be directly bound to a combined
encoder/decoder implementation.
It would be nice if these interfaces were added and the existing codec
classes (BaseNCodec, Hex, QCodec, QuotedPrintableCodec, URLCodec) could be
modified to implement these new interfaces.
I'm happy to contribute a patch if there is interest in this feature.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-481) Commons TFTP does not support RFCs 2347 and 2349
[ https://issues.apache.org/jira/browse/NET-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13465223#comment-13465223 ] Sebb commented on NET-481: -- Sounds like a useful enhancement. Could you provide a sample patch? Commons TFTP does not support RFCs 2347 and 2349 Key: NET-481 URL: https://issues.apache.org/jira/browse/NET-481 Project: Commons Net Issue Type: Improvement Components: TFTP Affects Versions: 1.4, 3.1 Reporter: Mirko Raner Priority: Minor Original Estimate: 2h Remaining Estimate: 2h Commons TFTP does not implement RFC 2347 (TFTP Option Extension) and RFC 2349 (TFTP Timeout Interval and Transfer Size Options). Implementing these two RFCs involves a new packet type (OACK) as well as additional optional header fields in existing read and write request packets. We recently had to do this work for an internal project and are considering to contribute our patches back to the project. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-158) Add Codec, StringCodec, and BinaryCodec interfaces that extend both encoder and decoder
[
https://issues.apache.org/jira/browse/CODEC-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13465224#comment-13465224
]
Gary D. Gregory commented on CODEC-158:
---
Somewhat related is the generification of codecs, for example
https://svn.apache.org/repos/asf/commons/proper/codec/branches/generics
Add Codec, StringCodec, and BinaryCodec interfaces that extend both encoder
and decoder
---
Key: CODEC-158
URL: https://issues.apache.org/jira/browse/CODEC-158
Project: Commons Codec
Issue Type: Improvement
Affects Versions: 1.7
Reporter: Mirko Raner
Priority: Minor
Original Estimate: 1h
Remaining Estimate: 1h
Currently, there are no common interfaces that extend both the encoder and
the decoder interfaces. This makes it hard to deal with a codec as a single
entity and requires separate treatment of encoder and decoder parts.
For example, let's say you want to develop a storage abstraction that uses an
encoding. Right now, you would need to write
class Storage
{
@Inject Encoder encoder;
@Inject Decoder decoder;
//...
}
In practice, encoder and decoder need to match, and most likely both encoder
and decoder would be bound to the same implementation, like Base64 or
URLCodec. Because of the lack of a common superinterface they need to be
specified separately. There are some classes like BaseNCodec that can be used
to unify some of the encoders and decoders, but they are too specific and
restrictive.
Ideally, I would like to write:
class Storage
{
@Inject Codec codec;
//...
}
Assuming that combined encoder/decoder classes like Base64 would implement
that Codec interface, this could be directly bound to a combined
encoder/decoder implementation.
It would be nice if these interfaces were added and the existing codec
classes (BaseNCodec, Hex, QCodec, QuotedPrintableCodec, URLCodec) could be
modified to implement these new interfaces.
I'm happy to contribute a patch if there is interest in this feature.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
