[jira] [Work logged] (LANG-1574) refine CharSequenceUtils.toCharArray
[ https://issues.apache.org/jira/browse/LANG-1574?focusedWorklogId=453787=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-453787 ] ASF GitHub Bot logged work on LANG-1574: Author: ASF GitHub Bot Created on: 02/Jul/20 05:16 Start Date: 02/Jul/20 05:16 Worklog Time Spent: 10m Work Description: XenoAmess commented on pull request #562: URL: https://github.com/apache/commons-lang/pull/562#issuecomment-652787499 @garydgregory so what is your opinions about this pr? And should I try to resolve conflict now? 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: 453787) Time Spent: 2h (was: 1h 50m) > refine CharSequenceUtils.toCharArray > > > Key: LANG-1574 > URL: https://issues.apache.org/jira/browse/LANG-1574 > Project: Commons Lang > Issue Type: Sub-task >Reporter: Jin Xu >Priority: Minor > Time Spent: 2h > Remaining Estimate: 0h > > [https://github.com/apache/commons-lang/pull/562] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-lang] XenoAmess commented on pull request #562: [LANG-1574] Refine CharSequencesUtils.toCharArray
XenoAmess commented on pull request #562: URL: https://github.com/apache/commons-lang/pull/562#issuecomment-652787499 @garydgregory so what is your opinions about this pr? And should I try to resolve conflict now? 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
[jira] [Work logged] (LANG-1574) refine CharSequenceUtils.toCharArray
[ https://issues.apache.org/jira/browse/LANG-1574?focusedWorklogId=453785=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-453785 ] ASF GitHub Bot logged work on LANG-1574: Author: ASF GitHub Bot Created on: 02/Jul/20 05:01 Start Date: 02/Jul/20 05:01 Worklog Time Spent: 10m Work Description: XenoAmess edited a comment on pull request #562: URL: https://github.com/apache/commons-lang/pull/562#issuecomment-652782560 > We cannot release with a component with a snapshot dependency on another, so until Commons Lang is released, Commons Text can have it's own version of the method. @garydgregory Oh yes you are right... I forgot we opened this function to public only recently... 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: 453785) Time Spent: 1h 50m (was: 1h 40m) > refine CharSequenceUtils.toCharArray > > > Key: LANG-1574 > URL: https://issues.apache.org/jira/browse/LANG-1574 > Project: Commons Lang > Issue Type: Sub-task >Reporter: Jin Xu >Priority: Minor > Time Spent: 1h 50m > Remaining Estimate: 0h > > [https://github.com/apache/commons-lang/pull/562] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-lang] XenoAmess commented on pull request #562: [LANG-1574] Refine CharSequencesUtils.toCharArray
XenoAmess commented on pull request #562: URL: https://github.com/apache/commons-lang/pull/562#issuecomment-652782560 > We cannot release with a component with a snapshot dependency on another, so until Commons Lang is released, Commons Text can have it's own version of the method. Oh yes you are right... I forgot we opened this function to public only recently... 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
[jira] [Work logged] (LANG-1574) refine CharSequenceUtils.toCharArray
[ https://issues.apache.org/jira/browse/LANG-1574?focusedWorklogId=453784=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-453784 ] ASF GitHub Bot logged work on LANG-1574: Author: ASF GitHub Bot Created on: 02/Jul/20 05:01 Start Date: 02/Jul/20 05:01 Worklog Time Spent: 10m Work Description: XenoAmess commented on pull request #562: URL: https://github.com/apache/commons-lang/pull/562#issuecomment-652782560 > We cannot release with a component with a snapshot dependency on another, so until Commons Lang is released, Commons Text can have it's own version of the method. Oh yes you are right... I forgot we opened this function to public only recently... 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: 453784) Time Spent: 1h 40m (was: 1.5h) > refine CharSequenceUtils.toCharArray > > > Key: LANG-1574 > URL: https://issues.apache.org/jira/browse/LANG-1574 > Project: Commons Lang > Issue Type: Sub-task >Reporter: Jin Xu >Priority: Minor > Time Spent: 1h 40m > Remaining Estimate: 0h > > [https://github.com/apache/commons-lang/pull/562] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-lang] XenoAmess edited a comment on pull request #562: [LANG-1574] Refine CharSequencesUtils.toCharArray
XenoAmess edited a comment on pull request #562: URL: https://github.com/apache/commons-lang/pull/562#issuecomment-652782560 > We cannot release with a component with a snapshot dependency on another, so until Commons Lang is released, Commons Text can have it's own version of the method. @garydgregory Oh yes you are right... I forgot we opened this function to public only recently... 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
[jira] [Work logged] (LANG-1574) refine CharSequenceUtils.toCharArray
[ https://issues.apache.org/jira/browse/LANG-1574?focusedWorklogId=453768=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-453768 ] ASF GitHub Bot logged work on LANG-1574: Author: ASF GitHub Bot Created on: 02/Jul/20 03:51 Start Date: 02/Jul/20 03:51 Worklog Time Spent: 10m Work Description: garydgregory commented on pull request #562: URL: https://github.com/apache/commons-lang/pull/562#issuecomment-652765782 We cannot release with a component with a snapshot dependency on another, so until Commons Lang is released, Commons Text can have it's own version of the method. 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: 453768) Time Spent: 1.5h (was: 1h 20m) > refine CharSequenceUtils.toCharArray > > > Key: LANG-1574 > URL: https://issues.apache.org/jira/browse/LANG-1574 > Project: Commons Lang > Issue Type: Sub-task >Reporter: Jin Xu >Priority: Minor > Time Spent: 1.5h > Remaining Estimate: 0h > > [https://github.com/apache/commons-lang/pull/562] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-lang] garydgregory commented on pull request #562: [LANG-1574] Refine CharSequencesUtils.toCharArray
garydgregory commented on pull request #562: URL: https://github.com/apache/commons-lang/pull/562#issuecomment-652765782 We cannot release with a component with a snapshot dependency on another, so until Commons Lang is released, Commons Text can have it's own version of the method. 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
[jira] [Work logged] (LANG-1574) refine CharSequenceUtils.toCharArray
[
https://issues.apache.org/jira/browse/LANG-1574?focusedWorklogId=453727=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-453727
]
ASF GitHub Bot logged work on LANG-1574:
Author: ASF GitHub Bot
Created on: 02/Jul/20 00:28
Start Date: 02/Jul/20 00:28
Worklog Time Spent: 10m
Work Description: XenoAmess edited a comment on pull request #562:
URL: https://github.com/apache/commons-lang/pull/562#issuecomment-652707356
> I sync'd this method's impl with the one in Commons Text; Text will
eventually reuse this method. WRT this patch, I do not see any explanation for
the use of the magic number 32.
@garydgregory
Hi.
1. I added a null-check for this function, so parameter null will not cause
trouble now.( by StringUtils.length() function.)
2. I added a length-check for not create new array when length == 0( by
StringUtils.length() function too.)
I see your latest commit, and seems you are agreed with thest two changes.
Maybe I should tell more about how I get the number 32.
You can see in the jmh test I added, there actually exists two functions.
```
public static char[] toCharArrayOld(final CharSequence cs) {
if (cs instanceof String) {
return ((String) cs).toCharArray();
}
final int sz = cs.length();
final char[] array = new char[cs.length()];
for (int i = 0; i < sz; i++) {
array[i] = cs.charAt(i);
}
return array;
}
/**
* Green implementation of toCharArray.
*
* @param cs the {@code CharSequence} to be processed
* @return the resulting char array
* @since 3.11
*/
public static char[] toCharArrayNew(final CharSequence cs) {
return cs.toString().toCharArray();
}
```
They actually do the same thing, the only difference is speed.
In theory, if the CharSequence is short enough, then toCharArrayOld should
be faster, as it does not cast a toString.
If CharSequence is long otherwise, then toCharArrayNew should be faster, as
usually when we implement a CharSequence, in toString we can have some more
efficient way than get all chars using index, one by one.
In other world, there exist a magic number m, when length <= m, we should
use toCharArrayOld. Otherwise we should use toCharArrayNew.
And we get the function in the main codes, who use toCharArrayOld when
length <= m, use toCharArrayNew when length > m
For why I chose the number 32:
In short, that is gotten from performance tests in jmh.
For CharBuffer and StringBuffer, it is always faster to use toCharArrayNew,
means you can see n as -1.
But for StringBuilder, it is around 32. At least 32 is better than 16, and
the n is between 16 and 32 according to my jmh tests.
I just think 32 is a elegant number to use here.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 453727)
Time Spent: 1h 20m (was: 1h 10m)
> refine CharSequenceUtils.toCharArray
>
>
> Key: LANG-1574
> URL: https://issues.apache.org/jira/browse/LANG-1574
> Project: Commons Lang
> Issue Type: Sub-task
>Reporter: Jin Xu
>Priority: Minor
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> [https://github.com/apache/commons-lang/pull/562]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] XenoAmess edited a comment on pull request #562: [LANG-1574] Refine CharSequencesUtils.toCharArray
XenoAmess edited a comment on pull request #562:
URL: https://github.com/apache/commons-lang/pull/562#issuecomment-652707356
> I sync'd this method's impl with the one in Commons Text; Text will
eventually reuse this method. WRT this patch, I do not see any explanation for
the use of the magic number 32.
@garydgregory
Hi.
1. I added a null-check for this function, so parameter null will not cause
trouble now.( by StringUtils.length() function.)
2. I added a length-check for not create new array when length == 0( by
StringUtils.length() function too.)
I see your latest commit, and seems you are agreed with thest two changes.
Maybe I should tell more about how I get the number 32.
You can see in the jmh test I added, there actually exists two functions.
```
public static char[] toCharArrayOld(final CharSequence cs) {
if (cs instanceof String) {
return ((String) cs).toCharArray();
}
final int sz = cs.length();
final char[] array = new char[cs.length()];
for (int i = 0; i < sz; i++) {
array[i] = cs.charAt(i);
}
return array;
}
/**
* Green implementation of toCharArray.
*
* @param cs the {@code CharSequence} to be processed
* @return the resulting char array
* @since 3.11
*/
public static char[] toCharArrayNew(final CharSequence cs) {
return cs.toString().toCharArray();
}
```
They actually do the same thing, the only difference is speed.
In theory, if the CharSequence is short enough, then toCharArrayOld should
be faster, as it does not cast a toString.
If CharSequence is long otherwise, then toCharArrayNew should be faster, as
usually when we implement a CharSequence, in toString we can have some more
efficient way than get all chars using index, one by one.
In other world, there exist a magic number m, when length <= m, we should
use toCharArrayOld. Otherwise we should use toCharArrayNew.
And we get the function in the main codes, who use toCharArrayOld when
length <= m, use toCharArrayNew when length > m
For why I chose the number 32:
In short, that is gotten from performance tests in jmh.
For CharBuffer and StringBuffer, it is always faster to use toCharArrayNew,
means you can see n as -1.
But for StringBuilder, it is around 32. At least 32 is better than 16, and
the n is between 16 and 32 according to my jmh tests.
I just think 32 is a elegant number to use here.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Work logged] (LANG-1574) refine CharSequenceUtils.toCharArray
[
https://issues.apache.org/jira/browse/LANG-1574?focusedWorklogId=453725=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-453725
]
ASF GitHub Bot logged work on LANG-1574:
Author: ASF GitHub Bot
Created on: 02/Jul/20 00:27
Start Date: 02/Jul/20 00:27
Worklog Time Spent: 10m
Work Description: XenoAmess edited a comment on pull request #562:
URL: https://github.com/apache/commons-lang/pull/562#issuecomment-652707356
> I sync'd this method's impl with the one in Commons Text; Text will
eventually reuse this method. WRT this patch, I do not see any explanation for
the use of the magic number 32.
@garydgregory
Hi.
1. I added a null-check for this function, so parameter null will not cause
trouble now.( by StringUtils.length() function.)
2. I added a length-check for not create new array when length == 0( by
StringUtils.length() function too.)
I see your latest commit, and seems you are agreed with thest two changes.
Maybe I should tell more about how I get the number 32.
You can see in the jmh test I added, there actually exists two functions.
```
public static char[] toCharArrayOld(final CharSequence cs) {
if (cs instanceof String) {
return ((String) cs).toCharArray();
}
final int sz = cs.length();
final char[] array = new char[cs.length()];
for (int i = 0; i < sz; i++) {
array[i] = cs.charAt(i);
}
return array;
}
/**
* Green implementation of toCharArray.
*
* @param cs the {@code CharSequence} to be processed
* @return the resulting char array
* @since 3.11
*/
public static char[] toCharArrayNew(final CharSequence cs) {
return cs.toString().toCharArray();
}
```
They actually do the same thing, the only difference is speed.
In theory, if the CharSequence is short enough, then toCharArrayOld should
be faster, as it does not cast a toString.
If CharSequence is long otherwise, then toCharArrayNew should be faster, as
usually when we implement a CharSequence, in toString we can have some more
efficient way than get all chars using index, one by one.
In other world, there exist a magic number m, when length < m, we should use
toCharArrayOld. Otherwise we should use toCharArrayNew.
And we get the function in the main codes, who use toCharArrayOld when
length < m, use toCharArrayNew when length >= m
For why I chose the number 32:
In short, that is gotten from performance tests in jmh.
For CharBuffer and StringBuffer, it is always faster to use toCharArrayNew,
means you can see n as -1.
But for StringBuilder, it is around 32. At least 32 is better than 16, and
the n is between 16 and 32 according to my jmh tests.
I just think 32 is a elegant number to use here.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 453725)
Time Spent: 1h 10m (was: 1h)
> refine CharSequenceUtils.toCharArray
>
>
> Key: LANG-1574
> URL: https://issues.apache.org/jira/browse/LANG-1574
> Project: Commons Lang
> Issue Type: Sub-task
>Reporter: Jin Xu
>Priority: Minor
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> [https://github.com/apache/commons-lang/pull/562]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] XenoAmess edited a comment on pull request #562: [LANG-1574] Refine CharSequencesUtils.toCharArray
XenoAmess edited a comment on pull request #562:
URL: https://github.com/apache/commons-lang/pull/562#issuecomment-652707356
> I sync'd this method's impl with the one in Commons Text; Text will
eventually reuse this method. WRT this patch, I do not see any explanation for
the use of the magic number 32.
@garydgregory
Hi.
1. I added a null-check for this function, so parameter null will not cause
trouble now.( by StringUtils.length() function.)
2. I added a length-check for not create new array when length == 0( by
StringUtils.length() function too.)
I see your latest commit, and seems you are agreed with thest two changes.
Maybe I should tell more about how I get the number 32.
You can see in the jmh test I added, there actually exists two functions.
```
public static char[] toCharArrayOld(final CharSequence cs) {
if (cs instanceof String) {
return ((String) cs).toCharArray();
}
final int sz = cs.length();
final char[] array = new char[cs.length()];
for (int i = 0; i < sz; i++) {
array[i] = cs.charAt(i);
}
return array;
}
/**
* Green implementation of toCharArray.
*
* @param cs the {@code CharSequence} to be processed
* @return the resulting char array
* @since 3.11
*/
public static char[] toCharArrayNew(final CharSequence cs) {
return cs.toString().toCharArray();
}
```
They actually do the same thing, the only difference is speed.
In theory, if the CharSequence is short enough, then toCharArrayOld should
be faster, as it does not cast a toString.
If CharSequence is long otherwise, then toCharArrayNew should be faster, as
usually when we implement a CharSequence, in toString we can have some more
efficient way than get all chars using index, one by one.
In other world, there exist a magic number m, when length < m, we should use
toCharArrayOld. Otherwise we should use toCharArrayNew.
And we get the function in the main codes, who use toCharArrayOld when
length < m, use toCharArrayNew when length >= m
For why I chose the number 32:
In short, that is gotten from performance tests in jmh.
For CharBuffer and StringBuffer, it is always faster to use toCharArrayNew,
means you can see n as -1.
But for StringBuilder, it is around 32. At least 32 is better than 16, and
the n is between 16 and 32 according to my jmh tests.
I just think 32 is a elegant number to use here.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [commons-lang] XenoAmess commented on pull request #562: [LANG-1574] Refine CharSequencesUtils.toCharArray
XenoAmess commented on pull request #562: URL: https://github.com/apache/commons-lang/pull/562#issuecomment-652708746 @garydgregory besides, I didn't see the meaning of reimplement this function in commons-text. I mean, commons-text have commons-lang as a dependency isn't it? shouldn't it be more reasonable to use the function in commons-lang directly? 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
[jira] [Work logged] (LANG-1574) refine CharSequenceUtils.toCharArray
[ https://issues.apache.org/jira/browse/LANG-1574?focusedWorklogId=453722=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-453722 ] ASF GitHub Bot logged work on LANG-1574: Author: ASF GitHub Bot Created on: 02/Jul/20 00:20 Start Date: 02/Jul/20 00:20 Worklog Time Spent: 10m Work Description: XenoAmess commented on pull request #562: URL: https://github.com/apache/commons-lang/pull/562#issuecomment-652708746 @garydgregory besides, I didn't see the meaning of reimplement this function in commons-text. I mean, commons-text have commons-lang as a dependency isn't it? shouldn't it be more reasonable to use the function in commons-lang directly? 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: 453722) Time Spent: 1h (was: 50m) > refine CharSequenceUtils.toCharArray > > > Key: LANG-1574 > URL: https://issues.apache.org/jira/browse/LANG-1574 > Project: Commons Lang > Issue Type: Sub-task >Reporter: Jin Xu >Priority: Minor > Time Spent: 1h > Remaining Estimate: 0h > > [https://github.com/apache/commons-lang/pull/562] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (LANG-1574) refine CharSequenceUtils.toCharArray
[
https://issues.apache.org/jira/browse/LANG-1574?focusedWorklogId=453720=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-453720
]
ASF GitHub Bot logged work on LANG-1574:
Author: ASF GitHub Bot
Created on: 02/Jul/20 00:16
Start Date: 02/Jul/20 00:16
Worklog Time Spent: 10m
Work Description: XenoAmess commented on pull request #562:
URL: https://github.com/apache/commons-lang/pull/562#issuecomment-652707356
> I sync'd this method's impl with the one in Commons Text; Text will
eventually reuse this method. WRT this patch, I do not see any explanation for
the use of the magic number 32.
Hi.
1. I added a null-check for this function, so parameter null will not cause
trouble now.( by StringUtils.length() function.)
2. I added a length-check for not create new array when length == 0( by
StringUtils.length() function too.)
I see your latest commit, and seems you are agreed with this change.
Maybe I should tell more about how I get the number 32.
You can see in the jmh test I added, there actually exists two functions.
```
public static char[] toCharArrayOld(final CharSequence cs) {
if (cs instanceof String) {
return ((String) cs).toCharArray();
}
final int sz = cs.length();
final char[] array = new char[cs.length()];
for (int i = 0; i < sz; i++) {
array[i] = cs.charAt(i);
}
return array;
}
/**
* Green implementation of toCharArray.
*
* @param cs the {@code CharSequence} to be processed
* @return the resulting char array
* @since 3.11
*/
public static char[] toCharArrayNew(final CharSequence cs) {
return cs.toString().toCharArray();
}
```
They actually do the same thing, the only difference is speed.
In theory, if the CharSequence is short enough, then toCharArrayOld should
be faster, as it does not cast a toString.
If CharSequence is long otherwise, then toCharArrayNew should be faster, as
usually when we implement a CharSequence, in toString we can have some more
efficient way than get all chars using index, one by one.
In other world, there exist a magic number m, when length < m, we should use
toCharArrayOld. Otherwise we should use toCharArrayNew.
And we get the function in the main codes.
For why I chose the number 32:
In short, that is gotten from performance tests in jmh.
For CharBuffer and StringBuffer, it is always faster to use toCharArrayNew,
means you can see n as -1.
But for StringBuilder, it is around 32. At least 32 is better than 16, and
the n is between 16 and 32 according to my jmh tests.
I just think 32 is a elegant number to use here.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 453720)
Time Spent: 40m (was: 0.5h)
> refine CharSequenceUtils.toCharArray
>
>
> Key: LANG-1574
> URL: https://issues.apache.org/jira/browse/LANG-1574
> Project: Commons Lang
> Issue Type: Sub-task
>Reporter: Jin Xu
>Priority: Minor
> Time Spent: 40m
> Remaining Estimate: 0h
>
> [https://github.com/apache/commons-lang/pull/562]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (LANG-1574) refine CharSequenceUtils.toCharArray
[
https://issues.apache.org/jira/browse/LANG-1574?focusedWorklogId=453721=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-453721
]
ASF GitHub Bot logged work on LANG-1574:
Author: ASF GitHub Bot
Created on: 02/Jul/20 00:16
Start Date: 02/Jul/20 00:16
Worklog Time Spent: 10m
Work Description: XenoAmess edited a comment on pull request #562:
URL: https://github.com/apache/commons-lang/pull/562#issuecomment-652707356
> I sync'd this method's impl with the one in Commons Text; Text will
eventually reuse this method. WRT this patch, I do not see any explanation for
the use of the magic number 32.
@garydgregory
Hi.
1. I added a null-check for this function, so parameter null will not cause
trouble now.( by StringUtils.length() function.)
2. I added a length-check for not create new array when length == 0( by
StringUtils.length() function too.)
I see your latest commit, and seems you are agreed with thest two changes.
Maybe I should tell more about how I get the number 32.
You can see in the jmh test I added, there actually exists two functions.
```
public static char[] toCharArrayOld(final CharSequence cs) {
if (cs instanceof String) {
return ((String) cs).toCharArray();
}
final int sz = cs.length();
final char[] array = new char[cs.length()];
for (int i = 0; i < sz; i++) {
array[i] = cs.charAt(i);
}
return array;
}
/**
* Green implementation of toCharArray.
*
* @param cs the {@code CharSequence} to be processed
* @return the resulting char array
* @since 3.11
*/
public static char[] toCharArrayNew(final CharSequence cs) {
return cs.toString().toCharArray();
}
```
They actually do the same thing, the only difference is speed.
In theory, if the CharSequence is short enough, then toCharArrayOld should
be faster, as it does not cast a toString.
If CharSequence is long otherwise, then toCharArrayNew should be faster, as
usually when we implement a CharSequence, in toString we can have some more
efficient way than get all chars using index, one by one.
In other world, there exist a magic number m, when length < m, we should use
toCharArrayOld. Otherwise we should use toCharArrayNew.
And we get the function in the main codes.
For why I chose the number 32:
In short, that is gotten from performance tests in jmh.
For CharBuffer and StringBuffer, it is always faster to use toCharArrayNew,
means you can see n as -1.
But for StringBuilder, it is around 32. At least 32 is better than 16, and
the n is between 16 and 32 according to my jmh tests.
I just think 32 is a elegant number to use here.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 453721)
Time Spent: 50m (was: 40m)
> refine CharSequenceUtils.toCharArray
>
>
> Key: LANG-1574
> URL: https://issues.apache.org/jira/browse/LANG-1574
> Project: Commons Lang
> Issue Type: Sub-task
>Reporter: Jin Xu
>Priority: Minor
> Time Spent: 50m
> Remaining Estimate: 0h
>
> [https://github.com/apache/commons-lang/pull/562]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] XenoAmess edited a comment on pull request #562: [LANG-1574] Refine CharSequencesUtils.toCharArray
XenoAmess edited a comment on pull request #562:
URL: https://github.com/apache/commons-lang/pull/562#issuecomment-652707356
> I sync'd this method's impl with the one in Commons Text; Text will
eventually reuse this method. WRT this patch, I do not see any explanation for
the use of the magic number 32.
@garydgregory
Hi.
1. I added a null-check for this function, so parameter null will not cause
trouble now.( by StringUtils.length() function.)
2. I added a length-check for not create new array when length == 0( by
StringUtils.length() function too.)
I see your latest commit, and seems you are agreed with thest two changes.
Maybe I should tell more about how I get the number 32.
You can see in the jmh test I added, there actually exists two functions.
```
public static char[] toCharArrayOld(final CharSequence cs) {
if (cs instanceof String) {
return ((String) cs).toCharArray();
}
final int sz = cs.length();
final char[] array = new char[cs.length()];
for (int i = 0; i < sz; i++) {
array[i] = cs.charAt(i);
}
return array;
}
/**
* Green implementation of toCharArray.
*
* @param cs the {@code CharSequence} to be processed
* @return the resulting char array
* @since 3.11
*/
public static char[] toCharArrayNew(final CharSequence cs) {
return cs.toString().toCharArray();
}
```
They actually do the same thing, the only difference is speed.
In theory, if the CharSequence is short enough, then toCharArrayOld should
be faster, as it does not cast a toString.
If CharSequence is long otherwise, then toCharArrayNew should be faster, as
usually when we implement a CharSequence, in toString we can have some more
efficient way than get all chars using index, one by one.
In other world, there exist a magic number m, when length < m, we should use
toCharArrayOld. Otherwise we should use toCharArrayNew.
And we get the function in the main codes.
For why I chose the number 32:
In short, that is gotten from performance tests in jmh.
For CharBuffer and StringBuffer, it is always faster to use toCharArrayNew,
means you can see n as -1.
But for StringBuilder, it is around 32. At least 32 is better than 16, and
the n is between 16 and 32 according to my jmh tests.
I just think 32 is a elegant number to use here.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [commons-lang] XenoAmess commented on pull request #562: [LANG-1574] Refine CharSequencesUtils.toCharArray
XenoAmess commented on pull request #562:
URL: https://github.com/apache/commons-lang/pull/562#issuecomment-652707356
> I sync'd this method's impl with the one in Commons Text; Text will
eventually reuse this method. WRT this patch, I do not see any explanation for
the use of the magic number 32.
Hi.
1. I added a null-check for this function, so parameter null will not cause
trouble now.( by StringUtils.length() function.)
2. I added a length-check for not create new array when length == 0( by
StringUtils.length() function too.)
I see your latest commit, and seems you are agreed with this change.
Maybe I should tell more about how I get the number 32.
You can see in the jmh test I added, there actually exists two functions.
```
public static char[] toCharArrayOld(final CharSequence cs) {
if (cs instanceof String) {
return ((String) cs).toCharArray();
}
final int sz = cs.length();
final char[] array = new char[cs.length()];
for (int i = 0; i < sz; i++) {
array[i] = cs.charAt(i);
}
return array;
}
/**
* Green implementation of toCharArray.
*
* @param cs the {@code CharSequence} to be processed
* @return the resulting char array
* @since 3.11
*/
public static char[] toCharArrayNew(final CharSequence cs) {
return cs.toString().toCharArray();
}
```
They actually do the same thing, the only difference is speed.
In theory, if the CharSequence is short enough, then toCharArrayOld should
be faster, as it does not cast a toString.
If CharSequence is long otherwise, then toCharArrayNew should be faster, as
usually when we implement a CharSequence, in toString we can have some more
efficient way than get all chars using index, one by one.
In other world, there exist a magic number m, when length < m, we should use
toCharArrayOld. Otherwise we should use toCharArrayNew.
And we get the function in the main codes.
For why I chose the number 32:
In short, that is gotten from performance tests in jmh.
For CharBuffer and StringBuffer, it is always faster to use toCharArrayNew,
means you can see n as -1.
But for StringBuilder, it is around 32. At least 32 is better than 16, and
the n is between 16 and 32 according to my jmh tests.
I just think 32 is a elegant number to use here.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Work logged] (LANG-1574) refine CharSequenceUtils.toCharArray
[ https://issues.apache.org/jira/browse/LANG-1574?focusedWorklogId=453670=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-453670 ] ASF GitHub Bot logged work on LANG-1574: Author: ASF GitHub Bot Created on: 01/Jul/20 21:23 Start Date: 01/Jul/20 21:23 Worklog Time Spent: 10m Work Description: garydgregory commented on pull request #562: URL: https://github.com/apache/commons-lang/pull/562#issuecomment-652653647 I sync'd this method's impl with the one in Commons Text; Text will eventually reuse this method. WRT this patch, I do not see any explanation for the use of the magic number 32. 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: 453670) Time Spent: 0.5h (was: 20m) > refine CharSequenceUtils.toCharArray > > > Key: LANG-1574 > URL: https://issues.apache.org/jira/browse/LANG-1574 > Project: Commons Lang > Issue Type: Sub-task >Reporter: Jin Xu >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > [https://github.com/apache/commons-lang/pull/562] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-lang] garydgregory commented on pull request #562: [LANG-1574] Refine CharSequencesUtils.toCharArray
garydgregory commented on pull request #562: URL: https://github.com/apache/commons-lang/pull/562#issuecomment-652653647 I sync'd this method's impl with the one in Commons Text; Text will eventually reuse this method. WRT this patch, I do not see any explanation for the use of the magic number 32. 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
[jira] [Updated] (DBCP-566) Clear PreparedStatement pool when connection is returned to the pool
[ https://issues.apache.org/jira/browse/DBCP-566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated DBCP-566: - Affects Version/s: (was: 2.7.0) > Clear PreparedStatement pool when connection is returned to the pool > > > Key: DBCP-566 > URL: https://issues.apache.org/jira/browse/DBCP-566 > Project: Commons DBCP > Issue Type: New Feature >Reporter: Robert Paschek >Priority: Major > > With the current configuration option poolPreparedStatements true the > statements are held open for the lifetime of the connection. This results in > cursors being open and locks in the database for a long time, which could > cause problems with administrative tasks in the database. > There should be an additional configuration clearStatementPoolOnReturn. When > set to true, the pool will be cleared and the statements closed when the > connection is returned to the pool. Default can be false to retain the > current behaviour. > With this the application can still benefit from the Statement-cache in mass > operations. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DBCP-566) Clear PreparedStatement pool when connection is returned to the pool
[ https://issues.apache.org/jira/browse/DBCP-566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149666#comment-17149666 ] Gary D. Gregory commented on DBCP-566: -- PRs welcome :) > Clear PreparedStatement pool when connection is returned to the pool > > > Key: DBCP-566 > URL: https://issues.apache.org/jira/browse/DBCP-566 > Project: Commons DBCP > Issue Type: New Feature >Affects Versions: 2.7.0 >Reporter: Robert Paschek >Priority: Major > > With the current configuration option poolPreparedStatements true the > statements are held open for the lifetime of the connection. This results in > cursors being open and locks in the database for a long time, which could > cause problems with administrative tasks in the database. > There should be an additional configuration clearStatementPoolOnReturn. When > set to true, the pool will be cleared and the statements closed when the > connection is returned to the pool. Default can be false to retain the > current behaviour. > With this the application can still benefit from the Statement-cache in mass > operations. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (DBCP-566) Clear PreparedStatement pool when connection is returned to the pool
[ https://issues.apache.org/jira/browse/DBCP-566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Paschek updated DBCP-566: Summary: Clear PreparedStatement pool when connection is returned to the pool (was: Clear PrepareStatement pool when connection is returned to the pool) > Clear PreparedStatement pool when connection is returned to the pool > > > Key: DBCP-566 > URL: https://issues.apache.org/jira/browse/DBCP-566 > Project: Commons DBCP > Issue Type: New Feature >Affects Versions: 2.7.0 >Reporter: Robert Paschek >Priority: Major > > With the current configuration option poolPreparedStatements true the > statements are held open for the lifetime of the connection. This results in > cursors being open and locks in the database for a long time, which could > cause problems with administrative tasks in the database. > There should be an additional configuration clearStatementPoolOnReturn. When > set to true, the pool will be cleared and the statements closed when the > connection is returned to the pool. Default can be false to retain the > current behaviour. > With this the application can still benefit from the Statement-cache in mass > operations. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (DBCP-566) Clear PrepareStatement pool when connection is returned to the pool
Robert Paschek created DBCP-566: --- Summary: Clear PrepareStatement pool when connection is returned to the pool Key: DBCP-566 URL: https://issues.apache.org/jira/browse/DBCP-566 Project: Commons DBCP Issue Type: New Feature Affects Versions: 2.7.0 Reporter: Robert Paschek With the current configuration option poolPreparedStatements true the statements are held open for the lifetime of the connection. This results in cursors being open and locks in the database for a long time, which could cause problems with administrative tasks in the database. There should be an additional configuration clearStatementPoolOnReturn. When set to true, the pool will be cleared and the statements closed when the connection is returned to the pool. Default can be false to retain the current behaviour. With this the application can still benefit from the Statement-cache in mass operations. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-geometry] singhbaljit commented on pull request #82: GEOMETRY-63: Various style issues
singhbaljit commented on pull request #82: URL: https://github.com/apache/commons-geometry/pull/82#issuecomment-652528092 @darkma773r Let me know if any change is not consistent. 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
[GitHub] [commons-geometry] singhbaljit opened a new pull request #82: GEOMETRY-63: Various style issues
singhbaljit opened a new pull request #82: URL: https://github.com/apache/commons-geometry/pull/82 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
[jira] [Resolved] (IO-675) InfiniteCircularInputStream throws a divide-by-zero exception when reading if its input buffer is size 0
[
https://issues.apache.org/jira/browse/IO-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved IO-675.
Fix Version/s: 2.8
Resolution: Fixed
> InfiniteCircularInputStream throws a divide-by-zero exception when reading if
> its input buffer is size 0
>
>
> Key: IO-675
> URL: https://issues.apache.org/jira/browse/IO-675
> Project: Commons IO
> Issue Type: Bug
> Components: Streams/Writers
>Reporter: Gary D. Gregory
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.8
>
>
> {{InfiniteCircularInputStream}} throws a divide-by-zero exception when
> reading if its input buffer is size 0.
> Instead, we will validate the buffer on construction.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IO-674) InfiniteCircularInputStream is not infinite if its input buffer contains -1
[
https://issues.apache.org/jira/browse/IO-674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved IO-674.
Fix Version/s: 2.8
Resolution: Fixed
> InfiniteCircularInputStream is not infinite if its input buffer contains -1
> ---
>
> Key: IO-674
> URL: https://issues.apache.org/jira/browse/IO-674
> Project: Commons IO
> Issue Type: Bug
> Components: Streams/Writers
>Reporter: Gary D. Gregory
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.8
>
>
> {{InfiniteCircularInputStream}} is not infinite if its input buffer contains
> -1 since that is the end of stream marker.
> Instead, we will validate the buffer on construction.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IO-675) InfiniteCircularInputStream throws a divide-by-zero exception when reading if its input buffer is size 0
[ https://issues.apache.org/jira/browse/IO-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated IO-675: --- Description: InfiniteCircularInputStream throws a divide-by-zero exception when reading if its input buffer is size 0. Instead, we will validate the buffer on construction. was: InfiniteCircularInputStream throws an exception when reading if its input buffer is size 0. Instead, we will validate the buffer on construction. > InfiniteCircularInputStream throws a divide-by-zero exception when reading if > its input buffer is size 0 > > > Key: IO-675 > URL: https://issues.apache.org/jira/browse/IO-675 > Project: Commons IO > Issue Type: Bug > Components: Streams/Writers >Reporter: Gary D. Gregory >Assignee: Gary D. Gregory >Priority: Major > > InfiniteCircularInputStream throws a divide-by-zero exception when reading if > its input buffer is size 0. > Instead, we will validate the buffer on construction. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IO-675) InfiniteCircularInputStream throws a divide-by-zero exception when reading if its input buffer is size 0
[
https://issues.apache.org/jira/browse/IO-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated IO-675:
---
Description:
{{InfiniteCircularInputStream}} throws a divide-by-zero exception when reading
if its input buffer is size 0.
Instead, we will validate the buffer on construction.
was:
InfiniteCircularInputStream throws a divide-by-zero exception when reading if
its input buffer is size 0.
Instead, we will validate the buffer on construction.
> InfiniteCircularInputStream throws a divide-by-zero exception when reading if
> its input buffer is size 0
>
>
> Key: IO-675
> URL: https://issues.apache.org/jira/browse/IO-675
> Project: Commons IO
> Issue Type: Bug
> Components: Streams/Writers
>Reporter: Gary D. Gregory
>Assignee: Gary D. Gregory
>Priority: Major
>
> {{InfiniteCircularInputStream}} throws a divide-by-zero exception when
> reading if its input buffer is size 0.
> Instead, we will validate the buffer on construction.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IO-675) InfiniteCircularInputStream throws a divide-by-zero exception when reading if its input buffer is size 0
[ https://issues.apache.org/jira/browse/IO-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated IO-675: --- Summary: InfiniteCircularInputStream throws a divide-by-zero exception when reading if its input buffer is size 0 (was: InfiniteCircularInputStream throws an exception when reading if its input buffer is size 0) > InfiniteCircularInputStream throws a divide-by-zero exception when reading if > its input buffer is size 0 > > > Key: IO-675 > URL: https://issues.apache.org/jira/browse/IO-675 > Project: Commons IO > Issue Type: Bug > Components: Streams/Writers >Reporter: Gary D. Gregory >Assignee: Gary D. Gregory >Priority: Major > > InfiniteCircularInputStream throws an exception when reading if its input > buffer is size 0. > Instead, we will validate the buffer on construction. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IO-675) InfiniteCircularInputStream throws an exception when reading if its input buffer is size 0
[ https://issues.apache.org/jira/browse/IO-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated IO-675: --- Description: InfiniteCircularInputStream throws an exception when reading if its input buffer is size 0. Instead, we will validate the buffer on construction. was:InfiniteCircularInputStream throws an exception when reading if its input buffer is size 0. > InfiniteCircularInputStream throws an exception when reading if its input > buffer is size 0 > -- > > Key: IO-675 > URL: https://issues.apache.org/jira/browse/IO-675 > Project: Commons IO > Issue Type: Bug > Components: Streams/Writers >Reporter: Gary D. Gregory >Assignee: Gary D. Gregory >Priority: Major > > InfiniteCircularInputStream throws an exception when reading if its input > buffer is size 0. > Instead, we will validate the buffer on construction. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IO-674) InfiniteCircularInputStream is not infinite if its input buffer contains -1
[
https://issues.apache.org/jira/browse/IO-674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated IO-674:
---
Description:
{{InfiniteCircularInputStream}} is not infinite if its input buffer contains -1
since that is the end of stream marker.
Instead, we will validate the buffer on construction.
was:
{{InfiniteCircularInputStream}} is not infinite if its input buffer contains -1
since that is the end of stream marker.
> InfiniteCircularInputStream is not infinite if its input buffer contains -1
> ---
>
> Key: IO-674
> URL: https://issues.apache.org/jira/browse/IO-674
> Project: Commons IO
> Issue Type: Bug
> Components: Streams/Writers
>Reporter: Gary D. Gregory
>Assignee: Gary D. Gregory
>Priority: Major
>
> {{InfiniteCircularInputStream}} is not infinite if its input buffer contains
> -1 since that is the end of stream marker.
> Instead, we will validate the buffer on construction.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IO-675) InfiniteCircularInputStream throws an exception when reading if its input buffer is size 0
Gary D. Gregory created IO-675: -- Summary: InfiniteCircularInputStream throws an exception when reading if its input buffer is size 0 Key: IO-675 URL: https://issues.apache.org/jira/browse/IO-675 Project: Commons IO Issue Type: Bug Components: Streams/Writers Reporter: Gary D. Gregory Assignee: Gary D. Gregory InfiniteCircularInputStream throws an exception when reading if its input buffer is size 0. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IO-674) InfiniteCircularInputStream is not infinite if its input buffer contains -1
Gary D. Gregory created IO-674:
--
Summary: InfiniteCircularInputStream is not infinite if its input
buffer contains -1
Key: IO-674
URL: https://issues.apache.org/jira/browse/IO-674
Project: Commons IO
Issue Type: Bug
Components: Streams/Writers
Reporter: Gary D. Gregory
Assignee: Gary D. Gregory
{{InfiniteCircularInputStream}} is not infinite if its input buffer contains -1
since that is the end of stream marker.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COMPRESS-507) Commons Compress cannot be built with JDK14 due to Pack200 removal
[ https://issues.apache.org/jira/browse/COMPRESS-507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149329#comment-17149329 ] Stefan Bodewig commented on COMPRESS-507: - AFAICT there still is no replacement library. So one possible solution for 1.21 still may be to completely remove pack200 support (and maybe move it to a module distributed separately), but we haven't decided anything, yet. In fact the current master still doesn't compile with JDK 14+ I'm not sure I understand why this build time problem causes issues for you - assuming you use a binary of Commons Compress built on JDK earlier than 14 (the one in Maven Central has been built with JDK 8). If you try to use Pack200 on JDK14+ it would probably fail even if there was a replacement library as the existing pack200 code (before it was removed) didn't work with Java14 bytecode AFAIU. > Commons Compress cannot be built with JDK14 due to Pack200 removal > -- > > Key: COMPRESS-507 > URL: https://issues.apache.org/jira/browse/COMPRESS-507 > Project: Commons Compress > Issue Type: Bug > Components: Build, Compressors >Affects Versions: 1.20 >Reporter: Vincent Privat >Priority: Major > Fix For: 1.21 > > > Oracle dropped Pack200 in JDK14 as per > [https://bugs.openjdk.java.net/browse/JDK-8232022] > Someone expressed his will to maintain Pack200 here: > [https://mail.openjdk.java.net/pipermail/jdk-dev/2020-March/003979.html] > [https://github.com/pfirmstone/Pack200-ex-openjdk] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (COMPRESS-507) Commons Compress cannot be built with JDK14 due to Pack200 removal
[ https://issues.apache.org/jira/browse/COMPRESS-507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149288#comment-17149288 ] Lőrinc Pap commented on COMPRESS-507: - Hey, we've just bumped into this issue, Proguard failing with > Warning: >org.apache.commons.compress.compressors.pack200.Pack200CompressorInputStream: >can't find referenced class java.util.jar.Pack200 when attempting a compilation with JDK 14, since testcontainers depends on commons-compress transitively. Is there a 1.21 snapshot with a fix already? Or an additional library that we could add that would fix this? > Commons Compress cannot be built with JDK14 due to Pack200 removal > -- > > Key: COMPRESS-507 > URL: https://issues.apache.org/jira/browse/COMPRESS-507 > Project: Commons Compress > Issue Type: Bug > Components: Build, Compressors >Affects Versions: 1.20 >Reporter: Vincent Privat >Priority: Major > Fix For: 1.21 > > > Oracle dropped Pack200 in JDK14 as per > [https://bugs.openjdk.java.net/browse/JDK-8232022] > Someone expressed his will to maintain Pack200 here: > [https://mail.openjdk.java.net/pipermail/jdk-dev/2020-March/003979.html] > [https://github.com/pfirmstone/Pack200-ex-openjdk] -- This message was sent by Atlassian Jira (v8.3.4#803005)
