[GitHub] [commons-rng] coveralls edited a comment on pull request #89: RNG-136: Add ObjectSampler and SharedStateObjectSampler interfaces
coveralls edited a comment on pull request #89: URL: https://github.com/apache/commons-rng/pull/89#issuecomment-842617274 [](https://coveralls.io/builds/39833916) Coverage increased (+0.0001%) to 99.554% when pulling **37bcab3d917bae53903c6eeceb9eebb89f540ceb on aherbert:feature-RNG-136** into **d36538538e0dd425e365c8b9b2e39d93a4a10f41 on apache:master**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (RNG-136) ObjectSampler and SharedStateObjectSampler interfaces
[
https://issues.apache.org/jira/browse/RNG-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Herbert updated RNG-136:
-
Description:
The sampling package currently contains interfaces for creating int and double
samples and their extensions to implement the SharedStateSampler interface:
{code:java}
public interface DiscreteSampler {
int sample();
}
public interface SharedStateDiscreteSampler
extends DiscreteSampler, SharedStateSampler {
// Composite interface
}
public interface ContinuousSampler {
double sample();
}
public interface SharedStateContinuousSampler
extends ContinuousSampler, SharedStateSampler
{
// Composite interface
}
{code}
Add a matching ObjectSampler interface for all samplers that create objects:
{code:java}
public interface ObjectSampler {
T sample();
}
public interface SharedStateObjectSampler extends
ObjectSampler,
SharedStateSampler> {
// Composite interface
}
{code}
Samplers currently returning an object should implement the new interface:
{code:java}
int[] CombinationSampler.sample()
int[] PermutationSampler.sample()
double[] UnitSphereSampler.nextVector()
T CollectionSampler.sample()
T DiscreteProbabilityCollectionSampler.sample()
double[] BoxSampler.sample()
double[] LineSampler.sample()
double[] TriangleSampler.sample()
double[] TetrahedronSampler.sample()
double[] UnitBallSampler.sample()
{code}
Only the UnitVectorSampler will require a new {{sample}} method. The current
{{nextVector}} method can be marked deprecated.
was:
The sampling package currently contains interfaces for creating int and double
samples and their extensions to implement the SharedStateSampler interface:
{code:java}
public interface DiscreteSampler {
int sample();
}
public interface SharedStateDiscreteSampler
extends DiscreteSampler, SharedStateSampler {
// Composite interface
}
public interface ContinuousSampler {
double sample();
}
public interface SharedStateContinuousSampler
extends ContinuousSampler, SharedStateSampler
{
// Composite interface
}
{code}
Add a matching ObjectSampler interface for all samplers that create objects:
{code:java}
public interface ObjectSampler {
T sample();
}
public interface SharedStateObjectSampler extends
ObjectSampler,
SharedStateSampler> {
// Composite interface
}
{code}
Samplers currently returning an object should implement the new interface:
{code:java}
int[] CombinationSampler.sample()
int[] PermutationSampler.sample()
double[] UnitVectorSampler.nextVector()
T CollectionSampler.sample()
T DiscreteProbabilityCollectionSampler.sample()
double[] BoxSampler.sample()
double[] LineSampler.sample()
double[] TriangleSampler.sample()
double[] TetrahedronSampler.sample()
double[] UnitBallSampler.sample()
{code}
Only the UnitVectorSampler will require a new {{sample}} method. The current
{{nextVector}} method can be marked deprecated.
> ObjectSampler and SharedStateObjectSampler interfaces
> ---
>
> Key: RNG-136
> URL: https://issues.apache.org/jira/browse/RNG-136
> Project: Commons RNG
> Issue Type: New Feature
> Components: sampling
>Affects Versions: 1.4
>Reporter: Alex Herbert
>Assignee: Alex Herbert
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The sampling package currently contains interfaces for creating int and
> double samples and their extensions to implement the SharedStateSampler
> interface:
> {code:java}
> public interface DiscreteSampler {
> int sample();
> }
> public interface SharedStateDiscreteSampler
> extends DiscreteSampler, SharedStateSampler {
> // Composite interface
> }
> public interface ContinuousSampler {
> double sample();
> }
> public interface SharedStateContinuousSampler
> extends ContinuousSampler,
> SharedStateSampler {
> // Composite interface
> }
> {code}
> Add a matching ObjectSampler interface for all samplers that create objects:
> {code:java}
> public interface ObjectSampler {
> T sample();
> }
> public interface SharedStateObjectSampler extends
> ObjectSampler,
> SharedStateSampler> {
> // Composite interface
> }
> {code}
> Samplers currently returning an object should implement the new interface:
> {code:java}
> int[] CombinationSampler.sample()
> int[] PermutationSampler.sample()
> double[] UnitSphereSampler.nextVector()
> T CollectionSampler.sample()
> T DiscreteProbabilityCollectionSampler.sample()
> double[] BoxSampler.sample()
> double[] LineSampler.sample()
> double[] TriangleSampler.sample()
> double[] TetrahedronSampler.sample()
> double[] UnitBallSampler.sample()
> {code}
> Only the UnitVectorSampler will require a new {{sample}} method. The current
> {{nextVector}} method can be marked deprecated.
--
This message
[jira] [Comment Edited] (RNG-136) ObjectSampler and SharedStateObjectSampler interfaces
[
https://issues.apache.org/jira/browse/RNG-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17347861#comment-17347861
]
Alex Herbert edited comment on RNG-136 at 5/19/21, 8:37 PM:
h2. Updating existing classes changes functional compatibility
Although there is no binary compatibility change for existing classes there is
functional compatibility change with updating to the new interface.
For example:
{code:java}
public class CollectionSampler implements
SharedStateSampler> {
{code}
Becomes:
{code:java}
public class CollectionSampler implements SharedStateObjectSampler {
{code}
The implementation signature of {{SharedStateSampler}} remains unchanged:
{code:java}
public CollectionSampler withUniformRandomProvider(UniformRandomProvider
rng) {
{code}
Due to type erasure the change from {{SharedStateSampler}} to
{{SharedStateObjectSampler}} is not detected as binary incompatible as the
class still implements {{SharedStateSampler}}. But the {{SharedStateSampler}}
is now of type {{SharedStateSampler>}} instead of
{{SharedStateSampler>}}.
If the derived sampler is assigned to the correct type this is functionally
compatible:
{code:java}
CollectionSampler sampler1 = new CollectionSampler(rng1, list);
CollectionSampler sampler2 = sampler1.withUniformRandomProvider(rng2);
{code}
If the derived sampler is assigned to a {{SharedStateSampler}} this is
functionally *incompatible*; this will *not* compile with version 1.4 where it
will with code from version 1.3:
{code:java}
CollectionSampler sampler1 = new CollectionSampler(rng1, list);
SharedStateSampler> sampler2 =
sampler1.withUniformRandomProvider(rng2);
{code}
The functionally incompatible change is to the following existing classes:
{code:java}
public CollectionSampler implements SharedStateSampler>
public CombinationSampler implements SharedStateSampler
public DiscreteProbabilityCollectionSampler
implements SharedStateSampler>
public PermutationSampler implements SharedStateSampler
public UnitSphereSampler implements SharedStateSampler
{code}
In each of the classes the method implementation {{withUniformRandomProvider}}
returns an instance of the class. Thus changing the interface implemented by
the class has not changed the signature of the method implementation.
If a user has coded their use of the interface to assign the result to an
instance of the class (as per the unit tests) then code will be functionally
compatible. If they have assigned an instance of {{SharedStateSampler}} then
code will not be functionally compatible.
Note that the SharedStateSampler interface only has 1 method:
{code:java}
public interface SharedStateSampler {
R withUniformRandomProvider(UniformRandomProvider rng);
}
{code}
So it is unlikely any user will assign the result of the method to an instance
of {{SharedStateSampler}} as functionally it can only be used to create more
instances. No sampling can actually be done from a {{SharedStateSampler}}. Code
that has done this will later have to cast the {{SharedStateSampler}} to some
other class to use it for sampling. This usage is incorrect and supporting it
is not a priority.
I propose to allow this change without updating the major version number of the
code. The functional compatibility change can be added to the release notes.
was (Author: alexherbert):
h2. Updating existing classes changes functional compatibility
Although there is no binary compatibility change for existing classes there is
functional compatibility change with updating to the new interface.
For example:
{code:java}
public class CollectionSampler implements
SharedStateSampler> {
{code}
Becomes:
{code:java}
public class CollectionSampler implements SharedStateObjectSampler {
{code}
The implementation signature of {{SharedStateSampler}} remains unchanged:
{code:java}
public CollectionSampler withUniformRandomProvider(UniformRandomProvider
rng) {
{code}
Due to type erasure the change from {{SharedStateSampler}} to
{{SharedStateObjectSampler}} is not detected as binary incompatible as the
class still implements {{SharedStateSampler}}. But the {{SharedStateSampler}}
is now of type {{SharedStateSampler>}} instead of
{{SharedStateSampler>}}.
If the derived sampler is assigned to the correct type this is functionally
compatible:
{code:java}
CollectionSampler sampler1 = new CollectionSampler(rng1, list);
CollectionSampler sampler2 = sampler1.withUniformRandomProvider(rng2);
{code}
If the derived sampler is assigned to a {{SharedStateSampler}} this is
functionally *incompatible*; this will *not* compile with version 1.4 where it
will with code from version 1.3:
{code:java}
CollectionSampler sampler1 = new CollectionSampler(rng1, list);
SharedStateSampler> sampler2 =
sampler1.withUniformRandomProvider(rng2);
{code}
The functionally incompatible change is to the following existing classes:
{code:java}
public CollectionSampler
[jira] [Commented] (RNG-136) ObjectSampler and SharedStateObjectSampler interfaces
[
https://issues.apache.org/jira/browse/RNG-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17347861#comment-17347861
]
Alex Herbert commented on RNG-136:
--
h2. Updating existing classes changes functional compatibility
Although there is no binary compatibility change for existing classes there is
functional compatibility change with updating to the new interface.
For example:
{code:java}
public class CollectionSampler implements
SharedStateSampler> {
{code}
Becomes:
{code:java}
public class CollectionSampler implements SharedStateObjectSampler {
{code}
The implementation signature of {{SharedStateSampler}} remains unchanged:
{code:java}
public CollectionSampler withUniformRandomProvider(UniformRandomProvider
rng) {
{code}
Due to type erasure the change from {{SharedStateSampler}} to
{{SharedStateObjectSampler}} is not detected as binary incompatible as the
class still implements {{SharedStateSampler}}. But the {{SharedStateSampler}}
is now of type {{SharedStateSampler>}} instead of
{{SharedStateSampler>}}.
If the derived sampler is assigned to the correct type this is functionally
compatible:
{code:java}
CollectionSampler sampler1 = new CollectionSampler(rng1, list);
CollectionSampler sampler2 = sampler1.withUniformRandomProvider(rng2);
{code}
If the derived sampler is assigned to a {{SharedStateSampler}} this is
functionally *incompatible*; this will *not* compile with version 1.4 where it
will with code from version 1.3:
{code:java}
CollectionSampler sampler1 = new CollectionSampler(rng1, list);
SharedStateSampler> sampler2 =
sampler1.withUniformRandomProvider(rng2);
{code}
The functionally incompatible change is to the following existing classes:
{code:java}
public CollectionSampler implements SharedStateSampler>
public CombinationSampler implements SharedStateSampler
public DiscreteProbabilityCollectionSampler
implements SharedStateSampler>
public PermutationSampler implements SharedStateSampler
public UnitVectorSampler implements SharedStateSampler
{code}
In each of the classes the method implementation {{withUniformRandomProvider}}
returns an instance of the class. Thus changing the interface implemented by
the class has not changed the signature of the method implementation.
If a user has coded their use of the interface to assign the result to an
instance of the class (as per the unit tests) then code will be functionally
compatible. If they have assigned an instance of {{SharedStateSampler}} then
code will not be functionally compatible.
Note that the SharedStateSampler interface only has 1 method:
{code:java}
public interface SharedStateSampler {
R withUniformRandomProvider(UniformRandomProvider rng);
}
{code}
So it is unlikely any user will assign the result of the method to an instance
of {{SharedStateSampler}} as functionally it can only be used to create more
instances. No sampling can actually be done from a {{SharedStateSampler}}. Code
that has done this will later have to cast the {{SharedStateSampler}} to some
other class to use it for sampling. This usage is incorrect and supporting it
is not a priority.
I propose to allow this change without updating the major version number of the
code. The functional compatibility change can be added to the release notes.
> ObjectSampler and SharedStateObjectSampler interfaces
> ---
>
> Key: RNG-136
> URL: https://issues.apache.org/jira/browse/RNG-136
> Project: Commons RNG
> Issue Type: New Feature
> Components: sampling
>Affects Versions: 1.4
>Reporter: Alex Herbert
>Assignee: Alex Herbert
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The sampling package currently contains interfaces for creating int and
> double samples and their extensions to implement the SharedStateSampler
> interface:
> {code:java}
> public interface DiscreteSampler {
> int sample();
> }
> public interface SharedStateDiscreteSampler
> extends DiscreteSampler, SharedStateSampler {
> // Composite interface
> }
> public interface ContinuousSampler {
> double sample();
> }
> public interface SharedStateContinuousSampler
> extends ContinuousSampler,
> SharedStateSampler {
> // Composite interface
> }
> {code}
> Add a matching ObjectSampler interface for all samplers that create objects:
> {code:java}
> public interface ObjectSampler {
> T sample();
> }
> public interface SharedStateObjectSampler extends
> ObjectSampler,
> SharedStateSampler> {
> // Composite interface
> }
> {code}
> Samplers currently returning an object should implement the new interface:
> {code:java}
> int[] CombinationSampler.sample()
> int[] PermutationSampler.sample()
> double[] UnitVectorSampler.nextVector()
> T CollectionSampler.sample()
> T
[jira] [Updated] (LANG-1661) Add methods to ClassUtils to get the class type names in a null-safe manner
[ https://issues.apache.org/jira/browse/LANG-1661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arturo Bernal updated LANG-1661: Labels: pull-request-available (was: ) > Add methods to ClassUtils to get the class type names in a null-safe manner > --- > > Key: LANG-1661 > URL: https://issues.apache.org/jira/browse/LANG-1661 > Project: Commons Lang > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > Add methods ClassUtils to get the class names type in a null-safe manner: > - getTypeName(Class) > - getTypeName(Object) > - getTypeName(Class, String) > - getTypeName(Object, String) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (LANG-1572) implement TODO in CharSequenceUtils.indexOf : remake it.
[ https://issues.apache.org/jira/browse/LANG-1572?focusedWorklogId=599339=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-599339 ] ASF GitHub Bot logged work on LANG-1572: Author: ASF GitHub Bot Created on: 19/May/21 16:48 Start Date: 19/May/21 16:48 Worklog Time Spent: 10m Work Description: coveralls edited a comment on pull request #560: URL: https://github.com/apache/commons-lang/pull/560#issuecomment-650483751 [](https://coveralls.io/builds/39825662) Coverage decreased (-0.007%) to 94.92% when pulling **17f9a8b10bce27dd9279f31a72511cb7c544427b on xenoamess-fork:remake_indexOf** into **c893f5d3ae90d5060db044ee3d0c79f36aea9511 on apache:master**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 599339) Time Spent: 4h 10m (was: 4h) > implement TODO in CharSequenceUtils.indexOf : remake it. > > > Key: LANG-1572 > URL: https://issues.apache.org/jira/browse/LANG-1572 > Project: Commons Lang > Issue Type: Sub-task >Reporter: Jin Xu >Priority: Major > Time Spent: 4h 10m > Remaining Estimate: 0h > > [https://github.com/apache/commons-lang/pull/560] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-lang] coveralls edited a comment on pull request #560: [LANG-1572] green implementation CharSequenceUtils.indexOf
coveralls edited a comment on pull request #560: URL: https://github.com/apache/commons-lang/pull/560#issuecomment-650483751 [](https://coveralls.io/builds/39825662) Coverage decreased (-0.007%) to 94.92% when pulling **17f9a8b10bce27dd9279f31a72511cb7c544427b on xenoamess-fork:remake_indexOf** into **c893f5d3ae90d5060db044ee3d0c79f36aea9511 on apache:master**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (LANG-1572) implement TODO in CharSequenceUtils.indexOf : remake it.
[ https://issues.apache.org/jira/browse/LANG-1572?focusedWorklogId=599327=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-599327 ] ASF GitHub Bot logged work on LANG-1572: Author: ASF GitHub Bot Created on: 19/May/21 16:14 Start Date: 19/May/21 16:14 Worklog Time Spent: 10m Work Description: XenoAmess commented on pull request #560: URL: https://github.com/apache/commons-lang/pull/560#issuecomment-844255113 @aherbert fixed. please re-review. thanks. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 599327) Time Spent: 4h (was: 3h 50m) > implement TODO in CharSequenceUtils.indexOf : remake it. > > > Key: LANG-1572 > URL: https://issues.apache.org/jira/browse/LANG-1572 > Project: Commons Lang > Issue Type: Sub-task >Reporter: Jin Xu >Priority: Major > Time Spent: 4h > Remaining Estimate: 0h > > [https://github.com/apache/commons-lang/pull/560] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-lang] XenoAmess commented on pull request #560: [LANG-1572] green implementation CharSequenceUtils.indexOf
XenoAmess commented on pull request #560: URL: https://github.com/apache/commons-lang/pull/560#issuecomment-844255113 @aherbert fixed. please re-review. thanks. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-io] coveralls commented on pull request #235: CharArrayWriter
coveralls commented on pull request #235: URL: https://github.com/apache/commons-io/pull/235#issuecomment-844244542 [](https://coveralls.io/builds/39824135) Coverage decreased (-0.6%) to 88.767% when pulling **eebc24512f38c4f23dc2e00e489763c6b8daeb17 on pjfanning:string-writer** into **e569d0f76924502007ba838dded7d5fdfcedd578 on apache:master**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (LANG-1572) implement TODO in CharSequenceUtils.indexOf : remake it.
[
https://issues.apache.org/jira/browse/LANG-1572?focusedWorklogId=599314=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-599314
]
ASF GitHub Bot logged work on LANG-1572:
Author: ASF GitHub Bot
Created on: 19/May/21 15:43
Start Date: 19/May/21 15:43
Worklog Time Spent: 10m
Work Description: XenoAmess commented on a change in pull request #560:
URL: https://github.com/apache/commons-lang/pull/560#discussion_r635366397
##
File path: src/main/java/org/apache/commons/lang3/CharSequenceUtils.java
##
@@ -133,24 +133,87 @@ static int indexOf(final CharSequence cs, final int
searchChar, int start) {
* @param start the start index
* @return the index where the search sequence was found
*/
-static int indexOf(final CharSequence cs, final CharSequence searchChar,
final int start) {
-if (cs instanceof String) {
-return ((String) cs).indexOf(searchChar.toString(), start);
-} else if (cs instanceof StringBuilder) {
-return ((StringBuilder) cs).indexOf(searchChar.toString(), start);
-} else if (cs instanceof StringBuffer) {
-return ((StringBuffer) cs).indexOf(searchChar.toString(), start);
-}
-return cs.toString().indexOf(searchChar.toString(), start);
-//if (cs instanceof String && searchChar instanceof String) {
-//// TODO: Do we assume searchChar is usually relatively small;
-//// If so then calling toString() on it is better than
reverting to
-//// the green implementation in the else block
-//return ((String) cs).indexOf((String) searchChar, start);
-//} else {
-//// TODO: Implement rather than convert to String
-//return cs.toString().indexOf(searchChar.toString(), start);
-//}
+static int indexOf(final CharSequence cs, final CharSequence searchChar,
int start) {
+// if searchChar is a String, and cs is some specific kind of
AbstractString,
+// which both have a indexOf function and widely used by normal java
codes,
+// then we just invoke their indexOf function.
+if (searchChar instanceof String) {
+if (cs instanceof String) {
+return ((String) cs).indexOf((String) searchChar, start);
+} else if (cs instanceof StringBuilder) {
+return ((StringBuilder) cs).indexOf((String) searchChar,
start);
+} else if (cs instanceof StringBuffer) {
+return ((StringBuffer) cs).indexOf((String) searchChar, start);
+}
+}
+
+int len1 = cs.length();
+int len2 = searchChar.length();
+
+// successful-result >= 0
+if (start < 0) {
+start = 0;
+}
+
+
+// successful-result <= len1
+if (start > len1) {
+start = len1;
+}
+
+// if len2 == 0 return directly.
+if (len2 == 0) {
+return start;
+}
+
+// limit means the largest possible value of successful-result
+final int limit = len1 - len2;
+
+// if start > limit, then have no enough length for a search,
+// thus cannot find a index, thus fail.
+// if len2 < 0, then it is illegal for this function.
+// if limit < 0, then it means len2 > len1, thus fail.
+if (start > limit || len2 < 0 || limit < 0) {
+return -1;
+}
+
+// notice that when we enter here, we make sure:
+// start in [0, limit]
+// limit in [0, len1-1]
+// len2 in [1, len1]
+
+// if len2 is small enough, and cs is some specific kind of
AbstractString,
+// which both have a indexOf function and widely used by normal java
codes,
+// then we just invoke their indexOf function.
+if (len2 <= TO_STRING_LIMIT) {
+if (cs instanceof String) {
+return ((String) cs).indexOf(searchChar.toString(), start);
+} else if (cs instanceof StringBuilder) {
+return ((StringBuilder) cs).indexOf(searchChar.toString(),
start);
+} else if (cs instanceof StringBuffer) {
+return ((StringBuffer) cs).indexOf(searchChar.toString(),
start);
+}
+}
+
+char char0 = searchChar.charAt(0);
+
+int i = start;
+while (true) {
Review comment:
@aherbert
yep, you are correct.
glad to fix it.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 599314)
Time Spent: 3h 50m (was: 3h 40m)
> implement TODO
[GitHub] [commons-lang] XenoAmess commented on a change in pull request #560: [LANG-1572] green implementation CharSequenceUtils.indexOf
XenoAmess commented on a change in pull request #560:
URL: https://github.com/apache/commons-lang/pull/560#discussion_r635366397
##
File path: src/main/java/org/apache/commons/lang3/CharSequenceUtils.java
##
@@ -133,24 +133,87 @@ static int indexOf(final CharSequence cs, final int
searchChar, int start) {
* @param start the start index
* @return the index where the search sequence was found
*/
-static int indexOf(final CharSequence cs, final CharSequence searchChar,
final int start) {
-if (cs instanceof String) {
-return ((String) cs).indexOf(searchChar.toString(), start);
-} else if (cs instanceof StringBuilder) {
-return ((StringBuilder) cs).indexOf(searchChar.toString(), start);
-} else if (cs instanceof StringBuffer) {
-return ((StringBuffer) cs).indexOf(searchChar.toString(), start);
-}
-return cs.toString().indexOf(searchChar.toString(), start);
-//if (cs instanceof String && searchChar instanceof String) {
-//// TODO: Do we assume searchChar is usually relatively small;
-//// If so then calling toString() on it is better than
reverting to
-//// the green implementation in the else block
-//return ((String) cs).indexOf((String) searchChar, start);
-//} else {
-//// TODO: Implement rather than convert to String
-//return cs.toString().indexOf(searchChar.toString(), start);
-//}
+static int indexOf(final CharSequence cs, final CharSequence searchChar,
int start) {
+// if searchChar is a String, and cs is some specific kind of
AbstractString,
+// which both have a indexOf function and widely used by normal java
codes,
+// then we just invoke their indexOf function.
+if (searchChar instanceof String) {
+if (cs instanceof String) {
+return ((String) cs).indexOf((String) searchChar, start);
+} else if (cs instanceof StringBuilder) {
+return ((StringBuilder) cs).indexOf((String) searchChar,
start);
+} else if (cs instanceof StringBuffer) {
+return ((StringBuffer) cs).indexOf((String) searchChar, start);
+}
+}
+
+int len1 = cs.length();
+int len2 = searchChar.length();
+
+// successful-result >= 0
+if (start < 0) {
+start = 0;
+}
+
+
+// successful-result <= len1
+if (start > len1) {
+start = len1;
+}
+
+// if len2 == 0 return directly.
+if (len2 == 0) {
+return start;
+}
+
+// limit means the largest possible value of successful-result
+final int limit = len1 - len2;
+
+// if start > limit, then have no enough length for a search,
+// thus cannot find a index, thus fail.
+// if len2 < 0, then it is illegal for this function.
+// if limit < 0, then it means len2 > len1, thus fail.
+if (start > limit || len2 < 0 || limit < 0) {
+return -1;
+}
+
+// notice that when we enter here, we make sure:
+// start in [0, limit]
+// limit in [0, len1-1]
+// len2 in [1, len1]
+
+// if len2 is small enough, and cs is some specific kind of
AbstractString,
+// which both have a indexOf function and widely used by normal java
codes,
+// then we just invoke their indexOf function.
+if (len2 <= TO_STRING_LIMIT) {
+if (cs instanceof String) {
+return ((String) cs).indexOf(searchChar.toString(), start);
+} else if (cs instanceof StringBuilder) {
+return ((StringBuilder) cs).indexOf(searchChar.toString(),
start);
+} else if (cs instanceof StringBuffer) {
+return ((StringBuffer) cs).indexOf(searchChar.toString(),
start);
+}
+}
+
+char char0 = searchChar.charAt(0);
+
+int i = start;
+while (true) {
Review comment:
@aherbert
yep, you are correct.
glad to fix it.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Work logged] (LANG-1572) implement TODO in CharSequenceUtils.indexOf : remake it.
[ https://issues.apache.org/jira/browse/LANG-1572?focusedWorklogId=599313=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-599313 ] ASF GitHub Bot logged work on LANG-1572: Author: ASF GitHub Bot Created on: 19/May/21 15:42 Start Date: 19/May/21 15:42 Worklog Time Spent: 10m Work Description: coveralls edited a comment on pull request #560: URL: https://github.com/apache/commons-lang/pull/560#issuecomment-650483751 [](https://coveralls.io/builds/39823280) Coverage decreased (-0.003%) to 94.924% when pulling **19463851b34a70872fcba83a180591a544d60159 on xenoamess-fork:remake_indexOf** into **c893f5d3ae90d5060db044ee3d0c79f36aea9511 on apache:master**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 599313) Time Spent: 3h 40m (was: 3.5h) > implement TODO in CharSequenceUtils.indexOf : remake it. > > > Key: LANG-1572 > URL: https://issues.apache.org/jira/browse/LANG-1572 > Project: Commons Lang > Issue Type: Sub-task >Reporter: Jin Xu >Priority: Major > Time Spent: 3h 40m > Remaining Estimate: 0h > > [https://github.com/apache/commons-lang/pull/560] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-lang] coveralls edited a comment on pull request #560: [LANG-1572] green implementation CharSequenceUtils.indexOf
coveralls edited a comment on pull request #560: URL: https://github.com/apache/commons-lang/pull/560#issuecomment-650483751 [](https://coveralls.io/builds/39823280) Coverage decreased (-0.003%) to 94.924% when pulling **19463851b34a70872fcba83a180591a544d60159 on xenoamess-fork:remake_indexOf** into **c893f5d3ae90d5060db044ee3d0c79f36aea9511 on apache:master**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (IO-726) Add MemoryMappedInputStream
[
https://issues.apache.org/jira/browse/IO-726?focusedWorklogId=599296=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-599296
]
ASF GitHub Bot logged work on IO-726:
-
Author: ASF GitHub Bot
Created on: 19/May/21 15:01
Start Date: 19/May/21 15:01
Worklog Time Spent: 10m
Work Description: shollander commented on pull request #215:
URL: https://github.com/apache/commons-io/pull/215#issuecomment-844190370
@garydgregory Issues addressed.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 599296)
Time Spent: 2h (was: 1h 50m)
> Add MemoryMappedInputStream
> ---
>
> Key: IO-726
> URL: https://issues.apache.org/jira/browse/IO-726
> Project: Commons IO
> Issue Type: New Feature
> Components: Streams/Writers
>Affects Versions: 2.8.0
>Reporter: S Hollander
>Priority: Major
> Fix For: 2.9.0
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> A very useful tool for improving performance with disk-based IO is the use of
> memory mapped files. I propose an {{InputStream}} that provides a bridge
> between memory mapped files and the {{InputStream}} ecosystem.
> In my limited performance tests, the use of the MemoryMappedInputStream
> provided a 25% increase in throughput.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-io] shollander commented on pull request #215: IO-726 Add MemoryMappedInputStream.
shollander commented on pull request #215: URL: https://github.com/apache/commons-io/pull/215#issuecomment-844190370 @garydgregory Issues addressed. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (LANG-1572) implement TODO in CharSequenceUtils.indexOf : remake it.
[
https://issues.apache.org/jira/browse/LANG-1572?focusedWorklogId=599292=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-599292
]
ASF GitHub Bot logged work on LANG-1572:
Author: ASF GitHub Bot
Created on: 19/May/21 14:59
Start Date: 19/May/21 14:59
Worklog Time Spent: 10m
Work Description: XenoAmess commented on a change in pull request #560:
URL: https://github.com/apache/commons-lang/pull/560#discussion_r635326740
##
File path: src/main/java/org/apache/commons/lang3/CharSequenceUtils.java
##
@@ -133,24 +133,87 @@ static int indexOf(final CharSequence cs, final int
searchChar, int start) {
* @param start the start index
* @return the index where the search sequence was found
*/
-static int indexOf(final CharSequence cs, final CharSequence searchChar,
final int start) {
-if (cs instanceof String) {
-return ((String) cs).indexOf(searchChar.toString(), start);
-} else if (cs instanceof StringBuilder) {
-return ((StringBuilder) cs).indexOf(searchChar.toString(), start);
-} else if (cs instanceof StringBuffer) {
-return ((StringBuffer) cs).indexOf(searchChar.toString(), start);
-}
-return cs.toString().indexOf(searchChar.toString(), start);
-//if (cs instanceof String && searchChar instanceof String) {
-//// TODO: Do we assume searchChar is usually relatively small;
-//// If so then calling toString() on it is better than
reverting to
-//// the green implementation in the else block
-//return ((String) cs).indexOf((String) searchChar, start);
-//} else {
-//// TODO: Implement rather than convert to String
-//return cs.toString().indexOf(searchChar.toString(), start);
-//}
+static int indexOf(final CharSequence cs, final CharSequence searchChar,
int start) {
+// if searchChar is a String, and cs is some specific kind of
AbstractString,
+// which both have a indexOf function and widely used by normal java
codes,
+// then we just invoke their indexOf function.
+if (searchChar instanceof String) {
+if (cs instanceof String) {
+return ((String) cs).indexOf((String) searchChar, start);
+} else if (cs instanceof StringBuilder) {
+return ((StringBuilder) cs).indexOf((String) searchChar,
start);
+} else if (cs instanceof StringBuffer) {
+return ((StringBuffer) cs).indexOf((String) searchChar, start);
+}
+}
+
+int len1 = cs.length();
+int len2 = searchChar.length();
+
+// successful-result >= 0
+if (start < 0) {
+start = 0;
+}
+
+
+// successful-result <= len1
+if (start > len1) {
+start = len1;
+}
+
+// if len2 == 0 return directly.
+if (len2 == 0) {
+return start;
+}
+
+// limit means the largest possible value of successful-result
+final int limit = len1 - len2;
+
+// if start > limit, then have no enough length for a search,
+// thus cannot find a index, thus fail.
+// if len2 < 0, then it is illegal for this function.
+// if limit < 0, then it means len2 > len1, thus fail.
+if (start > limit || len2 < 0 || limit < 0) {
+return -1;
+}
+
+// notice that when we enter here, we make sure:
+// start in [0, limit]
+// limit in [0, len1-1]
+// len2 in [1, len1]
+
+// if len2 is small enough, and cs is some specific kind of
AbstractString,
+// which both have a indexOf function and widely used by normal java
codes,
+// then we just invoke their indexOf function.
+if (len2 <= TO_STRING_LIMIT) {
+if (cs instanceof String) {
+return ((String) cs).indexOf(searchChar.toString(), start);
+} else if (cs instanceof StringBuilder) {
+return ((StringBuilder) cs).indexOf(searchChar.toString(),
start);
+} else if (cs instanceof StringBuffer) {
+return ((StringBuffer) cs).indexOf(searchChar.toString(),
start);
+}
+}
+
+char char0 = searchChar.charAt(0);
+
+int i = start;
+while (true) {
Review comment:
> If you think your way is faster then that remains to be proven.
OK, I will write a jmh now.
If it shows you be correct, then I'm glad to change the codes.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time
[GitHub] [commons-lang] XenoAmess commented on a change in pull request #560: [LANG-1572] green implementation CharSequenceUtils.indexOf
XenoAmess commented on a change in pull request #560:
URL: https://github.com/apache/commons-lang/pull/560#discussion_r635326740
##
File path: src/main/java/org/apache/commons/lang3/CharSequenceUtils.java
##
@@ -133,24 +133,87 @@ static int indexOf(final CharSequence cs, final int
searchChar, int start) {
* @param start the start index
* @return the index where the search sequence was found
*/
-static int indexOf(final CharSequence cs, final CharSequence searchChar,
final int start) {
-if (cs instanceof String) {
-return ((String) cs).indexOf(searchChar.toString(), start);
-} else if (cs instanceof StringBuilder) {
-return ((StringBuilder) cs).indexOf(searchChar.toString(), start);
-} else if (cs instanceof StringBuffer) {
-return ((StringBuffer) cs).indexOf(searchChar.toString(), start);
-}
-return cs.toString().indexOf(searchChar.toString(), start);
-//if (cs instanceof String && searchChar instanceof String) {
-//// TODO: Do we assume searchChar is usually relatively small;
-//// If so then calling toString() on it is better than
reverting to
-//// the green implementation in the else block
-//return ((String) cs).indexOf((String) searchChar, start);
-//} else {
-//// TODO: Implement rather than convert to String
-//return cs.toString().indexOf(searchChar.toString(), start);
-//}
+static int indexOf(final CharSequence cs, final CharSequence searchChar,
int start) {
+// if searchChar is a String, and cs is some specific kind of
AbstractString,
+// which both have a indexOf function and widely used by normal java
codes,
+// then we just invoke their indexOf function.
+if (searchChar instanceof String) {
+if (cs instanceof String) {
+return ((String) cs).indexOf((String) searchChar, start);
+} else if (cs instanceof StringBuilder) {
+return ((StringBuilder) cs).indexOf((String) searchChar,
start);
+} else if (cs instanceof StringBuffer) {
+return ((StringBuffer) cs).indexOf((String) searchChar, start);
+}
+}
+
+int len1 = cs.length();
+int len2 = searchChar.length();
+
+// successful-result >= 0
+if (start < 0) {
+start = 0;
+}
+
+
+// successful-result <= len1
+if (start > len1) {
+start = len1;
+}
+
+// if len2 == 0 return directly.
+if (len2 == 0) {
+return start;
+}
+
+// limit means the largest possible value of successful-result
+final int limit = len1 - len2;
+
+// if start > limit, then have no enough length for a search,
+// thus cannot find a index, thus fail.
+// if len2 < 0, then it is illegal for this function.
+// if limit < 0, then it means len2 > len1, thus fail.
+if (start > limit || len2 < 0 || limit < 0) {
+return -1;
+}
+
+// notice that when we enter here, we make sure:
+// start in [0, limit]
+// limit in [0, len1-1]
+// len2 in [1, len1]
+
+// if len2 is small enough, and cs is some specific kind of
AbstractString,
+// which both have a indexOf function and widely used by normal java
codes,
+// then we just invoke their indexOf function.
+if (len2 <= TO_STRING_LIMIT) {
+if (cs instanceof String) {
+return ((String) cs).indexOf(searchChar.toString(), start);
+} else if (cs instanceof StringBuilder) {
+return ((StringBuilder) cs).indexOf(searchChar.toString(),
start);
+} else if (cs instanceof StringBuffer) {
+return ((StringBuffer) cs).indexOf(searchChar.toString(),
start);
+}
+}
+
+char char0 = searchChar.charAt(0);
+
+int i = start;
+while (true) {
Review comment:
> If you think your way is faster then that remains to be proven.
OK, I will write a jmh now.
If it shows you be correct, then I'm glad to change the codes.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Work logged] (LANG-1572) implement TODO in CharSequenceUtils.indexOf : remake it.
[
https://issues.apache.org/jira/browse/LANG-1572?focusedWorklogId=599291=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-599291
]
ASF GitHub Bot logged work on LANG-1572:
Author: ASF GitHub Bot
Created on: 19/May/21 14:57
Start Date: 19/May/21 14:57
Worklog Time Spent: 10m
Work Description: XenoAmess commented on a change in pull request #560:
URL: https://github.com/apache/commons-lang/pull/560#discussion_r635324914
##
File path: src/main/java/org/apache/commons/lang3/CharSequenceUtils.java
##
@@ -133,24 +133,87 @@ static int indexOf(final CharSequence cs, final int
searchChar, int start) {
* @param start the start index
* @return the index where the search sequence was found
*/
-static int indexOf(final CharSequence cs, final CharSequence searchChar,
final int start) {
-if (cs instanceof String) {
-return ((String) cs).indexOf(searchChar.toString(), start);
-} else if (cs instanceof StringBuilder) {
-return ((StringBuilder) cs).indexOf(searchChar.toString(), start);
-} else if (cs instanceof StringBuffer) {
-return ((StringBuffer) cs).indexOf(searchChar.toString(), start);
-}
-return cs.toString().indexOf(searchChar.toString(), start);
-//if (cs instanceof String && searchChar instanceof String) {
-//// TODO: Do we assume searchChar is usually relatively small;
-//// If so then calling toString() on it is better than
reverting to
-//// the green implementation in the else block
-//return ((String) cs).indexOf((String) searchChar, start);
-//} else {
-//// TODO: Implement rather than convert to String
-//return cs.toString().indexOf(searchChar.toString(), start);
-//}
+static int indexOf(final CharSequence cs, final CharSequence searchChar,
int start) {
+// if searchChar is a String, and cs is some specific kind of
AbstractString,
+// which both have a indexOf function and widely used by normal java
codes,
+// then we just invoke their indexOf function.
+if (searchChar instanceof String) {
+if (cs instanceof String) {
+return ((String) cs).indexOf((String) searchChar, start);
+} else if (cs instanceof StringBuilder) {
+return ((StringBuilder) cs).indexOf((String) searchChar,
start);
+} else if (cs instanceof StringBuffer) {
+return ((StringBuffer) cs).indexOf((String) searchChar, start);
+}
+}
+
+int len1 = cs.length();
+int len2 = searchChar.length();
+
+// successful-result >= 0
+if (start < 0) {
+start = 0;
+}
Review comment:
> If `len1` is negative and if `len2` is zero then your return value
will be whatever `len1` was, which is an incorrect result when it is not `-1`.
@aherbert
you are correct.
this is a bug.
will fix it.
thanks.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 599291)
Time Spent: 3h 20m (was: 3h 10m)
> implement TODO in CharSequenceUtils.indexOf : remake it.
>
>
> Key: LANG-1572
> URL: https://issues.apache.org/jira/browse/LANG-1572
> Project: Commons Lang
> Issue Type: Sub-task
>Reporter: Jin Xu
>Priority: Major
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> [https://github.com/apache/commons-lang/pull/560]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] XenoAmess commented on a change in pull request #560: [LANG-1572] green implementation CharSequenceUtils.indexOf
XenoAmess commented on a change in pull request #560:
URL: https://github.com/apache/commons-lang/pull/560#discussion_r635324914
##
File path: src/main/java/org/apache/commons/lang3/CharSequenceUtils.java
##
@@ -133,24 +133,87 @@ static int indexOf(final CharSequence cs, final int
searchChar, int start) {
* @param start the start index
* @return the index where the search sequence was found
*/
-static int indexOf(final CharSequence cs, final CharSequence searchChar,
final int start) {
-if (cs instanceof String) {
-return ((String) cs).indexOf(searchChar.toString(), start);
-} else if (cs instanceof StringBuilder) {
-return ((StringBuilder) cs).indexOf(searchChar.toString(), start);
-} else if (cs instanceof StringBuffer) {
-return ((StringBuffer) cs).indexOf(searchChar.toString(), start);
-}
-return cs.toString().indexOf(searchChar.toString(), start);
-//if (cs instanceof String && searchChar instanceof String) {
-//// TODO: Do we assume searchChar is usually relatively small;
-//// If so then calling toString() on it is better than
reverting to
-//// the green implementation in the else block
-//return ((String) cs).indexOf((String) searchChar, start);
-//} else {
-//// TODO: Implement rather than convert to String
-//return cs.toString().indexOf(searchChar.toString(), start);
-//}
+static int indexOf(final CharSequence cs, final CharSequence searchChar,
int start) {
+// if searchChar is a String, and cs is some specific kind of
AbstractString,
+// which both have a indexOf function and widely used by normal java
codes,
+// then we just invoke their indexOf function.
+if (searchChar instanceof String) {
+if (cs instanceof String) {
+return ((String) cs).indexOf((String) searchChar, start);
+} else if (cs instanceof StringBuilder) {
+return ((StringBuilder) cs).indexOf((String) searchChar,
start);
+} else if (cs instanceof StringBuffer) {
+return ((StringBuffer) cs).indexOf((String) searchChar, start);
+}
+}
+
+int len1 = cs.length();
+int len2 = searchChar.length();
+
+// successful-result >= 0
+if (start < 0) {
+start = 0;
+}
Review comment:
> If `len1` is negative and if `len2` is zero then your return value
will be whatever `len1` was, which is an incorrect result when it is not `-1`.
@aherbert
you are correct.
this is a bug.
will fix it.
thanks.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (IO-732) Char equivalent of UnsynchronizedByteArrayOutputStream (and InputStream)
[ https://issues.apache.org/jira/browse/IO-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17347698#comment-17347698 ] PJ Fanning commented on IO-732: --- created [https://github.com/apache/commons-io/pull/235] as a draft > Char equivalent of UnsynchronizedByteArrayOutputStream (and InputStream) > > > Key: IO-732 > URL: https://issues.apache.org/jira/browse/IO-732 > Project: Commons IO > Issue Type: New Feature > Components: Streams/Writers >Affects Versions: 2.8.0 >Reporter: PJ Fanning >Priority: Major > > I was thinking of writing this and submitting it but just want to see if > people think it makes sense first. > The idea is to take AbstractByteArrayOutputStream and to replace the byte[] > with char[] (maybe called AbstractCharArrayWriter) and to create an > UnsynchronizedCharArrayWriter that extends it. Could so something similar > with UnsynchronizedByteArrayInputStream - to get an > UnsynchronizedStringReader. > The nice thing about AbstractByteArrayOutputStream is the way it avoids > arraycopy. The existing commons-io StringBuilderWriter still has arraycopy > under the hood (in the java.lang.StringBuilder). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-io] pjfanning opened a new pull request #235: CharArrayWriter
pjfanning opened a new pull request #235: URL: https://github.com/apache/commons-io/pull/235 A draft implementation of https://issues.apache.org/jira/browse/IO-732. * needs more tests * needs better javadoc -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (IO-732) Char equivalent of UnsynchronizedByteArrayOutputStream (and InputStream)
[ https://issues.apache.org/jira/browse/IO-732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] PJ Fanning updated IO-732: -- Description: I was thinking of writing this and submitting it but just want to see if people think it makes sense first. The idea is to take AbstractByteArrayOutputStream and to replace the byte[] with char[] (maybe called AbstractCharArrayWriter) and to create an UnsynchronizedCharArrayWriter that extends it. Could so something similar with UnsynchronizedByteArrayInputStream - to get an UnsynchronizedStringReader. The nice thing about AbstractByteArrayOutputStream is the way it avoids arraycopy. The existing commons-io StringBuilderWriter still has arraycopy under the hood (in the java.lang.StringBuilder). was: I was thinking of writing this and submitting it but just want to see if people think it makes sense first. The idea is to take AbstractByteArrayOutputStream and to replace the byte[] with char[] (maybe called AbstractStringWriter) and to create an UnsynchronizedStringWriter that extends it. Could so something similar with UnsynchronizedByteArrayInputStream - to get an UnsynchronizedStringReader. The nice thing about AbstractByteArrayOutputStream is the way it avoids arraycopy. The existing commons-io StringBuilderWriter still has arraycopy under the hood (in the java.lang.StringBuilder). > Char equivalent of UnsynchronizedByteArrayOutputStream (and InputStream) > > > Key: IO-732 > URL: https://issues.apache.org/jira/browse/IO-732 > Project: Commons IO > Issue Type: New Feature > Components: Streams/Writers >Affects Versions: 2.8.0 >Reporter: PJ Fanning >Priority: Major > > I was thinking of writing this and submitting it but just want to see if > people think it makes sense first. > The idea is to take AbstractByteArrayOutputStream and to replace the byte[] > with char[] (maybe called AbstractCharArrayWriter) and to create an > UnsynchronizedCharArrayWriter that extends it. Could so something similar > with UnsynchronizedByteArrayInputStream - to get an > UnsynchronizedStringReader. > The nice thing about AbstractByteArrayOutputStream is the way it avoids > arraycopy. The existing commons-io StringBuilderWriter still has arraycopy > under the hood (in the java.lang.StringBuilder). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (IO-726) Add MemoryMappedInputStream
[
https://issues.apache.org/jira/browse/IO-726?focusedWorklogId=599246=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-599246
]
ASF GitHub Bot logged work on IO-726:
-
Author: ASF GitHub Bot
Created on: 19/May/21 13:50
Start Date: 19/May/21 13:50
Worklog Time Spent: 10m
Work Description: coveralls edited a comment on pull request #215:
URL: https://github.com/apache/commons-io/pull/215#issuecomment-805093521
[](https://coveralls.io/builds/39819390)
Coverage decreased (-0.09%) to 89.286% when pulling
**c3e7bb06024303f3398d8e75bf2d371974660c75 on shollander:mmap_inputStream**
into **e569d0f76924502007ba838dded7d5fdfcedd578 on apache:master**.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 599246)
Time Spent: 1h 50m (was: 1h 40m)
> Add MemoryMappedInputStream
> ---
>
> Key: IO-726
> URL: https://issues.apache.org/jira/browse/IO-726
> Project: Commons IO
> Issue Type: New Feature
> Components: Streams/Writers
>Affects Versions: 2.8.0
>Reporter: S Hollander
>Priority: Major
> Fix For: 2.9.0
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> A very useful tool for improving performance with disk-based IO is the use of
> memory mapped files. I propose an {{InputStream}} that provides a bridge
> between memory mapped files and the {{InputStream}} ecosystem.
> In my limited performance tests, the use of the MemoryMappedInputStream
> provided a 25% increase in throughput.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-io] coveralls edited a comment on pull request #215: IO-726 Add MemoryMappedInputStream.
coveralls edited a comment on pull request #215: URL: https://github.com/apache/commons-io/pull/215#issuecomment-805093521 [](https://coveralls.io/builds/39819390) Coverage decreased (-0.09%) to 89.286% when pulling **c3e7bb06024303f3398d8e75bf2d371974660c75 on shollander:mmap_inputStream** into **e569d0f76924502007ba838dded7d5fdfcedd578 on apache:master**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (IO-726) Add MemoryMappedInputStream
[
https://issues.apache.org/jira/browse/IO-726?focusedWorklogId=599216=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-599216
]
ASF GitHub Bot logged work on IO-726:
-
Author: ASF GitHub Bot
Created on: 19/May/21 13:17
Start Date: 19/May/21 13:17
Worklog Time Spent: 10m
Work Description: coveralls edited a comment on pull request #215:
URL: https://github.com/apache/commons-io/pull/215#issuecomment-805093521
[](https://coveralls.io/builds/39818300)
Coverage decreased (-0.3%) to 89.03% when pulling
**d64e9274a8affeb256248f5e1c9210519ee5a904 on shollander:mmap_inputStream**
into **e569d0f76924502007ba838dded7d5fdfcedd578 on apache:master**.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 599216)
Time Spent: 1h 40m (was: 1.5h)
> Add MemoryMappedInputStream
> ---
>
> Key: IO-726
> URL: https://issues.apache.org/jira/browse/IO-726
> Project: Commons IO
> Issue Type: New Feature
> Components: Streams/Writers
>Affects Versions: 2.8.0
>Reporter: S Hollander
>Priority: Major
> Fix For: 2.9.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> A very useful tool for improving performance with disk-based IO is the use of
> memory mapped files. I propose an {{InputStream}} that provides a bridge
> between memory mapped files and the {{InputStream}} ecosystem.
> In my limited performance tests, the use of the MemoryMappedInputStream
> provided a 25% increase in throughput.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-io] coveralls edited a comment on pull request #215: IO-726 Add MemoryMappedInputStream.
coveralls edited a comment on pull request #215: URL: https://github.com/apache/commons-io/pull/215#issuecomment-805093521 [](https://coveralls.io/builds/39818300) Coverage decreased (-0.3%) to 89.03% when pulling **d64e9274a8affeb256248f5e1c9210519ee5a904 on shollander:mmap_inputStream** into **e569d0f76924502007ba838dded7d5fdfcedd578 on apache:master**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (COMPRESS-565) Regression - Corrupted headers when using 64 bit ZipArchiveOutputStream
[
https://issues.apache.org/jira/browse/COMPRESS-565?focusedWorklogId=599048=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-599048
]
ASF GitHub Bot logged work on COMPRESS-565:
---
Author: ASF GitHub Bot
Created on: 19/May/21 07:37
Start Date: 19/May/21 07:37
Worklog Time Spent: 10m
Work Description: PeterAlfredLee merged pull request #169:
URL: https://github.com/apache/commons-compress/pull/169
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 599048)
Time Spent: 4.5h (was: 4h 20m)
> Regression - Corrupted headers when using 64 bit ZipArchiveOutputStream
> ---
>
> Key: COMPRESS-565
> URL: https://issues.apache.org/jira/browse/COMPRESS-565
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.20
>Reporter: Evgenii Bovykin
>Assignee: Peter Lee
>Priority: Major
> Fix For: 1.21
>
> Attachments: commons-compress-1.21-SNAPSHOT.jar,
> image-2021-02-20-15-51-21-747.png
>
> Time Spent: 4.5h
> Remaining Estimate: 0h
>
> We've recently updated commons-compress library from version 1.9 to 1.20 and
> now experiencing the problem that didn't occur before.
>
> When using ZipArchiveOutputStream to archive 5Gb file and setting the
> following fields
> {{output.setUseZip64(Zip64Mode.Always)}}
>
> {{output.setCreateUnicodeExtraFields(ZipArchiveOutputStream.UnicodeExtraFieldPolicy.ALWAYS)}}
> resulting archive contains corrupted headers.
> *Expand-Archive Powershell utility cannot extract the archive at all with the
> error about corrupted header. 7zip also complains about it, but can extract
> the archive.*
>
> The problem didn't appear when using library version 1.9.
>
> I've created a sample project that reproduces the error -
> [https://github.com/missingdays/commons-compress-example]
> Issue doesn't reproduce if you do any of the following:
>
> # Downgrade library to version 1.9
> # Remove
> output.setCreateUnicodeExtraFields(ZipArchiveOutputStream.UnicodeExtraFieldPolicy.ALWAYS)
> # Remove output.setUseZip64(Zip64Mode.Always) and zip smaller file (e.g. 1Gb)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-compress] PeterAlfredLee merged pull request #169: COMPRESS-565 : add a new AlwaysWithCompatibility in Zip64Mode
PeterAlfredLee merged pull request #169: URL: https://github.com/apache/commons-compress/pull/169 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (LANG-1661) Add methods to ClassUtils to get the class type names in a null-safe manner
[ https://issues.apache.org/jira/browse/LANG-1661?focusedWorklogId=599037=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-599037 ] ASF GitHub Bot logged work on LANG-1661: Author: ASF GitHub Bot Created on: 19/May/21 06:53 Start Date: 19/May/21 06:53 Worklog Time Spent: 10m Work Description: coveralls edited a comment on pull request #762: URL: https://github.com/apache/commons-lang/pull/762#issuecomment-843798931 [](https://coveralls.io/builds/39806247) Coverage increased (+0.001%) to 94.928% when pulling **825acec7f61c2ea690386728ce5304d623c5fc6c on arturobernalg:feature/LANG-1661** into **c893f5d3ae90d5060db044ee3d0c79f36aea9511 on apache:master**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 599037) Time Spent: 0.5h (was: 20m) > Add methods to ClassUtils to get the class type names in a null-safe manner > --- > > Key: LANG-1661 > URL: https://issues.apache.org/jira/browse/LANG-1661 > Project: Commons Lang > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > Add methods ClassUtils to get the class names type in a null-safe manner: > - getTypeName(Class) > - getTypeName(Object) > - getTypeName(Class, String) > - getTypeName(Object, String) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-lang] coveralls edited a comment on pull request #762: LANG-1661 - Add methods to ClassUtils to get the class type names in a null-safe manner
coveralls edited a comment on pull request #762: URL: https://github.com/apache/commons-lang/pull/762#issuecomment-843798931 [](https://coveralls.io/builds/39806247) Coverage increased (+0.001%) to 94.928% when pulling **825acec7f61c2ea690386728ce5304d623c5fc6c on arturobernalg:feature/LANG-1661** into **c893f5d3ae90d5060db044ee3d0c79f36aea9511 on apache:master**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (LANG-1661) Add methods to ClassUtils to get the class type names in a null-safe manner
[ https://issues.apache.org/jira/browse/LANG-1661?focusedWorklogId=599036=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-599036 ] ASF GitHub Bot logged work on LANG-1661: Author: ASF GitHub Bot Created on: 19/May/21 06:52 Start Date: 19/May/21 06:52 Worklog Time Spent: 10m Work Description: coveralls commented on pull request #762: URL: https://github.com/apache/commons-lang/pull/762#issuecomment-843798931 [](https://coveralls.io/builds/39806202) Coverage increased (+0.001%) to 94.928% when pulling **825acec7f61c2ea690386728ce5304d623c5fc6c on arturobernalg:feature/LANG-1661** into **c893f5d3ae90d5060db044ee3d0c79f36aea9511 on apache:master**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 599036) Time Spent: 20m (was: 10m) > Add methods to ClassUtils to get the class type names in a null-safe manner > --- > > Key: LANG-1661 > URL: https://issues.apache.org/jira/browse/LANG-1661 > Project: Commons Lang > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Add methods ClassUtils to get the class names type in a null-safe manner: > - getTypeName(Class) > - getTypeName(Object) > - getTypeName(Class, String) > - getTypeName(Object, String) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-lang] coveralls commented on pull request #762: LANG-1661 - Add methods to ClassUtils to get the class type names in a null-safe manner
coveralls commented on pull request #762: URL: https://github.com/apache/commons-lang/pull/762#issuecomment-843798931 [](https://coveralls.io/builds/39806202) Coverage increased (+0.001%) to 94.928% when pulling **825acec7f61c2ea690386728ce5304d623c5fc6c on arturobernalg:feature/LANG-1661** into **c893f5d3ae90d5060db044ee3d0c79f36aea9511 on apache:master**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (LANG-1661) Add methods to ClassUtils to get the class type names in a null-safe manner
[ https://issues.apache.org/jira/browse/LANG-1661?focusedWorklogId=599029=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-599029 ] ASF GitHub Bot logged work on LANG-1661: Author: ASF GitHub Bot Created on: 19/May/21 06:43 Start Date: 19/May/21 06:43 Worklog Time Spent: 10m Work Description: arturobernalg opened a new pull request #762: URL: https://github.com/apache/commons-lang/pull/762 Add methods ClassUtils to get the class names type in a null-safe manner: - getTypeName(Class) - getTypeName(Object) - getTypeName(Class, String) - getTypeName(Object, String) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 599029) Remaining Estimate: 0h Time Spent: 10m > Add methods to ClassUtils to get the class type names in a null-safe manner > --- > > Key: LANG-1661 > URL: https://issues.apache.org/jira/browse/LANG-1661 > Project: Commons Lang > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Add methods ClassUtils to get the class names type in a null-safe manner: > - getTypeName(Class) > - getTypeName(Object) > - getTypeName(Class, String) > - getTypeName(Object, String) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-lang] arturobernalg opened a new pull request #762: LANG-1661 - Add methods to ClassUtils to get the class type names in a null-safe manner
arturobernalg opened a new pull request #762: URL: https://github.com/apache/commons-lang/pull/762 Add methods ClassUtils to get the class names type in a null-safe manner: - getTypeName(Class) - getTypeName(Object) - getTypeName(Class, String) - getTypeName(Object, String) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (LANG-1661) Add methods to ClassUtils to get the class type names in a null-safe manner
Arturo Bernal created LANG-1661: --- Summary: Add methods to ClassUtils to get the class type names in a null-safe manner Key: LANG-1661 URL: https://issues.apache.org/jira/browse/LANG-1661 Project: Commons Lang Issue Type: Improvement Reporter: Arturo Bernal Add methods ClassUtils to get the class names type in a null-safe manner: - getTypeName(Class) - getTypeName(Object) - getTypeName(Class, String) - getTypeName(Object, String) -- This message was sent by Atlassian Jira (v8.3.4#803005)
