[jira] [Commented] (JEXL-360) Add missing bitwise operators ( >>, >>>, etc)
[ https://issues.apache.org/jira/browse/JEXL-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17492400#comment-17492400 ] Dmitri Blinov commented on JEXL-360: This is what, among many other things, that I have added in the experimental fork ([See https://github.com/dmitri-blinov/commons-jexl|https://github.com/dmitri-blinov/commons-jexl]), you can look at it and tell what you think. I could prepare PR for this if Henry would be so kind to accept it. Henry, what is your current vision about further language extensions (new operators / refactoring) ? > Add missing bitwise operators ( >>, >>>, etc) > - > > Key: JEXL-360 > URL: https://issues.apache.org/jira/browse/JEXL-360 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Ian Hawkins >Priority: Minor > Labels: newbie > > Hi! > Jexl appears to be missing the >> << >>> <<< bit shift operators - it > would be really useful to have them so we can do things like (b >> > bitnumber), etc. > Thanks! > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [commons-beanutils] JKLedzion commented on pull request #106: BEANUTILS-550: correction of returning default value by StringConverter
JKLedzion commented on pull request #106: URL: https://github.com/apache/commons-beanutils/pull/106#issuecomment-1039928021 > @JKLedzion Thank you for the PR. Don't use Javadoc comments for comments that are not Javadoc. Inline comments would be more appropriate. Corrected. -- 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] [Comment Edited] (CSV-290) Produced CSV using PostgreSQL format cannot be read
[
https://issues.apache.org/jira/browse/CSV-290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17492340#comment-17492340
]
Angus C edited comment on CSV-290 at 2/15/22, 3:52 AM:
---
Basically the "EOF reached" always happens if quote-char = escape-char.
Considering the input string ("a"), Lexer.java treats the second (") as an
escape char and read the unescaped \r, and then complain for missing the
ending-quote (")
{code:java}
CSVFormat.Builder.create().setEscape('"').build().parse(new
StringReader("\"a\"")).getRecords();
{code}
I think the setEscape() is used for escaping special char like \r, \t etc. as
in Lexer.readEscape() but not the quote-char. The quote-char should always be
escaped by quote-char, not the escape-char.
Your fix is to disable the escape-char in quoted-string if it is equal to
quote-char. It can be a fail-safe but I think we should remove the
.setEscape(DOUBLE_QUOTE_CHAR) in POSTGRESQL_CSV. The javadoc says "special
characters are escaped with quote" but I doubt that it is correct or not
was (Author: JIRAUSER285196):
Basically the "EOF reached" always happens if quote-char = escape-char.
Considering the input string ("a"), Lexer.java treats the second (") as an
escape char and read the unescaped \r, and then complain for missing the
ending-quote (")
{code:java}
CSVFormat.Builder.create().setEscape('"').build().parse(new
StringReader("\"a\"")).getRecords();
{code}
I think the setEscape() is used for escaping special char like \r, \t etc. as
in Lexer.readEscape() but not the quote-char. The quote-char should be always
escaped by quote-char, not the escape-char.
Your fix is to disable the escape-char in quoted-string if it is equal to
quote-char. It can be a fail-save but I think we should remove the
.setEscape(DOUBLE_QUOTE_CHAR) in POSTGRESQL_CSV. The javadoc says "special *
characters are escaped with quote" but I doubt that it is correct or not
> Produced CSV using PostgreSQL format cannot be read
> ---
>
> Key: CSV-290
> URL: https://issues.apache.org/jira/browse/CSV-290
> Project: Commons CSV
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.6, 1.9.0
>Reporter: Anatoliy Artemenko
>Priority: Major
>
> {code:java}
> // code placeholder
> {code}
> CSV, produced using printer:
>
> CSVPrinter printer = new CSVPrinter(sw,
> CSVFormat.POSTGRESQL_CSV.withFirstRecordAsHeader());
>
> cannot be be read with same format parser:
>
> CSVParser parser = new CSVParser(new StringReader(sw.toString()),
> CSVFormat.POSTGRESQL_CSV.withFirstRecordAsHeader());
>
> To reproduce:
>
> {code:java}
> StringWriter sw = new StringWriter();
> CSVPrinter printer = new CSVPrinter(sw,
> CSVFormat.POSTGRESQL_CSV.withFirstRecordAsHeader());
> printer.printRecord("column1", "column2");
> printer.printRecord("v11", "v12");
> printer.printRecord("v21", "v22");
> printer.close();
> CSVParser parser = new CSVParser(new StringReader(sw.toString()),
> CSVFormat.POSTGRESQL_CSV.withFirstRecordAsHeader());
> System.out.println("headers: " +
> Arrays.equals(parser.getHeaderNames().toArray(), new String[] {"column1",
> "column2"}));
> Iterator i = parser.iterator();
> System.out.println("row: " + Arrays.equals(i.next().toList().toArray(), new
> String[] {"v11", "v12"}));
> System.out.println("row: " + Arrays.equals(i.next().toList().toArray(), new
> String[] {"v21", "v22"}));{code}
> I'd expect the above code to work, but it fails:
> {code:java}
> java.io.IOException: (startline 1) EOF reached before encapsulated token
> finishedjava.io.IOException: (startline 1) EOF reached before encapsulated
> token finished
> at org.apache.commons.csv.Lexer.parseEncapsulatedToken(Lexer.java:371)
> at org.apache.commons.csv.Lexer.nextToken(Lexer.java:285)
> at org.apache.commons.csv.CSVParser.nextRecord(CSVParser.java:701)
> at org.apache.commons.csv.CSVParser.createHeaders(CSVParser.java:480)
> at org.apache.commons.csv.CSVParser.(CSVParser.java:432)
> at org.apache.commons.csv.CSVParser.(CSVParser.java:398)
> at Test.main(Test.java:25)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CSV-290) Produced CSV using PostgreSQL format cannot be read
[
https://issues.apache.org/jira/browse/CSV-290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17492340#comment-17492340
]
Angus C commented on CSV-290:
-
Basically the "EOF reached" always happens if quote-char = escape-char.
Considering the input string ("a"), Lexer.java treats the second (") as an
escape char and read the unescaped \r, and then complain for missing the
ending-quote (")
{code:java}
CSVFormat.Builder.create().setEscape('"').build().parse(new
StringReader("\"a\"")).getRecords();
{code}
I think the setEscape() is used for escaping special char like \r, \t etc. as
in Lexer.readEscape() but not the quote-char. The quote-char should be always
escaped by quote-char, not the escape-char.
Your fix is to disable the escape-char in quoted-string if it is equal to
quote-char. It can be a fail-save but I think we should remove the
.setEscape(DOUBLE_QUOTE_CHAR) in POSTGRESQL_CSV. The javadoc says "special *
characters are escaped with quote" but I doubt that it is correct or not
> Produced CSV using PostgreSQL format cannot be read
> ---
>
> Key: CSV-290
> URL: https://issues.apache.org/jira/browse/CSV-290
> Project: Commons CSV
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.6, 1.9.0
>Reporter: Anatoliy Artemenko
>Priority: Major
>
> {code:java}
> // code placeholder
> {code}
> CSV, produced using printer:
>
> CSVPrinter printer = new CSVPrinter(sw,
> CSVFormat.POSTGRESQL_CSV.withFirstRecordAsHeader());
>
> cannot be be read with same format parser:
>
> CSVParser parser = new CSVParser(new StringReader(sw.toString()),
> CSVFormat.POSTGRESQL_CSV.withFirstRecordAsHeader());
>
> To reproduce:
>
> {code:java}
> StringWriter sw = new StringWriter();
> CSVPrinter printer = new CSVPrinter(sw,
> CSVFormat.POSTGRESQL_CSV.withFirstRecordAsHeader());
> printer.printRecord("column1", "column2");
> printer.printRecord("v11", "v12");
> printer.printRecord("v21", "v22");
> printer.close();
> CSVParser parser = new CSVParser(new StringReader(sw.toString()),
> CSVFormat.POSTGRESQL_CSV.withFirstRecordAsHeader());
> System.out.println("headers: " +
> Arrays.equals(parser.getHeaderNames().toArray(), new String[] {"column1",
> "column2"}));
> Iterator i = parser.iterator();
> System.out.println("row: " + Arrays.equals(i.next().toList().toArray(), new
> String[] {"v11", "v12"}));
> System.out.println("row: " + Arrays.equals(i.next().toList().toArray(), new
> String[] {"v21", "v22"}));{code}
> I'd expect the above code to work, but it fails:
> {code:java}
> java.io.IOException: (startline 1) EOF reached before encapsulated token
> finishedjava.io.IOException: (startline 1) EOF reached before encapsulated
> token finished
> at org.apache.commons.csv.Lexer.parseEncapsulatedToken(Lexer.java:371)
> at org.apache.commons.csv.Lexer.nextToken(Lexer.java:285)
> at org.apache.commons.csv.CSVParser.nextRecord(CSVParser.java:701)
> at org.apache.commons.csv.CSVParser.createHeaders(CSVParser.java:480)
> at org.apache.commons.csv.CSVParser.(CSVParser.java:432)
> at org.apache.commons.csv.CSVParser.(CSVParser.java:398)
> at Test.main(Test.java:25)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (CSV-294) CSVFormat does not support explicit " as escape char
[
https://issues.apache.org/jira/browse/CSV-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17492138#comment-17492138
]
Angus C edited comment on CSV-294 at 2/15/22, 3:37 AM:
---
Even the input string ("a") will cause the exception as Lexer.java treats the
second (") as an escape char and read the unescaped \r, and then complain for
missing the ending-quote (")
E.g.
{code:java}
CSVFormat.Builder.create().setEscape('"').build().parse(new
StringReader("\"a\"")).getRecords();{code}
I think you cannot use the quote char as escape char. commons-cvs already
implement the RFC part that the quote char is escaped by preceding quote char,
but not the escape char
E.g.
{code:java}
System.out.println("1 " + CSVFormat.Builder.create().build().parse(new
StringReader("\"a\"")).getRecords().get(0).get(0));
System.out.println("2 " + CSVFormat.Builder.create().build().parse(new
StringReader("\"\"\"a\"\"\"")).getRecords().get(0).get(0));
System.out.println("3 " +
CSVFormat.Builder.create().setQuote('|').build().parse(new
StringReader("|a|")).getRecords().get(0).get(0));
System.out.println("4 " +
CSVFormat.Builder.create().setQuote('|').build().parse(new
StringReader("|||a|||")).getRecords().get(0).get(0));
{code}
Output
{code:java}
1 a
2 "a"
3 a
4 |a|
{code}
was (Author: JIRAUSER285196):
Even the input string ("a") will cause the exception as Lexer.java treats the
second (") as an escape char and read the unescaped \r, and then complain for
missing the ending-quote (")
E.g.
{code:java}
CSVFormat.Builder.create().setEscape('"').build().parse(new
StringReader("\"a\"")).getRecords();{code}
I think you cannot use the quote char as escape char. commons-cvs already
implement the RFC part that the quote char is escaped by preceding quote char,
but not the escape char
E.g.
{code:java}
System.out.println("1 " + CSVFormat.Builder.create().build().parse(new
StringReader("\"a\"")).getRecords().get(0).get(0));
System.out.println("2 " + CSVFormat.Builder.create().build().parse(new
StringReader("\"\"\"a\"\"\"")).getRecords().get(0).get(0));
System.out.println("3 " +
CSVFormat.Builder.create().setQuote('|').build().parse(new
StringReader("|a|")).getRecords().get(0).get(0));
System.out.println("4 " +
CSVFormat.Builder.create().setQuote('|').build().parse(new
StringReader("|||a|||")).getRecords().get(0).get(0));
{code}
Output
{code:java}
1 a
2 "a"
3 a
4 |a|
{code}
> CSVFormat does not support explicit " as escape char
>
>
> Key: CSV-294
> URL: https://issues.apache.org/jira/browse/CSV-294
> Project: Commons CSV
> Issue Type: Bug
>Affects Versions: 1.9.0
>Reporter: Joern Huxhorn
>Priority: Major
> Attachments: JiraCsv294Test.java
>
>
> Reading data that contains " does not work if escape character is *manually
> set to {{'"'}}* as specified in [RFC
> 4180|https://datatracker.ietf.org/doc/html/rfc4180].
> *It works for other escape characters or if no escape character is explicitly
> defined in the format.*
> This line in {{Lexer.java}} is responsible for the originally quite erroneous
> ticket:
> {{this.escape = mapNullToDisabled(format.getEscapeCharacter());}}
> From this line I (wrongly) deduced that an unspecified escape character would
> actually disable escaping. Because of that I wanted to enable it by setting
> it to {{'"'}} which causes exceptions in the Lexer for perfectly valid input.
> That in turn convinced my that this is a way bigger issue than it is. Sorry
> about that.
> I don't think that the current situation is ideal, though.
> I would not have been this confused if {{CSVFormat}} would be more explicit
> about the escape char that will be used, i.e. if {{toString()}} would show
> the implicitly used quote character or print - in case of {{null}} - that
> this means it's using the quote character. It is currently omitted from the
> output if it is not set explicitly.
> There is also no documentation about what {{null}} as escape character
> actually means - it may be documented somewhere but isn't documented for
> {{CSVFormat.getEscapeCharacter()}} or {{CSVFormat.Builder.set/getEscape()}}
> methods.
> And setting the escape character explicitly to the value specified in the RFC
> should certainly not fail, even if setting it to that value is superfluous
> since {{null}} behaves exactly the same.
> h4. Relevant part of the RFC:
> 7. If double-quotes are used to enclose fields, then a double-quote
> appearing inside a field must be escaped by preceding it with
> another double quote. For example:
> "aaa","b""bb","ccc"
> h4. Related issue:
> https://issues.apache.org/jira/browse/CSV-150
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (COLLECTIONS-804) testCollectionToArray2() is non deterministic
[
https://issues.apache.org/jira/browse/COLLECTIONS-804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17492282#comment-17492282
]
Alex Herbert commented on COLLECTIONS-804:
--
The testCollectionToArray2 method is in AbstractCollectionTest and is also used
for collections that are ordered.
>From the java.util.Collection toArray method:
{noformat}
If this collection makes any guarantees as to what order its elements are
returned by its iterator, this method must return the elements in the same
order.{noformat}
This would suggest the test requires a property to determine if the collection
under test should have an ordered iterator or not. If not then the two arrays
can be compared using a HashBag. Otherwise the toArray output should be checked
against the iterator.
> testCollectionToArray2() is non deterministic
> -
>
> Key: COLLECTIONS-804
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-804
> Project: Commons Collections
> Issue Type: Bug
> Components: Collection
>Affects Versions: 4.4
>Reporter: Vivek Gupta
>Priority: Minor
>
> The test
> {{org.apache.commons.collections4.collection.AbstractCollectionTest.testCollectionToArray2()}}
> can fail if two {{toArray()}} calls return elements in a different order.
> One can check for that using the NonDex tool
> ([https://github.com/TestingResearchIllinois/NonDex]).
> Bug repoduction:
> # Clone the repo and cd into it.
> # {{mvn test
> -Dtest=org.apache.commons.collections4.bidimap.DualHashBidiMapTest#testCollectionToArray2
> -Drat.skip}} This test will pass.
> # {{mvn edu.illinois:nondex-maven-plugin:1.1.2:nondex
> -Dtest=org.apache.commons.collections4.bidimap.DualHashBidiMapTest#testCollectionToArray2
> -Drat.skip}} This command runs the NonDex tool on the the test. Near the end
> of the output, you will see a summary of test failures, where you will find
> {{testCollectionToArray2()}} function listed.
> The source of the bug:
> The test gets an array representation of the collections and then compares
> them, taking the order into account. However, Java Collections need not be
> necessarily ordered. Its member function {{toArray()}} also does not
> guarantee a deterministic order of the elements in its returned list. As
> such, we should ignore the order of the elements in the assertion.
> Proposed fix:
> We ignore the order of array lists by putting its elements into separate
> multisets and then comparing those multisets for equality. Multiset is not a
> part of the standard Java library. However, conveniently enough, this
> repository already had an implementation of multiset called HashBags, which I
> used.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [commons-collections] aherbert commented on a change in pull request #258: Simplify bloom filters
aherbert commented on a change in pull request #258:
URL:
https://github.com/apache/commons-collections/pull/258#discussion_r806265481
##
File path:
src/main/java/org/apache/commons/collections4/bloomfilter/SparseBloomFilter.java
##
@@ -0,0 +1,256 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.collections4.bloomfilter;
+
+import java.util.Objects;
+import java.util.TreeSet;
+import java.util.function.IntPredicate;
+import java.util.function.LongPredicate;
+
+/**
+ * A bloom filter using a TreeSet of integers to track enabled bits. This is a
standard
+ * implementation and should work well for most low cardinality Bloom filters.
+ * @since 4.5
+ */
+public class SparseBloomFilter implements BloomFilter {
+
+/**
+ * The bitSet that defines this BloomFilter.
+ */
+private final TreeSet indices;
+
+/**
+ * The shape of this BloomFilter.
+ */
+private final Shape shape;
+
+/**
+ * Constructs an empty BitSetBloomFilter.
+ *
+ * @param shape The shape of the filter.
+ */
+public SparseBloomFilter(Shape shape) {
+Objects.requireNonNull(shape, "shape");
+this.shape = shape;
+this.indices = new TreeSet<>();
+}
+
+/**
+ * Creates an instance that is equivalent to {@code other}.
+ *
+ * @param other The bloom filter to copy.
+ */
+public SparseBloomFilter(BloomFilter other) {
+Objects.requireNonNull(other, "other");
+this.shape = other.getShape();
+this.indices = new TreeSet<>();
+if (other.isSparse()) {
+mergeInPlace((IndexProducer) other);
+} else {
+mergeInPlace(IndexProducer.fromBitMapProducer(other));
+}
+}
+
+private void checkIndices(Shape shape) {
+if (this.indices.floor(-1) != null ||
this.indices.ceiling(shape.getNumberOfBits()) != null) {
+throw new IllegalArgumentException(
+String.format("Filter only accepts values in the [0,%d)
range", shape.getNumberOfBits()));
+}
+}
+
+/**
+ * Constructs a populated Bloom filter.
+ * @param shape the shape for the bloom filter.
+ * @param hasher the hasher to provide the initial data.
+ */
+public SparseBloomFilter(final Shape shape, Hasher hasher) {
+this(shape);
+Objects.requireNonNull(hasher, "hasher");
+hasher.indices(shape).forEachIndex(this::add);
+checkIndices(shape);
+}
+
+/**
+ * Constructs a populated Bloom filter.
+ * @param shape the shape of the filter.
+ * @param indices an index producer for the indices to to enable.
+ * @throws IllegalArgumentException if indices contains a value greater
than the number
+ * of bits in the shape.
+ */
+public SparseBloomFilter(Shape shape, IndexProducer indices) {
+this(shape);
+Objects.requireNonNull(indices, "indices");
+indices.forEachIndex(this::add);
+checkIndices(shape);
+}
+
+/**
+ * Constructs a populated Bloom filter.
+ * @param shape the shape of the filter.
+ * @param bitMaps a BitMapProducer for the bit maps to add.
+ * @throws IllegalArgumentException if the bit maps contain a value
greater than the number
+ * of bits in the shape.
+ */
+public SparseBloomFilter(Shape shape, BitMapProducer bitMaps) {
+this(shape);
+Objects.requireNonNull(bitMaps, "bitMaps");
+mergeInPlace(IndexProducer
+.fromBitMapProducer(new CheckBitMapCount(bitMaps,
BitMap.numberOfBitMaps(shape.getNumberOfBits();
+}
+
+@Override
+public long[] asBitMapArray() {
+long[] result = new
long[BitMap.numberOfBitMaps(shape.getNumberOfBits())];
+LongPredicate filler = new LongPredicate() {
+int idx = 0;
+
+@Override
+public boolean test(long value) {
+result[idx++] = value;
+return true;
+}
+};
+forEachBitMap(filler);
+return result;
+}
+
+@Override
+public SparseBloomFilter copy() {
+SparseBloomFilter result = new SparseBloomFilter(shape);
+
[jira] [Updated] (COLLECTIONS-804) testCollectionToArray2() is non deterministic
[
https://issues.apache.org/jira/browse/COLLECTIONS-804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vivek Gupta updated COLLECTIONS-804:
Affects Version/s: 4.4
> testCollectionToArray2() is non deterministic
> -
>
> Key: COLLECTIONS-804
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-804
> Project: Commons Collections
> Issue Type: Bug
> Components: Collection
>Affects Versions: 4.4
>Reporter: Vivek Gupta
>Priority: Minor
>
> The test
> {{org.apache.commons.collections4.collection.AbstractCollectionTest.testCollectionToArray2()}}
> can fail if two {{toArray()}} calls return elements in a different order.
> One can check for that using the NonDex tool
> ([https://github.com/TestingResearchIllinois/NonDex]).
> Bug repoduction:
> # Clone the repo and cd into it.
> # {{mvn test
> -Dtest=org.apache.commons.collections4.bidimap.DualHashBidiMapTest#testCollectionToArray2
> -Drat.skip}} This test will pass.
> # {{mvn edu.illinois:nondex-maven-plugin:1.1.2:nondex
> -Dtest=org.apache.commons.collections4.bidimap.DualHashBidiMapTest#testCollectionToArray2
> -Drat.skip}} This command runs the NonDex tool on the the test. Near the end
> of the output, you will see a summary of test failures, where you will find
> {{testCollectionToArray2()}} function listed.
> The source of the bug:
> The test gets an array representation of the collections and then compares
> them, taking the order into account. However, Java Collections need not be
> necessarily ordered. Its member function {{toArray()}} also does not
> guarantee a deterministic order of the elements in its returned list. As
> such, we should ignore the order of the elements in the assertion.
> Proposed fix:
> We ignore the order of array lists by putting its elements into separate
> multisets and then comparing those multisets for equality. Multiset is not a
> part of the standard Java library. However, conveniently enough, this
> repository already had an implementation of multiset called HashBags, which I
> used.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (COLLECTIONS-804) testCollectionToArray2() is non deterministic
Vivek Gupta created COLLECTIONS-804:
---
Summary: testCollectionToArray2() is non deterministic
Key: COLLECTIONS-804
URL: https://issues.apache.org/jira/browse/COLLECTIONS-804
Project: Commons Collections
Issue Type: Bug
Components: Collection
Reporter: Vivek Gupta
The test
{{org.apache.commons.collections4.collection.AbstractCollectionTest.testCollectionToArray2()}}
can fail if two {{toArray()}} calls return elements in a different order. One
can check for that using the NonDex tool
([https://github.com/TestingResearchIllinois/NonDex]).
Bug repoduction:
# Clone the repo and cd into it.
# {{mvn test
-Dtest=org.apache.commons.collections4.bidimap.DualHashBidiMapTest#testCollectionToArray2
-Drat.skip}} This test will pass.
# {{mvn edu.illinois:nondex-maven-plugin:1.1.2:nondex
-Dtest=org.apache.commons.collections4.bidimap.DualHashBidiMapTest#testCollectionToArray2
-Drat.skip}} This command runs the NonDex tool on the the test. Near the end
of the output, you will see a summary of test failures, where you will find
{{testCollectionToArray2()}} function listed.
The source of the bug:
The test gets an array representation of the collections and then compares
them, taking the order into account. However, Java Collections need not be
necessarily ordered. Its member function {{toArray()}} also does not guarantee
a deterministic order of the elements in its returned list. As such, we should
ignore the order of the elements in the assertion.
Proposed fix:
We ignore the order of array lists by putting its elements into separate
multisets and then comparing those multisets for equality. Multiset is not a
part of the standard Java library. However, conveniently enough, this
repository already had an implementation of multiset called HashBags, which I
used.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [commons-codec] garydgregory commented on a change in pull request #78: Validate byte and string
garydgregory commented on a change in pull request #78:
URL: https://github.com/apache/commons-codec/pull/78#discussion_r806300692
##
File path: src/main/java/org/apache/commons/codec/binary/StringUtils.java
##
@@ -269,6 +269,25 @@ public static ByteBuffer getByteBufferUtf8(final String
string) {
return getBytes(string, StandardCharsets.UTF_8);
}
+/**
+ * Checks if a CharSequence is empty ("") or null.
+ *
+ *
+ * StringUtils.isEmpty(null) = true
+ * StringUtils.isEmpty("")= true
+ * StringUtils.isEmpty(" ") = false
+ * StringUtils.isEmpty("bob") = false
+ * StringUtils.isEmpty(" bob ") = false
+ *
+ *
+ * @param cs the CharSequence to check, may be null
+ * @return {@code true} if the CharSequence is empty or null
+ * @since 1.16
+ */
+public static boolean isEmpty(final CharSequence cs) {
Review comment:
Make this package-private and move it somewhere in the language package
since it is the only place where it seems to be called, which will help as
noted in my other comment.
##
File path: src/main/java/org/apache/commons/codec/binary/BinaryCodec.java
##
@@ -136,8 +136,10 @@
* @param array
*the source array
* @return {@code true} if the given array is {@code null} or empty (size
0.)
+ *
+ * @since 1.16 change visibility to public
*/
-private static boolean isEmpty(final byte[] array) {
+public static boolean isEmpty(final byte[] array) {
Review comment:
Hello @arturobernalg
Please make this package private instead of public, this helps minimize the
API footprint we will need to maintain for BC, especially since this is just
for internal use.
--
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-codec] garydgregory merged pull request #39: CODEC-285 upgrade to JUnit v5.6.0
garydgregory merged pull request #39: URL: https://github.com/apache/commons-codec/pull/39 -- 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-codec] garydgregory closed pull request #92: Avoid inefficient usage of arraylist
garydgregory closed pull request #92: URL: https://github.com/apache/commons-codec/pull/92 -- 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-codec] garydgregory commented on pull request #92: Avoid inefficient usage of arraylist
garydgregory commented on pull request #92: URL: https://github.com/apache/commons-codec/pull/92#issuecomment-1039581068 Closing, no reply from OP. -- 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] garydgregory commented on pull request #298: Make more clear passing null value.
garydgregory commented on pull request #298: URL: https://github.com/apache/commons-text/pull/298#issuecomment-1039576597 For me, this just clutter's up the code. -- 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-compress] kinow commented on a change in pull request #247: Use Math.min and Math.max calculations.
kinow commented on a change in pull request #247:
URL: https://github.com/apache/commons-compress/pull/247#discussion_r806130570
##
File path:
src/main/java/org/apache/commons/compress/harmony/pack200/BHSDCodec.java
##
@@ -308,11 +308,8 @@ public boolean encodes(final long value) {
}
} else if (z < 0) {
// Need to use integer overflow here to represent negatives.
-if (cardinality < 4294967296L) {
-z += cardinality;
-} else {
-z += 4294967296L; // this value is equal to (1 << 32).
-}
+// this value is equal to (1 << 32).
Review comment:
True! I have to get used to jshell. Looks like the integer overflow
resets the value to `1`. But using longs works the same way as in Python.
--
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] [Comment Edited] (CSV-294) CSVFormat does not support explicit " as escape char
[
https://issues.apache.org/jira/browse/CSV-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17492138#comment-17492138
]
Angus C edited comment on CSV-294 at 2/14/22, 6:28 PM:
---
Even the input string ("a") will cause the exception as Lexer.java treats the
second (") as an escape char and read the unescaped \r, and then complain for
missing the ending-quote (")
E.g.
{code:java}
{code}
{{CSVFormat.Builder.create().setEscape('"').build().parse(new
StringReader("\"a\"")).getRecords();}}
I think you cannot use the quote char as escape char. commons-cvs already
implement the RFC part that the quote char is escaped by preceding quote char,
but not the escape char
E.g.
{code:java}
System.out.println("1 " + CSVFormat.Builder.create().build().parse(new
StringReader("\"a\"")).getRecords().get(0).get(0));
System.out.println("2 " + CSVFormat.Builder.create().build().parse(new
StringReader("\"\"\"a\"\"\"")).getRecords().get(0).get(0));
System.out.println("3 " +
CSVFormat.Builder.create().setQuote('|').build().parse(new
StringReader("|a|")).getRecords().get(0).get(0));
System.out.println("4 " +
CSVFormat.Builder.create().setQuote('|').build().parse(new
StringReader("|||a|||")).getRecords().get(0).get(0));
{code}
Output
{code:java}
1 a
2 "a"
3 a
4 |a|
{code}
was (Author: JIRAUSER285196):
Even the input string ("a") will cause the exception as Lexer.java treats the
second (") as an escape char and read the unescaped \r, and then complain for
missing the ending-quote (")
E.g.
{{CSVFormat.Builder.{_}create{_}().setEscape('"').build().parse({*}new{*}
StringReader("\"a\"")).getRecords();}}
I think you cannot use the quote char as escape char. commons-cvs already
implement the RFC part that the quote char is escaped by preceding quote char,
but not the escape char
E.g.
{{System.{*}_out_{*}.println("1 " +
CSVFormat.Builder.{_}create{_}().build().parse({*}new{*}
StringReader("\"a\"")).getRecords().get(0).get(0));}}
{{System.{*}_out_{*}.println("2 " +
CSVFormat.Builder.{_}create{_}().build().parse({*}new{*}
StringReader("\"\"\"a\"\"\"")).getRecords().get(0).get(0));}}
{{System.{*}_out_{*}.println("3 " +
CSVFormat.Builder.{_}create{_}().setQuote('|').build().parse({*}new{*}
StringReader("|a|")).getRecords().get(0).get(0));}}
{{System.{*}_out_{*}.println("4 " +
CSVFormat.Builder.{_}create{_}().setQuote('|').build().parse({*}new{*}
StringReader("|||a|||")).getRecords().get(0).get(0));}}
Output
--
{{1 a}}
{{2 "a"}}
{{3 a}}
{{4 |a|}}
> CSVFormat does not support explicit " as escape char
>
>
> Key: CSV-294
> URL: https://issues.apache.org/jira/browse/CSV-294
> Project: Commons CSV
> Issue Type: Bug
>Affects Versions: 1.9.0
>Reporter: Joern Huxhorn
>Priority: Major
> Attachments: JiraCsv294Test.java
>
>
> Reading data that contains " does not work if escape character is *manually
> set to {{'"'}}* as specified in [RFC
> 4180|https://datatracker.ietf.org/doc/html/rfc4180].
> *It works for other escape characters or if no escape character is explicitly
> defined in the format.*
> This line in {{Lexer.java}} is responsible for the originally quite erroneous
> ticket:
> {{this.escape = mapNullToDisabled(format.getEscapeCharacter());}}
> From this line I (wrongly) deduced that an unspecified escape character would
> actually disable escaping. Because of that I wanted to enable it by setting
> it to {{'"'}} which causes exceptions in the Lexer for perfectly valid input.
> That in turn convinced my that this is a way bigger issue than it is. Sorry
> about that.
> I don't think that the current situation is ideal, though.
> I would not have been this confused if {{CSVFormat}} would be more explicit
> about the escape char that will be used, i.e. if {{toString()}} would show
> the implicitly used quote character or print - in case of {{null}} - that
> this means it's using the quote character. It is currently omitted from the
> output if it is not set explicitly.
> There is also no documentation about what {{null}} as escape character
> actually means - it may be documented somewhere but isn't documented for
> {{CSVFormat.getEscapeCharacter()}} or {{CSVFormat.Builder.set/getEscape()}}
> methods.
> And setting the escape character explicitly to the value specified in the RFC
> should certainly not fail, even if setting it to that value is superfluous
> since {{null}} behaves exactly the same.
> h4. Relevant part of the RFC:
> 7. If double-quotes are used to enclose fields, then a double-quote
> appearing inside a field must be escaped by preceding it with
> another double quote. For example:
> "aaa","b""bb","ccc"
> h4. Related issue:
> https://issues.apache.org/jira/browse/CSV-150
--
This message was sent by Atlassian Jira
[jira] [Comment Edited] (CSV-294) CSVFormat does not support explicit " as escape char
[
https://issues.apache.org/jira/browse/CSV-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17492138#comment-17492138
]
Angus C edited comment on CSV-294 at 2/14/22, 6:28 PM:
---
Even the input string ("a") will cause the exception as Lexer.java treats the
second (") as an escape char and read the unescaped \r, and then complain for
missing the ending-quote (")
E.g.
{code:java}
CSVFormat.Builder.create().setEscape('"').build().parse(new
StringReader("\"a\"")).getRecords();{code}
I think you cannot use the quote char as escape char. commons-cvs already
implement the RFC part that the quote char is escaped by preceding quote char,
but not the escape char
E.g.
{code:java}
System.out.println("1 " + CSVFormat.Builder.create().build().parse(new
StringReader("\"a\"")).getRecords().get(0).get(0));
System.out.println("2 " + CSVFormat.Builder.create().build().parse(new
StringReader("\"\"\"a\"\"\"")).getRecords().get(0).get(0));
System.out.println("3 " +
CSVFormat.Builder.create().setQuote('|').build().parse(new
StringReader("|a|")).getRecords().get(0).get(0));
System.out.println("4 " +
CSVFormat.Builder.create().setQuote('|').build().parse(new
StringReader("|||a|||")).getRecords().get(0).get(0));
{code}
Output
{code:java}
1 a
2 "a"
3 a
4 |a|
{code}
was (Author: JIRAUSER285196):
Even the input string ("a") will cause the exception as Lexer.java treats the
second (") as an escape char and read the unescaped \r, and then complain for
missing the ending-quote (")
E.g.
{code:java}
{code}
{{CSVFormat.Builder.create().setEscape('"').build().parse(new
StringReader("\"a\"")).getRecords();}}
I think you cannot use the quote char as escape char. commons-cvs already
implement the RFC part that the quote char is escaped by preceding quote char,
but not the escape char
E.g.
{code:java}
System.out.println("1 " + CSVFormat.Builder.create().build().parse(new
StringReader("\"a\"")).getRecords().get(0).get(0));
System.out.println("2 " + CSVFormat.Builder.create().build().parse(new
StringReader("\"\"\"a\"\"\"")).getRecords().get(0).get(0));
System.out.println("3 " +
CSVFormat.Builder.create().setQuote('|').build().parse(new
StringReader("|a|")).getRecords().get(0).get(0));
System.out.println("4 " +
CSVFormat.Builder.create().setQuote('|').build().parse(new
StringReader("|||a|||")).getRecords().get(0).get(0));
{code}
Output
{code:java}
1 a
2 "a"
3 a
4 |a|
{code}
> CSVFormat does not support explicit " as escape char
>
>
> Key: CSV-294
> URL: https://issues.apache.org/jira/browse/CSV-294
> Project: Commons CSV
> Issue Type: Bug
>Affects Versions: 1.9.0
>Reporter: Joern Huxhorn
>Priority: Major
> Attachments: JiraCsv294Test.java
>
>
> Reading data that contains " does not work if escape character is *manually
> set to {{'"'}}* as specified in [RFC
> 4180|https://datatracker.ietf.org/doc/html/rfc4180].
> *It works for other escape characters or if no escape character is explicitly
> defined in the format.*
> This line in {{Lexer.java}} is responsible for the originally quite erroneous
> ticket:
> {{this.escape = mapNullToDisabled(format.getEscapeCharacter());}}
> From this line I (wrongly) deduced that an unspecified escape character would
> actually disable escaping. Because of that I wanted to enable it by setting
> it to {{'"'}} which causes exceptions in the Lexer for perfectly valid input.
> That in turn convinced my that this is a way bigger issue than it is. Sorry
> about that.
> I don't think that the current situation is ideal, though.
> I would not have been this confused if {{CSVFormat}} would be more explicit
> about the escape char that will be used, i.e. if {{toString()}} would show
> the implicitly used quote character or print - in case of {{null}} - that
> this means it's using the quote character. It is currently omitted from the
> output if it is not set explicitly.
> There is also no documentation about what {{null}} as escape character
> actually means - it may be documented somewhere but isn't documented for
> {{CSVFormat.getEscapeCharacter()}} or {{CSVFormat.Builder.set/getEscape()}}
> methods.
> And setting the escape character explicitly to the value specified in the RFC
> should certainly not fail, even if setting it to that value is superfluous
> since {{null}} behaves exactly the same.
> h4. Relevant part of the RFC:
> 7. If double-quotes are used to enclose fields, then a double-quote
> appearing inside a field must be escaped by preceding it with
> another double quote. For example:
> "aaa","b""bb","ccc"
> h4. Related issue:
> https://issues.apache.org/jira/browse/CSV-150
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [commons-compress] garydgregory commented on a change in pull request #247: Use Math.min and Math.max calculations.
garydgregory commented on a change in pull request #247:
URL: https://github.com/apache/commons-compress/pull/247#discussion_r806121231
##
File path:
src/main/java/org/apache/commons/compress/harmony/pack200/BHSDCodec.java
##
@@ -308,11 +308,8 @@ public boolean encodes(final long value) {
}
} else if (z < 0) {
// Need to use integer overflow here to represent negatives.
-if (cardinality < 4294967296L) {
-z += cardinality;
-} else {
-z += 4294967296L; // this value is equal to (1 << 32).
-}
+// this value is equal to (1 << 32).
Review comment:
I think you'd want to use jshell here, not python...
--
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-compress] kinow commented on a change in pull request #247: Use Math.min and Math.max calculations.
kinow commented on a change in pull request #247:
URL: https://github.com/apache/commons-compress/pull/247#discussion_r806110136
##
File path:
src/main/java/org/apache/commons/compress/harmony/pack200/BHSDCodec.java
##
@@ -308,11 +308,8 @@ public boolean encodes(final long value) {
}
} else if (z < 0) {
// Need to use integer overflow here to represent negatives.
-if (cardinality < 4294967296L) {
-z += cardinality;
-} else {
-z += 4294967296L; // this value is equal to (1 << 32).
-}
+// this value is equal to (1 << 32).
Review comment:
After this change it could be interpreted as `z` being `1 << 32`. Maybe
change the text to `4294967296 is 1 << 32` (which helps devs with the
magic-numbers issue)
--
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-compress] kinow commented on a change in pull request #247: Use Math.min and Math.max calculations.
kinow commented on a change in pull request #247:
URL: https://github.com/apache/commons-compress/pull/247#discussion_r806110136
##
File path:
src/main/java/org/apache/commons/compress/harmony/pack200/BHSDCodec.java
##
@@ -308,11 +308,8 @@ public boolean encodes(final long value) {
}
} else if (z < 0) {
// Need to use integer overflow here to represent negatives.
-if (cardinality < 4294967296L) {
-z += cardinality;
-} else {
-z += 4294967296L; // this value is equal to (1 << 32).
-}
+// this value is equal to (1 << 32).
Review comment:
Wrong comment, I think. `1 << 32` is `4294967296L`.
After this change it could be interpreted as `z` being `1 << 32`. Maybe
change the text to `4294967296 is 1 << 32` (which helps devs with the
magic-numbers issue)
--
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] [Resolved] (JEXL-359) Allow per-operator arithmetic handling of null arguments
[ https://issues.apache.org/jira/browse/JEXL-359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro resolved JEXL-359. Resolution: Fixed - Refactored OperatorController to map back AST nodes to operator enum; - Expose overridable method in arithmetic to declare operator strictness; Commit [73bb93|https://github.com/apache/commons-jexl/commit/73bb932e6cf856d4516ec543a3335925cd4d88aa] > Allow per-operator arithmetic handling of null arguments > > > Key: JEXL-359 > URL: https://issues.apache.org/jira/browse/JEXL-359 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3 > > > WHAT > A JexlArithmetic declares its behaviour with respect to null arguments using > the strict flag. When strict, no operator is null-safe and each should > consider a null argument as an error. > It can not strictly be the case since '==' must be able to use null as > argument. > There are cases where one would like to retain 'strictness' for most > operators but relax the behaviour for a few. A typical case is '+' for string > and null where one would like to consider null as a valid argument even if > arithmetic is strict. > HOW > There is already a scaffolding for this feature with the OperatorController. > Refining it to associate the operator to a syntactic node allows controlling > whether the interpretation of that node will tolerate null arguments before > it is called. > An overridable method in the JexlArithmetic to determine whether an operator > is strict or null-safe exposes the intent (isStrict(JexlOperator)). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (CSV-294) CSVFormat does not support explicit " as escape char
[
https://issues.apache.org/jira/browse/CSV-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17492138#comment-17492138
]
Angus C edited comment on CSV-294 at 2/14/22, 5:58 PM:
---
Even the input string ("a") will cause the exception as Lexer.java treats the
second (") as an escape char and read the unescaped \r, and then complain for
missing the ending-quote (")
E.g.
{{CSVFormat.Builder.{_}create{_}().setEscape('"').build().parse({*}new{*}
StringReader("\"a\"")).getRecords();}}
I think you cannot use the quote char as escape char. commons-cvs already
implement the RFC part that the quote char is escaped by preceding quote char,
but not the escape char
E.g.
{{System.{*}_out_{*}.println("1 " +
CSVFormat.Builder.{_}create{_}().build().parse({*}new{*}
StringReader("\"a\"")).getRecords().get(0).get(0));}}
{{System.{*}_out_{*}.println("2 " +
CSVFormat.Builder.{_}create{_}().build().parse({*}new{*}
StringReader("\"\"\"a\"\"\"")).getRecords().get(0).get(0));}}
{{System.{*}_out_{*}.println("3 " +
CSVFormat.Builder.{_}create{_}().setQuote('|').build().parse({*}new{*}
StringReader("|a|")).getRecords().get(0).get(0));}}
{{System.{*}_out_{*}.println("4 " +
CSVFormat.Builder.{_}create{_}().setQuote('|').build().parse({*}new{*}
StringReader("|||a|||")).getRecords().get(0).get(0));}}
Output
--
{{1 a}}
{{2 "a"}}
{{3 a}}
{{4 |a|}}
was (Author: JIRAUSER285196):
Even the input string ("a") will cause the exception as Lexer.java treats the
second (") as an escape char and read the unescaped \r, and then complain for
missing the ending-quote (")
E.g.
{{CSVFormat.Builder.{_}create{_}().setEscape('"').build().parse(*new*
StringReader("\"a\"")).getRecords();}}
I think you cannot use the quote char as escape char. commons-cvs already
implement the RFC part that the quote char is escaped by preceding quote char,
but not the escape char
E.g.
{{System.*_out_*.println("1 " +
CSVFormat.Builder.{_}create{_}().build().parse(*new*
StringReader("\"a\"")).getRecords().get(0).get(0));}}{{ }}
{{System.*_out_*.println("2 " +
CSVFormat.Builder.{_}create{_}().build().parse(*new*
StringReader("\"\"\"a\"\"\"")).getRecords().get(0).get(0));}}{{ }}
{{System.*_out_*.println("3 " +
CSVFormat.Builder.{_}create{_}().setQuote('|').build().parse(*new*
StringReader("|a|")).getRecords().get(0).get(0));}}{{ }}
{{System.*_out_*.println("4 " +
CSVFormat.Builder.{_}create{_}().setQuote('|').build().parse(*new*
StringReader("|||a|||")).getRecords().get(0).get(0));}}
Output
--
{{1 a}}
{{2 "a"}}
{{3 a}}
{{4 |a|}}
> CSVFormat does not support explicit " as escape char
>
>
> Key: CSV-294
> URL: https://issues.apache.org/jira/browse/CSV-294
> Project: Commons CSV
> Issue Type: Bug
>Affects Versions: 1.9.0
>Reporter: Joern Huxhorn
>Priority: Major
> Attachments: JiraCsv294Test.java
>
>
> Reading data that contains " does not work if escape character is *manually
> set to {{'"'}}* as specified in [RFC
> 4180|https://datatracker.ietf.org/doc/html/rfc4180].
> *It works for other escape characters or if no escape character is explicitly
> defined in the format.*
> This line in {{Lexer.java}} is responsible for the originally quite erroneous
> ticket:
> {{this.escape = mapNullToDisabled(format.getEscapeCharacter());}}
> From this line I (wrongly) deduced that an unspecified escape character would
> actually disable escaping. Because of that I wanted to enable it by setting
> it to {{'"'}} which causes exceptions in the Lexer for perfectly valid input.
> That in turn convinced my that this is a way bigger issue than it is. Sorry
> about that.
> I don't think that the current situation is ideal, though.
> I would not have been this confused if {{CSVFormat}} would be more explicit
> about the escape char that will be used, i.e. if {{toString()}} would show
> the implicitly used quote character or print - in case of {{null}} - that
> this means it's using the quote character. It is currently omitted from the
> output if it is not set explicitly.
> There is also no documentation about what {{null}} as escape character
> actually means - it may be documented somewhere but isn't documented for
> {{CSVFormat.getEscapeCharacter()}} or {{CSVFormat.Builder.set/getEscape()}}
> methods.
> And setting the escape character explicitly to the value specified in the RFC
> should certainly not fail, even if setting it to that value is superfluous
> since {{null}} behaves exactly the same.
> h4. Relevant part of the RFC:
> 7. If double-quotes are used to enclose fields, then a double-quote
> appearing inside a field must be escaped by preceding it with
> another double quote. For example:
> "aaa","b""bb","ccc"
> h4. Related issue:
>
[jira] [Commented] (CSV-294) CSVFormat does not support explicit " as escape char
[
https://issues.apache.org/jira/browse/CSV-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17492138#comment-17492138
]
Angus C commented on CSV-294:
-
Even the input string ("a") will cause the exception as Lexer.java treats the
second (") as an escape char and read the unescaped \r, and then complain for
missing the ending-quote (")
E.g.
{{CSVFormat.Builder.{_}create{_}().setEscape('"').build().parse(*new*
StringReader("\"a\"")).getRecords();}}
I think you cannot use the quote char as escape char. commons-cvs already
implement the RFC part that the quote char is escaped by preceding quote char,
but not the escape char
E.g.
{{System.*_out_*.println("1 " +
CSVFormat.Builder.{_}create{_}().build().parse(*new*
StringReader("\"a\"")).getRecords().get(0).get(0));}}{{ }}
{{System.*_out_*.println("2 " +
CSVFormat.Builder.{_}create{_}().build().parse(*new*
StringReader("\"\"\"a\"\"\"")).getRecords().get(0).get(0));}}{{ }}
{{System.*_out_*.println("3 " +
CSVFormat.Builder.{_}create{_}().setQuote('|').build().parse(*new*
StringReader("|a|")).getRecords().get(0).get(0));}}{{ }}
{{System.*_out_*.println("4 " +
CSVFormat.Builder.{_}create{_}().setQuote('|').build().parse(*new*
StringReader("|||a|||")).getRecords().get(0).get(0));}}
Output
--
{{1 a}}
{{2 "a"}}
{{3 a}}
{{4 |a|}}
> CSVFormat does not support explicit " as escape char
>
>
> Key: CSV-294
> URL: https://issues.apache.org/jira/browse/CSV-294
> Project: Commons CSV
> Issue Type: Bug
>Affects Versions: 1.9.0
>Reporter: Joern Huxhorn
>Priority: Major
> Attachments: JiraCsv294Test.java
>
>
> Reading data that contains " does not work if escape character is *manually
> set to {{'"'}}* as specified in [RFC
> 4180|https://datatracker.ietf.org/doc/html/rfc4180].
> *It works for other escape characters or if no escape character is explicitly
> defined in the format.*
> This line in {{Lexer.java}} is responsible for the originally quite erroneous
> ticket:
> {{this.escape = mapNullToDisabled(format.getEscapeCharacter());}}
> From this line I (wrongly) deduced that an unspecified escape character would
> actually disable escaping. Because of that I wanted to enable it by setting
> it to {{'"'}} which causes exceptions in the Lexer for perfectly valid input.
> That in turn convinced my that this is a way bigger issue than it is. Sorry
> about that.
> I don't think that the current situation is ideal, though.
> I would not have been this confused if {{CSVFormat}} would be more explicit
> about the escape char that will be used, i.e. if {{toString()}} would show
> the implicitly used quote character or print - in case of {{null}} - that
> this means it's using the quote character. It is currently omitted from the
> output if it is not set explicitly.
> There is also no documentation about what {{null}} as escape character
> actually means - it may be documented somewhere but isn't documented for
> {{CSVFormat.getEscapeCharacter()}} or {{CSVFormat.Builder.set/getEscape()}}
> methods.
> And setting the escape character explicitly to the value specified in the RFC
> should certainly not fail, even if setting it to that value is superfluous
> since {{null}} behaves exactly the same.
> h4. Relevant part of the RFC:
> 7. If double-quotes are used to enclose fields, then a double-quote
> appearing inside a field must be escaped by preceding it with
> another double quote. For example:
> "aaa","b""bb","ccc"
> h4. Related issue:
> https://issues.apache.org/jira/browse/CSV-150
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (JEXL-357) Configure accessible packages/classes/methods/fields
[ https://issues.apache.org/jira/browse/JEXL-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17492104#comment-17492104 ] Henri Biestro commented on JEXL-357: Hardened the code wrt package permissions. Thanks Dmitri. Commit [fed413d|https://github.com/apache/commons-jexl/commit/fed413dfa27ebb51dbeda1f173596d09c4e8d989] > Configure accessible packages/classes/methods/fields > - > > Key: JEXL-357 > URL: https://issues.apache.org/jira/browse/JEXL-357 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3 > > > The @NoJexl annotation allows 'hiding' functional elements from scripts; this > features will allow Jexl introspection to completely ignore existing > packages/classes/methods/fields ensuring they can not be called. > Acting (more or less) as a security manager, this will allow fine > configuration of what scripts are allowed to access on a platform. Used in > conjunction with Sandboxing, how much is exposed can be limited to explicit > permission. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [commons-compress] garydgregory commented on pull request #247: Use Math.min and Math.max calculations.
garydgregory commented on pull request #247: URL: https://github.com/apache/commons-compress/pull/247#issuecomment-1039261822 It does seem to me that this makes the code easier to read, what do others think? @kinow ? -- 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-compress] garydgregory commented on a change in pull request #206: Minor changes
garydgregory commented on a change in pull request #206:
URL: https://github.com/apache/commons-compress/pull/206#discussion_r805995048
##
File path:
src/main/java/org/apache/commons/compress/archivers/zip/ZipArchiveEntry.java
##
@@ -777,7 +777,7 @@ public String getName() {
@Override
public boolean isDirectory() {
final String n = getName();
-return n != null && n.endsWith("/");
+return n.endsWith("/");
Review comment:
It does seem that `getName()` can never be null, so maybe just `return
getName().endsWith("/");` ? Same for other getName() call sites?
--
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-compress] garydgregory commented on pull request #242: bzip2: calculate median-of-3 on unsigned values
garydgregory commented on pull request #242: URL: https://github.com/apache/commons-compress/pull/242#issuecomment-1039250469 @kinow , any thoughts here? -- 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] (COMPRESS-514) SevenZFile fails with encoded header over 2GiB
[
https://issues.apache.org/jira/browse/COMPRESS-514?focusedWorklogId=726372=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-726372
]
ASF GitHub Bot logged work on COMPRESS-514:
---
Author: ASF GitHub Bot
Created on: 14/Feb/22 15:53
Start Date: 14/Feb/22 15:53
Worklog Time Spent: 10m
Work Description: garydgregory commented on a change in pull request #98:
URL: https://github.com/apache/commons-compress/pull/98#discussion_r805984987
##
File path:
src/main/java/org/apache/commons/compress/archivers/sevenz/HeaderChannelBuffer.java
##
@@ -0,0 +1,174 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ *
+ */
+package org.apache.commons.compress.archivers.sevenz;
+
+import org.apache.commons.compress.utils.IOUtils;
+
+import java.io.IOException;
+import java.io.InputStream;
+import java.nio.BufferUnderflowException;
+import java.nio.ByteBuffer;
+import java.nio.ByteOrder;
+import java.nio.channels.Channels;
+import java.nio.channels.ReadableByteChannel;
+import java.util.zip.CRC32;
+
+/**
+ * Enables little-endian primitive type reads from a {@link
ReadableByteChannel}
+ * or {@link InputStream}, internally using a paged-in {@link ByteBuffer}.
+ *
+ * Access is serial only but does allow a
+ * virtual buffer capacity of {@code Long.MAX_VALUE}.
+ * If the requested capacity is within the maximum page size (default 16MiB)
+ * the buffer will be fully read and held in a {@link HeaderInMemoryBuffer}.
+ *
+ * @NotThreadSafe
+ * @since 1.21
+ */
+class HeaderChannelBuffer implements HeaderBuffer {
+private static final int DEFAULT_PAGE_MAX = 16_777_216;
+// This must match the largest get (currently getLong)
+private static final int MAX_GET_ELEMENT_SIZE = 8;
+private final ReadableByteChannel channel;
+private final ByteBuffer buffer;
+private long remaining;
+
+private HeaderChannelBuffer(final ReadableByteChannel channel, final long
capacity, final int maxPageBytes) {
+this.channel = channel;
+int limit = (int) Math.min(maxPageBytes, capacity);
+this.buffer =
ByteBuffer.allocate(limit).order(ByteOrder.LITTLE_ENDIAN);
+this.remaining = capacity;
+}
+
+public static HeaderBuffer create(final ReadableByteChannel channel, final
long capacity, final int maxPageBytes)
+throws IOException {
+if (maxPageBytes < MAX_GET_ELEMENT_SIZE) {
+throw new IllegalArgumentException("Page size must be at least " +
MAX_GET_ELEMENT_SIZE);
+}
+if (capacity <= maxPageBytes) {
+ByteBuffer buf = ByteBuffer.allocate((int)
capacity).order(ByteOrder.LITTLE_ENDIAN);
+IOUtils.readFully(channel, buf);
+buf.flip();
+return new HeaderInMemoryBuffer(buf);
+}
+HeaderChannelBuffer channelBuffer = new HeaderChannelBuffer(channel,
capacity, maxPageBytes);
+channelBuffer.fill();
+return channelBuffer;
+}
+
+public static HeaderBuffer create(final ReadableByteChannel channel, final
long capacity) throws IOException {
+return HeaderChannelBuffer.create(channel, capacity, DEFAULT_PAGE_MAX);
+}
+
+public static HeaderBuffer create(final InputStream inputStream, final
long capacity, final int maxPageBytes)
+throws IOException {
+return create(Channels.newChannel(inputStream), capacity,
maxPageBytes);
+}
+
+public static HeaderBuffer create(final InputStream inputStream, final
long capacity) throws IOException {
+return create(Channels.newChannel(inputStream), capacity,
DEFAULT_PAGE_MAX);
+}
+
+@Override
+public boolean hasCRC() {
+return false;
+}
+
+@Override
+public CRC32 getCRC() throws IOException {
+throw new IOException("CRC is not implemented for this header type");
+}
+
+@Override
+public void get(byte[] dst) throws IOException {
+int remainingBytes = dst.length;
+do {
+int length = Math.min(buffer.remaining(), remainingBytes);
+buffer.get(dst, dst.length - remainingBytes, length);
+
[GitHub] [commons-compress] garydgregory commented on a change in pull request #98: COMPRESS-514: SevenZFile header buffers over 2G
garydgregory commented on a change in pull request #98:
URL: https://github.com/apache/commons-compress/pull/98#discussion_r805984987
##
File path:
src/main/java/org/apache/commons/compress/archivers/sevenz/HeaderChannelBuffer.java
##
@@ -0,0 +1,174 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ *
+ */
+package org.apache.commons.compress.archivers.sevenz;
+
+import org.apache.commons.compress.utils.IOUtils;
+
+import java.io.IOException;
+import java.io.InputStream;
+import java.nio.BufferUnderflowException;
+import java.nio.ByteBuffer;
+import java.nio.ByteOrder;
+import java.nio.channels.Channels;
+import java.nio.channels.ReadableByteChannel;
+import java.util.zip.CRC32;
+
+/**
+ * Enables little-endian primitive type reads from a {@link
ReadableByteChannel}
+ * or {@link InputStream}, internally using a paged-in {@link ByteBuffer}.
+ *
+ * Access is serial only but does allow a
+ * virtual buffer capacity of {@code Long.MAX_VALUE}.
+ * If the requested capacity is within the maximum page size (default 16MiB)
+ * the buffer will be fully read and held in a {@link HeaderInMemoryBuffer}.
+ *
+ * @NotThreadSafe
+ * @since 1.21
+ */
+class HeaderChannelBuffer implements HeaderBuffer {
+private static final int DEFAULT_PAGE_MAX = 16_777_216;
+// This must match the largest get (currently getLong)
+private static final int MAX_GET_ELEMENT_SIZE = 8;
+private final ReadableByteChannel channel;
+private final ByteBuffer buffer;
+private long remaining;
+
+private HeaderChannelBuffer(final ReadableByteChannel channel, final long
capacity, final int maxPageBytes) {
+this.channel = channel;
+int limit = (int) Math.min(maxPageBytes, capacity);
+this.buffer =
ByteBuffer.allocate(limit).order(ByteOrder.LITTLE_ENDIAN);
+this.remaining = capacity;
+}
+
+public static HeaderBuffer create(final ReadableByteChannel channel, final
long capacity, final int maxPageBytes)
+throws IOException {
+if (maxPageBytes < MAX_GET_ELEMENT_SIZE) {
+throw new IllegalArgumentException("Page size must be at least " +
MAX_GET_ELEMENT_SIZE);
+}
+if (capacity <= maxPageBytes) {
+ByteBuffer buf = ByteBuffer.allocate((int)
capacity).order(ByteOrder.LITTLE_ENDIAN);
+IOUtils.readFully(channel, buf);
+buf.flip();
+return new HeaderInMemoryBuffer(buf);
+}
+HeaderChannelBuffer channelBuffer = new HeaderChannelBuffer(channel,
capacity, maxPageBytes);
+channelBuffer.fill();
+return channelBuffer;
+}
+
+public static HeaderBuffer create(final ReadableByteChannel channel, final
long capacity) throws IOException {
+return HeaderChannelBuffer.create(channel, capacity, DEFAULT_PAGE_MAX);
+}
+
+public static HeaderBuffer create(final InputStream inputStream, final
long capacity, final int maxPageBytes)
+throws IOException {
+return create(Channels.newChannel(inputStream), capacity,
maxPageBytes);
+}
+
+public static HeaderBuffer create(final InputStream inputStream, final
long capacity) throws IOException {
+return create(Channels.newChannel(inputStream), capacity,
DEFAULT_PAGE_MAX);
+}
+
+@Override
+public boolean hasCRC() {
+return false;
+}
+
+@Override
+public CRC32 getCRC() throws IOException {
+throw new IOException("CRC is not implemented for this header type");
+}
+
+@Override
+public void get(byte[] dst) throws IOException {
+int remainingBytes = dst.length;
+do {
+int length = Math.min(buffer.remaining(), remainingBytes);
+buffer.get(dst, dst.length - remainingBytes, length);
+remainingBytes -= length;
+} while (refilled(remainingBytes));
+}
+
+private boolean refilled(final int remainingBytes) throws IOException {
+if (remainingBytes <= 0) {
+return false;
+ }
Review comment:
Fix formatting please.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL
[GitHub] [commons-compress] garydgregory merged pull request #248: Fix thread safety issues when encoding 7z password
garydgregory merged pull request #248: URL: https://github.com/apache/commons-compress/pull/248 -- 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-beanutils] garydgregory commented on pull request #106: BEANUTILS-550: correction of returning default value by StringConverter
garydgregory commented on pull request #106: URL: https://github.com/apache/commons-beanutils/pull/106#issuecomment-1039097804 @JKLedzion Thank you for the PR. Don't use Javadoc comments for comments that are not Javadoc. Inline comments would be more appropriate. -- 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] (VFS-816) Apache commons VFS2 code is taking 5 min to resolve the file in SFTP
[ https://issues.apache.org/jira/browse/VFS-816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17491963#comment-17491963 ] Gary D. Gregory commented on VFS-816: - Hello [~Veeraswamy Naidu] Vfs1 and 2 are different code bases that depend on different version of other libraries, so who knows what is really going on, you'll have to fire up your debugger or visualvm to see where time is being spent > Apache commons VFS2 code is taking 5 min to resolve the file in SFTP > > > Key: VFS-816 > URL: https://issues.apache.org/jira/browse/VFS-816 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.7.0 >Reporter: Veeraswamy Naidu Pulaparti >Priority: Major > Attachments: SFTPTest.rtf > > > Hi Team, when i used the commons-vfs2-2.7.0.jar file in my application it is > taking around 5 min to resolve the file for 1kb as well. > when the same code is used by changing the packages from vf2 -> vfs and using > the jar commons-vfs-2.0.jar it is working normally and the same step is > coming out within milliseconds. > Could you please check the same and let me know if i am missing anything > here. For reference i am attaching reference java code. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (VFS-816) Apache commons VFS2 code is taking 5 min to resolve the file in SFTP
[ https://issues.apache.org/jira/browse/VFS-816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17491962#comment-17491962 ] Gary D. Gregory commented on VFS-816: - What is in the RTF file? > Apache commons VFS2 code is taking 5 min to resolve the file in SFTP > > > Key: VFS-816 > URL: https://issues.apache.org/jira/browse/VFS-816 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.7.0 >Reporter: Veeraswamy Naidu Pulaparti >Priority: Major > Attachments: SFTPTest.rtf > > > Hi Team, when i used the commons-vfs2-2.7.0.jar file in my application it is > taking around 5 min to resolve the file for 1kb as well. > when the same code is used by changing the packages from vf2 -> vfs and using > the jar commons-vfs-2.0.jar it is working normally and the same step is > coming out within milliseconds. > Could you please check the same and let me know if i am missing anything > here. For reference i am attaching reference java code. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [commons-codec] garydgregory commented on pull request #104: Maven Wrapper v3.1.0 with Maven v3.8.4
garydgregory commented on pull request #104: URL: https://github.com/apache/commons-codec/pull/104#issuecomment-1039031129 I'm still -1 for now. We have GitHub Actions builds, we used to also have Jenkins builds, but I'm not sure we need those unless we want to push SNAPSHOTS from within Apache. Forcing whatever pile of scripts and files in the root of the project makes a bigger mess, and what makes it worse and is confusing is then looking at whatever files are used to define CI builds. Fortunately, I recently dropped most Travis CI config files, so that leaves us with GitHub and Jenkins (which is defined elsewhere) -- 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] (BEANUTILS-550) Converting null in to String is always null
[ https://issues.apache.org/jira/browse/BEANUTILS-550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17491917#comment-17491917 ] Justyna Kubica-Ledzion commented on BEANUTILS-550: -- Hi, I’ve prepared PR for this issue: [https://github.com/apache/commons-beanutils/pull/106]. Assignment of default value in StringConverter didn’t work as method _getDefault(final_ *__* _Class type),_ only for String.class, returned null instead of default value. I’ve changed this method to return default value also for String.class. Could you please review and let me know if this modification is OK? I would appreciate any feedback. Justyna > Converting null in to String is always null > --- > > Key: BEANUTILS-550 > URL: https://issues.apache.org/jira/browse/BEANUTILS-550 > Project: Commons BeanUtils > Issue Type: Bug > Components: ConvertUtils Converters >Affects Versions: 1.9.4 >Reporter: Alessandro >Priority: Major > > Even if the defaultValue property of StringConverter is set to a non-null > value, the conversion process always responds with a null. > The clue is in the getDefault method of the AbstractConverter class which, in > case the request is to convert a null to a String, returns null -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [commons-beanutils] JKLedzion opened a new pull request #106: BEANUTILS-550: correction of returning default value by StringConverter
JKLedzion opened a new pull request #106: URL: https://github.com/apache/commons-beanutils/pull/106 PR for Jira issue: BEANUTILS-550. Assignment of default value in StringConverter didn’t work as method getDefault(final Class type), only for String.class, returned null instead of default value. I’ve changed this method to return default value also for String.class. Could you please review and let me know if this modification is OK? I would appreciate any feedback. Justyna -- 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] [Created] (VFS-816) Apache commons VFS2 code is taking 5 min to resolve the file in SFTP
Veeraswamy Naidu Pulaparti created VFS-816: -- Summary: Apache commons VFS2 code is taking 5 min to resolve the file in SFTP Key: VFS-816 URL: https://issues.apache.org/jira/browse/VFS-816 Project: Commons VFS Issue Type: Bug Affects Versions: 2.7.0 Reporter: Veeraswamy Naidu Pulaparti Attachments: SFTPTest.rtf Hi Team, when i used the commons-vfs2-2.7.0.jar file in my application it is taking around 5 min to resolve the file for 1kb as well. when the same code is used by changing the packages from vf2 -> vfs and using the jar commons-vfs-2.0.jar it is working normally and the same step is coming out within milliseconds. Could you please check the same and let me know if i am missing anything here. For reference i am attaching reference java code. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work logged] (COLLECTIONS-803) CaseInsensitiveMap prevent duplicate key conversion on put
[
https://issues.apache.org/jira/browse/COLLECTIONS-803?focusedWorklogId=726181=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-726181
]
ASF GitHub Bot logged work on COLLECTIONS-803:
--
Author: ASF GitHub Bot
Created on: 14/Feb/22 09:04
Start Date: 14/Feb/22 09:04
Worklog Time Spent: 10m
Work Description: Simulant87 commented on pull request #276:
URL:
https://github.com/apache/commons-collections/pull/276#issuecomment-1038825792
@garydgregory Thank you for the feedback.
I added a test that verifies the `convertKey` method is only called once,
which fails currently on the master branch without the production code changes
provided.
I kindly request another review. Please let me know if there is anything
else missing.
--
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: 726181)
Time Spent: 50m (was: 40m)
> CaseInsensitiveMap prevent duplicate key conversion on put
> --
>
> Key: COLLECTIONS-803
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-803
> Project: Commons Collections
> Issue Type: Improvement
> Components: Map
>Affects Versions: 4.4
>Reporter: Simulant
>Priority: Minor
> Labels: performance
> Time Spent: 50m
> Remaining Estimate: 0h
>
> When adding a new item into a {{CaseInsensitiveMap}} the {{convertKey(key)}}
> method is called twice, once in the {{put(key, value)}} method and second in
> the {{createEntry(next, hashCode, key, value)}} method. The result could be
> re-used resulting in a better performance.
> Depending on the {{toString()}} implementation of the key and the resulting
> length of the key before the lower case conversion the operation can get
> expensive and should not be called twice, as the {{CaseInsensitiveMap}}
> overwrites the {{convertKey(key)}} method and makes it more expensive and
> depending on the input unlike in the implementation of the
> {{AbstractHashedMap}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [commons-collections] Simulant87 commented on pull request #276: COLLECTIONS-803: prevent duplicate call to convertKey on put for CaseInsensitiveMap
Simulant87 commented on pull request #276: URL: https://github.com/apache/commons-collections/pull/276#issuecomment-1038825792 @garydgregory Thank you for the feedback. I added a test that verifies the `convertKey` method is only called once, which fails currently on the master branch without the production code changes provided. I kindly request another review. Please let me know if there is anything else missing. -- 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-803) CaseInsensitiveMap prevent duplicate key conversion on put
[
https://issues.apache.org/jira/browse/COLLECTIONS-803?focusedWorklogId=726180=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-726180
]
ASF GitHub Bot logged work on COLLECTIONS-803:
--
Author: ASF GitHub Bot
Created on: 14/Feb/22 09:03
Start Date: 14/Feb/22 09:03
Worklog Time Spent: 10m
Work Description: Simulant87 removed a comment on pull request #276:
URL:
https://github.com/apache/commons-collections/pull/276#issuecomment-1029455359
@garydgregory Thank you for the feedback.
I added a test the verifies the `convertKey` method is only called once,
which fails currently on the master branch without the production code changes
provided.
--
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: 726180)
Time Spent: 40m (was: 0.5h)
> CaseInsensitiveMap prevent duplicate key conversion on put
> --
>
> Key: COLLECTIONS-803
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-803
> Project: Commons Collections
> Issue Type: Improvement
> Components: Map
>Affects Versions: 4.4
>Reporter: Simulant
>Priority: Minor
> Labels: performance
> Time Spent: 40m
> Remaining Estimate: 0h
>
> When adding a new item into a {{CaseInsensitiveMap}} the {{convertKey(key)}}
> method is called twice, once in the {{put(key, value)}} method and second in
> the {{createEntry(next, hashCode, key, value)}} method. The result could be
> re-used resulting in a better performance.
> Depending on the {{toString()}} implementation of the key and the resulting
> length of the key before the lower case conversion the operation can get
> expensive and should not be called twice, as the {{CaseInsensitiveMap}}
> overwrites the {{convertKey(key)}} method and makes it more expensive and
> depending on the input unlike in the implementation of the
> {{AbstractHashedMap}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [commons-collections] Simulant87 removed a comment on pull request #276: COLLECTIONS-803: prevent duplicate call to convertKey on put for CaseInsensitiveMap
Simulant87 removed a comment on pull request #276: URL: https://github.com/apache/commons-collections/pull/276#issuecomment-1029455359 @garydgregory Thank you for the feedback. I added a test the verifies the `convertKey` method is only called once, which fails currently on the master branch without the production code changes provided. -- 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
