[jira] [Commented] (LANG-1402) ArrayUtils should have null and index-safe get methods.
[
https://issues.apache.org/jira/browse/LANG-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16537924#comment-16537924
]
Mark Dacek commented on LANG-1402:
--
I can't provide that. In any case, I'm willing to do just isArrayIndexValid if
a few others chime in. Thanks for the feedback!
> ArrayUtils should have null and index-safe get methods.
> ---
>
> Key: LANG-1402
> URL: https://issues.apache.org/jira/browse/LANG-1402
> Project: Commons Lang
> Issue Type: New Feature
> Components: General
>Reporter: Mark Dacek
>Priority: Minor
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> There should be a safe way to retrieve a value from array without having to
> check for null and length. It would be a very simple implementation but could
> save developers a great deal of time in writing and testing.
>
> Something like
>
> {code:java}
> String[] a = null;
> ArrayUtils.get(a, 5); //returns null
> a = new String[5];
> ArrayUtils.get(a, 10); // returns null
>
> a[0] = "Hello World";
> ArrayUtils.get(a, 0); // returns "Hello World"
> {code}
>
> We could handle a few other cases - a default return value. The
> tricky/annoying thing is the need to cast everything in order to make this
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LANG-1403) DateUtils.truncate(Object date, int field) breaks Java type safety.
[ https://issues.apache.org/jira/browse/LANG-1403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16537078#comment-16537078 ] Gary Gregory commented on LANG-1403: Note: Public methods can be removed in a major release. > DateUtils.truncate(Object date, int field) breaks Java type safety. > --- > > Key: LANG-1403 > URL: https://issues.apache.org/jira/browse/LANG-1403 > Project: Commons Lang > Issue Type: Wish >Affects Versions: 3.7 >Reporter: Christian >Priority: Minor > > The DateUtils.truncate have three types of possible date input. > Calendar, Date, and Object. > The method which accept object as input is not necessary and will break the > type safety idea of java itself, so a wrong object will cause an runtime > exception and can't be found at compile time. > > Solution: > remove DateUtils.truncate(Object, int) method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (LANG-1403) DateUtils.truncate(Object date, int field) breaks Java type safety.
[ https://issues.apache.org/jira/browse/LANG-1403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated LANG-1403: --- Priority: Minor (was: Major) Issue Type: Wish (was: Bug) > DateUtils.truncate(Object date, int field) breaks Java type safety. > --- > > Key: LANG-1403 > URL: https://issues.apache.org/jira/browse/LANG-1403 > Project: Commons Lang > Issue Type: Wish >Affects Versions: 3.7 >Reporter: Christian >Priority: Minor > > The DateUtils.truncate have three types of possible date input. > Calendar, Date, and Object. > The method which accept object as input is not necessary and will break the > type safety idea of java itself, so a wrong object will cause an runtime > exception and can't be found at compile time. > > Solution: > remove DateUtils.truncate(Object, int) method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (LANG-1403) DateUtils.truncate(Object date, int field) breaks Java type safety.
Christian created LANG-1403: --- Summary: DateUtils.truncate(Object date, int field) breaks Java type safety. Key: LANG-1403 URL: https://issues.apache.org/jira/browse/LANG-1403 Project: Commons Lang Issue Type: Bug Affects Versions: 3.7 Reporter: Christian The DateUtils.truncate have three types of possible date input. Calendar, Date, and Object. The method which accept object as input is not necessary and will break the type safety idea of java itself, so a wrong object will cause an runtime exception and can't be found at compile time. Solution: remove DateUtils.truncate(Object, int) method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (VALIDATOR-441) List of TLDs is not updated according to the latest IANA db.
[ https://issues.apache.org/jira/browse/VALIDATOR-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved VALIDATOR-441. Resolution: Duplicate > List of TLDs is not updated according to the latest IANA db. > > > Key: VALIDATOR-441 > URL: https://issues.apache.org/jira/browse/VALIDATOR-441 > Project: Commons Validator > Issue Type: Bug >Affects Versions: 1.6 >Reporter: Sergey Belyakov >Priority: Major > > Please check the > [https://www.iana.org/domains/root/db|https://www.iana.org/domains/root/db] > For example `.sport` or `.africa` is not present in `DomainValidator.class` > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (VALIDATOR-441) List of TLDs is not updated according to the latest IANA db.
[ https://issues.apache.org/jira/browse/VALIDATOR-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Belyakov updated VALIDATOR-441: -- Summary: List of TLDs is not updated according to the latest IANA db. (was: List of TLDs is not updated according to IANA db.) > List of TLDs is not updated according to the latest IANA db. > > > Key: VALIDATOR-441 > URL: https://issues.apache.org/jira/browse/VALIDATOR-441 > Project: Commons Validator > Issue Type: Bug >Affects Versions: 1.6 >Reporter: Sergey Belyakov >Priority: Major > > Please check the > [https://www.iana.org/domains/root/db|https://www.iana.org/domains/root/db] > For example `.sport` or `.africa` is not present in `DomainValidator.class` > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (VALIDATOR-441) List of TLDs is not updated according to IANA db.
[ https://issues.apache.org/jira/browse/VALIDATOR-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Belyakov updated VALIDATOR-441: -- Description: Please check the [https://www.iana.org/domains/root/db|https://www.iana.org/domains/root/db] For example `.sport` or `.africa` is not present in `DomainValidator.class` was: Please check the [https://www.iana.org/domains/root/db|https://www.iana.org/domains/root/db[]|https://www.iana.org/domains/root/db] For example `.sport` or `.africa` is not present in `DomainValidator.class` > List of TLDs is not updated according to IANA db. > - > > Key: VALIDATOR-441 > URL: https://issues.apache.org/jira/browse/VALIDATOR-441 > Project: Commons Validator > Issue Type: Bug >Affects Versions: 1.6 >Reporter: Sergey Belyakov >Priority: Major > > Please check the > [https://www.iana.org/domains/root/db|https://www.iana.org/domains/root/db] > For example `.sport` or `.africa` is not present in `DomainValidator.class` > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (VALIDATOR-441) List of TLDs is not updated according to IANA db.
Sergey Belyakov created VALIDATOR-441: - Summary: List of TLDs is not updated according to IANA db. Key: VALIDATOR-441 URL: https://issues.apache.org/jira/browse/VALIDATOR-441 Project: Commons Validator Issue Type: Bug Affects Versions: 1.6 Reporter: Sergey Belyakov Please check the [https://www.iana.org/domains/root/db|https://www.iana.org/domains/root/db[]|https://www.iana.org/domains/root/db] For example `.sport` or `.africa` is not present in `DomainValidator.class` -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (LANG-1402) ArrayUtils should have null and index-safe get methods.
[
https://issues.apache.org/jira/browse/LANG-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16536750#comment-16536750
]
Sebb commented on LANG-1402:
Yes, I mean actual code examples.
Does the code in question really not care if the array is null or empty?
I would have expected such conditions to already been handled in production
code.
> ArrayUtils should have null and index-safe get methods.
> ---
>
> Key: LANG-1402
> URL: https://issues.apache.org/jira/browse/LANG-1402
> Project: Commons Lang
> Issue Type: New Feature
> Components: General
>Reporter: Mark Dacek
>Priority: Minor
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> There should be a safe way to retrieve a value from array without having to
> check for null and length. It would be a very simple implementation but could
> save developers a great deal of time in writing and testing.
>
> Something like
>
> {code:java}
> String[] a = null;
> ArrayUtils.get(a, 5); //returns null
> a = new String[5];
> ArrayUtils.get(a, 10); // returns null
>
> a[0] = "Hello World";
> ArrayUtils.get(a, 0); // returns "Hello World"
> {code}
>
> We could handle a few other cases - a default return value. The
> tricky/annoying thing is the need to cast everything in order to make this
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COMPRESS-459) CPIO fails decoding multibyte name entries
[
https://issues.apache.org/jira/browse/COMPRESS-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16536739#comment-16536739
]
ASF GitHub Bot commented on COMPRESS-459:
-
Github user coveralls commented on the issue:
https://github.com/apache/commons-compress/pull/67
[](https://coveralls.io/builds/17891202)
Coverage increased (+0.002%) to 86.355% when pulling
**715352d3343358539a40b9623a9a00beb115ff30 on
ctron:feature/fix_COMPRESS_459_1** into
**f5330f7e667f5a7245c8a5f3007cda04554c5fe2 on apache:master**.
> CPIO fails decoding multibyte name entries
> --
>
> Key: COMPRESS-459
> URL: https://issues.apache.org/jira/browse/COMPRESS-459
> Project: Commons Compress
> Issue Type: Bug
> Components: Compressors
>Affects Versions: 1.9, 1.17
>Reporter: Jens Reimann
>Priority: Major
>
> Having a CPIO archive in (e.g. UTF-8) mode and having a name entry with a
> name containing multi-byte characters the decoder fails.
> The problem IMHO is the "getHeaderPadCount" method, which assumes a single
> byte per character:
>
> {code:java}
> public int getHeaderPadCount(){
> if (this.alignmentBoundary == 0) { return 0; }
> int size = this.headerSize + 1; // Name has terminating null
> if (name != null) {
> size += name.length();
> }
> final int remain = size % this.alignmentBoundary;
> if (remain > 0){
> return this.alignmentBoundary - remain;
> }
> return 0;
> }
> {code}
> However this may (or may not) be true for UTF-8.
>
> Also it wouldn't be enough to call "String#getBytes(…)" as this might already
> transform the underlying bytes.
> The proper solution would be to provide the name size, as read from the CPIO
> stream, and pass it to the entry.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COMPRESS-459) CPIO fails decoding multibyte name entries
[
https://issues.apache.org/jira/browse/COMPRESS-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16536735#comment-16536735
]
ASF GitHub Bot commented on COMPRESS-459:
-
GitHub user ctron opened a pull request:
https://github.com/apache/commons-compress/pull/67
[COMPRESS-459] Fix reading of multibyte name entries
This fixes COMPRESS-459 by using the name number of bytes from the field
in the stream instead of relying on the assumption that each character
is exactly one byte, which isn't true for UTF-8, UTF-16 or other
multi-byte character encodings.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ctron/commons-compress
feature/fix_COMPRESS_459_1
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/commons-compress/pull/67.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #67
commit 715352d3343358539a40b9623a9a00beb115ff30
Author: Jens Reimann
Date: 2018-07-09T09:41:43Z
[COMPRESS-459] Fix reading of multibyte name entries
This fixes COMPRESS-459 by using the name number of bytes from the field
in the stream instead of relying on the assumption that each character
is exactly one byte, which isn't true for UTF-8, UTF-16 or other
multi-byte character encodings.
> CPIO fails decoding multibyte name entries
> --
>
> Key: COMPRESS-459
> URL: https://issues.apache.org/jira/browse/COMPRESS-459
> Project: Commons Compress
> Issue Type: Bug
> Components: Compressors
>Affects Versions: 1.9, 1.17
>Reporter: Jens Reimann
>Priority: Major
>
> Having a CPIO archive in (e.g. UTF-8) mode and having a name entry with a
> name containing multi-byte characters the decoder fails.
> The problem IMHO is the "getHeaderPadCount" method, which assumes a single
> byte per character:
>
> {code:java}
> public int getHeaderPadCount(){
> if (this.alignmentBoundary == 0) { return 0; }
> int size = this.headerSize + 1; // Name has terminating null
> if (name != null) {
> size += name.length();
> }
> final int remain = size % this.alignmentBoundary;
> if (remain > 0){
> return this.alignmentBoundary - remain;
> }
> return 0;
> }
> {code}
> However this may (or may not) be true for UTF-8.
>
> Also it wouldn't be enough to call "String#getBytes(…)" as this might already
> transform the underlying bytes.
> The proper solution would be to provide the name size, as read from the CPIO
> stream, and pass it to the entry.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (COMPRESS-459) CPIO fails decoding multibyte name entries
Jens Reimann created COMPRESS-459:
-
Summary: CPIO fails decoding multibyte name entries
Key: COMPRESS-459
URL: https://issues.apache.org/jira/browse/COMPRESS-459
Project: Commons Compress
Issue Type: Bug
Components: Compressors
Affects Versions: 1.17, 1.9
Reporter: Jens Reimann
Having a CPIO archive in (e.g. UTF-8) mode and having a name entry with a name
containing multi-byte characters the decoder fails.
The problem IMHO is the "getHeaderPadCount" method, which assumes a single byte
per character:
{code:java}
public int getHeaderPadCount(){
if (this.alignmentBoundary == 0) { return 0; }
int size = this.headerSize + 1; // Name has terminating null
if (name != null) {
size += name.length();
}
final int remain = size % this.alignmentBoundary;
if (remain > 0){
return this.alignmentBoundary - remain;
}
return 0;
}
{code}
However this may (or may not) be true for UTF-8.
Also it wouldn't be enough to call "String#getBytes(…)" as this might already
transform the underlying bytes.
The proper solution would be to provide the name size, as read from the CPIO
stream, and pass it to the entry.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
