[jira] [Reopened] (MATH-649) SimpleRegression needs the ability to suppress the intercept
[ https://issues.apache.org/jira/browse/MATH-649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz reopened MATH-649: -- Need to update the user guide. > SimpleRegression needs the ability to suppress the intercept > > > Key: MATH-649 > URL: https://issues.apache.org/jira/browse/MATH-649 > Project: Commons Math > Issue Type: New Feature >Affects Versions: 1.2, 2.1, 2.2 > Environment: JAVA >Reporter: greg sterijevski >Assignee: greg sterijevski >Priority: Minor > Labels: NOINTERCEPT, SIMPLEREGRESSION > Fix For: 3.0 > > Attachments: simplereg, simplereg2, simpleregtest > > Original Estimate: 2h > Remaining Estimate: 2h > > The SimpleRegression class is a useful class for running regressions > involving one independent variable. It lacks the ability to constrain the > constant to be zero. I am attaching a patch which gives a constructor for > setting NOINT. I am also checking in two NIST data sets for noint estimation. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OGNL-18) Performance issue on high load (thread blocking)
[ https://issues.apache.org/jira/browse/OGNL-18?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13102090#comment-13102090 ] Daniel Pitts commented on OGNL-18: -- @Adam Ruggles, it looks like the majority of your threads are blocked on "com.opensymphony.xwork2.conversion.impl.XWorkConverter.getConverter(XWorkConverter.java:410)" This is not a class in the Ognl project, so I doubt that problem is related to this Jira. > Performance issue on high load (thread blocking) > > > Key: OGNL-18 > URL: https://issues.apache.org/jira/browse/OGNL-18 > Project: OGNL > Issue Type: Bug >Reporter: Christian Grobmeier >Priority: Critical > Attachments: thread-dump-lock.txt, thread-dump-lock2.txt > > > The Struts project is suffering from an issue occuring from OGNL on heavy > load. > The issue in question (with details) is: > https://issues.apache.org/jira/browse/WW-3580 > A similar issues has been reported in the OpenSymphony bugtracker: > https://issues.apache.org/jira/browse/WW-3580 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OGNL-18) Performance issue on high load (thread blocking)
[ https://issues.apache.org/jira/browse/OGNL-18?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13102095#comment-13102095 ] Maurizio Cucchiara commented on OGNL-18: Hi Adam, Daniel is right, it looks like this is a xwork-related problem. Again, I think we could easily convert every hashMap to the concurrent version and remove the synchronized block. Could you file an issue on [xwork|https://issues.apache.org/jira/browse/XW] section of JIRA. TIA > Performance issue on high load (thread blocking) > > > Key: OGNL-18 > URL: https://issues.apache.org/jira/browse/OGNL-18 > Project: OGNL > Issue Type: Bug >Reporter: Christian Grobmeier >Priority: Critical > Attachments: thread-dump-lock.txt, thread-dump-lock2.txt > > > The Struts project is suffering from an issue occuring from OGNL on heavy > load. > The issue in question (with details) is: > https://issues.apache.org/jira/browse/WW-3580 > A similar issues has been reported in the OpenSymphony bugtracker: > https://issues.apache.org/jira/browse/WW-3580 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OGNL-18) Performance issue on high load (thread blocking)
[ https://issues.apache.org/jira/browse/OGNL-18?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13102099#comment-13102099 ] Maurizio Cucchiara commented on OGNL-18: During my latest spare time I have tried to find out what would be the right way to approach this problem. So I wrote a jmeter test against the Struts ShowCase application, looking for a good trade-off between ramp-up period, concurrent user and so on. I have to say that has not been not a piece of cake: # both opensymphony ognl and patched version of commons ognl give more or less the same outcomes. I have also tested against a full application stack, but with no results. That happens because, IMO, the ognl load is very small compared with I/O request (servlet, DB access, and so on) which are the really bottleneck. Any idea, guys? > Performance issue on high load (thread blocking) > > > Key: OGNL-18 > URL: https://issues.apache.org/jira/browse/OGNL-18 > Project: OGNL > Issue Type: Bug >Reporter: Christian Grobmeier >Priority: Critical > Attachments: thread-dump-lock.txt, thread-dump-lock2.txt > > > The Struts project is suffering from an issue occuring from OGNL on heavy > load. > The issue in question (with details) is: > https://issues.apache.org/jira/browse/WW-3580 > A similar issues has been reported in the OpenSymphony bugtracker: > https://issues.apache.org/jira/browse/WW-3580 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OGNL-20) Performance - Replace synchronized blocks with ReentrantReadWriteLock
[
https://issues.apache.org/jira/browse/OGNL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Pitts updated OGNL-20:
-
Attachment: Bench Results.txt
Caching_Mechanism_Benchmarks.patch
New approach to caching with benchmarks.
I've created a few classes which I think can improve both the code design and
the concurrency of the caches used in OgnlRuntime.
It would require a refactor to use them (which I would provide if this approach
is agreed on).
I've attached a "patch", which doesn't actually change any Ognl code, but
provides implementations of this new approach, as well as a benchmark to test
the efficiency of the different approaches.
Also attached is the output of that bench mark on my machine. It seems to
clearly point to "ConcurrentHashMap" as the winner. Please feel free to
critique my benchmark code. If all seems well, I'll work on JavaDocs, unit
tests, and refactoring OgnlRuntime to use this new caching approach.
> Performance - Replace synchronized blocks with ReentrantReadWriteLock
> -
>
> Key: OGNL-20
> URL: https://issues.apache.org/jira/browse/OGNL-20
> Project: OGNL
> Issue Type: Improvement
> Environment: ALL
>Reporter: Greg Lively
> Attachments: Bench Results.txt, Caching_Mechanism_Benchmarks.patch
>
>
> I've noticed a lot of synchronized blocks of code in OGNL. For the most part,
> these synchronized blocks are controlling access to HashMaps, etc. I believe
> this could be done far better using ReentrantReadWriteLocks.
> ReentrantReadWriteLock allows unlimited concurrent access, and single threads
> only for writes. Perfect in an environment where the ratio of reads is far
> higher than writes; which is typically the scenario for caching. Plus the
> access control can be tuned for reads and writes; not just a big
> synchronized{} wrapping a bunch of code.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-664) Replace "LUDecompostionImpl" with "QRDecompositionImpl" in "AbstractLeastSquaresOptimizer"
[ https://issues.apache.org/jira/browse/MATH-664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13102160#comment-13102160 ] Gilles commented on MATH-664: - Done in revision 1167612. Changing the decomposition algorithm is still to be decided. > Replace "LUDecompostionImpl" with "QRDecompositionImpl" in > "AbstractLeastSquaresOptimizer" > -- > > Key: MATH-664 > URL: https://issues.apache.org/jira/browse/MATH-664 > Project: Commons Math > Issue Type: Improvement >Reporter: Gilles >Assignee: Gilles >Priority: Minor > Fix For: 3.0 > > > In some cases, the "getCovariances()" method throws a > "SingularMatrixException". This can be avoided by using "QR" instead of "LU" > decomposition. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-666) Remove "getData" in "FieldVector" (package "o.a.c.m.linear")
Remove "getData" in "FieldVector" (package "o.a.c.m.linear") Key: MATH-666 URL: https://issues.apache.org/jira/browse/MATH-666 Project: Commons Math Issue Type: Task Reporter: Gilles Priority: Trivial "getData()" is redundant with "toArray()". This is the same kind of change as performed in MATH-663. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-663) Remove "getData" in "RealVector" (package "o.a.c.m.linear")
[ https://issues.apache.org/jira/browse/MATH-663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles resolved MATH-663. - Resolution: Fixed > Remove "getData" in "RealVector" (package "o.a.c.m.linear") > --- > > Key: MATH-663 > URL: https://issues.apache.org/jira/browse/MATH-663 > Project: Commons Math > Issue Type: Task >Reporter: Gilles >Assignee: Gilles >Priority: Trivial > Labels: api-change > Fix For: 3.0 > > > "getData()" is redundant with "toArray()". -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-650) FastMath has static code which slows the first access to FastMath
[
https://issues.apache.org/jira/browse/MATH-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13102186#comment-13102186
]
Gilles commented on MATH-650:
-
Answering my own question using code committed in revision 1167657.
*Single call*
_--- Previous revision ---_
{noformat}
floor (runs per timed block: 1, timed blocks: 1)
StrictMath: 5.232920e-01 (0.00e+00) ms
Math: 1.188100e-02 (0.00e+00) ms
FastMath: 4.942540e+00 (0.00e+00) ms
{noformat}
_--- Current revision (preset arrays) ---_
{noformat}
floor (runs per timed block: 1, timed blocks: 1)
StrictMath: 5.290030e-01 (0.00e+00) ms
Math: 1.201200e-02 (0.00e+00) ms
FastMath: 4.871144e+00 (0.00e+00) ms
{noformat}
_--- Current revision (computed arrays) ---_
{noformat}
floor (runs per timed block: 1, timed blocks: 1)
StrictMath: 5.150580e-01 (0.00e+00) ms
Math: 1.236000e-02 (0.00e+00) ms
FastMath: 4.938346e+00 (0.00e+00) ms
{noformat}
*100 calls*
_--- Previous revision ---_
{noformat}
floor (runs per timed block: 10, timed blocks: 10)
StrictMath: 6.119510e-03 (1.700389e-02) ms
Math: 8.260500e-04 (3.575574e-04) ms
FastMath: 5.001669e-02 (1.563012e-01) ms
{noformat}
_--- Current revision (preset arrays) ---_
{noformat}
floor (runs per timed block: 10, timed blocks: 10)
StrictMath: 6.157360e-03 (1.718482e-02) ms
Math: 8.144700e-04 (3.643913e-04) ms
FastMath: 4.921887e-02 (1.537010e-01) ms
{noformat}
_--- Current revision (computed arrays) ---_
{noformat}
floor (runs per timed block: 10, timed blocks: 10)
StrictMath: 7.027420e-03 (1.983324e-02) ms
Math: 9.193500e-04 (3.579075e-04) ms
FastMath: 4.789965e-02 (1.498412e-01) ms
{noformat}
So, at startup,
* it takes about the same time to call {{floor}} once and 100 times,
* there is no difference between using preset arrays or computing them
({{floor}} does not need the arrays, so they are not initialized).
> FastMath has static code which slows the first access to FastMath
> -
>
> Key: MATH-650
> URL: https://issues.apache.org/jira/browse/MATH-650
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: Nightly Builds
> Environment: Android 2.3 (Dalvik VM with JIT)
>Reporter: Alexis Robert
>Priority: Minor
>
> Working on an Android application using Orekit, I've discovered that a simple
> FastMath.floor() takes about 4 to 5 secs on a 1GHz Nexus One phone (only the
> first time it's called). I've launched the Android profiling tool (traceview)
> and the problem seems to be linked with the static portion of FastMath code
> named "// Initialize tables"
> The timing resulted in :
> - FastMath.slowexp (40.8%)
> - FastMath.expint (39.2%)
> \- FastMath.quadmult() (95.6% of expint)
> - FastMath.slowlog (18.2%)
> Hoping that would help
> Thanks!
> Alexis Robert
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-650) FastMath has static code which slows the first access to FastMath
[
https://issues.apache.org/jira/browse/MATH-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13102190#comment-13102190
]
Gilles commented on MATH-650:
-
Now, for {{pow}} (which makes use of the tables).
*Single call*
_--- Current revision (preset arrays) ---_
{noformat}
pow (runs per timed block: 1, timed blocks: 1)
StrictMath: 3.505750e-01 (0.00e+00) ms
Math: 1.212800e-02 (0.00e+00) ms
FastMath: 1.615966e+01 (0.00e+00) ms
{noformat}
_--- Current revision (computed arrays) ---_
{noformat}
pow (runs per timed block: 1, timed blocks: 1)
StrictMath: 3.744040e-01 (0.00e+00) ms
Math: 1.167500e-02 (0.00e+00) ms
FastMath: 6.009579e+01 (0.00e+00) ms
{noformat}
*100 calls*
_--- Current revision (preset arrays) ---_
{noformat}
pow (runs per timed block: 10, timed blocks: 10)
StrictMath: 4.989190e-03 (1.327046e-02) ms
Math: 9.002900e-04 (3.572090e-04) ms
FastMath: 1.766465e-01 (5.395676e-01) ms
{noformat}
_--- Current revision (computed arrays) ---_
{noformat}
pow (runs per timed block: 10, timed blocks: 10)
StrictMath: 4.825060e-03 (1.264487e-02) ms
Math: 8.913100e-04 (3.244602e-04) ms
FastMath: 6.132025e-01 (1.920372e+00) ms
{noformat}
*1_000_000 calls*
_--- Current revision (preset arrays) ---_
{noformat}
pow (runs per timed block: 1, timed blocks: 100)
StrictMath: 3.579742e-04 (5.042732e-05) ms
Math: 3.488973e-04 (2.601644e-05) ms
FastMath: 2.985653e-04 (5.704499e-04) ms
{noformat}
_--- Current revision (computed arrays) ---_
{noformat}
pow (runs per timed block: 1, timed blocks: 100)
StrictMath: 3.574941e-04 (4.608201e-05) ms
Math: 3.520267e-04 (2.770605e-05) ms
FastMath: 3.399842e-04 (1.001058e-03) ms
{noformat}
One can see that using preset arrays is indeed faster. The ratio of times
(calling {{pow}} either using preset or using computed arrays):
* 1 call: 0.27
* 100 calls: 0.29
* 100 calls: 0.88
Do the above results warrant to triple the size of the source file? IMO, no.
We are not dealing with a "few seconds" of absolute running time: For each of
the 3 runs (single call, one hundred and one million calls), we gain no more
than about 45 milliseconds!
> FastMath has static code which slows the first access to FastMath
> -
>
> Key: MATH-650
> URL: https://issues.apache.org/jira/browse/MATH-650
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: Nightly Builds
> Environment: Android 2.3 (Dalvik VM with JIT)
>Reporter: Alexis Robert
>Priority: Minor
>
> Working on an Android application using Orekit, I've discovered that a simple
> FastMath.floor() takes about 4 to 5 secs on a 1GHz Nexus One phone (only the
> first time it's called). I've launched the Android profiling tool (traceview)
> and the problem seems to be linked with the static portion of FastMath code
> named "// Initialize tables"
> The timing resulted in :
> - FastMath.slowexp (40.8%)
> - FastMath.expint (39.2%)
> \- FastMath.quadmult() (95.6% of expint)
> - FastMath.slowlog (18.2%)
> Hoping that would help
> Thanks!
> Alexis Robert
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-577) Add ObjectReference interface and two implementations
[
https://issues.apache.org/jira/browse/LANG-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13102209#comment-13102209
]
Henri Yandell commented on LANG-577:
Also, iiuc, while the interface might be the overlapping, the implementations
won't be.
I'm +1 for the feature.
Matt called it a StrongReference - would that be a better name? Or is that
implementation dependent (ie: MemoryReference would be a strong reference, but
ObjectReference could be multiple types?)
> Add ObjectReference interface and two implementations
> -
>
> Key: LANG-577
> URL: https://issues.apache.org/jira/browse/LANG-577
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.*
>Reporter: Joerg Schaible
>Assignee: Joerg Schaible
>Priority: Minor
> Fix For: 3.x
>
> Attachments: reference.diff
>
>
> In some situations it would be helpful to use a reference to an object, e.g.
> for parameters by reference
> {code:java}
> void doSomething(ObjectReference ref) {
> ref.set("Hello");
> }
> {code}
> or for anonymous methods
> {code:java}
> final ObjectReference ref = new MemoryReference();
> final Runnable r = new Runnable() {
> void run() {
> ref.set("Hello");
> }
> }
> r.run();
> {code}
> Additionally it is sometimes useful to keep the reference in other places
> than in shared memory, e.g. in a ThreadLocal or in case of a web application
> in a scoped reference or even in combination with some other persistence
> mechanism. Basically I am proposing the interface ObjectReference:
> {code:Java}
> /**
> * Interface to reference an object.
> *
> * @param the type of the referenced object
> * @author Apache Software Foundation
> * @since 3.0
> */
> public interface ObjectReference {
> /**
> * Getter for the referenced object.
> *
> * @return the object or null
> */
> T get();
> /**
> * Setter for the reference.
> *
> * @param object the object to reference (may be null)
> */
> void set(T object);
> }
> {code}
> and the two implementations MemoryReference and ThreadLocalReference in the
> new package org.apache.commons.lang3.reference. I've seen such or similar
> types in various libraries.
> Comments?
> Unit test will be provided also.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-744) StringUtils throws java.security.AccessControlException on Google App Engine
[
https://issues.apache.org/jira/browse/LANG-744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13102219#comment-13102219
]
Henri Yandell commented on LANG-744:
Gary - are you +1 on Sebb's change?
ie) Keep the exception, but only when stripAccents is invoked (making it the
same as other examples presumably are).
> StringUtils throws java.security.AccessControlException on Google App Engine
>
>
> Key: LANG-744
> URL: https://issues.apache.org/jira/browse/LANG-744
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.0.1
> Environment: Google App Engine
>Reporter: Clément Denis
> Fix For: 3.0.2
>
>
> In the static initializer of org.apache.commons.lang3.StringUtils, there is
> an attempt to load the class sun.text.Normalizer.
> Such a class is prohibited on Google App Engine, and the static intializer
> throws a java.security.AccessControlException.
> {code}
> Caused by: java.security.AccessControlException: access denied
> (java.lang.RuntimePermission accessClassInPackage.sun.text)
> at
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:374)
> at
> java.security.AccessController.checkPermission(AccessController.java:546)
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
> at
> com.google.appengine.tools.development.DevAppServerFactory$CustomSecurityManager.checkPermission(DevAppServerFactory.java:166)
> at
> java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1512)
> at java.lang.Class.checkMemberAccess(Class.java:2164)
> at java.lang.Class.getMethod(Class.java:1602)
> at org.apache.commons.lang3.StringUtils.(StringUtils.java:739)
> {code}
> The exception should be caught in the catch clauses around
> loadClass("sun.text.Normalizer").
> Commons lang 2 worked fine on GAE.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-693) Method createNumber from NumberUtils doesn't work for floating point numbers other than Float
[ https://issues.apache.org/jira/browse/LANG-693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-693: --- Fix Version/s: (was: 3.0.2) 3.0.3 Pushing back to 3.0.3; I don't think is ready yet as the toString approach is likely to lead to bugs and there's not another solution on the table. > Method createNumber from NumberUtils doesn't work for floating point numbers > other than Float > - > > Key: LANG-693 > URL: https://issues.apache.org/jira/browse/LANG-693 > Project: Commons Lang > Issue Type: Bug > Components: lang.math.* >Affects Versions: 2.6 >Reporter: Carlos Rego >Priority: Minor > Fix For: 3.0.3 > > > Method createNumber from NumberUtils is trying to parse a string with a > floating point number always first as a Float, that will cause that if we > send a string with a number that will need a Double or even a BigDecimal the > number will be truncate to accommodate into the Float without an exception to > be thrown, so in fact we will no be returning ever neither a Double nor a > BigDecimal. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-622) StringUtils.lastIndexOfAnyBut() function desired
[ https://issues.apache.org/jira/browse/LANG-622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-622: --- Fix Version/s: (was: 3.0.2) 3.x Pushing back to 3.x. Needs more work - namely to use lastIndex and add a few more tests for the expected use cases. > StringUtils.lastIndexOfAnyBut() function desired > > > Key: LANG-622 > URL: https://issues.apache.org/jira/browse/LANG-622 > Project: Commons Lang > Issue Type: Improvement > Components: lang.* >Reporter: david cogen >Priority: Minor > Fix For: 3.x > > Attachments: LANG-622.patch, StringUtilslLastIndexOfAnyButTest.java > > > class StringUtils needs the function lastIndexOfAnyBut() > This would be like indexOfAnyBut() except searches from the end rather than > the beginning. > It would be like lastIndexOfAny() except looks for a character other than > those in the string rather than for those in the string. > This is the only one of the four combinations of "from beginning"/"from end" > and "for any"/"for any but" that is not provided. > Interestingly, the class header doc. mentions "LastIndexOfAnyBut" but the > function does not exist - even as a private, as determined by class > introspection. > (This is not a frivolous request. I actually did need this function and ended > up having to code a search loop.) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-604) Optimize isBlank() for untrimmed strings
[
https://issues.apache.org/jira/browse/LANG-604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13102223#comment-13102223
]
Henri Yandell commented on LANG-604:
Coming back to this one, I'm unconvinced of the need to improve performance (at
the cost of simplicity). There are theory based performance improvements for "
123", but we're talking the difference between 1 and 2 charAt calls. Very small
stuff. The same could hold true for much larger strings, but they are going to
be rare enough as to require their own optimization techniques if they're
expected as the norm (ie: hand roll your own code, possibly switch to a faster
system if Java is considered 'too slow').
So while I continue to agree with the performance improvement, I don't believe
they actualize as big enough to warrant the code complexity.
Sorry for the big delay.
> Optimize isBlank() for untrimmed strings
>
>
> Key: LANG-604
> URL: https://issues.apache.org/jira/browse/LANG-604
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.0
>Reporter: Kai Gülzau
>Priority: Minor
> Fix For: 3.0.2
>
>
> Change isBlank() to start iteration in the middle of the String.
> So you get better performance for untrimmed Strings like " dummy ".
> Here is my proposal:
> public static boolean isBlank(CharSequence cs) {
> int strLen;
> if (cs == null || (strLen = cs.length()) == 0) {
> return true;
> }
> int mid = strLen / 2, i = mid;
> for (; i < strLen; i++) {
> if (!Character.isWhitespace(cs.charAt(i))) {
> return false;
> }
> }
> for (i = 0; i < mid; i++) {
> if (!Character.isWhitespace(cs.charAt(i))) {
> return false;
> }
> }
> return true;
> }
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-750) Add MethodUtil APIs to call methods without parameters.
[ https://issues.apache.org/jira/browse/LANG-750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-750: --- Fix Version/s: (was: 3.0.2) > Add MethodUtil APIs to call methods without parameters. > --- > > Key: LANG-750 > URL: https://issues.apache.org/jira/browse/LANG-750 > Project: Commons Lang > Issue Type: New Feature > Components: lang.reflect.* >Affects Versions: 3.0.1 > Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) > Maven home: C:\Java\apache-maven-3.0.3\bin\.. > Java version: 1.6.0_24, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_24\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Gary D. Gregory >Assignee: Gary D. Gregory > > Add MethodUtil APIs to call methods without parameters: > - invokeExactMethod(Object, String) > - invokeExactStaticMethod(Class, String) > - invokeMethod(Object, String) > - invokeStaticMethod(Class, String) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (LANG-526) Performance testing
[ https://issues.apache.org/jira/browse/LANG-526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed LANG-526. -- Resolution: Won't Fix Fix Version/s: (was: 3.x) Nothing identified to do here, resolving. > Performance testing > --- > > Key: LANG-526 > URL: https://issues.apache.org/jira/browse/LANG-526 > Project: Commons Lang > Issue Type: Task > Components: General >Reporter: Henri Yandell > > It's worth doing some performance testing of interesting areas of code to see > if there are good improvements that might be made. > List below: -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-502) new method StringUtils.replaceIgnoreCase (with patch)
[
https://issues.apache.org/jira/browse/LANG-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13102228#comment-13102228
]
Henri Yandell commented on LANG-502:
The big pain on this one is that it requires 7 new ignoreCase variants of the
existing replace methods in StringUtils.
I don't think it's a common enough situation to warrant that extra code and
would point towards the regexp classes.
My vote is to resolve this as wontfix.
Apologies for slowness in reaching that opinion.
> new method StringUtils.replaceIgnoreCase (with patch)
> -
>
> Key: LANG-502
> URL: https://issues.apache.org/jira/browse/LANG-502
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
> Environment: all
>Reporter: Flo
>Priority: Minor
> Fix For: 3.0.2
>
>
> Method implementation:
> /**
>* Searches for all appearances of searchString (ignoring
> case) in text and replaces them by replacement.
>* The difference to {@link String#replace(CharSequence, CharSequence)}
> and {@link StringUtils#replace(String, String, String)} is that this
> implementation ignores case.
>*
>* @param text The text in which to do replacements.
>* @param searchString The string to remove from the text (ignoring
> case).
>* @param replacement The string to put instead of the searchString.
>* @return A new string with all searchString replaced by replacement.
>* @author frickert
>*/
> public static String replaceIgnoreCase(String text, String
> searchString, String replacement)
> {
> String lowerCaseText = text.toLowerCase();
> String lowerCaseSearchString = searchString.toLowerCase();
> StringBuilder sb = new StringBuilder(text);
> int searchStart = 0;
> final int modifierPerReplacement = replacement.length() -
> searchString.length();
> int sbDrift = 0; // by doing replacements in sb, sb and the
> text drift off in length and index in case the searchString and the
> replacement are of different length
> int finding = lowerCaseText.indexOf(lowerCaseSearchString,
> searchStart);
> while (finding >= 0)
> {
> sb.replace(finding + sbDrift, finding + sbDrift +
> searchString.length(), replacement);
> sbDrift += modifierPerReplacement;
> searchStart = finding + searchString.length();
> finding = lowerCaseText.indexOf(lowerCaseSearchString,
> searchStart);
> }
> return sb.toString();
> }
> test cases:
> public void testReplaceIgnoreCase() throws Throwable {
> String is;
> is = CommonHelpers.replaceIgnoreCase("bobOBOBobOB", "Bob", "Flo");
> assertEquals("search really ignores case", "FloOFlooFlo", is);
> is = CommonHelpers.replaceIgnoreCase("bobOBOBobOB", "Bob", "Flo");
> assertEquals("replacement does care about case", "FloOFlooFlo", is);
> is = CommonHelpers.replaceIgnoreCase("bob bob bob", "Bob", "Florian");
> assertEquals("length difference of searchString and replacement > 0",
> "Florian Florian Florian", is);
> is = CommonHelpers.replaceIgnoreCase("bob bob bob", "Bob", "Ed");
> assertEquals("length difference of searchString and replacement < 0",
> "Ed Ed Ed", is);
> is = CommonHelpers.replaceIgnoreCase("GROSS und klein", "und", "&");
> assertEquals("originals case is preserved in not replace chars",
> "GROSS & klein", is);
> }
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
