[jira] [Work logged] (IO-756) Update FileWriterWithEncoding to extend ProxyWriter
[ https://issues.apache.org/jira/browse/IO-756?focusedWorklogId=676875&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-676875 ] ASF GitHub Bot logged work on IO-756: - Author: ASF GitHub Bot Created on: 05/Nov/21 04:15 Start Date: 05/Nov/21 04:15 Worklog Time Spent: 10m Work Description: wodencafe commented on pull request #296: URL: https://github.com/apache/commons-io/pull/296#issuecomment-961615200 @kinow The commits have been squashed and and updated as per your request. Thank you for the help! -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 676875) Time Spent: 2h (was: 1h 50m) > Update FileWriterWithEncoding to extend ProxyWriter > --- > > Key: IO-756 > URL: https://issues.apache.org/jira/browse/IO-756 > Project: Commons IO > Issue Type: Improvement > Components: Streams/Writers >Affects Versions: 2.11.0 >Reporter: Woden Cafe >Priority: Minor > Labels: Commons, io > Fix For: 2.12.0 > > Time Spent: 2h > Remaining Estimate: 0h > > This change is to make org.apache.commons.io.output.FileWriterWithEncoding > extend org.apache.commons.io.output.ProxyWriter, to use the ProxyWriter's > delegate Writer rather than storing the delegate Writer reference within > FileWriterWithEncoding explicitly. > This simplifies FileWriterWithEncoding as it no longer needs to override any > methods from its super class, and no longer needs to store and maintain a > reference to a delegate Writer explicitly - this is provided by the super > class already. > [~kinow] Here is the ticket for the Pull Request. > https://github.com/apache/commons-io/pull/296 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-io] wodencafe commented on pull request #296: IO-756: Update FileWriterWithEncoding to extend ProxyWriter
wodencafe commented on pull request #296: URL: https://github.com/apache/commons-io/pull/296#issuecomment-961615200 @kinow The commits have been squashed and and updated as per your request. Thank you for the help! -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (IO-756) Update FileWriterWithEncoding to extend ProxyWriter
[
https://issues.apache.org/jira/browse/IO-756?focusedWorklogId=676874&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-676874
]
ASF GitHub Bot logged work on IO-756:
-
Author: ASF GitHub Bot
Created on: 05/Nov/21 04:14
Start Date: 05/Nov/21 04:14
Worklog Time Spent: 10m
Work Description: wodencafe commented on a change in pull request #296:
URL: https://github.com/apache/commons-io/pull/296#discussion_r743379795
##
File path:
src/main/java/org/apache/commons/io/output/FileWriterWithEncoding.java
##
@@ -59,7 +57,7 @@
* @return the initialized writer
* @throws IOException if an error occurs
*/
-private static Writer initWriter(final File file, final Object encoding,
final boolean append) throws IOException {
+private static final Writer initWriter(final File file, final Object
encoding, final boolean append) throws IOException {
Review comment:
I usually do this out of habit, but after doing some research it seems
that there is no functional difference for adding the `final` modifier to a
private static nested class. It has been removed.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 676874)
Time Spent: 1h 50m (was: 1h 40m)
> Update FileWriterWithEncoding to extend ProxyWriter
> ---
>
> Key: IO-756
> URL: https://issues.apache.org/jira/browse/IO-756
> Project: Commons IO
> Issue Type: Improvement
> Components: Streams/Writers
>Affects Versions: 2.11.0
>Reporter: Woden Cafe
>Priority: Minor
> Labels: Commons, io
> Fix For: 2.12.0
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> This change is to make org.apache.commons.io.output.FileWriterWithEncoding
> extend org.apache.commons.io.output.ProxyWriter, to use the ProxyWriter's
> delegate Writer rather than storing the delegate Writer reference within
> FileWriterWithEncoding explicitly.
> This simplifies FileWriterWithEncoding as it no longer needs to override any
> methods from its super class, and no longer needs to store and maintain a
> reference to a delegate Writer explicitly - this is provided by the super
> class already.
> [~kinow] Here is the ticket for the Pull Request.
> https://github.com/apache/commons-io/pull/296
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-io] wodencafe commented on a change in pull request #296: IO-756: Update FileWriterWithEncoding to extend ProxyWriter
wodencafe commented on a change in pull request #296:
URL: https://github.com/apache/commons-io/pull/296#discussion_r743379795
##
File path:
src/main/java/org/apache/commons/io/output/FileWriterWithEncoding.java
##
@@ -59,7 +57,7 @@
* @return the initialized writer
* @throws IOException if an error occurs
*/
-private static Writer initWriter(final File file, final Object encoding,
final boolean append) throws IOException {
+private static final Writer initWriter(final File file, final Object
encoding, final boolean append) throws IOException {
Review comment:
I usually do this out of habit, but after doing some research it seems
that there is no functional difference for adding the `final` modifier to a
private static nested class. It has been removed.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Work logged] (IMAGING-159) There should be a Parameters class
[
https://issues.apache.org/jira/browse/IMAGING-159?focusedWorklogId=676756&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-676756
]
ASF GitHub Bot logged work on IMAGING-159:
--
Author: ASF GitHub Bot
Created on: 04/Nov/21 21:55
Start Date: 04/Nov/21 21:55
Worklog Time Spent: 10m
Work Description: kinow commented on pull request #116:
URL: https://github.com/apache/commons-imaging/pull/116#issuecomment-961461586
>I just had another thought on this: it strikes me that the main issue with
the generic ImagerParser format is how to deal
with format-agnostic code, mainly the utility methods in Imaging.
Exactly. Were it not for the `Imaging` public methods, we could use the
generics or any other design without much impact to users. But the current code
base uses `Imaging` as the main entry point for users in the API (unless users
want something more complicated, in which case they can use parsers directly.)
>In other words, how do users specify parameters when they don't even know
what the format is? The current approach is to have users pass in their own
parameters objects to these utility methods but this gets into the problem of
what happens when they pass the wrong parameters type.
:+1: you described the problem really well!
>What if we flipped this? Instead of having the users create the parameters
object, we have the parser create one and then have the user modify it as
needed in a callback. So, instead of this
Ah, it sounds like a good thing to try! I think this approach would apply
some inversion of control, or algebraic effects, and could help us solve the
current impasse.
>Thoughts?
I think it would need a few more changes to allow users to configure the
correct parameter type? The `Consumer` uses the base type,
so in this closure the user has only an instance of `ImagingParameters`, and
would have to cast to the correct type.
I used the last method in `Imaging.java` instead of `getIccProfileBytes`
(for convenience, to have the `main` method nearby in the IDE :grimacing: ):
```java
public static void writeImage(final BufferedImage src, final
OutputStream os,
final ImageFormat format, final Consumer
configurer) throws ImageWriteException,
IOException {
final List imageParsers =
ImageParser.getAllImageParsers();
ImageParser imageParser = null;
for (final ImageParser imageParser2 : imageParsers) {
if (imageParser2.canAcceptType(format)) {
imageParser = imageParser2;
break;
}
}
if (imageParser == null) {
throw new ImageWriteException("Unknown Format: " + format);
}
final ImagingParameters params = imageParser.getDefaultParameters();
configurer.accept(params);
imageParser.writeImage(src, os, params);
}
```
But the caller code still has issues with the parameter type, I think?
```java
public static void main(String[] args) throws Exception {
Imaging.writeImage(
(BufferedImage) null,
(OutputStream) null,
ImageFormats.TIFF,
(ImagingParameters p) -> { // if `TiffImagingParameters`:
Incompatible parameter types in lambda expression: expected ImagingParameters
but found TiffImagingParameters
// p is still ImagingParameters, not
TiffImagingParameters
p.setFileName("bla.tif");
});
}
```
Or would you re-write `writeImage` differently, @darkma773r ?
Thanks!
Bruno
--
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.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 676756)
Time Spent: 12h 50m (was: 12h 40m)
> There should be a Parameters class
> --
>
> Key: IMAGING-159
> URL: https://issues.apache.org/jira/browse/IMAGING-159
> Project: Commons Imaging
> Issue Type: Improvement
> Components: imaging.*
>Affects Versions: 1.0-alpha2
>Reporter: Benedikt Ritter
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Labels: github
> Fix For: 1.0-alpha3
>
> Time Spent: 12h 50m
> Remaining Estimate: 0h
>
> Currently options for image I/O are defined as Maps. The leads to the problem
> that our code has to validate parameter types when t
[GitHub] [commons-imaging] kinow commented on pull request #116: [IMAGING-159] Add ImagingParameters interface and BaseParameters (POJO)
kinow commented on pull request #116:
URL: https://github.com/apache/commons-imaging/pull/116#issuecomment-961461586
>I just had another thought on this: it strikes me that the main issue with
the generic ImagerParser format is how to deal
with format-agnostic code, mainly the utility methods in Imaging.
Exactly. Were it not for the `Imaging` public methods, we could use the
generics or any other design without much impact to users. But the current code
base uses `Imaging` as the main entry point for users in the API (unless users
want something more complicated, in which case they can use parsers directly.)
>In other words, how do users specify parameters when they don't even know
what the format is? The current approach is to have users pass in their own
parameters objects to these utility methods but this gets into the problem of
what happens when they pass the wrong parameters type.
:+1: you described the problem really well!
>What if we flipped this? Instead of having the users create the parameters
object, we have the parser create one and then have the user modify it as
needed in a callback. So, instead of this
Ah, it sounds like a good thing to try! I think this approach would apply
some inversion of control, or algebraic effects, and could help us solve the
current impasse.
>Thoughts?
I think it would need a few more changes to allow users to configure the
correct parameter type? The `Consumer` uses the base type,
so in this closure the user has only an instance of `ImagingParameters`, and
would have to cast to the correct type.
I used the last method in `Imaging.java` instead of `getIccProfileBytes`
(for convenience, to have the `main` method nearby in the IDE :grimacing: ):
```java
public static void writeImage(final BufferedImage src, final
OutputStream os,
final ImageFormat format, final Consumer
configurer) throws ImageWriteException,
IOException {
final List imageParsers =
ImageParser.getAllImageParsers();
ImageParser imageParser = null;
for (final ImageParser imageParser2 : imageParsers) {
if (imageParser2.canAcceptType(format)) {
imageParser = imageParser2;
break;
}
}
if (imageParser == null) {
throw new ImageWriteException("Unknown Format: " + format);
}
final ImagingParameters params = imageParser.getDefaultParameters();
configurer.accept(params);
imageParser.writeImage(src, os, params);
}
```
But the caller code still has issues with the parameter type, I think?
```java
public static void main(String[] args) throws Exception {
Imaging.writeImage(
(BufferedImage) null,
(OutputStream) null,
ImageFormats.TIFF,
(ImagingParameters p) -> { // if `TiffImagingParameters`:
Incompatible parameter types in lambda expression: expected ImagingParameters
but found TiffImagingParameters
// p is still ImagingParameters, not
TiffImagingParameters
p.setFileName("bla.tif");
});
}
```
Or would you re-write `writeImage` differently, @darkma773r ?
Thanks!
Bruno
--
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.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Work logged] (TEXT-211) TextStringBuilder equals method changed behaviour from 1.8 to 1.9
[
https://issues.apache.org/jira/browse/TEXT-211?focusedWorklogId=676749&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-676749
]
ASF GitHub Bot logged work on TEXT-211:
---
Author: ASF GitHub Bot
Created on: 04/Nov/21 21:35
Start Date: 04/Nov/21 21:35
Worklog Time Spent: 10m
Work Description: kinow commented on a change in pull request #281:
URL: https://github.com/apache/commons-text/pull/281#discussion_r743219933
##
File path: src/main/java/org/apache/commons/text/TextStringBuilder.java
##
@@ -1850,7 +1850,14 @@ public boolean equals(final Object obj) {
* @return true if the builders contain the same characters in the same
order
*/
public boolean equals(final TextStringBuilder other) {
-return other != null && Arrays.equals(buffer, other.buffer);
+
+if(other == null) {
+return false;
+}
+if (this.size != other.size) {
+return false;
+}
+return this.toString().equals(other.toString());
Review comment:
@sebx59 your change makes the code look very similar to the code prior
to the change that added `Arrays.equals` (which I also wouldn't have guessed to
cause a regression here).
Maybe we could just revert it instead?
https://github.com/apache/commons-text/commit/36af8b1884a3ac7bf323a08a7d62e4a290336d2b
And also add a comment in the code so we don't accidentally add the
regression again in the code. WDYT?
##
File path: src/test/java/org/apache/commons/text/TextStringBuilderTest.java
##
@@ -1057,15 +1057,24 @@ public void testHashCode() {
final TextStringBuilder sb = new TextStringBuilder();
final int hc1a = sb.hashCode();
final int hc1b = sb.hashCode();
-final int emptyHc = Arrays.hashCode(sb.getBuffer());
-assertEquals(emptyHc, hc1a);
Review comment:
@sebx59 maybe instead of removing the asserts (this :point_up: and
:point_down: ) we could invert them then, if the behavior has changed?
--
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.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 676749)
Time Spent: 3h 50m (was: 3h 40m)
> TextStringBuilder equals method changed behaviour from 1.8 to 1.9
> -
>
> Key: TEXT-211
> URL: https://issues.apache.org/jira/browse/TEXT-211
> Project: Commons Text
> Issue Type: Bug
>Affects Versions: 1.9
>Reporter: Nikolaos Georgiou
>Priority: Major
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> We found a regression (or breaking compatibility change) in the
> TextStringBuilder equals method when upgrading commons-text from 1.8 to 1.9
>
> The 1.8 version (
> [https://github.com/apache/commons-text/blob/commons-text-1.8/src/main/java/org/apache/commons/text/TextStringBuilder.java#L2915]
> ) would only compare the parts of the buffer that fall within the range
> 0..size.
> The 1.9 version (
> [https://github.com/apache/commons-text/blob/rel/commons-text-1.9/src/main/java/org/apache/commons/text/TextStringBuilder.java#L1855]
> ) compares the entire buffer arrays.
> If a TextStringBuilder has extra capacity in the buffer, comparison fails.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-text] kinow commented on a change in pull request #281: TEXT-211 - TextStringBuilder.equals whatever the capacity is
kinow commented on a change in pull request #281:
URL: https://github.com/apache/commons-text/pull/281#discussion_r743219933
##
File path: src/main/java/org/apache/commons/text/TextStringBuilder.java
##
@@ -1850,7 +1850,14 @@ public boolean equals(final Object obj) {
* @return true if the builders contain the same characters in the same
order
*/
public boolean equals(final TextStringBuilder other) {
-return other != null && Arrays.equals(buffer, other.buffer);
+
+if(other == null) {
+return false;
+}
+if (this.size != other.size) {
+return false;
+}
+return this.toString().equals(other.toString());
Review comment:
@sebx59 your change makes the code look very similar to the code prior
to the change that added `Arrays.equals` (which I also wouldn't have guessed to
cause a regression here).
Maybe we could just revert it instead?
https://github.com/apache/commons-text/commit/36af8b1884a3ac7bf323a08a7d62e4a290336d2b
And also add a comment in the code so we don't accidentally add the
regression again in the code. WDYT?
##
File path: src/test/java/org/apache/commons/text/TextStringBuilderTest.java
##
@@ -1057,15 +1057,24 @@ public void testHashCode() {
final TextStringBuilder sb = new TextStringBuilder();
final int hc1a = sb.hashCode();
final int hc1b = sb.hashCode();
-final int emptyHc = Arrays.hashCode(sb.getBuffer());
-assertEquals(emptyHc, hc1a);
Review comment:
@sebx59 maybe instead of removing the asserts (this :point_up: and
:point_down: ) we could invert them then, if the behavior has changed?
--
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.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Updated] (COLLECTIONS-800) Provide a ListUtils.partitionBalanced(List, int) method where returned sublists are "balanced"
[ https://issues.apache.org/jira/browse/COLLECTIONS-800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claudio updated COLLECTIONS-800: Description: [https://github.com/apache/commons-collections/pull/265] The new method re-uses some of the logic of the existing ListUtils.partition(List, int). The difference with that method is that the returned sublists are "balanced" so that they all have the same amount of elements (with a maximum of 1 element difference). Some examples: A list of 10 elements, partition 10: * partition() and partitionBalanced() both return a single sublist with 10 elements A list of 11 elements, partition 10: * partition() returns a sublist of 10 and another sublist of 1 element * partitionBalanced() method returns a sublist of 6 and another sublist of 5 elements A list of 14 elements, partition 10: * partition() returns a sublist of 10 and another sublist of 4 elements * partitionBalanced() method returns two sublists of 7 elements each A list of 20 elements, partition 10: * partition() and partitionBalanced() both return two sublists of 10 elements was: The new method re-uses some of the logic of the existing ListUtils.partition(List, int). The difference with that method is that the returned sublists are "balanced" so that they all have the same amount of elements (with a maximum of 1 element difference). Some examples: A list of 10 elements, partition 10: * partition() and partitionBalanced() both return a single sublist with 10 elements A list of 11 elements, partition 10: * partition() returns a sublist of 10 and another sublist of 1 element * partitionBalanced() method returns a sublist of 6 and another sublist of 5 elements A list of 14 elements, partition 10: * partition() returns a sublist of 10 and another sublist of 4 elements * partitionBalanced() method returns two sublists of 7 elements each A list of 20 elements, partition 10: * partition() and partitionBalanced() both return two sublists of 10 elements If we are ok to add this feature, I have a working implementation with tests and I'm happy to create a PR on Github. > Provide a ListUtils.partitionBalanced(List, int) method where returned > sublists are "balanced" > -- > > Key: COLLECTIONS-800 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-800 > Project: Commons Collections > Issue Type: New Feature > Components: List >Reporter: Claudio >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > [https://github.com/apache/commons-collections/pull/265] > The new method re-uses some of the logic of the existing > ListUtils.partition(List, int). The difference with that method is that the > returned sublists are "balanced" so that they all have the same amount of > elements (with a maximum of 1 element difference). Some examples: > A list of 10 elements, partition 10: > * partition() and partitionBalanced() both return a single sublist with 10 > elements > A list of 11 elements, partition 10: > * partition() returns a sublist of 10 and another sublist of 1 element > * partitionBalanced() method returns a sublist of 6 and another sublist of 5 > elements > A list of 14 elements, partition 10: > * partition() returns a sublist of 10 and another sublist of 4 elements > * partitionBalanced() method returns two sublists of 7 elements each > A list of 20 elements, partition 10: > * partition() and partitionBalanced() both return two sublists of 10 elements > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-collections] ClaudioConsolmagno opened a new pull request #265: [COLLECTIONS-800] Adding partitionBalanced(List,int) method
ClaudioConsolmagno opened a new pull request #265: URL: https://github.com/apache/commons-collections/pull/265 See [COLLECTIONS-800](https://issues.apache.org/jira/projects/COLLECTIONS/issues/COLLECTIONS-800) Implementation Notes: - Given that the `Partition` class is a private static class not used by anything else I think it's ok to just use isBalanced as a boolean instead of, say, an enum or having a separate brand new private class for this new method. - Added several comments to clarify the logic, let me know if you think that's too much. - I didn't know how far I could go when refactoring existing tests so I only half changed them for `partition()` method. - Similarly, existing tests all around seem fairly simple but I thought I should have good coverage and test different scenarios for partitionBalanced() hence added the whole `forEach` test cases (I'm a fan of Spock and data driven testing). -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (COLLECTIONS-800) Provide a ListUtils.partitionBalanced(List, int) method where returned sublists are "balanced"
[ https://issues.apache.org/jira/browse/COLLECTIONS-800?focusedWorklogId=676747&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-676747 ] ASF GitHub Bot logged work on COLLECTIONS-800: -- Author: ASF GitHub Bot Created on: 04/Nov/21 21:30 Start Date: 04/Nov/21 21:30 Worklog Time Spent: 10m Work Description: ClaudioConsolmagno opened a new pull request #265: URL: https://github.com/apache/commons-collections/pull/265 See [COLLECTIONS-800](https://issues.apache.org/jira/projects/COLLECTIONS/issues/COLLECTIONS-800) Implementation Notes: - Given that the `Partition` class is a private static class not used by anything else I think it's ok to just use isBalanced as a boolean instead of, say, an enum or having a separate brand new private class for this new method. - Added several comments to clarify the logic, let me know if you think that's too much. - I didn't know how far I could go when refactoring existing tests so I only half changed them for `partition()` method. - Similarly, existing tests all around seem fairly simple but I thought I should have good coverage and test different scenarios for partitionBalanced() hence added the whole `forEach` test cases (I'm a fan of Spock and data driven testing). -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 676747) Remaining Estimate: 0h Time Spent: 10m > Provide a ListUtils.partitionBalanced(List, int) method where returned > sublists are "balanced" > -- > > Key: COLLECTIONS-800 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-800 > Project: Commons Collections > Issue Type: New Feature > Components: List >Reporter: Claudio >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > The new method re-uses some of the logic of the existing > ListUtils.partition(List, int). The difference with that method is that the > returned sublists are "balanced" so that they all have the same amount of > elements (with a maximum of 1 element difference). Some examples: > A list of 10 elements, partition 10: > * partition() and partitionBalanced() both return a single sublist with 10 > elements > A list of 11 elements, partition 10: > * partition() returns a sublist of 10 and another sublist of 1 element > * partitionBalanced() method returns a sublist of 6 and another sublist of 5 > elements > A list of 14 elements, partition 10: > * partition() returns a sublist of 10 and another sublist of 4 elements > * partitionBalanced() method returns two sublists of 7 elements each > A list of 20 elements, partition 10: > * partition() and partitionBalanced() both return two sublists of 10 elements > If we are ok to add this feature, I have a working implementation with tests > and I'm happy to create a PR on Github. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (IO-756) Update FileWriterWithEncoding to extend ProxyWriter
[
https://issues.apache.org/jira/browse/IO-756?focusedWorklogId=676738&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-676738
]
ASF GitHub Bot logged work on IO-756:
-
Author: ASF GitHub Bot
Created on: 04/Nov/21 21:13
Start Date: 04/Nov/21 21:13
Worklog Time Spent: 10m
Work Description: kinow commented on a change in pull request #296:
URL: https://github.com/apache/commons-io/pull/296#discussion_r743203274
##
File path:
src/main/java/org/apache/commons/io/output/FileWriterWithEncoding.java
##
@@ -59,7 +57,7 @@
* @return the initialized writer
* @throws IOException if an error occurs
*/
-private static Writer initWriter(final File file, final Object encoding,
final boolean append) throws IOException {
+private static final Writer initWriter(final File file, final Object
encoding, final boolean append) throws IOException {
Review comment:
This one is not really necessary @wodencafe ? `initWriter` is already
private, so making it `final` won't change much for internal/external devs?
--
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.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 676738)
Time Spent: 1h 40m (was: 1.5h)
> Update FileWriterWithEncoding to extend ProxyWriter
> ---
>
> Key: IO-756
> URL: https://issues.apache.org/jira/browse/IO-756
> Project: Commons IO
> Issue Type: Improvement
> Components: Streams/Writers
>Affects Versions: 2.11.0
>Reporter: Woden Cafe
>Priority: Minor
> Labels: Commons, io
> Fix For: 2.12.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> This change is to make org.apache.commons.io.output.FileWriterWithEncoding
> extend org.apache.commons.io.output.ProxyWriter, to use the ProxyWriter's
> delegate Writer rather than storing the delegate Writer reference within
> FileWriterWithEncoding explicitly.
> This simplifies FileWriterWithEncoding as it no longer needs to override any
> methods from its super class, and no longer needs to store and maintain a
> reference to a delegate Writer explicitly - this is provided by the super
> class already.
> [~kinow] Here is the ticket for the Pull Request.
> https://github.com/apache/commons-io/pull/296
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-io] kinow commented on a change in pull request #296: IO-756: Update FileWriterWithEncoding to extend ProxyWriter
kinow commented on a change in pull request #296:
URL: https://github.com/apache/commons-io/pull/296#discussion_r743203274
##
File path:
src/main/java/org/apache/commons/io/output/FileWriterWithEncoding.java
##
@@ -59,7 +57,7 @@
* @return the initialized writer
* @throws IOException if an error occurs
*/
-private static Writer initWriter(final File file, final Object encoding,
final boolean append) throws IOException {
+private static final Writer initWriter(final File file, final Object
encoding, final boolean append) throws IOException {
Review comment:
This one is not really necessary @wodencafe ? `initWriter` is already
private, so making it `final` won't change much for internal/external devs?
--
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.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Work logged] (IO-756) Update FileWriterWithEncoding to extend ProxyWriter
[ https://issues.apache.org/jira/browse/IO-756?focusedWorklogId=67&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-67 ] ASF GitHub Bot logged work on IO-756: - Author: ASF GitHub Bot Created on: 04/Nov/21 19:20 Start Date: 04/Nov/21 19:20 Worklog Time Spent: 10m Work Description: wodencafe commented on pull request #296: URL: https://github.com/apache/commons-io/pull/296#issuecomment-961346035 Thank you @garydgregory and @kinow for the assistance with this pull request. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 67) Time Spent: 1.5h (was: 1h 20m) > Update FileWriterWithEncoding to extend ProxyWriter > --- > > Key: IO-756 > URL: https://issues.apache.org/jira/browse/IO-756 > Project: Commons IO > Issue Type: Improvement > Components: Streams/Writers >Affects Versions: 2.11.0 >Reporter: Woden Cafe >Priority: Minor > Labels: Commons, io > Fix For: 2.12.0 > > Time Spent: 1.5h > Remaining Estimate: 0h > > This change is to make org.apache.commons.io.output.FileWriterWithEncoding > extend org.apache.commons.io.output.ProxyWriter, to use the ProxyWriter's > delegate Writer rather than storing the delegate Writer reference within > FileWriterWithEncoding explicitly. > This simplifies FileWriterWithEncoding as it no longer needs to override any > methods from its super class, and no longer needs to store and maintain a > reference to a delegate Writer explicitly - this is provided by the super > class already. > [~kinow] Here is the ticket for the Pull Request. > https://github.com/apache/commons-io/pull/296 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-io] wodencafe commented on pull request #296: IO-756: Update FileWriterWithEncoding to extend ProxyWriter
wodencafe commented on pull request #296: URL: https://github.com/apache/commons-io/pull/296#issuecomment-961346035 Thank you @garydgregory and @kinow for the assistance with this pull request. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (IO-756) Update FileWriterWithEncoding to extend ProxyWriter
[ https://issues.apache.org/jira/browse/IO-756?focusedWorklogId=676665&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-676665 ] ASF GitHub Bot logged work on IO-756: - Author: ASF GitHub Bot Created on: 04/Nov/21 19:19 Start Date: 04/Nov/21 19:19 Worklog Time Spent: 10m Work Description: data443-cboyd removed a comment on pull request #296: URL: https://github.com/apache/commons-io/pull/296#issuecomment-961249815 Thank you @garydgregory and @kinow for the assistance with this pull request. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 676665) Time Spent: 1h 20m (was: 1h 10m) > Update FileWriterWithEncoding to extend ProxyWriter > --- > > Key: IO-756 > URL: https://issues.apache.org/jira/browse/IO-756 > Project: Commons IO > Issue Type: Improvement > Components: Streams/Writers >Affects Versions: 2.11.0 >Reporter: Woden Cafe >Priority: Minor > Labels: Commons, io > Fix For: 2.12.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > This change is to make org.apache.commons.io.output.FileWriterWithEncoding > extend org.apache.commons.io.output.ProxyWriter, to use the ProxyWriter's > delegate Writer rather than storing the delegate Writer reference within > FileWriterWithEncoding explicitly. > This simplifies FileWriterWithEncoding as it no longer needs to override any > methods from its super class, and no longer needs to store and maintain a > reference to a delegate Writer explicitly - this is provided by the super > class already. > [~kinow] Here is the ticket for the Pull Request. > https://github.com/apache/commons-io/pull/296 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-io] data443-cboyd removed a comment on pull request #296: IO-756: Update FileWriterWithEncoding to extend ProxyWriter
data443-cboyd removed a comment on pull request #296: URL: https://github.com/apache/commons-io/pull/296#issuecomment-961249815 Thank you @garydgregory and @kinow for the assistance with this pull request. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-daemon] garydgregory commented on a change in pull request #32: DAEMON-336 - If lCallbacks is empty don't call the fnCallbacks to avoid an ACCESS_VIOLATION
garydgregory commented on a change in pull request #32:
URL: https://github.com/apache/commons-daemon/pull/32#discussion_r743135596
##
File path: src/native/windows/src/handles.c
##
@@ -496,13 +496,15 @@ apxCloseHandle(APXHANDLE hObject)
if (IS_INVALID_HANDLE(hObject) || hObject->dwType ==
APXHANDLE_TYPE_INVALID)
return FALSE;
-/* Call the user callback first */
-(*hObject->fnCallback)(hObject, WM_CLOSE, 0, 0);
-/* Now go through the callback chain */
-TAILQ_FOREACH(lpCall, &hObject->lCallbacks, queue) {
+if (!TAILQ_EMPTY(&hObject->lCallbacks)) {
+/* Call the user callback first */
+(*hObject->fnCallback)(hObject, WM_CLOSE, 0, 0);
Review comment:
@stevehof ping?
--
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.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [commons-daemon] garydgregory merged pull request #31: MInor Changes
garydgregory merged pull request #31: URL: https://github.com/apache/commons-daemon/pull/31 -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (IO-756) Update FileWriterWithEncoding to extend ProxyWriter
[ https://issues.apache.org/jira/browse/IO-756?focusedWorklogId=676582&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-676582 ] ASF GitHub Bot logged work on IO-756: - Author: ASF GitHub Bot Created on: 04/Nov/21 17:15 Start Date: 04/Nov/21 17:15 Worklog Time Spent: 10m Work Description: data443-cboyd commented on pull request #296: URL: https://github.com/apache/commons-io/pull/296#issuecomment-961249815 Thank you @garydgregory and @kinow for the assistance with this pull request. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 676582) Time Spent: 1h 10m (was: 1h) > Update FileWriterWithEncoding to extend ProxyWriter > --- > > Key: IO-756 > URL: https://issues.apache.org/jira/browse/IO-756 > Project: Commons IO > Issue Type: Improvement > Components: Streams/Writers >Affects Versions: 2.11.0 >Reporter: Woden Cafe >Priority: Minor > Labels: Commons, io > Fix For: 2.12.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > This change is to make org.apache.commons.io.output.FileWriterWithEncoding > extend org.apache.commons.io.output.ProxyWriter, to use the ProxyWriter's > delegate Writer rather than storing the delegate Writer reference within > FileWriterWithEncoding explicitly. > This simplifies FileWriterWithEncoding as it no longer needs to override any > methods from its super class, and no longer needs to store and maintain a > reference to a delegate Writer explicitly - this is provided by the super > class already. > [~kinow] Here is the ticket for the Pull Request. > https://github.com/apache/commons-io/pull/296 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-io] data443-cboyd commented on pull request #296: IO-756: Update FileWriterWithEncoding to extend ProxyWriter
data443-cboyd commented on pull request #296: URL: https://github.com/apache/commons-io/pull/296#issuecomment-961249815 Thank you @garydgregory and @kinow for the assistance with this pull request. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (IO-756) Update FileWriterWithEncoding to extend ProxyWriter
[ https://issues.apache.org/jira/browse/IO-756?focusedWorklogId=676579&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-676579 ] ASF GitHub Bot logged work on IO-756: - Author: ASF GitHub Bot Created on: 04/Nov/21 17:09 Start Date: 04/Nov/21 17:09 Worklog Time Spent: 10m Work Description: garydgregory commented on pull request #296: URL: https://github.com/apache/commons-io/pull/296#issuecomment-961244505 FYI: I should be able to review this over the weekend. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 676579) Time Spent: 1h (was: 50m) > Update FileWriterWithEncoding to extend ProxyWriter > --- > > Key: IO-756 > URL: https://issues.apache.org/jira/browse/IO-756 > Project: Commons IO > Issue Type: Improvement > Components: Streams/Writers >Affects Versions: 2.11.0 >Reporter: Woden Cafe >Priority: Minor > Labels: Commons, io > Fix For: 2.12.0 > > Time Spent: 1h > Remaining Estimate: 0h > > This change is to make org.apache.commons.io.output.FileWriterWithEncoding > extend org.apache.commons.io.output.ProxyWriter, to use the ProxyWriter's > delegate Writer rather than storing the delegate Writer reference within > FileWriterWithEncoding explicitly. > This simplifies FileWriterWithEncoding as it no longer needs to override any > methods from its super class, and no longer needs to store and maintain a > reference to a delegate Writer explicitly - this is provided by the super > class already. > [~kinow] Here is the ticket for the Pull Request. > https://github.com/apache/commons-io/pull/296 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-io] garydgregory commented on pull request #296: IO-756: Update FileWriterWithEncoding to extend ProxyWriter
garydgregory commented on pull request #296: URL: https://github.com/apache/commons-io/pull/296#issuecomment-961244505 FYI: I should be able to review this over the weekend. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-daemon] arturobernalg commented on pull request #31: MInor Changes
arturobernalg commented on pull request #31: URL: https://github.com/apache/commons-daemon/pull/31#issuecomment-961235790 > @arturobernalg May you please rebase on master? Done. TY -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (COMPRESS-595) IOUtils.readRange(ReadableByteChannel input, int len) reads more than len when input.read() returns < len (ie. rewind() makes no sense)
[
https://issues.apache.org/jira/browse/COMPRESS-595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17438767#comment-17438767
]
Gary D. Gregory commented on COMPRESS-595:
--
This would be easier to work with as a PR in GitHub ;-)
> IOUtils.readRange(ReadableByteChannel input, int len) reads more than len
> when input.read() returns < len (ie. rewind() makes no sense)
> ---
>
> Key: COMPRESS-595
> URL: https://issues.apache.org/jira/browse/COMPRESS-595
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.21
>Reporter: NP
>Priority: Major
> Attachments: IOUtilsTest.kt
>
>
> When `input.read(b)` returns `readNow` < `len`, then it means
> `input.read(b)` will need to be called again with the same
> buffer, whose `remaining()` is now the old `remaining()` - `readNow`.
> This way the ReadableByteChannel knows how many bytes are to be
> read in subsequent iterations of the `while (read < len)` loop.
> This is currently not the case, because there is a call to rewind()
> which results in a buffer whose remaining() is reset to `len` if
> `readNow` < `len`.
> I suspect the readRange() method has only been used with channels that never
> do partial reads (such as File Channels), and hence the problem has not been
> experienced until now.
> Here is a test case that exhibits the bug:
>
> ```kotlin
> import org.apache.commons.compress.utils.IOUtils
> import org.junit.jupiter.api.Assertions.assertArrayEquals
> import org.junit.jupiter.api.Assertions.assertEquals
> import org.junit.jupiter.api.Test
> import java.nio.ByteBuffer
> import java.nio.channels.ReadableByteChannel
> class IOUtilsTest {
> private class ReadableBytePerByteChannel: ReadableByteChannel {
> val data = byteArrayOf(0x03, 0x02, 0x01)
> val dataBuffer = ByteBuffer.wrap(data)!!
> override fun close(): Unit = TODO("Not needed")
> override fun isOpen(): Boolean = TODO("Not needed")
> override fun read(dst: ByteBuffer): Int {
> if (! dataBuffer.hasRemaining()) return -1
> val bytesAvailableForReading = dataBuffer.remaining()
> for (bytesReadSoFar in 1..bytesAvailableForReading) {
> val nextByte: Byte = dataBuffer.get()
> dst.put(nextByte)
> // first read() call reads 1 byte, less than requested(2)
> if (0x03.toByte() == nextByte) return bytesReadSoFar
> }
> return bytesAvailableForReading
> }
> }
> @Test
> fun readRangeShouldHandlePartialReads() {
> val channel = ReadableBytePerByteChannel()
> // should result in two calls to read()
> val actual = IOUtils.readRange(channel, 2)
> val expected = byteArrayOf(0x03, 0x02)
> assertArrayEquals(expected, actual)
> assertEquals(1, channel.dataBuffer.remaining())
> }
> }
> ```
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COMPRESS-595) IOUtils.readRange(ReadableByteChannel input, int len) reads more than len when input.read() returns < len (ie. rewind() makes no sense)
[
https://issues.apache.org/jira/browse/COMPRESS-595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17438698#comment-17438698
]
NP commented on COMPRESS-595:
-
Test case in Java syntax, closer to the other two test cases for readRange()
{code:java}
@Test
public void readRangeFromChannelHandlesPartialRead() throws IOException {
byte[] bytes = {1, 2, 3, 4, 5};
ByteBuffer byteBuffer = ByteBuffer.wrap(bytes);
try (ReadableByteChannel in = new ReadableByteChannel() {
@Override
public int read(ByteBuffer dst) throws IOException {
if (! byteBuffer.hasRemaining()) return -1;
int wanted = dst.remaining();
for (int bytesReadSoFar = 1; bytesReadSoFar <= wanted ;
bytesReadSoFar++) {
byte currentByte = byteBuffer.get();
dst.put(currentByte);
if (currentByte == 2) return bytesReadSoFar; // simulate
one partial read
}
return wanted;
}
@Override
public boolean isOpen() {
throw new UnsupportedOperationException("not called");
}
@Override
public void close() throws IOException {
throw new UnsupportedOperationException("not called");
}
}) {
byte[] read = IOUtils.readRange(in, 3);
Assert.assertEquals(2, byteBuffer.remaining());
Assert.assertArrayEquals(new byte[] { 1, 2, 3 }, read);
final ByteBuffer b = ByteBuffer.allocate(1);
Assert.assertEquals(1, in.read(b));
Assert.assertEquals(1, byteBuffer.remaining());
Assert.assertArrayEquals(new byte[] { 4 }, b.array());
}
}
{code}
> IOUtils.readRange(ReadableByteChannel input, int len) reads more than len
> when input.read() returns < len (ie. rewind() makes no sense)
> ---
>
> Key: COMPRESS-595
> URL: https://issues.apache.org/jira/browse/COMPRESS-595
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.21
>Reporter: NP
>Priority: Major
> Attachments: IOUtilsTest.kt
>
>
> When `input.read(b)` returns `readNow` < `len`, then it means
> `input.read(b)` will need to be called again with the same
> buffer, whose `remaining()` is now the old `remaining()` - `readNow`.
> This way the ReadableByteChannel knows how many bytes are to be
> read in subsequent iterations of the `while (read < len)` loop.
> This is currently not the case, because there is a call to rewind()
> which results in a buffer whose remaining() is reset to `len` if
> `readNow` < `len`.
> I suspect the readRange() method has only been used with channels that never
> do partial reads (such as File Channels), and hence the problem has not been
> experienced until now.
> Here is a test case that exhibits the bug:
>
> ```kotlin
> import org.apache.commons.compress.utils.IOUtils
> import org.junit.jupiter.api.Assertions.assertArrayEquals
> import org.junit.jupiter.api.Assertions.assertEquals
> import org.junit.jupiter.api.Test
> import java.nio.ByteBuffer
> import java.nio.channels.ReadableByteChannel
> class IOUtilsTest {
> private class ReadableBytePerByteChannel: ReadableByteChannel {
> val data = byteArrayOf(0x03, 0x02, 0x01)
> val dataBuffer = ByteBuffer.wrap(data)!!
> override fun close(): Unit = TODO("Not needed")
> override fun isOpen(): Boolean = TODO("Not needed")
> override fun read(dst: ByteBuffer): Int {
> if (! dataBuffer.hasRemaining()) return -1
> val bytesAvailableForReading = dataBuffer.remaining()
> for (bytesReadSoFar in 1..bytesAvailableForReading) {
> val nextByte: Byte = dataBuffer.get()
> dst.put(nextByte)
> // first read() call reads 1 byte, less than requested(2)
> if (0x03.toByte() == nextByte) return bytesReadSoFar
> }
> return bytesAvailableForReading
> }
> }
> @Test
> fun readRangeShouldHandlePartialReads() {
> val channel = ReadableBytePerByteChannel()
> // should result in two calls to read()
> val actual = IOUtils.readRange(channel, 2)
> val expected = byteArrayOf(0x03, 0x02)
> assertArrayEquals(expected, actual)
> assertEquals(1, channel.dataBuffer.remaining())
> }
> }
> ```
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-daemon] garydgregory commented on pull request #31: MInor Changes:
garydgregory commented on pull request #31: URL: https://github.com/apache/commons-daemon/pull/31#issuecomment-960821130 @arturobernalg May you please rebase on 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-daemon] garydgregory merged pull request #34: Bump actions/checkout from 2.3.4 to 2.4.0
garydgregory merged pull request #34: URL: https://github.com/apache/commons-daemon/pull/34 -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (COMPRESS-595) IOUtils.readRange(ReadableByteChannel input, int len) reads more than len when input.read() returns < len (ie. rewind() makes no sense)
[
https://issues.apache.org/jira/browse/COMPRESS-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
NP updated COMPRESS-595:
Summary: IOUtils.readRange(ReadableByteChannel input, int len) reads more
than len when input.read() returns < len (ie. rewind() makes no sense) (was:
IOUtils.readRange() reads more than len when input.read() returns < len (ie.
rewind() makes no sense))
> IOUtils.readRange(ReadableByteChannel input, int len) reads more than len
> when input.read() returns < len (ie. rewind() makes no sense)
> ---
>
> Key: COMPRESS-595
> URL: https://issues.apache.org/jira/browse/COMPRESS-595
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.21
>Reporter: NP
>Priority: Major
> Attachments: IOUtilsTest.kt
>
>
> When `input.read(b)` returns `readNow` < `len`, then it means
> `input.read(b)` will need to be called again with the same
> buffer, whose `remaining()` is now the old `remaining()` - `readNow`.
> This way the ReadableByteChannel knows how many bytes are to be
> read in subsequent iterations of the `while (read < len)` loop.
> This is currently not the case, because there is a call to rewind()
> which results in a buffer whose remaining() is reset to `len` if
> `readNow` < `len`.
> I suspect the readRange() method has only been used with channels that never
> do partial reads (such as File Channels), and hence the problem has not been
> experienced until now.
> Here is a test case that exhibits the bug:
>
> ```kotlin
> import org.apache.commons.compress.utils.IOUtils
> import org.junit.jupiter.api.Assertions.assertArrayEquals
> import org.junit.jupiter.api.Assertions.assertEquals
> import org.junit.jupiter.api.Test
> import java.nio.ByteBuffer
> import java.nio.channels.ReadableByteChannel
> class IOUtilsTest {
> private class ReadableBytePerByteChannel: ReadableByteChannel {
> val data = byteArrayOf(0x03, 0x02, 0x01)
> val dataBuffer = ByteBuffer.wrap(data)!!
> override fun close(): Unit = TODO("Not needed")
> override fun isOpen(): Boolean = TODO("Not needed")
> override fun read(dst: ByteBuffer): Int {
> if (! dataBuffer.hasRemaining()) return -1
> val bytesAvailableForReading = dataBuffer.remaining()
> for (bytesReadSoFar in 1..bytesAvailableForReading) {
> val nextByte: Byte = dataBuffer.get()
> dst.put(nextByte)
> // first read() call reads 1 byte, less than requested(2)
> if (0x03.toByte() == nextByte) return bytesReadSoFar
> }
> return bytesAvailableForReading
> }
> }
> @Test
> fun readRangeShouldHandlePartialReads() {
> val channel = ReadableBytePerByteChannel()
> // should result in two calls to read()
> val actual = IOUtils.readRange(channel, 2)
> val expected = byteArrayOf(0x03, 0x02)
> assertArrayEquals(expected, actual)
> assertEquals(1, channel.dataBuffer.remaining())
> }
> }
> ```
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (COMPRESS-595) IOUtils.readRange() reads more than len when input.read() returns < len (ie. rewind() makes no sense)
[
https://issues.apache.org/jira/browse/COMPRESS-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
NP updated COMPRESS-595:
Priority: Major (was: Minor)
> IOUtils.readRange() reads more than len when input.read() returns < len (ie.
> rewind() makes no sense)
> -
>
> Key: COMPRESS-595
> URL: https://issues.apache.org/jira/browse/COMPRESS-595
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.21
>Reporter: NP
>Priority: Major
> Attachments: IOUtilsTest.kt
>
>
> When `input.read(b)` returns `readNow` < `len`, then it means
> `input.read(b)` will need to be called again with the same
> buffer, whose `remaining()` is now the old `remaining()` - `readNow`.
> This way the ReadableByteChannel knows how many bytes are to be
> read in subsequent iterations of the `while (read < len)` loop.
> This is currently not the case, because there is a call to rewind()
> which results in a buffer whose remaining() is reset to `len` if
> `readNow` < `len`.
> I suspect the readRange() method has only been used with channels that never
> do partial reads (such as File Channels), and hence the problem has not been
> experienced until now.
> Here is a test case that exhibits the bug:
>
> ```kotlin
> import org.apache.commons.compress.utils.IOUtils
> import org.junit.jupiter.api.Assertions.assertArrayEquals
> import org.junit.jupiter.api.Assertions.assertEquals
> import org.junit.jupiter.api.Test
> import java.nio.ByteBuffer
> import java.nio.channels.ReadableByteChannel
> class IOUtilsTest {
> private class ReadableBytePerByteChannel: ReadableByteChannel {
> val data = byteArrayOf(0x03, 0x02, 0x01)
> val dataBuffer = ByteBuffer.wrap(data)!!
> override fun close(): Unit = TODO("Not needed")
> override fun isOpen(): Boolean = TODO("Not needed")
> override fun read(dst: ByteBuffer): Int {
> if (! dataBuffer.hasRemaining()) return -1
> val bytesAvailableForReading = dataBuffer.remaining()
> for (bytesReadSoFar in 1..bytesAvailableForReading) {
> val nextByte: Byte = dataBuffer.get()
> dst.put(nextByte)
> // first read() call reads 1 byte, less than requested(2)
> if (0x03.toByte() == nextByte) return bytesReadSoFar
> }
> return bytesAvailableForReading
> }
> }
> @Test
> fun readRangeShouldHandlePartialReads() {
> val channel = ReadableBytePerByteChannel()
> // should result in two calls to read()
> val actual = IOUtils.readRange(channel, 2)
> val expected = byteArrayOf(0x03, 0x02)
> assertArrayEquals(expected, actual)
> assertEquals(1, channel.dataBuffer.remaining())
> }
> }
> ```
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COMPRESS-595) IOUtils.readRange() reads more than len when input.read() returns < len (ie. rewind() makes no sense)
[
https://issues.apache.org/jira/browse/COMPRESS-595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17438615#comment-17438615
]
NP commented on COMPRESS-595:
-
adding attachment for the test, as the formatting looks weird.
> IOUtils.readRange() reads more than len when input.read() returns < len (ie.
> rewind() makes no sense)
> -
>
> Key: COMPRESS-595
> URL: https://issues.apache.org/jira/browse/COMPRESS-595
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.21
>Reporter: NP
>Priority: Minor
> Attachments: IOUtilsTest.kt
>
>
> When `input.read(b)` returns `readNow` < `len`, then it means
> `input.read(b)` will need to be called again with the same
> buffer, whose `remaining()` is now the old `remaining()` - `readNow`.
> This way the ReadableByteChannel knows how many bytes are to be
> read in subsequent iterations of the `while (read < len)` loop.
> This is currently not the case, because there is a call to rewind()
> which results in a buffer whose remaining() is reset to `len` if
> `readNow` < `len`.
> I suspect the readRange() method has only been used with channels that never
> do partial reads (such as File Channels), and hence the problem has not been
> experienced until now.
> Here is a test case that exhibits the bug:
>
> ```kotlin
> import org.apache.commons.compress.utils.IOUtils
> import org.junit.jupiter.api.Assertions.assertArrayEquals
> import org.junit.jupiter.api.Assertions.assertEquals
> import org.junit.jupiter.api.Test
> import java.nio.ByteBuffer
> import java.nio.channels.ReadableByteChannel
> class IOUtilsTest {
> private class ReadableBytePerByteChannel: ReadableByteChannel {
> val data = byteArrayOf(0x03, 0x02, 0x01)
> val dataBuffer = ByteBuffer.wrap(data)!!
> override fun close(): Unit = TODO("Not needed")
> override fun isOpen(): Boolean = TODO("Not needed")
> override fun read(dst: ByteBuffer): Int {
> if (! dataBuffer.hasRemaining()) return -1
> val bytesAvailableForReading = dataBuffer.remaining()
> for (bytesReadSoFar in 1..bytesAvailableForReading) {
> val nextByte: Byte = dataBuffer.get()
> dst.put(nextByte)
> // first read() call reads 1 byte, less than requested(2)
> if (0x03.toByte() == nextByte) return bytesReadSoFar
> }
> return bytesAvailableForReading
> }
> }
> @Test
> fun readRangeShouldHandlePartialReads() {
> val channel = ReadableBytePerByteChannel()
> // should result in two calls to read()
> val actual = IOUtils.readRange(channel, 2)
> val expected = byteArrayOf(0x03, 0x02)
> assertArrayEquals(expected, actual)
> assertEquals(1, channel.dataBuffer.remaining())
> }
> }
> ```
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (COMPRESS-595) IOUtils.readRange() reads more than len when input.read() returns < len (ie. rewind() makes no sense)
[
https://issues.apache.org/jira/browse/COMPRESS-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
NP updated COMPRESS-595:
Attachment: IOUtilsTest.kt
> IOUtils.readRange() reads more than len when input.read() returns < len (ie.
> rewind() makes no sense)
> -
>
> Key: COMPRESS-595
> URL: https://issues.apache.org/jira/browse/COMPRESS-595
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.21
>Reporter: NP
>Priority: Minor
> Attachments: IOUtilsTest.kt
>
>
> When `input.read(b)` returns `readNow` < `len`, then it means
> `input.read(b)` will need to be called again with the same
> buffer, whose `remaining()` is now the old `remaining()` - `readNow`.
> This way the ReadableByteChannel knows how many bytes are to be
> read in subsequent iterations of the `while (read < len)` loop.
> This is currently not the case, because there is a call to rewind()
> which results in a buffer whose remaining() is reset to `len` if
> `readNow` < `len`.
> I suspect the readRange() method has only been used with channels that never
> do partial reads (such as File Channels), and hence the problem has not been
> experienced until now.
> Here is a test case that exhibits the bug:
>
> ```kotlin
> import org.apache.commons.compress.utils.IOUtils
> import org.junit.jupiter.api.Assertions.assertArrayEquals
> import org.junit.jupiter.api.Assertions.assertEquals
> import org.junit.jupiter.api.Test
> import java.nio.ByteBuffer
> import java.nio.channels.ReadableByteChannel
> class IOUtilsTest {
> private class ReadableBytePerByteChannel: ReadableByteChannel {
> val data = byteArrayOf(0x03, 0x02, 0x01)
> val dataBuffer = ByteBuffer.wrap(data)!!
> override fun close(): Unit = TODO("Not needed")
> override fun isOpen(): Boolean = TODO("Not needed")
> override fun read(dst: ByteBuffer): Int {
> if (! dataBuffer.hasRemaining()) return -1
> val bytesAvailableForReading = dataBuffer.remaining()
> for (bytesReadSoFar in 1..bytesAvailableForReading) {
> val nextByte: Byte = dataBuffer.get()
> dst.put(nextByte)
> // first read() call reads 1 byte, less than requested(2)
> if (0x03.toByte() == nextByte) return bytesReadSoFar
> }
> return bytesAvailableForReading
> }
> }
> @Test
> fun readRangeShouldHandlePartialReads() {
> val channel = ReadableBytePerByteChannel()
> // should result in two calls to read()
> val actual = IOUtils.readRange(channel, 2)
> val expected = byteArrayOf(0x03, 0x02)
> assertArrayEquals(expected, actual)
> assertEquals(1, channel.dataBuffer.remaining())
> }
> }
> ```
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (COMPRESS-595) IOUtils.readRange() reads more than len when input.read() returns < len (ie. rewind() makes no sense)
[
https://issues.apache.org/jira/browse/COMPRESS-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
NP updated COMPRESS-595:
Attachment: (was: IOUtilsTest.kt)
> IOUtils.readRange() reads more than len when input.read() returns < len (ie.
> rewind() makes no sense)
> -
>
> Key: COMPRESS-595
> URL: https://issues.apache.org/jira/browse/COMPRESS-595
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.21
>Reporter: NP
>Priority: Minor
> Attachments: IOUtilsTest.kt
>
>
> When `input.read(b)` returns `readNow` < `len`, then it means
> `input.read(b)` will need to be called again with the same
> buffer, whose `remaining()` is now the old `remaining()` - `readNow`.
> This way the ReadableByteChannel knows how many bytes are to be
> read in subsequent iterations of the `while (read < len)` loop.
> This is currently not the case, because there is a call to rewind()
> which results in a buffer whose remaining() is reset to `len` if
> `readNow` < `len`.
> I suspect the readRange() method has only been used with channels that never
> do partial reads (such as File Channels), and hence the problem has not been
> experienced until now.
> Here is a test case that exhibits the bug:
>
> ```kotlin
> import org.apache.commons.compress.utils.IOUtils
> import org.junit.jupiter.api.Assertions.assertArrayEquals
> import org.junit.jupiter.api.Assertions.assertEquals
> import org.junit.jupiter.api.Test
> import java.nio.ByteBuffer
> import java.nio.channels.ReadableByteChannel
> class IOUtilsTest {
> private class ReadableBytePerByteChannel: ReadableByteChannel {
> val data = byteArrayOf(0x03, 0x02, 0x01)
> val dataBuffer = ByteBuffer.wrap(data)!!
> override fun close(): Unit = TODO("Not needed")
> override fun isOpen(): Boolean = TODO("Not needed")
> override fun read(dst: ByteBuffer): Int {
> if (! dataBuffer.hasRemaining()) return -1
> val bytesAvailableForReading = dataBuffer.remaining()
> for (bytesReadSoFar in 1..bytesAvailableForReading) {
> val nextByte: Byte = dataBuffer.get()
> dst.put(nextByte)
> // first read() call reads 1 byte, less than requested(2)
> if (0x03.toByte() == nextByte) return bytesReadSoFar
> }
> return bytesAvailableForReading
> }
> }
> @Test
> fun readRangeShouldHandlePartialReads() {
> val channel = ReadableBytePerByteChannel()
> // should result in two calls to read()
> val actual = IOUtils.readRange(channel, 2)
> val expected = byteArrayOf(0x03, 0x02)
> assertArrayEquals(expected, actual)
> assertEquals(1, channel.dataBuffer.remaining())
> }
> }
> ```
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (COMPRESS-595) IOUtils.readRange() reads more than len when input.read() returns < len (ie. rewind() makes no sense)
[
https://issues.apache.org/jira/browse/COMPRESS-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
NP updated COMPRESS-595:
Attachment: IOUtilsTest.kt
> IOUtils.readRange() reads more than len when input.read() returns < len (ie.
> rewind() makes no sense)
> -
>
> Key: COMPRESS-595
> URL: https://issues.apache.org/jira/browse/COMPRESS-595
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.21
>Reporter: NP
>Priority: Minor
> Attachments: IOUtilsTest.kt
>
>
> When `input.read(b)` returns `readNow` < `len`, then it means
> `input.read(b)` will need to be called again with the same
> buffer, whose `remaining()` is now the old `remaining()` - `readNow`.
> This way the ReadableByteChannel knows how many bytes are to be
> read in subsequent iterations of the `while (read < len)` loop.
> This is currently not the case, because there is a call to rewind()
> which results in a buffer whose remaining() is reset to `len` if
> `readNow` < `len`.
> I suspect the readRange() method has only been used with channels that never
> do partial reads (such as File Channels), and hence the problem has not been
> experienced until now.
> Here is a test case that exhibits the bug:
>
> ```kotlin
> import org.apache.commons.compress.utils.IOUtils
> import org.junit.jupiter.api.Assertions.assertArrayEquals
> import org.junit.jupiter.api.Assertions.assertEquals
> import org.junit.jupiter.api.Test
> import java.nio.ByteBuffer
> import java.nio.channels.ReadableByteChannel
> class IOUtilsTest {
> private class ReadableBytePerByteChannel: ReadableByteChannel {
> val data = byteArrayOf(0x03, 0x02, 0x01)
> val dataBuffer = ByteBuffer.wrap(data)!!
> override fun close(): Unit = TODO("Not needed")
> override fun isOpen(): Boolean = TODO("Not needed")
> override fun read(dst: ByteBuffer): Int {
> if (! dataBuffer.hasRemaining()) return -1
> val bytesAvailableForReading = dataBuffer.remaining()
> for (bytesReadSoFar in 1..bytesAvailableForReading) {
> val nextByte: Byte = dataBuffer.get()
> dst.put(nextByte)
> // first read() call reads 1 byte, less than requested(2)
> if (0x03.toByte() == nextByte) return bytesReadSoFar
> }
> return bytesAvailableForReading
> }
> }
> @Test
> fun readRangeShouldHandlePartialReads() {
> val channel = ReadableBytePerByteChannel()
> // should result in two calls to read()
> val actual = IOUtils.readRange(channel, 2)
> val expected = byteArrayOf(0x03, 0x02)
> assertArrayEquals(expected, actual)
> assertEquals(1, channel.dataBuffer.remaining())
> }
> }
> ```
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (COMPRESS-595) IOUtils.readRange() reads more than len when input.read() returns < len (ie. rewind() makes no sense)
NP created COMPRESS-595:
---
Summary: IOUtils.readRange() reads more than len when input.read()
returns < len (ie. rewind() makes no sense)
Key: COMPRESS-595
URL: https://issues.apache.org/jira/browse/COMPRESS-595
Project: Commons Compress
Issue Type: Bug
Affects Versions: 1.21
Reporter: NP
When `input.read(b)` returns `readNow` < `len`, then it means
`input.read(b)` will need to be called again with the same
buffer, whose `remaining()` is now the old `remaining()` - `readNow`.
This way the ReadableByteChannel knows how many bytes are to be
read in subsequent iterations of the `while (read < len)` loop.
This is currently not the case, because there is a call to rewind()
which results in a buffer whose remaining() is reset to `len` if
`readNow` < `len`.
I suspect the readRange() method has only been used with channels that never do
partial reads (such as File Channels), and hence the problem has not been
experienced until now.
Here is a test case that exhibits the bug:
```kotlin
import org.apache.commons.compress.utils.IOUtils
import org.junit.jupiter.api.Assertions.assertArrayEquals
import org.junit.jupiter.api.Assertions.assertEquals
import org.junit.jupiter.api.Test
import java.nio.ByteBuffer
import java.nio.channels.ReadableByteChannel
class IOUtilsTest {
private class ReadableBytePerByteChannel: ReadableByteChannel {
val data = byteArrayOf(0x03, 0x02, 0x01)
val dataBuffer = ByteBuffer.wrap(data)!!
override fun close(): Unit = TODO("Not needed")
override fun isOpen(): Boolean = TODO("Not needed")
override fun read(dst: ByteBuffer): Int {
if (! dataBuffer.hasRemaining()) return -1
val bytesAvailableForReading = dataBuffer.remaining()
for (bytesReadSoFar in 1..bytesAvailableForReading) {
val nextByte: Byte = dataBuffer.get()
dst.put(nextByte)
// first read() call reads 1 byte, less than requested(2)
if (0x03.toByte() == nextByte) return bytesReadSoFar
}
return bytesAvailableForReading
}
}
@Test
fun readRangeShouldHandlePartialReads() {
val channel = ReadableBytePerByteChannel()
// should result in two calls to read()
val actual = IOUtils.readRange(channel, 2)
val expected = byteArrayOf(0x03, 0x02)
assertArrayEquals(expected, actual)
assertEquals(1, channel.dataBuffer.remaining())
}
}
```
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (TEXT-211) TextStringBuilder equals method changed behaviour from 1.8 to 1.9
[
https://issues.apache.org/jira/browse/TEXT-211?focusedWorklogId=676252&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-676252
]
ASF GitHub Bot logged work on TEXT-211:
---
Author: ASF GitHub Bot
Created on: 04/Nov/21 08:19
Start Date: 04/Nov/21 08:19
Worklog Time Spent: 10m
Work Description: sebx59 commented on a change in pull request #281:
URL: https://github.com/apache/commons-text/pull/281#discussion_r742616356
##
File path: src/main/java/org/apache/commons/text/TextStringBuilder.java
##
@@ -1850,7 +1850,14 @@ public boolean equals(final Object obj) {
* @return true if the builders contain the same characters in the same
order
*/
public boolean equals(final TextStringBuilder other) {
-return other != null && Arrays.equals(buffer, other.buffer);
+
+ if(other == null) {
+ return false;
+ }
+ if (this.size != other.size) {
+return false;
+}
+return Arrays.equals(ArrayUtils.subarray(buffer, 0, size),
ArrayUtils.subarray(other.buffer, 0, size));
Review comment:
indeed, done in new commit
--
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.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 676252)
Time Spent: 3.5h (was: 3h 20m)
> TextStringBuilder equals method changed behaviour from 1.8 to 1.9
> -
>
> Key: TEXT-211
> URL: https://issues.apache.org/jira/browse/TEXT-211
> Project: Commons Text
> Issue Type: Bug
>Affects Versions: 1.9
>Reporter: Nikolaos Georgiou
>Priority: Major
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> We found a regression (or breaking compatibility change) in the
> TextStringBuilder equals method when upgrading commons-text from 1.8 to 1.9
>
> The 1.8 version (
> [https://github.com/apache/commons-text/blob/commons-text-1.8/src/main/java/org/apache/commons/text/TextStringBuilder.java#L2915]
> ) would only compare the parts of the buffer that fall within the range
> 0..size.
> The 1.9 version (
> [https://github.com/apache/commons-text/blob/rel/commons-text-1.9/src/main/java/org/apache/commons/text/TextStringBuilder.java#L1855]
> ) compares the entire buffer arrays.
> If a TextStringBuilder has extra capacity in the buffer, comparison fails.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (TEXT-211) TextStringBuilder equals method changed behaviour from 1.8 to 1.9
[
https://issues.apache.org/jira/browse/TEXT-211?focusedWorklogId=676253&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-676253
]
ASF GitHub Bot logged work on TEXT-211:
---
Author: ASF GitHub Bot
Created on: 04/Nov/21 08:19
Start Date: 04/Nov/21 08:19
Worklog Time Spent: 10m
Work Description: sebx59 commented on a change in pull request #281:
URL: https://github.com/apache/commons-text/pull/281#discussion_r742616420
##
File path: src/main/java/org/apache/commons/text/TextStringBuilder.java
##
@@ -1947,7 +1954,7 @@ public String getNullText() {
*/
@Override
public int hashCode() {
-return Arrays.hashCode(buffer);
+return Arrays.hashCode(ArrayUtils.subarray(buffer, 0, size));
Review comment:
indeed, done in new commit
--
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.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 676253)
Time Spent: 3h 40m (was: 3.5h)
> TextStringBuilder equals method changed behaviour from 1.8 to 1.9
> -
>
> Key: TEXT-211
> URL: https://issues.apache.org/jira/browse/TEXT-211
> Project: Commons Text
> Issue Type: Bug
>Affects Versions: 1.9
>Reporter: Nikolaos Georgiou
>Priority: Major
> Time Spent: 3h 40m
> Remaining Estimate: 0h
>
> We found a regression (or breaking compatibility change) in the
> TextStringBuilder equals method when upgrading commons-text from 1.8 to 1.9
>
> The 1.8 version (
> [https://github.com/apache/commons-text/blob/commons-text-1.8/src/main/java/org/apache/commons/text/TextStringBuilder.java#L2915]
> ) would only compare the parts of the buffer that fall within the range
> 0..size.
> The 1.9 version (
> [https://github.com/apache/commons-text/blob/rel/commons-text-1.9/src/main/java/org/apache/commons/text/TextStringBuilder.java#L1855]
> ) compares the entire buffer arrays.
> If a TextStringBuilder has extra capacity in the buffer, comparison fails.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-text] sebx59 commented on a change in pull request #281: TEXT-211 - TextStringBuilder.equals whatever the capacity is
sebx59 commented on a change in pull request #281:
URL: https://github.com/apache/commons-text/pull/281#discussion_r742616420
##
File path: src/main/java/org/apache/commons/text/TextStringBuilder.java
##
@@ -1947,7 +1954,7 @@ public String getNullText() {
*/
@Override
public int hashCode() {
-return Arrays.hashCode(buffer);
+return Arrays.hashCode(ArrayUtils.subarray(buffer, 0, size));
Review comment:
indeed, done in new commit
--
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.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [commons-text] sebx59 commented on a change in pull request #281: TEXT-211 - TextStringBuilder.equals whatever the capacity is
sebx59 commented on a change in pull request #281:
URL: https://github.com/apache/commons-text/pull/281#discussion_r742616356
##
File path: src/main/java/org/apache/commons/text/TextStringBuilder.java
##
@@ -1850,7 +1850,14 @@ public boolean equals(final Object obj) {
* @return true if the builders contain the same characters in the same
order
*/
public boolean equals(final TextStringBuilder other) {
-return other != null && Arrays.equals(buffer, other.buffer);
+
+ if(other == null) {
+ return false;
+ }
+ if (this.size != other.size) {
+return false;
+}
+return Arrays.equals(ArrayUtils.subarray(buffer, 0, size),
ArrayUtils.subarray(other.buffer, 0, size));
Review comment:
indeed, done in new commit
--
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.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Work logged] (TEXT-211) TextStringBuilder equals method changed behaviour from 1.8 to 1.9
[
https://issues.apache.org/jira/browse/TEXT-211?focusedWorklogId=676248&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-676248
]
ASF GitHub Bot logged work on TEXT-211:
---
Author: ASF GitHub Bot
Created on: 04/Nov/21 08:01
Start Date: 04/Nov/21 08:01
Worklog Time Spent: 10m
Work Description: sebx59 commented on a change in pull request #281:
URL: https://github.com/apache/commons-text/pull/281#discussion_r742605627
##
File path: src/test/java/org/apache/commons/text/TextStringBuilderTest.java
##
@@ -1057,15 +1057,24 @@ public void testHashCode() {
final TextStringBuilder sb = new TextStringBuilder();
final int hc1a = sb.hashCode();
final int hc1b = sb.hashCode();
-final int emptyHc = Arrays.hashCode(sb.getBuffer());
-assertEquals(emptyHc, hc1a);
Review comment:
The point here is that this assert is not passing anymore as hashcode of
the buffer is not equals to the hashcode of the TextStringBuilder itself (it
may be equals if the buffer is fully loaded with the 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.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 676248)
Time Spent: 3h 20m (was: 3h 10m)
> TextStringBuilder equals method changed behaviour from 1.8 to 1.9
> -
>
> Key: TEXT-211
> URL: https://issues.apache.org/jira/browse/TEXT-211
> Project: Commons Text
> Issue Type: Bug
>Affects Versions: 1.9
>Reporter: Nikolaos Georgiou
>Priority: Major
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> We found a regression (or breaking compatibility change) in the
> TextStringBuilder equals method when upgrading commons-text from 1.8 to 1.9
>
> The 1.8 version (
> [https://github.com/apache/commons-text/blob/commons-text-1.8/src/main/java/org/apache/commons/text/TextStringBuilder.java#L2915]
> ) would only compare the parts of the buffer that fall within the range
> 0..size.
> The 1.9 version (
> [https://github.com/apache/commons-text/blob/rel/commons-text-1.9/src/main/java/org/apache/commons/text/TextStringBuilder.java#L1855]
> ) compares the entire buffer arrays.
> If a TextStringBuilder has extra capacity in the buffer, comparison fails.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-text] sebx59 commented on a change in pull request #281: TEXT-211 - TextStringBuilder.equals whatever the capacity is
sebx59 commented on a change in pull request #281:
URL: https://github.com/apache/commons-text/pull/281#discussion_r742605627
##
File path: src/test/java/org/apache/commons/text/TextStringBuilderTest.java
##
@@ -1057,15 +1057,24 @@ public void testHashCode() {
final TextStringBuilder sb = new TextStringBuilder();
final int hc1a = sb.hashCode();
final int hc1b = sb.hashCode();
-final int emptyHc = Arrays.hashCode(sb.getBuffer());
-assertEquals(emptyHc, hc1a);
Review comment:
The point here is that this assert is not passing anymore as hashcode of
the buffer is not equals to the hashcode of the TextStringBuilder itself (it
may be equals if the buffer is fully loaded with the 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.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [commons-text] sebx59 commented on a change in pull request #281: TEXT-211 - TextStringBuilder.equals whatever the capacity is
sebx59 commented on a change in pull request #281:
URL: https://github.com/apache/commons-text/pull/281#discussion_r742605627
##
File path: src/test/java/org/apache/commons/text/TextStringBuilderTest.java
##
@@ -1057,15 +1057,24 @@ public void testHashCode() {
final TextStringBuilder sb = new TextStringBuilder();
final int hc1a = sb.hashCode();
final int hc1b = sb.hashCode();
-final int emptyHc = Arrays.hashCode(sb.getBuffer());
-assertEquals(emptyHc, hc1a);
Review comment:
The point here is that this assert is not passing anymore as hashcode of
the buffer is not equals to the hashcode of the TextStringBuilder itself
--
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.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Work logged] (TEXT-211) TextStringBuilder equals method changed behaviour from 1.8 to 1.9
[
https://issues.apache.org/jira/browse/TEXT-211?focusedWorklogId=676247&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-676247
]
ASF GitHub Bot logged work on TEXT-211:
---
Author: ASF GitHub Bot
Created on: 04/Nov/21 08:01
Start Date: 04/Nov/21 08:01
Worklog Time Spent: 10m
Work Description: sebx59 commented on a change in pull request #281:
URL: https://github.com/apache/commons-text/pull/281#discussion_r742605627
##
File path: src/test/java/org/apache/commons/text/TextStringBuilderTest.java
##
@@ -1057,15 +1057,24 @@ public void testHashCode() {
final TextStringBuilder sb = new TextStringBuilder();
final int hc1a = sb.hashCode();
final int hc1b = sb.hashCode();
-final int emptyHc = Arrays.hashCode(sb.getBuffer());
-assertEquals(emptyHc, hc1a);
Review comment:
The point here is that this assert is not passing anymore as hashcode of
the buffer is not equals to the hashcode of the TextStringBuilder itself
--
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.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 676247)
Time Spent: 3h 10m (was: 3h)
> TextStringBuilder equals method changed behaviour from 1.8 to 1.9
> -
>
> Key: TEXT-211
> URL: https://issues.apache.org/jira/browse/TEXT-211
> Project: Commons Text
> Issue Type: Bug
>Affects Versions: 1.9
>Reporter: Nikolaos Georgiou
>Priority: Major
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> We found a regression (or breaking compatibility change) in the
> TextStringBuilder equals method when upgrading commons-text from 1.8 to 1.9
>
> The 1.8 version (
> [https://github.com/apache/commons-text/blob/commons-text-1.8/src/main/java/org/apache/commons/text/TextStringBuilder.java#L2915]
> ) would only compare the parts of the buffer that fall within the range
> 0..size.
> The 1.9 version (
> [https://github.com/apache/commons-text/blob/rel/commons-text-1.9/src/main/java/org/apache/commons/text/TextStringBuilder.java#L1855]
> ) compares the entire buffer arrays.
> If a TextStringBuilder has extra capacity in the buffer, comparison fails.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (COMPRESS-594) 1.19 throws ZipException: Unexpected record signature: 0X3034B50
ben ke created COMPRESS-594: --- Summary: 1.19 throws ZipException: Unexpected record signature: 0X3034B50 Key: COMPRESS-594 URL: https://issues.apache.org/jira/browse/COMPRESS-594 Project: Commons Compress Issue Type: Bug Components: Archivers Affects Versions: 1.20, 1.19 Reporter: ben ke Attachments: image-2021-11-04-15-00-51-565.png !image-2021-11-04-15-00-51-565.png|width=1582,height=124! What's the problem? How to deal with this problem? -- This message was sent by Atlassian Jira (v8.3.4#803005)
