[jira] [Comment Edited] (LANG-1491) Unit tests visibility is non-conforming with JUnit 5
[ https://issues.apache.org/jira/browse/LANG-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16939125#comment-16939125 ] Peter Verhas edited comment on LANG-1491 at 9/27/19 5:02 AM: - Here you are. Welcome. https://github.com/apache/commons-lang/pull/461 was (Author: pe...@verhas.com): Here you are. Welcome. > Unit tests visibility is non-conforming with JUnit 5 > > > Key: LANG-1491 > URL: https://issues.apache.org/jira/browse/LANG-1491 > Project: Commons Lang > Issue Type: Improvement > Components: lang.* >Affects Versions: 3.9 >Reporter: Peter Verhas >Priority: Major > Original Estimate: 1h > Remaining Estimate: 1h > > The used JUnit 5 library does not require that the unit test classes and > methods be {{public}}. > All these {{public}} keywords are only noise in the source code and have to > be deleted. Otherwise, the code becomes inconsistent as the new and modified > tests will be package protected as per required by the test library and the > old tests remain public unnecessarily. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (LANG-1491) Unit tests visibility is non-conforming with JUnit 5
[ https://issues.apache.org/jira/browse/LANG-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16939125#comment-16939125 ] Peter Verhas commented on LANG-1491: Here you are. Welcome. > Unit tests visibility is non-conforming with JUnit 5 > > > Key: LANG-1491 > URL: https://issues.apache.org/jira/browse/LANG-1491 > Project: Commons Lang > Issue Type: Improvement > Components: lang.* >Affects Versions: 3.9 >Reporter: Peter Verhas >Priority: Major > Original Estimate: 1h > Remaining Estimate: 1h > > The used JUnit 5 library does not require that the unit test classes and > methods be {{public}}. > All these {{public}} keywords are only noise in the source code and have to > be deleted. Otherwise, the code becomes inconsistent as the new and modified > tests will be package protected as per required by the test library and the > old tests remain public unnecessarily. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-lang] verhas opened a new pull request #461: Lang 1491
verhas opened a new pull request #461: Lang 1491 URL: https://github.com/apache/commons-lang/pull/461 Removing all public modifiers that are not needed anymore when we are using JUnit 5 and not JUnit 4. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Work logged] (LANG-1480) ClassUtils. getAbbreviatedName(String ,int) returns too long result
[ https://issues.apache.org/jira/browse/LANG-1480?focusedWorklogId=319313&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-319313 ] ASF GitHub Bot logged work on LANG-1480: Author: ASF GitHub Bot Created on: 27/Sep/19 01:48 Start Date: 27/Sep/19 01:48 Worklog Time Spent: 10m Work Description: garydgregory commented on issue #446: LANG-1480 getAbbreviatedName refactored to create appropriate length … URL: https://github.com/apache/commons-lang/pull/446#issuecomment-535749533 > > > Please merge it instead of nitpicking. > > > That's not the best attitude IMO. > > I said please. Btw: I opened a ticket https://issues.apache.org/jira/browse/LANG-1491 to fix this issue. It's rather simple IMO: this patch should be consistent with the current code base as it is now. IOW, tests are `public`. If someone wants to do the busy work of changing all of Commons Lang, more power to them, then the community can decide what to do, but this PR is not the place to do it. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 319313) Remaining Estimate: 16h 40m (was: 16h 50m) Time Spent: 7h 20m (was: 7h 10m) > ClassUtils. getAbbreviatedName(String ,int) returns too long result > --- > > Key: LANG-1480 > URL: https://issues.apache.org/jira/browse/LANG-1480 > Project: Commons Lang > Issue Type: Bug > Components: lang.* >Affects Versions: 3.9 > Environment: Environment independent. >Reporter: Peter Verhas >Assignee: Bruno P. Kinoshita >Priority: Major > Original Estimate: 24h > Time Spent: 7h 20m > Remaining Estimate: 16h 40m > > In some cases, the algorithm decides incorrectly when to which package names > to abbreviate. For example, abbreviating > {{org.apache.commons.lang3.ClassUtils}} to the length 18 will result > {{o.a.c.lang3.ClassUtils}} (22 characters) instead of {{o.a.c.l.ClassUtils}} > (18 characters as requested). The reason for this is that the algorithm > starts from the right and goes to the left abbreviating the packages and > starts to abbreviate the packages when it runs out of the available space. > Instead, the algorithm should start from the left and abbreviate all packages > that would result in a too-long string without abbreviating the package name. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-lang] garydgregory commented on issue #446: LANG-1480 getAbbreviatedName refactored to create appropriate length …
garydgregory commented on issue #446: LANG-1480 getAbbreviatedName refactored to create appropriate length … URL: https://github.com/apache/commons-lang/pull/446#issuecomment-535749533 > > > Please merge it instead of nitpicking. > > > That's not the best attitude IMO. > > I said please. Btw: I opened a ticket https://issues.apache.org/jira/browse/LANG-1491 to fix this issue. It's rather simple IMO: this patch should be consistent with the current code base as it is now. IOW, tests are `public`. If someone wants to do the busy work of changing all of Commons Lang, more power to them, then the community can decide what to do, but this PR is not the place to do it. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (LANG-1491) Unit tests visibility is non-conforming with JUnit 5
[ https://issues.apache.org/jira/browse/LANG-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16939063#comment-16939063 ] Gary D. Gregory commented on LANG-1491: --- Hi [~pe...@verhas.com], PRs are welcome on GitHub. Gary > Unit tests visibility is non-conforming with JUnit 5 > > > Key: LANG-1491 > URL: https://issues.apache.org/jira/browse/LANG-1491 > Project: Commons Lang > Issue Type: Improvement > Components: lang.* >Affects Versions: 3.9 >Reporter: Peter Verhas >Priority: Major > Original Estimate: 1h > Remaining Estimate: 1h > > The used JUnit 5 library does not require that the unit test classes and > methods be {{public}}. > All these {{public}} keywords are only noise in the source code and have to > be deleted. Otherwise, the code becomes inconsistent as the new and modified > tests will be package protected as per required by the test library and the > old tests remain public unnecessarily. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (LANG-1480) ClassUtils. getAbbreviatedName(String ,int) returns too long result
[ https://issues.apache.org/jira/browse/LANG-1480?focusedWorklogId=319311&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-319311 ] ASF GitHub Bot logged work on LANG-1480: Author: ASF GitHub Bot Created on: 27/Sep/19 01:45 Start Date: 27/Sep/19 01:45 Worklog Time Spent: 10m Work Description: verhas commented on issue #446: LANG-1480 getAbbreviatedName refactored to create appropriate length … URL: https://github.com/apache/commons-lang/pull/446#issuecomment-535748891 >>Please merge it instead of nitpicking. >That's not the best attitude IMO. I said please. Btw: I opened a ticket https://issues.apache.org/jira/browse/LANG-1491 to fix this 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 319311) Remaining Estimate: 16h 50m (was: 17h) Time Spent: 7h 10m (was: 7h) > ClassUtils. getAbbreviatedName(String ,int) returns too long result > --- > > Key: LANG-1480 > URL: https://issues.apache.org/jira/browse/LANG-1480 > Project: Commons Lang > Issue Type: Bug > Components: lang.* >Affects Versions: 3.9 > Environment: Environment independent. >Reporter: Peter Verhas >Assignee: Bruno P. Kinoshita >Priority: Major > Original Estimate: 24h > Time Spent: 7h 10m > Remaining Estimate: 16h 50m > > In some cases, the algorithm decides incorrectly when to which package names > to abbreviate. For example, abbreviating > {{org.apache.commons.lang3.ClassUtils}} to the length 18 will result > {{o.a.c.lang3.ClassUtils}} (22 characters) instead of {{o.a.c.l.ClassUtils}} > (18 characters as requested). The reason for this is that the algorithm > starts from the right and goes to the left abbreviating the packages and > starts to abbreviate the packages when it runs out of the available space. > Instead, the algorithm should start from the left and abbreviate all packages > that would result in a too-long string without abbreviating the package name. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (LANG-1480) ClassUtils. getAbbreviatedName(String ,int) returns too long result
[ https://issues.apache.org/jira/browse/LANG-1480?focusedWorklogId=319310&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-319310 ] ASF GitHub Bot logged work on LANG-1480: Author: ASF GitHub Bot Created on: 27/Sep/19 01:44 Start Date: 27/Sep/19 01:44 Worklog Time Spent: 10m Work Description: garydgregory commented on issue #446: LANG-1480 getAbbreviatedName refactored to create appropriate length … URL: https://github.com/apache/commons-lang/pull/446#issuecomment-535747664 > Please merge it instead of nitpicking. That's not the best attitude IMO. If you want to follow JUnit 5 conventions, please provide a patch that is consistent over all classes and methods. Having a mix and public and package private will just be confusing to others who will not know which convention to follow. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 319310) Remaining Estimate: 17h (was: 17h 10m) Time Spent: 7h (was: 6h 50m) > ClassUtils. getAbbreviatedName(String ,int) returns too long result > --- > > Key: LANG-1480 > URL: https://issues.apache.org/jira/browse/LANG-1480 > Project: Commons Lang > Issue Type: Bug > Components: lang.* >Affects Versions: 3.9 > Environment: Environment independent. >Reporter: Peter Verhas >Assignee: Bruno P. Kinoshita >Priority: Major > Original Estimate: 24h > Time Spent: 7h > Remaining Estimate: 17h > > In some cases, the algorithm decides incorrectly when to which package names > to abbreviate. For example, abbreviating > {{org.apache.commons.lang3.ClassUtils}} to the length 18 will result > {{o.a.c.lang3.ClassUtils}} (22 characters) instead of {{o.a.c.l.ClassUtils}} > (18 characters as requested). The reason for this is that the algorithm > starts from the right and goes to the left abbreviating the packages and > starts to abbreviate the packages when it runs out of the available space. > Instead, the algorithm should start from the left and abbreviate all packages > that would result in a too-long string without abbreviating the package name. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-lang] verhas commented on issue #446: LANG-1480 getAbbreviatedName refactored to create appropriate length …
verhas commented on issue #446: LANG-1480 getAbbreviatedName refactored to create appropriate length … URL: https://github.com/apache/commons-lang/pull/446#issuecomment-535748891 >>Please merge it instead of nitpicking. >That's not the best attitude IMO. I said please. Btw: I opened a ticket https://issues.apache.org/jira/browse/LANG-1491 to fix this 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-lang] garydgregory edited a comment on issue #446: LANG-1480 getAbbreviatedName refactored to create appropriate length …
garydgregory edited a comment on issue #446: LANG-1480 getAbbreviatedName refactored to create appropriate length … URL: https://github.com/apache/commons-lang/pull/446#issuecomment-535747664 > Please merge it instead of nitpicking. That's not the best attitude IMO. If you want to follow JUnit 5 conventions, please provide a patch that is consistent over all classes and methods. Having a mix and public and package private will just be confusing to others who will not know which convention to follow. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Work logged] (LANG-1480) ClassUtils. getAbbreviatedName(String ,int) returns too long result
[ https://issues.apache.org/jira/browse/LANG-1480?focusedWorklogId=319308&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-319308 ] ASF GitHub Bot logged work on LANG-1480: Author: ASF GitHub Bot Created on: 27/Sep/19 01:40 Start Date: 27/Sep/19 01:40 Worklog Time Spent: 10m Work Description: garydgregory commented on issue #446: LANG-1480 getAbbreviatedName refactored to create appropriate length … URL: https://github.com/apache/commons-lang/pull/446#issuecomment-535747664 > Please merge it instead of nitpicking. That's not the best attitude IMO. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 319308) Remaining Estimate: 17h 10m (was: 17h 20m) Time Spent: 6h 50m (was: 6h 40m) > ClassUtils. getAbbreviatedName(String ,int) returns too long result > --- > > Key: LANG-1480 > URL: https://issues.apache.org/jira/browse/LANG-1480 > Project: Commons Lang > Issue Type: Bug > Components: lang.* >Affects Versions: 3.9 > Environment: Environment independent. >Reporter: Peter Verhas >Assignee: Bruno P. Kinoshita >Priority: Major > Original Estimate: 24h > Time Spent: 6h 50m > Remaining Estimate: 17h 10m > > In some cases, the algorithm decides incorrectly when to which package names > to abbreviate. For example, abbreviating > {{org.apache.commons.lang3.ClassUtils}} to the length 18 will result > {{o.a.c.lang3.ClassUtils}} (22 characters) instead of {{o.a.c.l.ClassUtils}} > (18 characters as requested). The reason for this is that the algorithm > starts from the right and goes to the left abbreviating the packages and > starts to abbreviate the packages when it runs out of the available space. > Instead, the algorithm should start from the left and abbreviate all packages > that would result in a too-long string without abbreviating the package name. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-lang] garydgregory commented on issue #446: LANG-1480 getAbbreviatedName refactored to create appropriate length …
garydgregory commented on issue #446: LANG-1480 getAbbreviatedName refactored to create appropriate length … URL: https://github.com/apache/commons-lang/pull/446#issuecomment-535747664 > Please merge it instead of nitpicking. That's not the best attitude IMO. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (LANG-1491) Unit tests visibility is non-conforming with JUnit 5
[ https://issues.apache.org/jira/browse/LANG-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Verhas updated LANG-1491: --- Description: The used JUnit 5 library does not require that the unit test classes and methods be {{public}}. All these {{public}} keywords are only noise in the source code and have to be deleted. Otherwise, the code becomes inconsistent as the new and modified tests will be package protected as per required by the test library and the old tests remain public unnecessarily. was: The used JUnit 5 library does not require that the unit test classes and methods be {{public}}. All these {{public}} keywords are only noise in the source code and have to be deleted. > Unit tests visibility is non-conforming with JUnit 5 > > > Key: LANG-1491 > URL: https://issues.apache.org/jira/browse/LANG-1491 > Project: Commons Lang > Issue Type: Improvement > Components: lang.* >Affects Versions: 3.9 >Reporter: Peter Verhas >Priority: Major > Original Estimate: 1h > Remaining Estimate: 1h > > The used JUnit 5 library does not require that the unit test classes and > methods be {{public}}. > All these {{public}} keywords are only noise in the source code and have to > be deleted. Otherwise, the code becomes inconsistent as the new and modified > tests will be package protected as per required by the test library and the > old tests remain public unnecessarily. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (LANG-1491) Unit tests visibility is non-conforming with JUnit 5
Peter Verhas created LANG-1491: -- Summary: Unit tests visibility is non-conforming with JUnit 5 Key: LANG-1491 URL: https://issues.apache.org/jira/browse/LANG-1491 Project: Commons Lang Issue Type: Improvement Components: lang.* Affects Versions: 3.9 Reporter: Peter Verhas The used JUnit 5 library does not require that the unit test classes and methods be {{public}}. All these {{public}} keywords are only noise in the source code and have to be deleted. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (LANG-1480) ClassUtils. getAbbreviatedName(String ,int) returns too long result
[ https://issues.apache.org/jira/browse/LANG-1480?focusedWorklogId=319303&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-319303 ] ASF GitHub Bot logged work on LANG-1480: Author: ASF GitHub Bot Created on: 27/Sep/19 01:15 Start Date: 27/Sep/19 01:15 Worklog Time Spent: 10m Work Description: verhas commented on pull request #446: LANG-1480 getAbbreviatedName refactored to create appropriate length … URL: https://github.com/apache/commons-lang/pull/446#discussion_r328881438 ## File path: src/test/java/org/apache/commons/lang3/ClassUtilsTest.java ## @@ -160,26 +162,59 @@ public void test_getAbbreviatedName_Class() { assertEquals("", ClassUtils.getAbbreviatedName((Class) null, 1)); assertEquals("j.l.String", ClassUtils.getAbbreviatedName(String.class, 1)); assertEquals("j.l.String", ClassUtils.getAbbreviatedName(String.class, 5)); +assertEquals("o.a.c.l.ClassUtils", ClassUtils.getAbbreviatedName(ClassUtils.class, 18)); assertEquals("j.lang.String", ClassUtils.getAbbreviatedName(String.class, 13)); assertEquals("j.lang.String", ClassUtils.getAbbreviatedName(String.class, 15)); assertEquals("java.lang.String", ClassUtils.getAbbreviatedName(String.class, 20)); } +/** + * Test that in case the required length is larger than the name and thus there is no need for any shortening + * then the returned string object is the same as the one passed as argument. Note, however, that this is + * tested as an internal implementation detail, but it is not a guaranteed feature of the implementation. + */ @Test -public void test_getAbbreviatedName_Class_NegativeLen() { +@DisplayName("When the length hint is longer than the actual length then the same String object is returned") +void test_getAbbreviatedName_TooLongHint(){ +final String className = "java.lang.String"; +Assertions.assertSame(className, ClassUtils.getAbbreviatedName(className, className.length()+1)); +Assertions.assertSame(className, ClassUtils.getAbbreviatedName(className, className.length())); +} + +@Test +@DisplayName("When the desired length is negative then exception is thrown") +void test_getAbbreviatedName_Class_NegativeLen() { assertThrows(IllegalArgumentException.class, () -> ClassUtils.getAbbreviatedName(String.class, -10)); } @Test -public void test_getAbbreviatedName_Class_ZeroLen() { +@DisplayName("When the desired length is zero then exception is thrown") +void test_getAbbreviatedName_Class_ZeroLen() { assertThrows(IllegalArgumentException.class, () -> ClassUtils.getAbbreviatedName(String.class, 0)); } @Test -public void test_getAbbreviatedName_String() { Review comment: Sorry, but wrong addressee. This is not me, who has changed the visibility, but JUnit 5. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 319303) Remaining Estimate: 17h 20m (was: 17.5h) Time Spent: 6h 40m (was: 6.5h) > ClassUtils. getAbbreviatedName(String ,int) returns too long result > --- > > Key: LANG-1480 > URL: https://issues.apache.org/jira/browse/LANG-1480 > Project: Commons Lang > Issue Type: Bug > Components: lang.* >Affects Versions: 3.9 > Environment: Environment independent. >Reporter: Peter Verhas >Assignee: Bruno P. Kinoshita >Priority: Major > Original Estimate: 24h > Time Spent: 6h 40m > Remaining Estimate: 17h 20m > > In some cases, the algorithm decides incorrectly when to which package names > to abbreviate. For example, abbreviating > {{org.apache.commons.lang3.ClassUtils}} to the length 18 will result > {{o.a.c.lang3.ClassUtils}} (22 characters) instead of {{o.a.c.l.ClassUtils}} > (18 characters as requested). The reason for this is that the algorithm > starts from the right and goes to the left abbreviating the packages and > starts to abbreviate the packages when it runs out of the available space. > Instead, the algorithm should start from the left and abbreviate all packages > that would result in a too-long string without abbreviating the package name. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-lang] verhas commented on a change in pull request #446: LANG-1480 getAbbreviatedName refactored to create appropriate length …
verhas commented on a change in pull request #446: LANG-1480 getAbbreviatedName refactored to create appropriate length … URL: https://github.com/apache/commons-lang/pull/446#discussion_r328881438 ## File path: src/test/java/org/apache/commons/lang3/ClassUtilsTest.java ## @@ -160,26 +162,59 @@ public void test_getAbbreviatedName_Class() { assertEquals("", ClassUtils.getAbbreviatedName((Class) null, 1)); assertEquals("j.l.String", ClassUtils.getAbbreviatedName(String.class, 1)); assertEquals("j.l.String", ClassUtils.getAbbreviatedName(String.class, 5)); +assertEquals("o.a.c.l.ClassUtils", ClassUtils.getAbbreviatedName(ClassUtils.class, 18)); assertEquals("j.lang.String", ClassUtils.getAbbreviatedName(String.class, 13)); assertEquals("j.lang.String", ClassUtils.getAbbreviatedName(String.class, 15)); assertEquals("java.lang.String", ClassUtils.getAbbreviatedName(String.class, 20)); } +/** + * Test that in case the required length is larger than the name and thus there is no need for any shortening + * then the returned string object is the same as the one passed as argument. Note, however, that this is + * tested as an internal implementation detail, but it is not a guaranteed feature of the implementation. + */ @Test -public void test_getAbbreviatedName_Class_NegativeLen() { +@DisplayName("When the length hint is longer than the actual length then the same String object is returned") +void test_getAbbreviatedName_TooLongHint(){ +final String className = "java.lang.String"; +Assertions.assertSame(className, ClassUtils.getAbbreviatedName(className, className.length()+1)); +Assertions.assertSame(className, ClassUtils.getAbbreviatedName(className, className.length())); +} + +@Test +@DisplayName("When the desired length is negative then exception is thrown") +void test_getAbbreviatedName_Class_NegativeLen() { assertThrows(IllegalArgumentException.class, () -> ClassUtils.getAbbreviatedName(String.class, -10)); } @Test -public void test_getAbbreviatedName_Class_ZeroLen() { +@DisplayName("When the desired length is zero then exception is thrown") +void test_getAbbreviatedName_Class_ZeroLen() { assertThrows(IllegalArgumentException.class, () -> ClassUtils.getAbbreviatedName(String.class, 0)); } @Test -public void test_getAbbreviatedName_String() { Review comment: Sorry, but wrong addressee. This is not me, who has changed the visibility, but JUnit 5. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Work logged] (LANG-1480) ClassUtils. getAbbreviatedName(String ,int) returns too long result
[ https://issues.apache.org/jira/browse/LANG-1480?focusedWorklogId=319302&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-319302 ] ASF GitHub Bot logged work on LANG-1480: Author: ASF GitHub Bot Created on: 27/Sep/19 01:08 Start Date: 27/Sep/19 01:08 Worklog Time Spent: 10m Work Description: verhas commented on pull request #446: LANG-1480 getAbbreviatedName refactored to create appropriate length … URL: https://github.com/apache/commons-lang/pull/446#discussion_r328881438 ## File path: src/test/java/org/apache/commons/lang3/ClassUtilsTest.java ## @@ -160,26 +162,59 @@ public void test_getAbbreviatedName_Class() { assertEquals("", ClassUtils.getAbbreviatedName((Class) null, 1)); assertEquals("j.l.String", ClassUtils.getAbbreviatedName(String.class, 1)); assertEquals("j.l.String", ClassUtils.getAbbreviatedName(String.class, 5)); +assertEquals("o.a.c.l.ClassUtils", ClassUtils.getAbbreviatedName(ClassUtils.class, 18)); assertEquals("j.lang.String", ClassUtils.getAbbreviatedName(String.class, 13)); assertEquals("j.lang.String", ClassUtils.getAbbreviatedName(String.class, 15)); assertEquals("java.lang.String", ClassUtils.getAbbreviatedName(String.class, 20)); } +/** + * Test that in case the required length is larger than the name and thus there is no need for any shortening + * then the returned string object is the same as the one passed as argument. Note, however, that this is + * tested as an internal implementation detail, but it is not a guaranteed feature of the implementation. + */ @Test -public void test_getAbbreviatedName_Class_NegativeLen() { +@DisplayName("When the length hint is longer than the actual length then the same String object is returned") +void test_getAbbreviatedName_TooLongHint(){ +final String className = "java.lang.String"; +Assertions.assertSame(className, ClassUtils.getAbbreviatedName(className, className.length()+1)); +Assertions.assertSame(className, ClassUtils.getAbbreviatedName(className, className.length())); +} + +@Test +@DisplayName("When the desired length is negative then exception is thrown") +void test_getAbbreviatedName_Class_NegativeLen() { assertThrows(IllegalArgumentException.class, () -> ClassUtils.getAbbreviatedName(String.class, -10)); } @Test -public void test_getAbbreviatedName_Class_ZeroLen() { +@DisplayName("When the desired length is zero then exception is thrown") +void test_getAbbreviatedName_Class_ZeroLen() { assertThrows(IllegalArgumentException.class, () -> ClassUtils.getAbbreviatedName(String.class, 0)); } @Test -public void test_getAbbreviatedName_String() { Review comment: Sorry, but wrong addressee. This is not me, who has changed the visibility, but JUnit 5. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 319302) Remaining Estimate: 17.5h (was: 17h 40m) Time Spent: 6.5h (was: 6h 20m) > ClassUtils. getAbbreviatedName(String ,int) returns too long result > --- > > Key: LANG-1480 > URL: https://issues.apache.org/jira/browse/LANG-1480 > Project: Commons Lang > Issue Type: Bug > Components: lang.* >Affects Versions: 3.9 > Environment: Environment independent. >Reporter: Peter Verhas >Assignee: Bruno P. Kinoshita >Priority: Major > Original Estimate: 24h > Time Spent: 6.5h > Remaining Estimate: 17.5h > > In some cases, the algorithm decides incorrectly when to which package names > to abbreviate. For example, abbreviating > {{org.apache.commons.lang3.ClassUtils}} to the length 18 will result > {{o.a.c.lang3.ClassUtils}} (22 characters) instead of {{o.a.c.l.ClassUtils}} > (18 characters as requested). The reason for this is that the algorithm > starts from the right and goes to the left abbreviating the packages and > starts to abbreviate the packages when it runs out of the available space. > Instead, the algorithm should start from the left and abbreviate all packages > that would result in a too-long string without abbreviating the package name. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-lang] verhas commented on a change in pull request #446: LANG-1480 getAbbreviatedName refactored to create appropriate length …
verhas commented on a change in pull request #446: LANG-1480 getAbbreviatedName refactored to create appropriate length … URL: https://github.com/apache/commons-lang/pull/446#discussion_r328881438 ## File path: src/test/java/org/apache/commons/lang3/ClassUtilsTest.java ## @@ -160,26 +162,59 @@ public void test_getAbbreviatedName_Class() { assertEquals("", ClassUtils.getAbbreviatedName((Class) null, 1)); assertEquals("j.l.String", ClassUtils.getAbbreviatedName(String.class, 1)); assertEquals("j.l.String", ClassUtils.getAbbreviatedName(String.class, 5)); +assertEquals("o.a.c.l.ClassUtils", ClassUtils.getAbbreviatedName(ClassUtils.class, 18)); assertEquals("j.lang.String", ClassUtils.getAbbreviatedName(String.class, 13)); assertEquals("j.lang.String", ClassUtils.getAbbreviatedName(String.class, 15)); assertEquals("java.lang.String", ClassUtils.getAbbreviatedName(String.class, 20)); } +/** + * Test that in case the required length is larger than the name and thus there is no need for any shortening + * then the returned string object is the same as the one passed as argument. Note, however, that this is + * tested as an internal implementation detail, but it is not a guaranteed feature of the implementation. + */ @Test -public void test_getAbbreviatedName_Class_NegativeLen() { +@DisplayName("When the length hint is longer than the actual length then the same String object is returned") +void test_getAbbreviatedName_TooLongHint(){ +final String className = "java.lang.String"; +Assertions.assertSame(className, ClassUtils.getAbbreviatedName(className, className.length()+1)); +Assertions.assertSame(className, ClassUtils.getAbbreviatedName(className, className.length())); +} + +@Test +@DisplayName("When the desired length is negative then exception is thrown") +void test_getAbbreviatedName_Class_NegativeLen() { assertThrows(IllegalArgumentException.class, () -> ClassUtils.getAbbreviatedName(String.class, -10)); } @Test -public void test_getAbbreviatedName_Class_ZeroLen() { +@DisplayName("When the desired length is zero then exception is thrown") +void test_getAbbreviatedName_Class_ZeroLen() { assertThrows(IllegalArgumentException.class, () -> ClassUtils.getAbbreviatedName(String.class, 0)); } @Test -public void test_getAbbreviatedName_String() { Review comment: Sorry, but wrong addressee. This is not me, who has changed the visibility, but JUnit 5. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Work logged] (LANG-1480) ClassUtils. getAbbreviatedName(String ,int) returns too long result
[ https://issues.apache.org/jira/browse/LANG-1480?focusedWorklogId=319300&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-319300 ] ASF GitHub Bot logged work on LANG-1480: Author: ASF GitHub Bot Created on: 27/Sep/19 01:07 Start Date: 27/Sep/19 01:07 Worklog Time Spent: 10m Work Description: verhas commented on pull request #446: LANG-1480 getAbbreviatedName refactored to create appropriate length … URL: https://github.com/apache/commons-lang/pull/446#discussion_r328881421 ## File path: src/test/java/org/apache/commons/lang3/ClassUtilsTest.java ## @@ -160,26 +162,59 @@ public void test_getAbbreviatedName_Class() { assertEquals("", ClassUtils.getAbbreviatedName((Class) null, 1)); assertEquals("j.l.String", ClassUtils.getAbbreviatedName(String.class, 1)); assertEquals("j.l.String", ClassUtils.getAbbreviatedName(String.class, 5)); +assertEquals("o.a.c.l.ClassUtils", ClassUtils.getAbbreviatedName(ClassUtils.class, 18)); assertEquals("j.lang.String", ClassUtils.getAbbreviatedName(String.class, 13)); assertEquals("j.lang.String", ClassUtils.getAbbreviatedName(String.class, 15)); assertEquals("java.lang.String", ClassUtils.getAbbreviatedName(String.class, 20)); } +/** + * Test that in case the required length is larger than the name and thus there is no need for any shortening + * then the returned string object is the same as the one passed as argument. Note, however, that this is + * tested as an internal implementation detail, but it is not a guaranteed feature of the implementation. + */ @Test -public void test_getAbbreviatedName_Class_NegativeLen() { +@DisplayName("When the length hint is longer than the actual length then the same String object is returned") +void test_getAbbreviatedName_TooLongHint(){ +final String className = "java.lang.String"; +Assertions.assertSame(className, ClassUtils.getAbbreviatedName(className, className.length()+1)); +Assertions.assertSame(className, ClassUtils.getAbbreviatedName(className, className.length())); +} + +@Test +@DisplayName("When the desired length is negative then exception is thrown") +void test_getAbbreviatedName_Class_NegativeLen() { assertThrows(IllegalArgumentException.class, () -> ClassUtils.getAbbreviatedName(String.class, -10)); } @Test -public void test_getAbbreviatedName_Class_ZeroLen() { Review comment: Sorry, but wrong addressee. This is not me, who has changed the visibility, but JUnit 5. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 319300) Remaining Estimate: 17h 40m (was: 17h 50m) Time Spent: 6h 20m (was: 6h 10m) > ClassUtils. getAbbreviatedName(String ,int) returns too long result > --- > > Key: LANG-1480 > URL: https://issues.apache.org/jira/browse/LANG-1480 > Project: Commons Lang > Issue Type: Bug > Components: lang.* >Affects Versions: 3.9 > Environment: Environment independent. >Reporter: Peter Verhas >Assignee: Bruno P. Kinoshita >Priority: Major > Original Estimate: 24h > Time Spent: 6h 20m > Remaining Estimate: 17h 40m > > In some cases, the algorithm decides incorrectly when to which package names > to abbreviate. For example, abbreviating > {{org.apache.commons.lang3.ClassUtils}} to the length 18 will result > {{o.a.c.lang3.ClassUtils}} (22 characters) instead of {{o.a.c.l.ClassUtils}} > (18 characters as requested). The reason for this is that the algorithm > starts from the right and goes to the left abbreviating the packages and > starts to abbreviate the packages when it runs out of the available space. > Instead, the algorithm should start from the left and abbreviate all packages > that would result in a too-long string without abbreviating the package name. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-lang] verhas commented on a change in pull request #446: LANG-1480 getAbbreviatedName refactored to create appropriate length …
verhas commented on a change in pull request #446: LANG-1480 getAbbreviatedName refactored to create appropriate length … URL: https://github.com/apache/commons-lang/pull/446#discussion_r328881421 ## File path: src/test/java/org/apache/commons/lang3/ClassUtilsTest.java ## @@ -160,26 +162,59 @@ public void test_getAbbreviatedName_Class() { assertEquals("", ClassUtils.getAbbreviatedName((Class) null, 1)); assertEquals("j.l.String", ClassUtils.getAbbreviatedName(String.class, 1)); assertEquals("j.l.String", ClassUtils.getAbbreviatedName(String.class, 5)); +assertEquals("o.a.c.l.ClassUtils", ClassUtils.getAbbreviatedName(ClassUtils.class, 18)); assertEquals("j.lang.String", ClassUtils.getAbbreviatedName(String.class, 13)); assertEquals("j.lang.String", ClassUtils.getAbbreviatedName(String.class, 15)); assertEquals("java.lang.String", ClassUtils.getAbbreviatedName(String.class, 20)); } +/** + * Test that in case the required length is larger than the name and thus there is no need for any shortening + * then the returned string object is the same as the one passed as argument. Note, however, that this is + * tested as an internal implementation detail, but it is not a guaranteed feature of the implementation. + */ @Test -public void test_getAbbreviatedName_Class_NegativeLen() { +@DisplayName("When the length hint is longer than the actual length then the same String object is returned") +void test_getAbbreviatedName_TooLongHint(){ +final String className = "java.lang.String"; +Assertions.assertSame(className, ClassUtils.getAbbreviatedName(className, className.length()+1)); +Assertions.assertSame(className, ClassUtils.getAbbreviatedName(className, className.length())); +} + +@Test +@DisplayName("When the desired length is negative then exception is thrown") +void test_getAbbreviatedName_Class_NegativeLen() { assertThrows(IllegalArgumentException.class, () -> ClassUtils.getAbbreviatedName(String.class, -10)); } @Test -public void test_getAbbreviatedName_Class_ZeroLen() { Review comment: Sorry, but wrong addressee. This is not me, who has changed the visibility, but JUnit 5. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-imaging] kinow commented on issue #49: Add support for EXIF 2.32
kinow commented on issue #49: Add support for EXIF 2.32 URL: https://github.com/apache/commons-imaging/pull/49#issuecomment-535682893 Hi @GITNE >I have added terminal newlines where applicable but Travis CI still fails for some unrelated reason. You have to rebase your branch on master. I've fixed the Javadoc error on JVM 13. So once rebased, this PR should pass Travis with no issues 🤞 . Do you intend to modify anything else in the PR? Add any feature/code? >Btw, personally I consider tools which require you to put a terminal newline in your files to be broken or to have a badly implemented parser. That pseudo argument for terminal newlines where stream processing concatenated files my lead to undesired behavior is dumb. It is naive to assume that processing concatenated files and processing files separately will or should always produce identical results. It is the file format that governs parsing not the mode of processing. Just to clarify, the newline here is for git. I believe it came from unix where it was good practice to have the newline. Not sure if there's a practical reason for that. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Work logged] (LANG-1480) ClassUtils. getAbbreviatedName(String ,int) returns too long result
[ https://issues.apache.org/jira/browse/LANG-1480?focusedWorklogId=319195&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-319195 ] ASF GitHub Bot logged work on LANG-1480: Author: ASF GitHub Bot Created on: 26/Sep/19 20:14 Start Date: 26/Sep/19 20:14 Worklog Time Spent: 10m Work Description: garydgregory commented on issue #446: LANG-1480 getAbbreviatedName refactored to create appropriate length … URL: https://github.com/apache/commons-lang/pull/446#issuecomment-535668589 Because all other tests are public. IOW, consistency. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 319195) Remaining Estimate: 17h 50m (was: 18h) Time Spent: 6h 10m (was: 6h) > ClassUtils. getAbbreviatedName(String ,int) returns too long result > --- > > Key: LANG-1480 > URL: https://issues.apache.org/jira/browse/LANG-1480 > Project: Commons Lang > Issue Type: Bug > Components: lang.* >Affects Versions: 3.9 > Environment: Environment independent. >Reporter: Peter Verhas >Assignee: Bruno P. Kinoshita >Priority: Major > Original Estimate: 24h > Time Spent: 6h 10m > Remaining Estimate: 17h 50m > > In some cases, the algorithm decides incorrectly when to which package names > to abbreviate. For example, abbreviating > {{org.apache.commons.lang3.ClassUtils}} to the length 18 will result > {{o.a.c.lang3.ClassUtils}} (22 characters) instead of {{o.a.c.l.ClassUtils}} > (18 characters as requested). The reason for this is that the algorithm > starts from the right and goes to the left abbreviating the packages and > starts to abbreviate the packages when it runs out of the available space. > Instead, the algorithm should start from the left and abbreviate all packages > that would result in a too-long string without abbreviating the package name. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-lang] garydgregory commented on issue #446: LANG-1480 getAbbreviatedName refactored to create appropriate length …
garydgregory commented on issue #446: LANG-1480 getAbbreviatedName refactored to create appropriate length … URL: https://github.com/apache/commons-lang/pull/446#issuecomment-535668589 Because all other tests are public. IOW, consistency. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Work logged] (LANG-1480) ClassUtils. getAbbreviatedName(String ,int) returns too long result
[ https://issues.apache.org/jira/browse/LANG-1480?focusedWorklogId=319139&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-319139 ] ASF GitHub Bot logged work on LANG-1480: Author: ASF GitHub Bot Created on: 26/Sep/19 18:54 Start Date: 26/Sep/19 18:54 Worklog Time Spent: 10m Work Description: verhas commented on pull request #446: LANG-1480 getAbbreviatedName refactored to create appropriate length … URL: https://github.com/apache/commons-lang/pull/446#discussion_r328774255 ## File path: src/test/java/org/apache/commons/lang3/ClassUtilsTest.java ## @@ -160,26 +162,59 @@ public void test_getAbbreviatedName_Class() { assertEquals("", ClassUtils.getAbbreviatedName((Class) null, 1)); assertEquals("j.l.String", ClassUtils.getAbbreviatedName(String.class, 1)); assertEquals("j.l.String", ClassUtils.getAbbreviatedName(String.class, 5)); +assertEquals("o.a.c.l.ClassUtils", ClassUtils.getAbbreviatedName(ClassUtils.class, 18)); assertEquals("j.lang.String", ClassUtils.getAbbreviatedName(String.class, 13)); assertEquals("j.lang.String", ClassUtils.getAbbreviatedName(String.class, 15)); assertEquals("java.lang.String", ClassUtils.getAbbreviatedName(String.class, 20)); } +/** + * Test that in case the required length is larger than the name and thus there is no need for any shortening + * then the returned string object is the same as the one passed as argument. Note, however, that this is + * tested as an internal implementation detail, but it is not a guaranteed feature of the implementation. + */ @Test -public void test_getAbbreviatedName_Class_NegativeLen() { +@DisplayName("When the length hint is longer than the actual length then the same String object is returned") +void test_getAbbreviatedName_TooLongHint(){ +final String className = "java.lang.String"; +Assertions.assertSame(className, ClassUtils.getAbbreviatedName(className, className.length()+1)); +Assertions.assertSame(className, ClassUtils.getAbbreviatedName(className, className.length())); +} + +@Test +@DisplayName("When the desired length is negative then exception is thrown") +void test_getAbbreviatedName_Class_NegativeLen() { assertThrows(IllegalArgumentException.class, () -> ClassUtils.getAbbreviatedName(String.class, -10)); } @Test -public void test_getAbbreviatedName_Class_ZeroLen() { +@DisplayName("When the desired length is zero then exception is thrown") +void test_getAbbreviatedName_Class_ZeroLen() { assertThrows(IllegalArgumentException.class, () -> ClassUtils.getAbbreviatedName(String.class, 0)); } @Test -public void test_getAbbreviatedName_String() { Review comment: Why? Since the project uses JUnit 5 the required visibility is package private. Any access modifier is noise. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 319139) Remaining Estimate: 18h (was: 18h 10m) Time Spent: 6h (was: 5h 50m) > ClassUtils. getAbbreviatedName(String ,int) returns too long result > --- > > Key: LANG-1480 > URL: https://issues.apache.org/jira/browse/LANG-1480 > Project: Commons Lang > Issue Type: Bug > Components: lang.* >Affects Versions: 3.9 > Environment: Environment independent. >Reporter: Peter Verhas >Assignee: Bruno P. Kinoshita >Priority: Major > Original Estimate: 24h > Time Spent: 6h > Remaining Estimate: 18h > > In some cases, the algorithm decides incorrectly when to which package names > to abbreviate. For example, abbreviating > {{org.apache.commons.lang3.ClassUtils}} to the length 18 will result > {{o.a.c.lang3.ClassUtils}} (22 characters) instead of {{o.a.c.l.ClassUtils}} > (18 characters as requested). The reason for this is that the algorithm > starts from the right and goes to the left abbreviating the packages and > starts to abbreviate the packages when it runs out of the available space. > Instead, the algorithm should start from the left and abbreviate all packages > that would result in a too-long string without abbreviating the package name. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-lang] verhas commented on a change in pull request #446: LANG-1480 getAbbreviatedName refactored to create appropriate length …
verhas commented on a change in pull request #446: LANG-1480 getAbbreviatedName refactored to create appropriate length … URL: https://github.com/apache/commons-lang/pull/446#discussion_r328774255 ## File path: src/test/java/org/apache/commons/lang3/ClassUtilsTest.java ## @@ -160,26 +162,59 @@ public void test_getAbbreviatedName_Class() { assertEquals("", ClassUtils.getAbbreviatedName((Class) null, 1)); assertEquals("j.l.String", ClassUtils.getAbbreviatedName(String.class, 1)); assertEquals("j.l.String", ClassUtils.getAbbreviatedName(String.class, 5)); +assertEquals("o.a.c.l.ClassUtils", ClassUtils.getAbbreviatedName(ClassUtils.class, 18)); assertEquals("j.lang.String", ClassUtils.getAbbreviatedName(String.class, 13)); assertEquals("j.lang.String", ClassUtils.getAbbreviatedName(String.class, 15)); assertEquals("java.lang.String", ClassUtils.getAbbreviatedName(String.class, 20)); } +/** + * Test that in case the required length is larger than the name and thus there is no need for any shortening + * then the returned string object is the same as the one passed as argument. Note, however, that this is + * tested as an internal implementation detail, but it is not a guaranteed feature of the implementation. + */ @Test -public void test_getAbbreviatedName_Class_NegativeLen() { +@DisplayName("When the length hint is longer than the actual length then the same String object is returned") +void test_getAbbreviatedName_TooLongHint(){ +final String className = "java.lang.String"; +Assertions.assertSame(className, ClassUtils.getAbbreviatedName(className, className.length()+1)); +Assertions.assertSame(className, ClassUtils.getAbbreviatedName(className, className.length())); +} + +@Test +@DisplayName("When the desired length is negative then exception is thrown") +void test_getAbbreviatedName_Class_NegativeLen() { assertThrows(IllegalArgumentException.class, () -> ClassUtils.getAbbreviatedName(String.class, -10)); } @Test -public void test_getAbbreviatedName_Class_ZeroLen() { +@DisplayName("When the desired length is zero then exception is thrown") +void test_getAbbreviatedName_Class_ZeroLen() { assertThrows(IllegalArgumentException.class, () -> ClassUtils.getAbbreviatedName(String.class, 0)); } @Test -public void test_getAbbreviatedName_String() { Review comment: Why? Since the project uses JUnit 5 the required visibility is package private. Any access modifier is noise. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-csv] garydgregory commented on issue #43: CSVFormat#valiadte() does not account for allowDuplicateHeaderNames
garydgregory commented on issue #43: CSVFormat#valiadte() does not account for allowDuplicateHeaderNames URL: https://github.com/apache/commons-csv/pull/43#issuecomment-535624098 @macsharker6 I think a week or maybe two. I have two other releases to do first. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-cli] garydgregory merged pull request #31: Switch from Oracle JDK 8 to Open JDK 8
garydgregory merged pull request #31: Switch from Oracle JDK 8 to Open JDK 8 URL: https://github.com/apache/commons-cli/pull/31 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Resolved] (RNG-119) Add LongJumpable support to XorShiRo generators
[ https://issues.apache.org/jira/browse/RNG-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Herbert resolved RNG-119. -- Fix Version/s: 1.3 Resolution: Implemented In git master. > Add LongJumpable support to XorShiRo generators > --- > > Key: RNG-119 > URL: https://issues.apache.org/jira/browse/RNG-119 > Project: Commons RNG > Issue Type: New Feature > Components: core >Affects Versions: 1.3 >Reporter: Alex Herbert >Priority: Major > Fix For: 1.3 > > Time Spent: 0.5h > Remaining Estimate: 0h > > The following generators now have a long jump function: > {noformat} > XoShiRo128Plus > XoShiRo128StarStar > XoShiRo512Plus > XoShiRo512StarStar > {noformat} > This has been added to the original source since the generators were added to > the commons RNG library. > See [xoshiro / xoroshiro generators|http://prng.di.unimi.it/] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-rng] asfgit merged pull request #69: RNG-119: Add LongJumpable support to XoShiRo generators.
asfgit merged pull request #69: RNG-119: Add LongJumpable support to XoShiRo generators. URL: https://github.com/apache/commons-rng/pull/69 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-rng] coveralls commented on issue #69: RNG-119: Add LongJumpable support to XoShiRo generators.
coveralls commented on issue #69: RNG-119: Add LongJumpable support to XoShiRo generators. URL: https://github.com/apache/commons-rng/pull/69#issuecomment-535596703 [![Coverage Status](https://coveralls.io/builds/25953368/badge)](https://coveralls.io/builds/25953368) Coverage increased (+0.001%) to 99.455% when pulling **8449aa64871180bf1fb2be78264b8c3974b94c99 on aherbert:improvement-RNG-119** into **4774ada3ec6eb0fb21455f3975fc5df1d697cbc9 on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (NET-642) using execPROT on FTPSClients with Proxy Settings removes Proxy Settings
[ https://issues.apache.org/jira/browse/NET-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16938804#comment-16938804 ] Danish Kamaal commented on NET-642: --- I am writing a fix for this. This issue has been open for too long and I think there should be a fix. > using execPROT on FTPSClients with Proxy Settings removes Proxy Settings > > > Key: NET-642 > URL: https://issues.apache.org/jira/browse/NET-642 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 3.6 > Environment: Java 1.8.0_112 > Linux 64bit >Reporter: Johannes Frank >Priority: Critical > Time Spent: 20m > Remaining Estimate: 0h > > In Reference to https://issues.apache.org/jira/browse/NET-578 > I'm trying to establish an FTPS Connection via a HTTP Proxy. The Control > Connection is properly established, however the Moment I do execPROT the > Proxy settings are resetted by call to setSocketFactory(new > FTPSSocketFactory(context)); in FTPSClient.java:534. > This causes FTPSClients with a call to execPROT to actually ignore the proxy > settings and attempt to contact the FTPS Server directly for data connections. > Since we are required to use PROT P this is currently blocking our feature > for FTPS Connections via HTTP proxy. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (RNG-117) RandomSource to support creating byte[] seed for implementing class.
[ https://issues.apache.org/jira/browse/RNG-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Herbert resolved RNG-117. -- Fix Version/s: 1.3 Resolution: Implemented In git master. > RandomSource to support creating byte[] seed for implementing class. > > > Key: RNG-117 > URL: https://issues.apache.org/jira/browse/RNG-117 > Project: Commons RNG > Issue Type: Improvement > Components: simple >Affects Versions: 1.3 >Reporter: Alex Herbert >Assignee: Alex Herbert >Priority: Minor > Fix For: 1.3 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Each implementing class represented by {{RandomSource}} has a defined seed > type. The internal package knows the type and can create appropriate seeds. > This occurs when a {{null}} seed is passed to the factory method > {{create(RandomSource, ...)}}. > Notably the seed generation functionality satisfies any extra requirements of > the generator such as avoiding all zero bytes and, for example, low > complexity bytes for the MiddleSquareWeylSequence class. > The seed generation functionality can be exposed to allow: > # Generation of a seed that exactly matches that generated in the factory > create method > # Generation of a seed using a user defined source of randomness > This requires 2 new methods in RandomSource: > {code:java} > // To use the factory source of randomness > public byte[] createSeed(); > // To use a user-defined source of randomness > public byte[] createSeed(UniformRandomProvider rng); > {code} > This would allow separation of seed generation from RNG construction: > {code:java} > RandomSource source = ...; > UniformRandomProvider rng = RandomSource.create(source); > {code} > Becomes > {code:java} > RandomSource source = ...; > byte[] seed = source.createSeed(); > // Some later point > UniformRandomProvider rng = RandomSource.create(source, seed); > {code} > An example of a user-defined source of randomness: > {code:java} > RandomSource source = ...; > UniformRandomProvider seedRng = new JDKRandomWrapper(new SecureRandom()); > byte[] seed = source.createSeed(seedRng); > UniformRandomProvider rng = RandomSource.create(source, seed); > {code} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-imaging] GITNE commented on issue #49: Add support for EXIF 2.32
GITNE commented on issue #49: Add support for EXIF 2.32 URL: https://github.com/apache/commons-imaging/pull/49#issuecomment-535581417 I have added terminal newlines where applicable but Travis CI still fails for some unrelated reason. Btw, personally I consider tools which require you to put a terminal newline in your files to be broken or to have a badly implemented parser. That pseudo argument for terminal newlines where stream processing concatenated files my lead to undesired behavior is dumb. It is naive to assume that processing concatenated files and processing files separately will or should always produce identical results. It is the file format that governs parsing not the mode of processing. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-rng] asfgit merged pull request #70: Changed samplers parametric test failure probability.
asfgit merged pull request #70: Changed samplers parametric test failure probability. URL: https://github.com/apache/commons-rng/pull/70 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-rng] aherbert opened a new pull request #70: Changed samplers parametric test failure probability.
aherbert opened a new pull request #70: Changed samplers parametric test failure probability. URL: https://github.com/apache/commons-rng/pull/70 Only 1 re-run is allowed and the number of samplers is high enough that spurious failures are realistic for the samplers. Changed the Continuous samplers failure rate from p=0.0138 to p=0.0016. This is an effective change of numFailures(n=50, p=0.01) > 2 to numFailures(n=50, p=0.01) > 3. Changed the Discrete samplers failure rate from p=0.189 to p=0.0016 to match the continuous samplers test. Each test is now assessed at the p=0.01 level not the p=0.001 level. This is an effective change of numFailures(n=50, p=0.001) > 2 to numFailures(n=50, p=0.01) > 3. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-rng] aherbert opened a new pull request #69: RNG-119: Add LongJumpable support to XoShiRo generators.
aherbert opened a new pull request #69: RNG-119: Add LongJumpable support to XoShiRo generators. URL: https://github.com/apache/commons-rng/pull/69 This adds the long jump function to those generators previously supporting only a jump function. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (RNG-119) Add LongJumpable support to XorShiRo generators
Alex Herbert created RNG-119: Summary: Add LongJumpable support to XorShiRo generators Key: RNG-119 URL: https://issues.apache.org/jira/browse/RNG-119 Project: Commons RNG Issue Type: New Feature Components: core Affects Versions: 1.3 Reporter: Alex Herbert The following generators now have a long jump function: {noformat} XoShiRo128Plus XoShiRo128StarStar XoShiRo512Plus XoShiRo512StarStar {noformat} This has been added to the original source since the generators were added to the commons RNG library. See [xoshiro / xoroshiro generators|http://prng.di.unimi.it/] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-cli] mincong-h opened a new pull request #31: Switch from Oracle JDK 8 to Open JDK 8
mincong-h opened a new pull request #31: Switch from Oracle JDK 8 to Open JDK 8 URL: https://github.com/apache/commons-cli/pull/31 Fix broken build [589473088](https://travis-ci.org/apache/commons-cli/builds/589473088) (triggered by https://github.com/apache/commons-cli/commit/684b3c9eb54aa7d5328d1a4e2583c3dbdfe64465) by switching from Oracle JDK 8 to Open JDK 8. Open JDK 8 has already been used by other repositories of Apache Commons, such as [commons-math](https://github.com/apache/commons-math/blob/master/.travis.yml#L20), [commons-io](https://github.com/apache/commons-io/blob/master/.travis.yml#L20), and [commons-lang](https://github.com/apache/commons-lang/blob/master/.travis.yml#L18). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (GEOMETRY-30) VectorBuilder?D Classes
[ https://issues.apache.org/jira/browse/GEOMETRY-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16938701#comment-16938701 ] Gilles Sadowski commented on GEOMETRY-30: - In order to figure what is actually necessary, perhaps start with a "minimal" implementation: {code} public class Vector2D { // ... public static class Builder { private double x; private double y; private Builder(double x, double y) { this.x = x; this.y = y; } public Builder create() { return new Builder(0, 0); } public Builder add(double x, double y) { this.x += x; this.y += y; } public Vector2D build(); } } {code} Then we should benchmark alternative implementations ("Builder" vs vector addition) in order to e.g. compute a barycenter. > VectorBuilder?D Classes > --- > > Key: GEOMETRY-30 > URL: https://issues.apache.org/jira/browse/GEOMETRY-30 > Project: Apache Commons Geometry > Issue Type: Wish >Reporter: Matt Juntunen >Priority: Major > > We should add a {{VectorBuilder?D}} class for each dimension. These classes > would have the same coordinate properties as their corresponding {{Vector}} > classes but would be mutable. They would be used to build {{Vector}} > instances from a number of input values without requiring a new instance to > be created for each step. The primary API should look something like this: > {code:java} > public class VectorBuilder2D { > double getX(); > VectorBuilder2D setX(double); > double getY(); > VectorBuilder2D setY(double); > VectorBuilder2D add(Vector2D); > VectorBuilder2D subtract(Vector2D); > VectorBuilder2D multiply(double); > Vector2D toVector(); > } > {code} > A good use case for this is computing a centroid: > {code:java} > VectorBuilder2D builder = new VectorBuilder2D(); > for (Vector2D pt : points) { > builder.add(pt); > } > builder.multiply(1.0 / points.size()); > Vector2D centroid = builder.toVector(); > {code} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (FILEUPLOAD-301) Problems uploading files greater than 100kb using HTTPS
Andrea created FILEUPLOAD-301: - Summary: Problems uploading files greater than 100kb using HTTPS Key: FILEUPLOAD-301 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-301 Project: Commons FileUpload Issue Type: Bug Affects Versions: 1.2.2, 1.4 Environment: Apache Tomcat 8.5 java 9.0.4 Windows Server 2016 Datacenter Reporter: Andrea I'have a java web app that uses Apache Commons FileUpload for uploading files using servlets. My base code worked perfectly for years on a plain http environment (Apache Tomcat 8.5). I've changed my environment to work with HTTPS, using a Let's Encrypt certificate using connector configured with org.apache.coyote.http11.Http11AprProtocol. My uploads now suddenly fail if files are greater than 100kb. Same files uploaded successfully using plain HTTP environment. This is the exception logged: {{org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: Processing of multipart/form-data request failed. java.io.IOException: The socket [925,024,592] associated with this connection has been closed.}} this is the code fragment i use for manage request: {{DiskFileItemFactory factory = new DiskFileItemFactory(); }} {{File repository = (File) request.getServletContext().getAttribute("javax.servlet.context.tempdir"); factory.setRepository(repository); }} {{ServletFileUpload upload = new ServletFileUpload(factory); upload.setHeaderEncoding(encoding); }} {{multipartItems = upload.parseRequest(request);}} Tomcat settings: {{}} {{}} {{ }} {{ }} {{ }} {{ }} {{}} Thanks -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-rng] asfgit merged pull request #68: RNG-117: RandomSource to support creating byte[] seed for implementing class.
asfgit merged pull request #68: RNG-117: RandomSource to support creating byte[] seed for implementing class. URL: https://github.com/apache/commons-rng/pull/68 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (GEOMETRY-30) VectorBuilder?D Classes
[ https://issues.apache.org/jira/browse/GEOMETRY-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16938578#comment-16938578 ] Gilles Sadowski commented on GEOMETRY-30: - bq. avoid unnecessary vector creation. At some point, it would be useful to create benchmarks (using [JMH|https://openjdk.java.net/projects/code-tools/jmh/]) so that we can assess when "unnecessary" equals "costly". bq. computing the region barycenter. Isn't that a case for a stream operation? > VectorBuilder?D Classes > --- > > Key: GEOMETRY-30 > URL: https://issues.apache.org/jira/browse/GEOMETRY-30 > Project: Apache Commons Geometry > Issue Type: Wish >Reporter: Matt Juntunen >Priority: Major > > We should add a {{VectorBuilder?D}} class for each dimension. These classes > would have the same coordinate properties as their corresponding {{Vector}} > classes but would be mutable. They would be used to build {{Vector}} > instances from a number of input values without requiring a new instance to > be created for each step. The primary API should look something like this: > {code:java} > public class VectorBuilder2D { > double getX(); > VectorBuilder2D setX(double); > double getY(); > VectorBuilder2D setY(double); > VectorBuilder2D add(Vector2D); > VectorBuilder2D subtract(Vector2D); > VectorBuilder2D multiply(double); > Vector2D toVector(); > } > {code} > A good use case for this is computing a centroid: > {code:java} > VectorBuilder2D builder = new VectorBuilder2D(); > for (Vector2D pt : points) { > builder.add(pt); > } > builder.multiply(1.0 / points.size()); > Vector2D centroid = builder.toVector(); > {code} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-geometry] asfgit closed pull request #39: GEOMETRY-46: Add additional UnitVector methods
asfgit closed pull request #39: GEOMETRY-46: Add additional UnitVector methods URL: https://github.com/apache/commons-geometry/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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (RNG-118) XoRoShiRo PlusPlus generators
Alex Herbert created RNG-118: Summary: XoRoShiRo PlusPlus generators Key: RNG-118 URL: https://issues.apache.org/jira/browse/RNG-118 Project: Commons RNG Issue Type: New Feature Components: core Affects Versions: 1.3 Reporter: Alex Herbert New variants of the XoRoShiRo generators have been written by Blackman and Vigna (2019): These are variants of the StarStar all purpose generators and should be faster on architectures where long multiplication (the star operation) is slow: {noformat} 32-bit XoShiRo128PlusPlus 64-bit XoRoShiRo128PlusPlus XoShiRo256PlusPlus XoShiRo512PlusPlus {noformat} These are new 1024-bit footprint generators to replace the XorShift1024 generator: {noformat} 64-bit XoRoShiRo1024Star XoRoShiRo1024PlusPlus XoRoShiRo1024StarStar {noformat} Reference [xoshiro / xoroshiro generators|http://prng.di.unimi.it/] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEOMETRY-62) Fix "CheckStyle" errors
Gilles Sadowski created GEOMETRY-62: --- Summary: Fix "CheckStyle" errors Key: GEOMETRY-62 URL: https://issues.apache.org/jira/browse/GEOMETRY-62 Project: Apache Commons Geometry Issue Type: Task Reporter: Gilles Sadowski Fix For: 1.0 CheckStyle currently reports: * "commons-geometry-core": 50 errors * "commons-geometry-euclidean": 136 errors * "commons-geometry-spherical": 9 errors * "commons-geometry-hull": 3 errors * "commons-geometry-enclosing": 3 errors When the report is clean, the "validate" phase could reinstate the check (see POM) in order to fail the build in the presence of any error. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEOMETRY-30) VectorBuilder?D Classes
[ https://issues.apache.org/jira/browse/GEOMETRY-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16938549#comment-16938549 ] Matt Juntunen commented on GEOMETRY-30: --- [Here|https://github.com/darkma773r/commons-geometry/blob/geometry-32-working/commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/threed/RegionBSPTree3D.java#L654] is an actual example from my geometry-32 working branch where I'm computing the region barycenter. I use separate doubles for each component to avoid unnecessary vector creation. This same type of construct is repeated in all of the other {{RegionBSPTreeXD}} classes. > VectorBuilder?D Classes > --- > > Key: GEOMETRY-30 > URL: https://issues.apache.org/jira/browse/GEOMETRY-30 > Project: Apache Commons Geometry > Issue Type: Wish >Reporter: Matt Juntunen >Priority: Major > > We should add a {{VectorBuilder?D}} class for each dimension. These classes > would have the same coordinate properties as their corresponding {{Vector}} > classes but would be mutable. They would be used to build {{Vector}} > instances from a number of input values without requiring a new instance to > be created for each step. The primary API should look something like this: > {code:java} > public class VectorBuilder2D { > double getX(); > VectorBuilder2D setX(double); > double getY(); > VectorBuilder2D setY(double); > VectorBuilder2D add(Vector2D); > VectorBuilder2D subtract(Vector2D); > VectorBuilder2D multiply(double); > Vector2D toVector(); > } > {code} > A good use case for this is computing a centroid: > {code:java} > VectorBuilder2D builder = new VectorBuilder2D(); > for (Vector2D pt : points) { > builder.add(pt); > } > builder.multiply(1.0 / points.size()); > Vector2D centroid = builder.toVector(); > {code} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEOMETRY-54) Cleanup Checkstyle Reported issues
[ https://issues.apache.org/jira/browse/GEOMETRY-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16938542#comment-16938542 ] Matt Juntunen commented on GEOMETRY-54: --- Is there a pull request for this? It seems like we should be able to merge this is and close this issue. > Cleanup Checkstyle Reported issues > -- > > Key: GEOMETRY-54 > URL: https://issues.apache.org/jira/browse/GEOMETRY-54 > Project: Apache Commons Geometry > Issue Type: Improvement > Components: core, Euclidean 1D, Euclidean 2D, Euclidean 3D >Reporter: Karl Heinz Marbaise >Priority: Minor > Labels: checkstyle > Fix For: 1.0 > > > *Problem* > * Currently several Checkstyle based ERRORs/WARNINGs are reported > ** {{geometry-core}}: > *** {{DoublePrecisionContextTest.java}} usage of {{new Double(...)}} is > deprecated marked with JDK 9 which can simply being replaced by using > {{Double.valueOf(..)}}. > ** {{geometry-euclidian}}, {{geometry-core}} > *** {{Vector.java}} messages like {{Vector.java:99:8: Unable to get class > information for @throws tag 'IllegalNormException'. [JavadocMethod]}} > *** {{AffineTransformMatrix3D.java}}, {{AffineTransformMatrix1D.java}} and > {{AffineTransformMatrix1D.java}} messages like {{Unable to get class > information for @throws tag 'NonInvertibleTransformException'.}}. > ** This is related to that the methods do not add the throwing to the method > signature and using a wrong JavaDoc Tag like {{@exception}}. > *Goal* > * Remove the ERRORs/WARNINGs -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEOMETRY-46) Additional UnitVector methods
[ https://issues.apache.org/jira/browse/GEOMETRY-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16938541#comment-16938541 ] Matt Juntunen commented on GEOMETRY-46: --- Sounds good to me! > Additional UnitVector methods > - > > Key: GEOMETRY-46 > URL: https://issues.apache.org/jira/browse/GEOMETRY-46 > Project: Apache Commons Geometry > Issue Type: Improvement >Reporter: Matt Juntunen >Priority: Minor > Labels: easyfix, pull-request-available, starter > Attachments: GEOMETRY-46.patch > > Time Spent: 10m > Remaining Estimate: 0h > > The following methods should be overridden in the {{UnitVector}} private > subclasses of the {{Vector?D}} classes: > * {{normSq}} -- should return {{1}} for consistency with {{norm}} > * {{negate}} -- should be overridden to also return a {{UnitVector}} instance > instead of a regular {{Vector?D}} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEOMETRY-61) Provide "unit" vector concept
Gilles Sadowski created GEOMETRY-61: --- Summary: Provide "unit" vector concept Key: GEOMETRY-61 URL: https://issues.apache.org/jira/browse/GEOMETRY-61 Project: Apache Commons Geometry Issue Type: Improvement Components: Euclidean 1D, Euclidean 2D, Euclidean 3D Reporter: Gilles Sadowski Assignee: Gilles Sadowski The concept of unit vector exists in geometry; hence it would make sense to allow it to be represented in code (possibly allowing more efficient implementations of some algorithms). Discussion on this feature was started in GEOMETRY-46. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEOMETRY-46) Additional UnitVector methods
[ https://issues.apache.org/jira/browse/GEOMETRY-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16938520#comment-16938520 ] Gilles Sadowski commented on GEOMETRY-46: - {quote}Can we merge [...]? {quote} Yes. However (for next time), it's better to squash all commits related to the same feature, especially if some of them fix issues that shouldn't have appeared in the repository in the first place (e.g. spurious white space). {quote}I could get on board with this design [...] being a separate Jira issue. {quote} OK. I'll create another report. {quote}VALJO [...] implies that classes should be final and immutable. {quote} I think that there are 2 separate/orthogonal considerations: * Making a class "final" assumes that at some point, it could lead to performance enhancements in addition to what is already performed by the JIT compiler. But (AFAIK) currently, immutability (as discovered by runtime analysis) already leads to the same performance optimizations. * Making a class immutable provides benefits right now, if just by making the code (much) more robust (especially through thread-safety becoming trivial). The other advantage of making a class "final" is that it allows adding to the API without breaking compatibility; but the same is achieved by having the class _effectively_ "final" (through all constructors being "private"), which is indeed the case for the vector classes. {quote}we would not be able to make the VectorXD classes final if needed. {quote} Even with the current code, it would not be possible (since {{UnitVector}} inherits from {{Vector1D}}). Also, what we have here is a perfectly valid usage of inheritance: a unit vector _is-a_ vector (it would be contorted to represent the relationship with composition). > Additional UnitVector methods > - > > Key: GEOMETRY-46 > URL: https://issues.apache.org/jira/browse/GEOMETRY-46 > Project: Apache Commons Geometry > Issue Type: Improvement >Reporter: Matt Juntunen >Priority: Minor > Labels: easyfix, pull-request-available, starter > Attachments: GEOMETRY-46.patch > > Time Spent: 10m > Remaining Estimate: 0h > > The following methods should be overridden in the {{UnitVector}} private > subclasses of the {{Vector?D}} classes: > * {{normSq}} -- should return {{1}} for consistency with {{norm}} > * {{negate}} -- should be overridden to also return a {{UnitVector}} instance > instead of a regular {{Vector?D}} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CODEC-263) Base64.decodeBase64 throw exception
xie tao created CODEC-263: - Summary: Base64.decodeBase64 throw exception Key: CODEC-263 URL: https://issues.apache.org/jira/browse/CODEC-263 Project: Commons Codec Issue Type: Bug Affects Versions: 1.13 Environment: JDK 7/JDK 8 commons-codec 1.13 Reporter: xie tao Codec upgrade to 1.13, code throw exception as follows: {code:java} @Test public void test(){ Base64.decodeBase64("publishMessage"); } {code} exception like: {code:java} java.lang.IllegalArgumentException: Last encoded character (before the paddings if any) is a valid base 64 alphabet but not a possible value at org.apache.commons.codec.binary.Base64.validateCharacter(Base64.java:798) at org.apache.commons.codec.binary.Base64.decode(Base64.java:472) at org.apache.commons.codec.binary.BaseNCodec.decode(BaseNCodec.java:412) at org.apache.commons.codec.binary.BaseNCodec.decode(BaseNCodec.java:395) at org.apache.commons.codec.binary.Base64.decodeBase64(Base64.java:694) {code} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-lang] michael-o commented on issue #460: Lang-1465: Fix the ZZ time zone format
michael-o commented on issue #460: Lang-1465: Fix the ZZ time zone format URL: https://github.com/apache/commons-lang/pull/460#issuecomment-535423035 The `Z` modifier here is not the same as within Java itself. Therefore, rejecting it. Moreover, your usecase is nonsense because the format is not valid according to ISO 8601. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-csv] macsharker6 edited a comment on issue #43: CSVFormat#valiadte() does not account for allowDuplicateHeaderNames
macsharker6 edited a comment on issue #43: CSVFormat#valiadte() does not account for allowDuplicateHeaderNames URL: https://github.com/apache/commons-csv/pull/43#issuecomment-533182150 Hi @garydgregory, any update for the release 1.8? Thanks in advance. macsharker6 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Comment Edited] (COLLECTIONS-674) Add Collections Drain Method
[ https://issues.apache.org/jira/browse/COLLECTIONS-674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16938352#comment-16938352 ] Chen edited comment on COLLECTIONS-674 at 9/26/19 7:06 AM: --- {code:java} public static Collection drain(Collection input, int start, int count) { if (null == input) { throw new IllegalArgumentException("The collection can't be null."); } if (start < 0) { throw new IllegalArgumentException("The Start can't less than 0."); } if (count < 1) { throw new IllegalArgumentException("The Count can't less than 1."); } if (input.size() < start + count) { throw new IllegalArgumentException( "The sum of start and count cann't be greater than the size of collection."); } Collection result = new ArrayList(count); Iterator iterator = input.iterator(); while (count > 0) { result.add(iterator.next()); iterator.remove(); count = count - 1; } return result; } {code} was (Author: guoping1): {code:java} public static Collection drain(Collection input, int start, int count) { if (null == input) { throw new IllegalArgumentException("The Collection of Input can't be null."); } if (start < 0) { throw new IllegalArgumentException("The Start can't less than 0."); } if (count < 1) { throw new IllegalArgumentException("The Count can't less than 1."); } if (input.size() < start + count) { throw new IllegalArgumentException( "The sum of start and count cann't be greater than the size of collection."); } Collection result = new ArrayList(count); Iterator iterator = input.iterator(); while (count > 0) { result.add(iterator.next()); iterator.remove(); count = count - 1; } return result; } {code} > Add Collections Drain Method > > > Key: COLLECTIONS-674 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-674 > Project: Commons Collections > Issue Type: Improvement > Components: Collection >Affects Versions: 4.1 >Reporter: David Mollitor >Priority: Major > > Add a {{Collections.drain()}} method which removes the first N elements from > the collection and returns them. This method would have the side-effect of > modifying the input collections (due to removal). > > {code:java} > // Some suggestions > void Collections.drain(Collection from, Collection to, int count); > Collection Collections.drain(Collection from, int count);{code} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (COLLECTIONS-674) Add Collections Drain Method
[ https://issues.apache.org/jira/browse/COLLECTIONS-674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16938352#comment-16938352 ] Chen commented on COLLECTIONS-674: -- {code:java} public static Collection drain(Collection input, int start, int count) { if (null == input) { throw new IllegalArgumentException("The Collection of Input can't be null."); } if (start < 0) { throw new IllegalArgumentException("The Start can't less than 0."); } if (count < 1) { throw new IllegalArgumentException("The Count can't less than 1."); } if (input.size() < start + count) { throw new IllegalArgumentException( "The sum of start and count cann't be greater than the size of collection."); } Collection result = new ArrayList(count); Iterator iterator = input.iterator(); while (count > 0) { result.add(iterator.next()); iterator.remove(); count = count - 1; } return result; } {code} > Add Collections Drain Method > > > Key: COLLECTIONS-674 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-674 > Project: Commons Collections > Issue Type: Improvement > Components: Collection >Affects Versions: 4.1 >Reporter: David Mollitor >Priority: Major > > Add a {{Collections.drain()}} method which removes the first N elements from > the collection and returns them. This method would have the side-effect of > modifying the input collections (due to removal). > > {code:java} > // Some suggestions > void Collections.drain(Collection from, Collection to, int count); > Collection Collections.drain(Collection from, int count);{code} -- This message was sent by Atlassian Jira (v8.3.4#803005)