[jira] [Commented] (LANG-1638) commons-lang3-3.11 - Date
[
https://issues.apache.org/jira/browse/LANG-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17567499#comment-17567499
]
Andrew Thomas commented on LANG-1638:
-
[~aavanathan] Based on your most recent update, I created a PR for this issue
to update the docs.
https://github.com/greatmastermario/commons-lang/tree/LANG-1638-Week-Year-Docs
> commons-lang3-3.11 - Date
> --
>
> Key: LANG-1638
> URL: https://issues.apache.org/jira/browse/LANG-1638
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.11
> Environment: Production
>Reporter: Shailendra Soni
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> December 27th to 31st 2020 gets converted into 2021 while trying to use
> `DateFormatUtils.format` method.
> {code:java}
> import org.apache.commons.lang3.time.DateFormatUtils;
> import org.apache.commons.lang3.time.DateUtils;
> public class DateEx {
> public static void main(String... args) throws Exception{
> String startDateStr = "2020-12-31";
> String startDate = DateFormatUtils
> .format(DateUtils.parseDate(startDateStr, "-MM-dd"),
> "-MM-dd-HH.MM.SS.mm");
> System.out.println("startDate with Timestamp - " + startDate);
> }
> }
> {code}
>
> Actual Output - 2021-12-31-00.12.00.00
> Expected Output - 2020-12-31-00.12.00.00
>
> Can someone look into it.
>
> Version :-
> # Java -> 1.8.0_212-b10
> # Common-lang3 -> 3.11
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (LANG-1667) Cannot Use ReflectionToStringBuilder for ArrayList on Java 16 Due to Module Access
[
https://issues.apache.org/jira/browse/LANG-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Thomas closed LANG-1667.
---
Fix merged and is working as expected
> Cannot Use ReflectionToStringBuilder for ArrayList on Java 16 Due to Module
> Access
> --
>
> Key: LANG-1667
> URL: https://issues.apache.org/jira/browse/LANG-1667
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.builder.*
>Affects Versions: 3.12.0
> Environment: JDK 16
>Reporter: Andrew Thomas
>Priority: Major
> Fix For: 3.13.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> In Java 16, many classes in java.base module are not able to be made
> accessible due to access restrictions on the module. An example is ArrayList.
>
> In ToStringBuilderTest.testReflectionHierarchyArrayList(), the test fails
> with the following error:
> {code:java}
> java.lang.reflect.InaccessibleObjectException: Unable to make field private
> static final java.lang.Object[]
> java.util.ArrayList.DEFAULTCAPACITY_EMPTY_ELEMENTDATA accessible: module
> java.base does not "opens java.util" to unnamed module @3339ad8e{code}
>
> This is causing build failures for all open PRs.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (LANG-1669) Known Failure in Java 16 When Parsing sq_MK Locale
[ https://issues.apache.org/jira/browse/LANG-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Thomas closed LANG-1669. --- Fix has been merged and is working as expected. > Known Failure in Java 16 When Parsing sq_MK Locale > -- > > Key: LANG-1669 > URL: https://issues.apache.org/jira/browse/LANG-1669 > Project: Commons Lang > Issue Type: Bug > Components: lang.time.* >Affects Versions: 3.12.0 > Environment: OpenJDK 16 >Reporter: Andrew Thomas >Priority: Major > Fix For: 3.13.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > There is a known issue that I do not see tracked already. In Java 16, there > is a failure when parsing sq_MK locale. This is not an issue with Apache > Commons-Lang, but an issue with the addition of day period support in OpenJDK > version 16. This is resolved in JDK 17, but there are still build failures in > JDK 16 due to this bug with OpenJDK. > See [[JDK-8262108] SimpleDateFormat formatting broken for sq_MK Locale - Java > Bug System|https://bugs-stage.openjdk.java.net/browse/JDK-8262108] > and [8262108: SimpleDateFormat formatting broken for sq_MK Locale · > openjdk/jdk@64e2130 > (github.com)|https://github.com/openjdk/jdk/commit/64e21307] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (LANG-1669) Known Failure in Java 16 When Parsing sq_MK Locale
[ https://issues.apache.org/jira/browse/LANG-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Thomas updated LANG-1669: Description: There is a known issue that I do not see tracked already. In Java 16, there is a failure when parsing sq_MK locale. This is not an issue with Apache Commons-Lang, but an issue with the addition of day period support in OpenJDK version 16. This is resolved in JDK 17, but there are still build failures in JDK 16 due to this bug with OpenJDK. See [[JDK-8262108] SimpleDateFormat formatting broken for sq_MK Locale - Java Bug System|https://bugs-stage.openjdk.java.net/browse/JDK-8262108] and [8262108: SimpleDateFormat formatting broken for sq_MK Locale · openjdk/jdk@64e2130 (github.com)|https://github.com/openjdk/jdk/commit/64e21307] was: There is a known issue that I do not see tracked already. In Java 16, there is a failure when parsing sq_MK locale. This is not an issue with Apache Commons-Lang, but an issue with the addition of day period support in OpenJDK version 16. This is resolved in JDK 17, but there are still build failures in JDK 16 due to this bug with OpenJDK. See [[JDK-8262108] SimpleDateFormat formatting broken for sq_MK Locale - Java Bug System|https://bugs-stage.openjdk.java.net/browse/JDK-8262108] and [8262108: SimpleDateFormat formatting broken for sq_MK Locale · openjdk/jdk@64e2130 (github.com)|https://github.com/openjdk/jdk/commit/64e21307] Since a backward compatibility fix may not resolve the test case issue (it is using SimpleDateFormat for validation, which is affected by the bug), there are two options. One is to skip that locale in the existing tests and explicitly write a test that validates the date as a hardcoded value. The other option is to ignore this failure for JDK 16 since it is not a failure with commons-lang. > Known Failure in Java 16 When Parsing sq_MK Locale > -- > > Key: LANG-1669 > URL: https://issues.apache.org/jira/browse/LANG-1669 > Project: Commons Lang > Issue Type: Bug > Components: lang.time.* >Affects Versions: 3.12.0 > Environment: OpenJDK 16 >Reporter: Andrew Thomas >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > There is a known issue that I do not see tracked already. In Java 16, there > is a failure when parsing sq_MK locale. This is not an issue with Apache > Commons-Lang, but an issue with the addition of day period support in OpenJDK > version 16. This is resolved in JDK 17, but there are still build failures in > JDK 16 due to this bug with OpenJDK. > See [[JDK-8262108] SimpleDateFormat formatting broken for sq_MK Locale - Java > Bug System|https://bugs-stage.openjdk.java.net/browse/JDK-8262108] > and [8262108: SimpleDateFormat formatting broken for sq_MK Locale · > openjdk/jdk@64e2130 > (github.com)|https://github.com/openjdk/jdk/commit/64e21307] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (LANG-1669) Known Failure in Java 16 When Parsing sq_MK Locale
[ https://issues.apache.org/jira/browse/LANG-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17401474#comment-17401474 ] Andrew Thomas commented on LANG-1669: - PR opened here: [LANG-1669|https://github.com/apache/commons-lang/pull/791] > Known Failure in Java 16 When Parsing sq_MK Locale > -- > > Key: LANG-1669 > URL: https://issues.apache.org/jira/browse/LANG-1669 > Project: Commons Lang > Issue Type: Bug > Components: lang.time.* >Affects Versions: 3.12.0 > Environment: OpenJDK 16 >Reporter: Andrew Thomas >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > There is a known issue that I do not see tracked already. In Java 16, there > is a failure when parsing sq_MK locale. This is not an issue with Apache > Commons-Lang, but an issue with the addition of day period support in OpenJDK > version 16. This is resolved in JDK 17, but there are still build failures in > JDK 16 due to this bug with OpenJDK. > See [[JDK-8262108] SimpleDateFormat formatting broken for sq_MK Locale - Java > Bug System|https://bugs-stage.openjdk.java.net/browse/JDK-8262108] > and [8262108: SimpleDateFormat formatting broken for sq_MK Locale · > openjdk/jdk@64e2130 > (github.com)|https://github.com/openjdk/jdk/commit/64e21307] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (LANG-1669) Known Failure in Java 16 When Parsing sq_MK Locale
Andrew Thomas created LANG-1669: --- Summary: Known Failure in Java 16 When Parsing sq_MK Locale Key: LANG-1669 URL: https://issues.apache.org/jira/browse/LANG-1669 Project: Commons Lang Issue Type: Bug Components: lang.time.* Affects Versions: 3.12.0 Environment: OpenJDK 16 Reporter: Andrew Thomas There is a known issue that I do not see tracked already. In Java 16, there is a failure when parsing sq_MK locale. This is not an issue with Apache Commons-Lang, but an issue with the addition of day period support in OpenJDK version 16. This is resolved in JDK 17, but there are still build failures in JDK 16 due to this bug with OpenJDK. See [[JDK-8262108] SimpleDateFormat formatting broken for sq_MK Locale - Java Bug System|https://bugs-stage.openjdk.java.net/browse/JDK-8262108] and [8262108: SimpleDateFormat formatting broken for sq_MK Locale · openjdk/jdk@64e2130 (github.com)|https://github.com/openjdk/jdk/commit/64e21307] Since a backward compatibility fix may not resolve the test case issue (it is using SimpleDateFormat for validation, which is affected by the bug), there are two options. One is to skip that locale in the existing tests and explicitly write a test that validates the date as a hardcoded value. The other option is to ignore this failure for JDK 16 since it is not a failure with commons-lang. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (LANG-1667) Cannot Use ReflectionToStringBuilder for ArrayList on Java 16 Due to Module Access
[
https://issues.apache.org/jira/browse/LANG-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17398423#comment-17398423
]
Andrew Thomas commented on LANG-1667:
-
Done. I have it working now. Opened a PR here: [LANG-1667: Allow tests to
access java.util classes such as ArrayList in Java 16 by greatmastermario ·
Pull Request #788 · apache/commons-lang
(github.com)|https://github.com/apache/commons-lang/pull/788]
> Cannot Use ReflectionToStringBuilder for ArrayList on Java 16 Due to Module
> Access
> --
>
> Key: LANG-1667
> URL: https://issues.apache.org/jira/browse/LANG-1667
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.builder.*
>Affects Versions: 3.12.0
> Environment: JDK 16
>Reporter: Andrew Thomas
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In Java 16, many classes in java.base module are not able to be made
> accessible due to access restrictions on the module. An example is ArrayList.
>
> In ToStringBuilderTest.testReflectionHierarchyArrayList(), the test fails
> with the following error:
> {code:java}
> java.lang.reflect.InaccessibleObjectException: Unable to make field private
> static final java.lang.Object[]
> java.util.ArrayList.DEFAULTCAPACITY_EMPTY_ELEMENTDATA accessible: module
> java.base does not "opens java.util" to unnamed module @3339ad8e{code}
>
> This is causing build failures for all open PRs.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (LANG-1667) Cannot Use ReflectionToStringBuilder for ArrayList on Java 16 Due to Module Access
Andrew Thomas created LANG-1667:
---
Summary: Cannot Use ReflectionToStringBuilder for ArrayList on
Java 16 Due to Module Access
Key: LANG-1667
URL: https://issues.apache.org/jira/browse/LANG-1667
Project: Commons Lang
Issue Type: Bug
Components: lang.builder.*
Affects Versions: 3.12.0
Environment: JDK 16
Reporter: Andrew Thomas
In Java 16, many classes in java.base module are not able to be made accessible
due to access restrictions on the module. An example is ArrayList.
In ToStringBuilderTest.testReflectionHierarchyArrayList(), the test fails with
the following error:
{code:java}
java.lang.reflect.InaccessibleObjectException: Unable to make field private
static final java.lang.Object[]
java.util.ArrayList.DEFAULTCAPACITY_EMPTY_ELEMENTDATA accessible: module
java.base does not "opens java.util" to unnamed module @3339ad8e{code}
This is causing build failures for all open PRs.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (LANG-1657) DiffBuilder: Type constraint for method append(..., DiffResult) too strict
[
https://issues.apache.org/jira/browse/LANG-1657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17395247#comment-17395247
]
Andrew Thomas commented on LANG-1657:
-
Opened a PR here: [Lang-1657|https://github.com/apache/commons-lang/pull/786]
> DiffBuilder: Type constraint for method append(..., DiffResult) too strict
> --
>
> Key: LANG-1657
> URL: https://issues.apache.org/jira/browse/LANG-1657
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.builder.*
>Affects Versions: 3.12.0
>Reporter: Matthias Welz
>Priority: Major
>
> The DiffBuilder has a method append which allows to append an existing
> DiffResult for a property. The example illustrates this the following way:
>
> {code:java}
> public class Person implements Diffable {
>String name;
>Address address; // implements Diffable
>...
>public DiffResult diff(Person obj) {
> return new DiffBuilder(this, obj, ToStringStyle.SHORT_PREFIX_STYLE)
>.append("name", this.name, obj.name)
>.append("address", this.address.diff(obj.address))
>.build();
>}
> }
> {code}
>
> However, the signature of the method was recently changed to:
> {code:java}
> public DiffBuilder append(final String fieldName, final DiffResult
> diffResult)
> {code}
> As a consequence, the example code won't compile anymore when using generics
> because the a _DiffBuilder_ will only accept _DiffResult_ but
> not _DiffResult_ for its append method.
> The signature should be:
> {code:java}
> public DiffBuilder append(final String fieldName, final DiffResult
> diffResult)
> {code}
> or:
> {code:java}
> public DiffBuilder append(final String fieldName, final DiffResult
> diffResult)
> {code}
> instead.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (LANG-1663) Wrong exception in various NumberUtils method documentations
[ https://issues.apache.org/jira/browse/LANG-1663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17395043#comment-17395043 ] Andrew Thomas commented on LANG-1663: - I have created a PR for this issue here: [LANG-1663|https://github.com/apache/commons-lang/pull/785] > Wrong exception in various NumberUtils method documentations > > > Key: LANG-1663 > URL: https://issues.apache.org/jira/browse/LANG-1663 > Project: Commons Lang > Issue Type: Bug > Components: lang.math.* >Affects Versions: 3.12.0 >Reporter: Tobias Helms >Priority: Minor > Labels: documentation > Time Spent: 10m > Remaining Estimate: 0h > > The documentation of various methods in _NumberUtils_ says an > _IllegalArgumentException_ is thrown in case of a _null_ argument , e.g., see > [https://github.com/apache/commons-lang/blob/197d50434748bfb2db935266cfe740fc01a607ee/src/main/java/org/apache/commons/lang3/math/NumberUtils.java#L1194] > > However, these methods throw a _NullPointerException_ in this case. The > following methods are affected: > * long min(final long... array) > * int min(final int... array) > * short min(final short... array) > * byte min(final byte... array) > * static double min(final double... array) > * float min(final float... array) > * long max(final long... array) > * int max(final int... array) > * short max(final short... array) > * byte max(final byte... array) > * double max(final double... array) > * float max(final float... array) > * void validateArray(final Object array) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (LANG-1657) DiffBuilder: Type constraint for method append(..., DiffResult) too strict
[
https://issues.apache.org/jira/browse/LANG-1657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17380903#comment-17380903
]
Andrew Thomas commented on LANG-1657:
-
Can someone confirm if this needs to be worked on? If no one has taken it up, I
can open a PR based on the proposed solution.
> DiffBuilder: Type constraint for method append(..., DiffResult) too strict
> --
>
> Key: LANG-1657
> URL: https://issues.apache.org/jira/browse/LANG-1657
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.builder.*
>Affects Versions: 3.12.0
>Reporter: Matthias Welz
>Priority: Major
>
> The DiffBuilder has a method append which allows to append an existing
> DiffResult for a property. The example illustrates this the following way:
>
> {code:java}
> public class Person implements Diffable {
>String name;
>Address address; // implements Diffable
>...
>public DiffResult diff(Person obj) {
> return new DiffBuilder(this, obj, ToStringStyle.SHORT_PREFIX_STYLE)
>.append("name", this.name, obj.name)
>.append("address", this.address.diff(obj.address))
>.build();
>}
> }
> {code}
>
> However, the signature of the method was recently changed to:
> {code:java}
> public DiffBuilder append(final String fieldName, final DiffResult
> diffResult)
> {code}
> As a consequence, the example code won't compile anymore when using generics
> because the a _DiffBuilder_ will only accept _DiffResult_ but
> not _DiffResult_ for its append method.
> The signature should be:
> {code:java}
> public DiffBuilder append(final String fieldName, final DiffResult
> diffResult)
> {code}
> or:
> {code:java}
> public DiffBuilder append(final String fieldName, final DiffResult
> diffResult)
> {code}
> instead.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (LANG-1462) After version Commons-lang3.4 DateFormatUtils has a bug
[
https://issues.apache.org/jira/browse/LANG-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17380901#comment-17380901
]
Andrew Thomas commented on LANG-1462:
-
I see that this has been open for some time. Is this a bug or a documentation
issue? Either way I can open a PR since the fix (if it's a bug) seems to be
documented above.
> After version Commons-lang3.4 DateFormatUtils has a bug
> ---
>
> Key: LANG-1462
> URL: https://issues.apache.org/jira/browse/LANG-1462
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 3.5, 3.6, 3.7, 3.8, 3.9, 3.8.1
>Reporter: Lijun Liang
>Priority: Critical
>
> The code is as follows ：
> Calendar cale = Calendar.getInstance();
> System.out.println("Old time is " + DateFormatUtils.format(cale,
> "MMddHHmmss"));
> cale.setTimeZone(TimeZone.getTimeZone("JST"));
> System.out.println("New time is " + DateFormatUtils.format(cale,
> "MMddHHmmss"));
>
> The results of commons-lang3 3.4：
> Old time is 20190605144536
> New time is 20190605154536
>
> The results of the version after commons-lang3 3.4:
> Old time is 20190605144536
> New time is 20190605144536
>
> We found that the time zone setting was invalidated when it was formatted
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
