[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16642648#comment-16642648
]
Gilles commented on RNG-57:
---
bq. Apologies in advance for the long post.
A very interesting analysis (and a useful appendix to the user guide perhaps).
Here on JIRA, it's not easy to follow the discussion (e.g. wide tables are not
displayed in their entirety).
Codes (that would produce the above tables) could go in the
{{commons-rng-examples}} module.
bq. An alternative approach would be to reduce the number of tests per RNG.
These could be limited to nextBytes and either nextInt or nextLong depending on
the type of provider.
Did I understand correctly that you propose to
# test the randomness uniformity of each of the implementations of
{{IntProvider}} (resp. {{LongProvider}}) through exercising {{nextInt()}}
(resp. {{nextLong()}}) only, and
# test the rest of the methods defined in {{UniformRandomProvider}} using
{{SecureRandom}} as the source?
bq. It is not very convenient for local development though as builds will fail
a fair amount.
JUnit is set to rerun failing tests (once in the current config); it seems to
work fine for module {{commons-rng-sampling}}, where the distribution tests do
indeed use random seeds.
> CachedUniformRandomProvider for nextBoolean() and nextInt()
> ---
>
> Key: RNG-57
> URL: https://issues.apache.org/jira/browse/RNG-57
> Project: Commons RNG
> Issue Type: Improvement
> Components: sampling
>Affects Versions: 1.2
>Reporter: Alex D Herbert
>Priority: Minor
> Labels: performance
>
> Implement a wrapper around a {{UniformRandomProvider}} that can cache the
> underlying source of random bytes for use in the methods {{nextBoolean()}}
> and {{nextInt()}} (in the case of {{LongProvider}}). E.g.
> {code:java}
> LongProvider provider = RandomSource.create(RandomSource.SPLIT_MIX_64);
> CachedLongProvider rng = new CachedLongProvider(provider);
> // Uses cached nextLong() 64 times
> rng.nextBoolean();
> // Uses cached nextLong() twice
> rng.nextInt();
> IntProvider provider = RandomSource.create(RandomSource.KISS);
> CachedIntProvider rng2 = new CachedIntProvider(provider);
> // Uses cached nextInt() 32 times
> rng2.nextBoolean();
> // This could be wrapped by a factory method:
> UniformRandomProvider rng = CachedUniformRandomProviderFactory.wrap(
> // Any supported source: IntProvider or LongProvider
> RandomSource.create(RandomSource...));
> {code}
> The implementation should be speed tested to determine the benefit for
> {{nextBoolean()}} and if {{nextInt()}} can be improved for {{LongProviders}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (BEANUTILS-514) Remove deprecated code for 2.0.0
[
https://issues.apache.org/jira/browse/BEANUTILS-514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated BEANUTILS-514:
---
Description: Remove all code marked with {{@deprecated}} and
{{@Deprecated}}.
> Remove deprecated code for 2.0.0
>
>
> Key: BEANUTILS-514
> URL: https://issues.apache.org/jira/browse/BEANUTILS-514
> Project: Commons BeanUtils
> Issue Type: New Feature
>Reporter: Gary Gregory
>Priority: Major
> Fix For: 2.0.0
>
>
> Remove all code marked with {{@deprecated}} and {{@Deprecated}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] commons-lang issue #371: Update tuple tests to JUnit Jupiter
Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/371 Thanks! ð ---
[GitHub] commons-lang pull request #371: Update tuple tests to JUnit Jupiter
Github user asfgit closed the pull request at: https://github.com/apache/commons-lang/pull/371 ---
[GitHub] commons-lang issue #371: Update tuple tests to JUnit Jupiter
Github user coveralls commented on the issue: https://github.com/apache/commons-lang/pull/371 [](https://coveralls.io/builds/19410680) Coverage decreased (-0.007%) to 95.246% when pulling **f110da945a8af0914f348cfe576b5a8257159fd9 on mureinik:junit-jupiter-tuple** into **182e335432fe4634d770c5861be40dacf1816f0c on apache:master**. ---
[GitHub] commons-lang pull request #371: Update tuple tests to JUnit Jupiter
GitHub user mureinik opened a pull request: https://github.com/apache/commons-lang/pull/371 Update tuple tests to JUnit Jupiter Upgrade the tests in the text package to use JUnit Jupiter as part of the effort to remove the dependency on the Vintage Engine. You can merge this pull request into a Git repository by running: $ git pull https://github.com/mureinik/commons-lang junit-jupiter-tuple Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-lang/pull/371.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #371 commit f110da945a8af0914f348cfe576b5a8257159fd9 Author: Allon Mureinik Date: 2018-10-02T03:41:37Z Update tuple tests to JUnit Jupiter Upgrade the tests in the text package to use JUnit Jupiter as part of the effort to remove the dependency on the Vintage Engine. ---
[GitHub] commons-lang pull request #370: Update text tests to JUnit Jupiter
Github user asfgit closed the pull request at: https://github.com/apache/commons-lang/pull/370 ---
[GitHub] commons-lang issue #370: Update text tests to JUnit Jupiter
Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/370 Thanks! ð ---
[jira] [Commented] (COLLECTIONS-667) CollectionUtils Concat Method
[
https://issues.apache.org/jira/browse/COLLECTIONS-667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16642236#comment-16642236
]
BELUGA BEHR commented on COLLECTIONS-667:
-
I have need for such a facility again, so I was reminded of this ticket.
{quote}
Maybe create a new Collection object that keeps a pointer to each internal
Collection
{quote}
Just throwing the idea out there: Instead of creating a large array and
copying everything into it, create a new structure that is an array (list) of
Collections. Obviously it would have to be an immutable Collection. The
collection's iterator would have to iterate over the first collection in the
list, and when that's done, iterate over the second collection, then the third,
and so on.
That is to say, maybe this should also be paired with an {{Iterable}} method
that is... Iterable.all(Collection 1, Collection 2, Collection 3, etc.);
> CollectionUtils Concat Method
> -
>
> Key: COLLECTIONS-667
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-667
> Project: Commons Collections
> Issue Type: New Feature
> Components: Collection
>Reporter: BELUGA BEHR
>Priority: Minor
>
> Add a _concat_ method which returns a Collection of all the Collections in
> the argument list
> {code}
> public Collection concat(Collection c...)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (BEANUTILS-514) Remove deprecated code for 2.0.0
[ https://issues.apache.org/jira/browse/BEANUTILS-514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated BEANUTILS-514: --- Summary: Remove deprecated code for 2.0.0 (was: Remove deprecated code for 2.0) > Remove deprecated code for 2.0.0 > > > Key: BEANUTILS-514 > URL: https://issues.apache.org/jira/browse/BEANUTILS-514 > Project: Commons BeanUtils > Issue Type: New Feature >Reporter: Gary Gregory >Priority: Major > Fix For: 2.0.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (BEANUTILS-514) Remove deprecated code for 2.0
Gary Gregory created BEANUTILS-514: -- Summary: Remove deprecated code for 2.0 Key: BEANUTILS-514 URL: https://issues.apache.org/jira/browse/BEANUTILS-514 Project: Commons BeanUtils Issue Type: New Feature Reporter: Gary Gregory Fix For: 2.0.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (BEANUTILS-513) Error when getting configuration
[
https://issues.apache.org/jira/browse/BEANUTILS-513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lemyagov updated BEANUTILS-513:
-
Environment: Java 8.
> Error when getting configuration
>
>
> Key: BEANUTILS-513
> URL: https://issues.apache.org/jira/browse/BEANUTILS-513
> Project: Commons BeanUtils
> Issue Type: Bug
> Components: Bean / Property Utils
>Affects Versions: 1.9.3
> Environment: Java 8.
>Reporter: Alexander Lemyagov
>Priority: Major
> Labels: config
>
> I use Apache Commans Configuration 2 and a read config file:
>
> {code:java}
> Parameters parameters = new Parameters();
> this.configFileBuilder =
> new
> FileBasedConfigurationBuilder(PropertiesConfiguration.class)
> .configure(parameters.fileBased().setListDelimiterHandler(new
> DefaultListDelimiterHandler(';'))
> .setFile(MUSICMALL_CONFIG_FILE).setThrowExceptionOnMissing(true));
> this.configuration = this.configFileBuilder.getConfiguration();{code}
> And when I call *getConfiguration* method I get exception:
> {code:java}
> 2018-10-08 20:13:18 [JavaFX Application Thread] DEBUG
> org.apache.commons.beanutils.FluentPropertyBeanIntrospector:149#introspect -
> Exception is: java.beans.IntrospectionException: bad write method arg count:
> public final void
> org.apache.commons.configuration2.AbstractConfiguration.setProperty(java.lang.String,java.lang.Object)
> at
> java.beans.PropertyDescriptor.findPropertyType(PropertyDescriptor.java:657)
> at java.beans.PropertyDescriptor.setWriteMethod(PropertyDescriptor.java:327)
> at java.beans.PropertyDescriptor.(PropertyDescriptor.java:139)
> at
> org.apache.commons.beanutils.FluentPropertyBeanIntrospector.createFluentPropertyDescritor(FluentPropertyBeanIntrospector.java:178)
> at
> org.apache.commons.beanutils.FluentPropertyBeanIntrospector.introspect(FluentPropertyBeanIntrospector.java:141)
> at
> org.apache.commons.beanutils.PropertyUtilsBean.fetchIntrospectionData(PropertyUtilsBean.java:2245)
> at
> org.apache.commons.beanutils.PropertyUtilsBean.getIntrospectionData(PropertyUtilsBean.java:2226)
> at
> org.apache.commons.beanutils.PropertyUtilsBean.getPropertyDescriptor(PropertyUtilsBean.java:954)
> at
> org.apache.commons.beanutils.PropertyUtilsBean.isWriteable(PropertyUtilsBean.java:1478)
> at
> org.apache.commons.configuration2.beanutils.BeanHelper.isPropertyWriteable(BeanHelper.java:521)
> at
> org.apache.commons.configuration2.beanutils.BeanHelper.initProperty(BeanHelper.java:357)
> at
> org.apache.commons.configuration2.beanutils.BeanHelper.initBeanProperties(BeanHelper.java:273)
> at
> org.apache.commons.configuration2.beanutils.BeanHelper.initBean(BeanHelper.java:192)
> at
> org.apache.commons.configuration2.beanutils.BeanHelper$BeanCreationContextImpl.initBean(BeanHelper.java:669)
> at
> org.apache.commons.configuration2.beanutils.DefaultBeanFactory.initBeanInstance(DefaultBeanFactory.java:162)
> at
> org.apache.commons.configuration2.beanutils.DefaultBeanFactory.createBean(DefaultBeanFactory.java:116)
> at
> org.apache.commons.configuration2.beanutils.BeanHelper.createBean(BeanHelper.java:459)
> at
> org.apache.commons.configuration2.beanutils.BeanHelper.createBean(BeanHelper.java:479)
> at
> org.apache.commons.configuration2.beanutils.BeanHelper.createBean(BeanHelper.java:492)
> at
> org.apache.commons.configuration2.builder.BasicConfigurationBuilder.createResultInstance(BasicConfigurationBuilder.java:447)
> at
> org.apache.commons.configuration2.builder.BasicConfigurationBuilder.createResult(BasicConfigurationBuilder.java:417)
> at
> org.apache.commons.configuration2.builder.BasicConfigurationBuilder.getConfiguration(BasicConfigurationBuilder.java:285){code}
> What wrong?
> Config example:
> {noformat}
> initialized = false
> ftp.host=site.com.ua
> ftp.port=22
> ftp.user=root
> ftp.password=root
> name=
> object.number=120
> sync.time=30,59{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (BEANUTILS-513) Error when getting configuration
Alexander Lemyagov created BEANUTILS-513:
Summary: Error when getting configuration
Key: BEANUTILS-513
URL: https://issues.apache.org/jira/browse/BEANUTILS-513
Project: Commons BeanUtils
Issue Type: Bug
Components: Bean / Property Utils
Affects Versions: 1.9.3
Reporter: Alexander Lemyagov
I use Apache Commans Configuration 2 and a read config file:
{code:java}
Parameters parameters = new Parameters();
this.configFileBuilder =
new
FileBasedConfigurationBuilder(PropertiesConfiguration.class)
.configure(parameters.fileBased().setListDelimiterHandler(new
DefaultListDelimiterHandler(';'))
.setFile(MUSICMALL_CONFIG_FILE).setThrowExceptionOnMissing(true));
this.configuration = this.configFileBuilder.getConfiguration();{code}
And when I call *getConfiguration* method I get exception:
{code:java}
2018-10-08 20:13:18 [JavaFX Application Thread] DEBUG
org.apache.commons.beanutils.FluentPropertyBeanIntrospector:149#introspect -
Exception is: java.beans.IntrospectionException: bad write method arg count:
public final void
org.apache.commons.configuration2.AbstractConfiguration.setProperty(java.lang.String,java.lang.Object)
at java.beans.PropertyDescriptor.findPropertyType(PropertyDescriptor.java:657)
at java.beans.PropertyDescriptor.setWriteMethod(PropertyDescriptor.java:327)
at java.beans.PropertyDescriptor.(PropertyDescriptor.java:139)
at
org.apache.commons.beanutils.FluentPropertyBeanIntrospector.createFluentPropertyDescritor(FluentPropertyBeanIntrospector.java:178)
at
org.apache.commons.beanutils.FluentPropertyBeanIntrospector.introspect(FluentPropertyBeanIntrospector.java:141)
at
org.apache.commons.beanutils.PropertyUtilsBean.fetchIntrospectionData(PropertyUtilsBean.java:2245)
at
org.apache.commons.beanutils.PropertyUtilsBean.getIntrospectionData(PropertyUtilsBean.java:2226)
at
org.apache.commons.beanutils.PropertyUtilsBean.getPropertyDescriptor(PropertyUtilsBean.java:954)
at
org.apache.commons.beanutils.PropertyUtilsBean.isWriteable(PropertyUtilsBean.java:1478)
at
org.apache.commons.configuration2.beanutils.BeanHelper.isPropertyWriteable(BeanHelper.java:521)
at
org.apache.commons.configuration2.beanutils.BeanHelper.initProperty(BeanHelper.java:357)
at
org.apache.commons.configuration2.beanutils.BeanHelper.initBeanProperties(BeanHelper.java:273)
at
org.apache.commons.configuration2.beanutils.BeanHelper.initBean(BeanHelper.java:192)
at
org.apache.commons.configuration2.beanutils.BeanHelper$BeanCreationContextImpl.initBean(BeanHelper.java:669)
at
org.apache.commons.configuration2.beanutils.DefaultBeanFactory.initBeanInstance(DefaultBeanFactory.java:162)
at
org.apache.commons.configuration2.beanutils.DefaultBeanFactory.createBean(DefaultBeanFactory.java:116)
at
org.apache.commons.configuration2.beanutils.BeanHelper.createBean(BeanHelper.java:459)
at
org.apache.commons.configuration2.beanutils.BeanHelper.createBean(BeanHelper.java:479)
at
org.apache.commons.configuration2.beanutils.BeanHelper.createBean(BeanHelper.java:492)
at
org.apache.commons.configuration2.builder.BasicConfigurationBuilder.createResultInstance(BasicConfigurationBuilder.java:447)
at
org.apache.commons.configuration2.builder.BasicConfigurationBuilder.createResult(BasicConfigurationBuilder.java:417)
at
org.apache.commons.configuration2.builder.BasicConfigurationBuilder.getConfiguration(BasicConfigurationBuilder.java:285){code}
What wrong?
Config example:
{noformat}
initialized = false
ftp.host=site.com.ua
ftp.port=22
ftp.user=root
ftp.password=root
name=
object.number=120
sync.time=30,59{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] commons-lang issue #370: Update text tests to JUnit Jupiter
Github user coveralls commented on the issue: https://github.com/apache/commons-lang/pull/370 [](https://coveralls.io/builds/19407353) Coverage remained the same at 95.253% when pulling **182e335432fe4634d770c5861be40dacf1816f0c on mureinik:junit-jupiter-text** into **cbc8e0b2952164f97779c9a5fadca6acd2600ae2 on apache:master**. ---
[jira] [Commented] (BEANUTILS-509) WeakHashmap enters into infinite loop in WrapDynaClass.java
[
https://issues.apache.org/jira/browse/BEANUTILS-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16642146#comment-16642146
]
Gary Gregory commented on BEANUTILS-509:
Stepping back, would we want instead a {{WrapDynaClass}} AND a
{{ConcurrentWrapDynaClass}}? I imagine some folks would not want to pay the
extra cost of using a synchronized map all the time... ?
> WeakHashmap enters into infinite loop in WrapDynaClass.java
> ---
>
> Key: BEANUTILS-509
> URL: https://issues.apache.org/jira/browse/BEANUTILS-509
> Project: Commons BeanUtils
> Issue Type: Bug
> Components: DynaBean
>Affects Versions: 1.8.2
>Reporter: sunil
>Priority: Major
> Attachments: WrapDynaCache.patch,
> WrapDynaCache_after_svn_commit.patch, console.log.backup
>
>
> We noticed that our application was using too much of CPU , all the 6 cores
> were used.
> On capturing the thread dump we saw that large number of threads were in the
> running state and in :
> at java.util.WeakHashMap.get(WeakHashMap.java:403)
> at
> org.apache.commons.beanutils.WrapDynaClass.createDynaClass(WrapDynaClass.java:425)
>
> So we are suspecting that the thread has entered into indefinite while loop
> and hogging all the CPU resources.
> I have attached the thread dump for reference.
>
> what is the solution for this issue?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (BEANUTILS-509) WeakHashmap enters into infinite loop in WrapDynaClass.java
[ https://issues.apache.org/jira/browse/BEANUTILS-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16642133#comment-16642133 ] Gary Gregory commented on BEANUTILS-509: Obviously not a trivial undertaking since the JRE's WeakHashMap and ConcurrentHashMap are thousands of lines of code... > WeakHashmap enters into infinite loop in WrapDynaClass.java > --- > > Key: BEANUTILS-509 > URL: https://issues.apache.org/jira/browse/BEANUTILS-509 > Project: Commons BeanUtils > Issue Type: Bug > Components: DynaBean >Affects Versions: 1.8.2 >Reporter: sunil >Priority: Major > Attachments: WrapDynaCache.patch, > WrapDynaCache_after_svn_commit.patch, console.log.backup > > > We noticed that our application was using too much of CPU , all the 6 cores > were used. > On capturing the thread dump we saw that large number of threads were in the > running state and in : > at java.util.WeakHashMap.get(WeakHashMap.java:403) > at > org.apache.commons.beanutils.WrapDynaClass.createDynaClass(WrapDynaClass.java:425) > > So we are suspecting that the thread has entered into indefinite while loop > and hogging all the CPU resources. > I have attached the thread dump for reference. > > what is the solution for this issue? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] commons-lang pull request #370: Update text tests to JUnit Jupiter
GitHub user mureinik opened a pull request: https://github.com/apache/commons-lang/pull/370 Update text tests to JUnit Jupiter Upgrade the tests in the `text` package to use JUnit Jupiter as part of the effort to remove the dependency on the Vintage Engine. While most of these changes are drop-in replacements with no functional benefit, there are some non-obvious changes worth mentioning. Unlike `org.junit.Test`, `org.junit.jupiter.api.Test` does not have an `expected` argument. Instead, an explicit call to `org.junit.jupiter.api.Assertions.assertThrows` is used. It's also worth noting this is a minimal patch for migrating the package's tests to Jupiter. There are several tests that can be made more elegant with Jupiter's new features, but that work is left for subsequent patches. You can merge this pull request into a Git repository by running: $ git pull https://github.com/mureinik/commons-lang junit-jupiter-text Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-lang/pull/370.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #370 commit 182e335432fe4634d770c5861be40dacf1816f0c Author: Allon Mureinik Date: 2018-10-02T03:41:37Z Update text tests to JUnit Jupiter Upgrade the tests in the text package to use JUnit Jupiter as part of the effort to remove the dependency on the Vintage Engine. While most of these changes are drop-in replacements with no functional benefit, there are some non-obvious changes worth mentioning. Unlike org.junit.Test, org.junit.jupiter.api.Test does not have an "expected" argument. Instead, an explicit call to org.junit.jupiter.api.Assertions.assertThrows is used. It's also worth noting this is a minimal patch for migrating the package's tests to Jupiter. There are several tests that can be made more elegant with Jupiter's new features, but that work is left for subsequent patches. ---
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16641910#comment-16641910
]
Alex D Herbert commented on RNG-57:
---
Apologies in advance for the long post. This stems from the desire to
understand why my simple changes for RNG-57 have broken the test suite for
commons-rng-core.
I ran the {{ProvidersCommonParametricTest}} test 1000 times with a random seed
generated by SecureRandom as a 1024 byte array. Code snippet to do this is
posted in [#comment-16640722].
The raw data were large (>40MB) so I extracted the number of failures for each
test and have uploaded this to my current PC. Unfortunately I produced the raw
data incorrectly as the test stops at the first failure and later tests will be
missing repeats. So for example this test for nextInteger has incomplete data
because early tests fail:
{code:java}
@Test
public void testUniformNextIntegerInRange() {
checkNextIntegerInRange(4, 1000);
checkNextIntegerInRange(10, 1000);
checkNextIntegerInRange(12, 1000);
// If this fails ...
checkNextIntegerInRange(31, 1000);
// Data for the remaining will be missing !!!
checkNextIntegerInRange(32, 1000);
checkNextIntegerInRange(2016128993, 1000);
checkNextIntegerInRange(1834691456, 1000);
checkNextIntegerInRange(869657561, 1000);
checkNextIntegerInRange(1570504788, 1000);
}
{code}
However the number of tests is always above 900 and so I did a Chi squared test
to determine if the number of failures fits a Binomial distribution. Here are
some demo results for the MWC_256 method.
The table shows the method under test, the mean number of failures, the p-value
from a chi squared test matching the histogram of failures to a Binomial and
then a cumulative histogram of the number of failures. The final column value
is the number of tests (sometimes less than 1000).
|Method|Mean fails|p(Binomial(n,p=0.01)|Cumul Fails
(X<=x\|x=0)|1|2|3|4|5|6|7|8|9|10|11|12|13|14|15|
|nextInteger(1834691456)|5.027|0.999|6|49|130|256|406|565|710|812|892|923|937|947|950|950|951|
|
|nextLong(6917529027641081853)|4.904|1|9|41|127|252|418|580|719|828|867|898|920|926|928|
| | |
|nextDouble()|4.928|0.989|8|42|131|265|446|633|772|876|940|973|989|998|999|1000|
| |
|nextInteger(32)|4.889|0.997|6|38|130|268|451|619|761|848|909|941|958|964|967|969|
| |
|nextInteger(10)|4.914|0.991|9|36|121|270|460|636|776|872|940|976|994|997|999|1000|
| |
|nextInteger(1570504788)|4.902|1|4|38|118|256|429|594|725|809|867|899|918|921|923|925|925|926|
|nextInteger(2016128993)|4.98|1|6|39|110|230|428|585|749|839|900|935|951|954|957|958|
| |
|nextInteger(31)|4.969|0.996|9|40|132|265|450|606|753|839|901|952|969|975|979|980|
| |
|nextLong(31)|4.99|0.999|7|32|106|253|429|601|747|845|911|947|964|968|969|970|971|
|
|nextLong(4611686018427387902)|4.989|1|7|44|122|254|404|572|721|819|876|912|928|940|940|940|941|
|
|nextLong(32)|5.053|1|7|36|113|240|408|585|728|845|897|929|949|961|963|964| | |
|nextInteger(12)|5.016|0.994|6|44|129|261|436|610|752|856|925|961|980|985|992|993|994|
|
|nextFloat()|4.953|0.991|8|42|129|261|428|625|777|878|949|974|984|994|998|1000|
| |
|nextLong(11)|4.922|0.991|7|36|135|272|440|631|776|890|940|973|986|995|997|1000|
| |
|nextLong(2305843009213693951)|5.046|1|1|33|109|241|401|582|704|826|894|924|941|945|947|949|
| |
|nextInteger(4)|0|0|1000| | | | | | | | | | | | | | | |
|nextLong(4)|0|0|1000| | | | | | | | | | | | | | | |
|nextLong(19)|4.977|0.997|5|37|130|271|448|620|744|855|915|948|971|983|984|986|
| |
|nextInteger(869657561)|4.918|1|5|33|98|252|409|599|749|831|886|915|926|934|936|937|
| |
Here are some conclusions:
- Repeating the Chi squared test for uniformity 500 times with a critical
p-value of 0.01 produces counts that can be modelled as a binomial distribution.
- The mean is 5 (n*p = 500*0.01).
- The test for nextInteger/Long(4) always passes. The test is performed using
10 bins and there only 4 discrete values. Basically the test is invalid and the
Chi square test should be done using 3 degrees of freedom.
- The test fail threshold of 10 allowed failures corresponds to a cumulative
probability of 0.9868 (see [#comment-16640891]). This means it will fail 1.32%
of the time.
Note that currently there are 19 tests using this approach. We can discount 2
(nextInteger(4) and nextLong(4)) leaving 17. There are also 3 random walk tests
with a 1% critical value on the range allowed and 2 tests for uniform next
bytes using a single chi squared p-value of 1%.
So for a single RNG the probability that no tests will fail is:
{noformat}
(1 - 0.0132)^17 * (1 - 0.01)^3 * (1 - 0.01)^2 = 0.7587
{noformat}
The test is performed on 16 variants of the RNG. So the probability no tests
will fail is:
{noformat}
0.7587^16 = 0.0121
{noformat}
This seems very low. I don't have data for the random walk and nextBytes
[jira] [Resolved] (SCXML-283) Upgrade testing framework to JUnit Jupiter
[ https://issues.apache.org/jira/browse/SCXML-283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Woonsan Ko resolved SCXML-283. -- Resolution: Fixed > Upgrade testing framework to JUnit Jupiter > -- > > Key: SCXML-283 > URL: https://issues.apache.org/jira/browse/SCXML-283 > Project: Commons SCXML > Issue Type: Task >Reporter: Allon Mureinik >Assignee: Woonsan Ko >Priority: Minor > Fix For: 2.0 > > > commons-scxml already requires Java 8, so there's nothing inhibiting the > upgrade to a modern JUnit version, and taking advantage of Jupiter's newer > features. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SCXML-283) Upgrade testing framework to JUnit Jupiter
[ https://issues.apache.org/jira/browse/SCXML-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16641870#comment-16641870 ] Woonsan Ko commented on SCXML-283: -- Merged. I was impressed on your correctness in such many changes and focus on migration itself. Thank you very much, [~mureinik], for your contribution! Cheers, Woonsan > Upgrade testing framework to JUnit Jupiter > -- > > Key: SCXML-283 > URL: https://issues.apache.org/jira/browse/SCXML-283 > Project: Commons SCXML > Issue Type: Task >Reporter: Allon Mureinik >Assignee: Woonsan Ko >Priority: Minor > Fix For: 2.0 > > > commons-scxml already requires Java 8, so there's nothing inhibiting the > upgrade to a modern JUnit version, and taking advantage of Jupiter's newer > features. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SCXML-283) Upgrade testing framework to JUnit Jupiter
[ https://issues.apache.org/jira/browse/SCXML-283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Woonsan Ko updated SCXML-283: - Fix Version/s: 2.0 > Upgrade testing framework to JUnit Jupiter > -- > > Key: SCXML-283 > URL: https://issues.apache.org/jira/browse/SCXML-283 > Project: Commons SCXML > Issue Type: Task >Reporter: Allon Mureinik >Assignee: Woonsan Ko >Priority: Minor > Fix For: 2.0 > > > commons-scxml already requires Java 8, so there's nothing inhibiting the > upgrade to a modern JUnit version, and taking advantage of Jupiter's newer > features. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SCXML-283) Upgrade testing framework to JUnit Jupiter
[ https://issues.apache.org/jira/browse/SCXML-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16641860#comment-16641860 ] ASF GitHub Bot commented on SCXML-283: -- Github user asfgit closed the pull request at: https://github.com/apache/commons-scxml/pull/3 > Upgrade testing framework to JUnit Jupiter > -- > > Key: SCXML-283 > URL: https://issues.apache.org/jira/browse/SCXML-283 > Project: Commons SCXML > Issue Type: Task >Reporter: Allon Mureinik >Assignee: Woonsan Ko >Priority: Minor > > commons-scxml already requires Java 8, so there's nothing inhibiting the > upgrade to a modern JUnit version, and taking advantage of Jupiter's newer > features. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] commons-scxml pull request #3: SCXML-283 Upgrade to JUnit Jupiter
Github user asfgit closed the pull request at: https://github.com/apache/commons-scxml/pull/3 ---
[jira] [Updated] (SCXML-283) Upgrade testing framework to JUnit Jupiter
[ https://issues.apache.org/jira/browse/SCXML-283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Woonsan Ko updated SCXML-283: - Assignee: Woonsan Ko > Upgrade testing framework to JUnit Jupiter > -- > > Key: SCXML-283 > URL: https://issues.apache.org/jira/browse/SCXML-283 > Project: Commons SCXML > Issue Type: Task >Reporter: Allon Mureinik >Assignee: Woonsan Ko >Priority: Minor > > commons-scxml already requires Java 8, so there's nothing inhibiting the > upgrade to a modern JUnit version, and taking advantage of Jupiter's newer > features. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16641739#comment-16641739
]
Gilles commented on RNG-57:
---
{quote}Because they are not all perfect.
{quote}
I was expecting the answer.
{quote}The DieHarder results show that.
{quote}
Indeed. And it is unlikely that the unit tests of "Commons RNG" can do better
than the "Big Crush" test suite. Thus I don't think that we should evaluate the
quality of the underlying source: the unit test should identify a bug in the
Java implementation, not a flawed RNG algorithm.
If the issue here is not a seed problem, we can make the build more robust by
setting the JUnit config to repeat "flaky" tests. If some RNG sources fail
more often than others, it is already a piece of information, while being more
tolerant for bad generators is not a good idea IMO.
> CachedUniformRandomProvider for nextBoolean() and nextInt()
> ---
>
> Key: RNG-57
> URL: https://issues.apache.org/jira/browse/RNG-57
> Project: Commons RNG
> Issue Type: Improvement
> Components: sampling
>Affects Versions: 1.2
>Reporter: Alex D Herbert
>Priority: Minor
> Labels: performance
>
> Implement a wrapper around a {{UniformRandomProvider}} that can cache the
> underlying source of random bytes for use in the methods {{nextBoolean()}}
> and {{nextInt()}} (in the case of {{LongProvider}}). E.g.
> {code:java}
> LongProvider provider = RandomSource.create(RandomSource.SPLIT_MIX_64);
> CachedLongProvider rng = new CachedLongProvider(provider);
> // Uses cached nextLong() 64 times
> rng.nextBoolean();
> // Uses cached nextLong() twice
> rng.nextInt();
> IntProvider provider = RandomSource.create(RandomSource.KISS);
> CachedIntProvider rng2 = new CachedIntProvider(provider);
> // Uses cached nextInt() 32 times
> rng2.nextBoolean();
> // This could be wrapped by a factory method:
> UniformRandomProvider rng = CachedUniformRandomProviderFactory.wrap(
> // Any supported source: IntProvider or LongProvider
> RandomSource.create(RandomSource...));
> {code}
> The implementation should be speed tested to determine the benefit for
> {{nextBoolean()}} and if {{nextInt()}} can be improved for {{LongProviders}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (BEANUTILS-509) WeakHashmap enters into infinite loop in WrapDynaClass.java
[ https://issues.apache.org/jira/browse/BEANUTILS-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16641676#comment-16641676 ] Akshay Gehi commented on BEANUTILS-509: --- I believe that ConcurrentWeakHashMap would be great! We could increase the timeout of the test to 10 minutes because different users could have different hardware. > WeakHashmap enters into infinite loop in WrapDynaClass.java > --- > > Key: BEANUTILS-509 > URL: https://issues.apache.org/jira/browse/BEANUTILS-509 > Project: Commons BeanUtils > Issue Type: Bug > Components: DynaBean >Affects Versions: 1.8.2 >Reporter: sunil >Priority: Major > Attachments: WrapDynaCache.patch, > WrapDynaCache_after_svn_commit.patch, console.log.backup > > > We noticed that our application was using too much of CPU , all the 6 cores > were used. > On capturing the thread dump we saw that large number of threads were in the > running state and in : > at java.util.WeakHashMap.get(WeakHashMap.java:403) > at > org.apache.commons.beanutils.WrapDynaClass.createDynaClass(WrapDynaClass.java:425) > > So we are suspecting that the thread has entered into indefinite while loop > and hogging all the CPU resources. > I have attached the thread dump for reference. > > what is the solution for this issue? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16641616#comment-16641616
]
Alex D Herbert commented on RNG-57:
---
bq. Why should the number of expected failures be different for each algorithm?
Because they are not all perfect. The DieHarder results show that.
The null hypothesis is that the RNG is perfect and the binomial distribution
can be used to determine how many failures to expect for the repeated Chi
square test.
> CachedUniformRandomProvider for nextBoolean() and nextInt()
> ---
>
> Key: RNG-57
> URL: https://issues.apache.org/jira/browse/RNG-57
> Project: Commons RNG
> Issue Type: Improvement
> Components: sampling
>Affects Versions: 1.2
>Reporter: Alex D Herbert
>Priority: Minor
> Labels: performance
>
> Implement a wrapper around a {{UniformRandomProvider}} that can cache the
> underlying source of random bytes for use in the methods {{nextBoolean()}}
> and {{nextInt()}} (in the case of {{LongProvider}}). E.g.
> {code:java}
> LongProvider provider = RandomSource.create(RandomSource.SPLIT_MIX_64);
> CachedLongProvider rng = new CachedLongProvider(provider);
> // Uses cached nextLong() 64 times
> rng.nextBoolean();
> // Uses cached nextLong() twice
> rng.nextInt();
> IntProvider provider = RandomSource.create(RandomSource.KISS);
> CachedIntProvider rng2 = new CachedIntProvider(provider);
> // Uses cached nextInt() 32 times
> rng2.nextBoolean();
> // This could be wrapped by a factory method:
> UniformRandomProvider rng = CachedUniformRandomProviderFactory.wrap(
> // Any supported source: IntProvider or LongProvider
> RandomSource.create(RandomSource...));
> {code}
> The implementation should be speed tested to determine the benefit for
> {{nextBoolean()}} and if {{nextInt()}} can be improved for {{LongProviders}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (RNG-59) More robust "SeedFactory"
[
https://issues.apache.org/jira/browse/RNG-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles updated RNG-59:
--
Description:
{{SeedFactory}} will produce the same seed when several instances of the same
program are launched in rapid successions.
In the _static_ block of {{SeedFactory}}, an initial "random" seed is generated
using {{System.currentTimeMillis()}}.
I think that it should be replaced by retrieving data from a {{SecureRandom}}
instance.
The drawback is that instantiating such an object is necessary slower. However
if it is the way to go (to ensure different initial seeds in parallel runs of a
program), the question is whether to use only {{SecureRandom}} to create the
(relatively large) state of the RNG used by the {{SeedFactory}} or to use it
only to generate 8 bytes (and proceed with the rest of the _static_ block as it
is now).
I'm planning to follow the advice
[here|https://tersesystems.com/blog/2015/12/17/the-right-way-to-use-securerandom/],
i.e. fill the whole state with the system's default RNG.
was:
{{SeedFactory}} will produce the same seed when several instances of the same
program are launched in rapid successions.
In the {{static}} block of {{SeedFactory}}, an initial "random" seed is
generated using {{System.currentTimeMillis()}}.
I think that it should be replaced by retrieving data from a {{SecureRandom}}
instance.
The drawback is that instantiating such an object is necessary slower. However
if it is the way to go (to ensure different initial seeds in parallel runs of a
program), the question is whether to use only {{SecureRandom}} to create the
(relatively large) state of the RNG used by the {{SeedFactory}} or to use it
only to generate 8 bytes (and proceed with the rest of the _static_ block as it
is now).
> More robust "SeedFactory"
> -
>
> Key: RNG-59
> URL: https://issues.apache.org/jira/browse/RNG-59
> Project: Commons RNG
> Issue Type: Improvement
> Components: simple
>Affects Versions: 1.0, 1.1
>Reporter: Gilles
>Priority: Major
> Fix For: 1.2
>
>
> {{SeedFactory}} will produce the same seed when several instances of the same
> program are launched in rapid successions.
> In the _static_ block of {{SeedFactory}}, an initial "random" seed is
> generated using {{System.currentTimeMillis()}}.
> I think that it should be replaced by retrieving data from a {{SecureRandom}}
> instance.
> The drawback is that instantiating such an object is necessary slower.
> However if it is the way to go (to ensure different initial seeds in parallel
> runs of a program), the question is whether to use only {{SecureRandom}} to
> create the (relatively large) state of the RNG used by the {{SeedFactory}} or
> to use it only to generate 8 bytes (and proceed with the rest of the _static_
> block as it is now).
> I'm planning to follow the advice
> [here|https://tersesystems.com/blog/2015/12/17/the-right-way-to-use-securerandom/],
> i.e. fill the whole state with the system's default RNG.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16641535#comment-16641535
]
Gilles commented on RNG-57:
---
bq. what the failure rate would be for each
Why should the number of expected failures be different for each algorithm?
> CachedUniformRandomProvider for nextBoolean() and nextInt()
> ---
>
> Key: RNG-57
> URL: https://issues.apache.org/jira/browse/RNG-57
> Project: Commons RNG
> Issue Type: Improvement
> Components: sampling
>Affects Versions: 1.2
>Reporter: Alex D Herbert
>Priority: Minor
> Labels: performance
>
> Implement a wrapper around a {{UniformRandomProvider}} that can cache the
> underlying source of random bytes for use in the methods {{nextBoolean()}}
> and {{nextInt()}} (in the case of {{LongProvider}}). E.g.
> {code:java}
> LongProvider provider = RandomSource.create(RandomSource.SPLIT_MIX_64);
> CachedLongProvider rng = new CachedLongProvider(provider);
> // Uses cached nextLong() 64 times
> rng.nextBoolean();
> // Uses cached nextLong() twice
> rng.nextInt();
> IntProvider provider = RandomSource.create(RandomSource.KISS);
> CachedIntProvider rng2 = new CachedIntProvider(provider);
> // Uses cached nextInt() 32 times
> rng2.nextBoolean();
> // This could be wrapped by a factory method:
> UniformRandomProvider rng = CachedUniformRandomProviderFactory.wrap(
> // Any supported source: IntProvider or LongProvider
> RandomSource.create(RandomSource...));
> {code}
> The implementation should be speed tested to determine the benefit for
> {{nextBoolean()}} and if {{nextInt()}} can be improved for {{LongProviders}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEOMETRY-14) AffineTransform?D Classes
[
https://issues.apache.org/jira/browse/GEOMETRY-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16641524#comment-16641524
]
Gilles commented on GEOMETRY-14:
About {{Point}} and {{Vector}}, the question is simply to have (programming)
use-cases for both.
{quote}the difference is mathematical
{quote}
I like when the design can be close to the mathematical concepts. But you
argued that having
{code:java}
public class Vector3D extends Cartesian3D implements
MultiDimensionalEuclideanVector
{code}
and
{code:java}
public final class Point3D extends Cartesian3D implements
EuclideanPoint
{code}
was going to be more effective from a usage POV even though the class hierarchy
does not agree with the mathematics (a point exists independently of the
coordinate system).
So my (design) question is of the same order: If programming is allowed to be
a step away from mathematics, maybe (?) that a "point" class is not strictly
necessary (here).
As a basic user of a very small fraction of that code, I don't know (yet).
That's why I'm suggesting that, if possible, some real-use cases should be
presented for the concepts (a.o. _both_ "point" and "vector") that are
represented in the API.
If now is not a good time, then I can wait; but this is "for the record" of
trying to avoid issues as they seem to appear (at least to me). ;)
About affine transforms: I'm convinced that {{java.util.function}} is not going
to help then.
However, do you see a real use-case where the composition of transforms would
need more than this method:
{code:java}
public AffineTransform3D combine(AffineTransform3D transform) { /* ... */ }
public static AffineTransform3D combine(AffineTransform3D ... transforms) { /*
... */ }
{code}
together with the varargs static method shown above (as syntactic sugar)?
Note: I couldn't figure out the 3-arguments {{multiply}} method (in the PR).
Can the API of {{AffineTransform3D}} be discussed without including rotations?
Shall we just have
{code:java}
public Rotation extends AffineTransform3D { /* ... */ }
{code}
?
> AffineTransform?D Classes
> -
>
> Key: GEOMETRY-14
> URL: https://issues.apache.org/jira/browse/GEOMETRY-14
> Project: Apache Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Labels: pull-request-available
>
> We should create AffineTransform?D classes that implement matrix-based affine
> transforms. They should have simple methods for creating translations,
> rotations, and scaling and calculating the inverse.
>
> Pull Request #1: https://github.com/apache/commons-geometry/pull/14
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COMPRESS-466) Opening of a very large zip file is extremely slow compared to java.util.zip.ZipFile
[
https://issues.apache.org/jira/browse/COMPRESS-466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16641482#comment-16641482
]
Jakob Sultan Ericsson commented on COMPRESS-466:
One thing though? Why does {{getRawInputStream()}} return null in this case?
Isn't basically same as {{getInputStream()}}
On thing that might not be totally related to this, why is
{{ZipArchiveEntry.getLocalHeaderOffset()}} protected?
We might have problems with taking the X seconds (18 in my test) penalty for
opening the file and reading it every time. If {{getLocalHeaderOffset}} is
public I can basically find out where the data starts and decompress it myself.
> Opening of a very large zip file is extremely slow compared to
> java.util.zip.ZipFile
>
>
> Key: COMPRESS-466
> URL: https://issues.apache.org/jira/browse/COMPRESS-466
> Project: Commons Compress
> Issue Type: Improvement
> Components: Compressors
>Affects Versions: 1.18
> Environment: Tested both on Linux and OSX 10.13.6.
>Reporter: Jakob Sultan Ericsson
>Priority: Major
> Fix For: 1.19
>
>
> We have a quite large zip file 35 gb and try to open this with ZipFile.
> {code:java}
> try (ZipFile zf = new ZipFile(new File("35gb.zip"))) {
> System.out.println("File opened..." + (System.currentTimeMillis()
> - start));
> }
> {code}
> This code takes about 300 000 - 400 000 ms (5-6 minutes).
> If I run this with JDK-builtin java.util.zip.ZipFile, same code takes 300 ms
> (less than a second).
> I'm not totally sure what it is the problem but I did some debugging and
> basically all time is spent in
> {code:java}
> private void resolveLocalFileHeaderData(final Map NameAndComment> entriesWithoutUTF8Flag)
> {code}
> Anything that can be done to improve this?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] commons-lang pull request #369: Update reflect tests to JUnit Jupiter
Github user asfgit closed the pull request at: https://github.com/apache/commons-lang/pull/369 ---
[GitHub] commons-lang issue #369: Update reflect tests to JUnit Jupiter
Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/369 Thanks! ð ---
[jira] [Updated] (COMPRESS-466) Opening of a very large zip file is extremely slow compared to java.util.zip.ZipFile
[
https://issues.apache.org/jira/browse/COMPRESS-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated COMPRESS-466:
Issue Type: Improvement (was: Bug)
> Opening of a very large zip file is extremely slow compared to
> java.util.zip.ZipFile
>
>
> Key: COMPRESS-466
> URL: https://issues.apache.org/jira/browse/COMPRESS-466
> Project: Commons Compress
> Issue Type: Improvement
> Components: Compressors
>Affects Versions: 1.18
> Environment: Tested both on Linux and OSX 10.13.6.
>Reporter: Jakob Sultan Ericsson
>Priority: Major
> Fix For: 1.19
>
>
> We have a quite large zip file 35 gb and try to open this with ZipFile.
> {code:java}
> try (ZipFile zf = new ZipFile(new File("35gb.zip"))) {
> System.out.println("File opened..." + (System.currentTimeMillis()
> - start));
> }
> {code}
> This code takes about 300 000 - 400 000 ms (5-6 minutes).
> If I run this with JDK-builtin java.util.zip.ZipFile, same code takes 300 ms
> (less than a second).
> I'm not totally sure what it is the problem but I did some debugging and
> basically all time is spent in
> {code:java}
> private void resolveLocalFileHeaderData(final Map NameAndComment> entriesWithoutUTF8Flag)
> {code}
> Anything that can be done to improve this?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (COMPRESS-466) Opening of a very large zip file is extremely slow compared to java.util.zip.ZipFile
[
https://issues.apache.org/jira/browse/COMPRESS-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig resolved COMPRESS-466.
-
Resolution: Fixed
Fix Version/s: 1.19
Thank you for testing.
It's easier to be "bold" when you are familiar with the code :)
> Opening of a very large zip file is extremely slow compared to
> java.util.zip.ZipFile
>
>
> Key: COMPRESS-466
> URL: https://issues.apache.org/jira/browse/COMPRESS-466
> Project: Commons Compress
> Issue Type: Bug
> Components: Compressors
>Affects Versions: 1.18
> Environment: Tested both on Linux and OSX 10.13.6.
>Reporter: Jakob Sultan Ericsson
>Priority: Major
> Fix For: 1.19
>
>
> We have a quite large zip file 35 gb and try to open this with ZipFile.
> {code:java}
> try (ZipFile zf = new ZipFile(new File("35gb.zip"))) {
> System.out.println("File opened..." + (System.currentTimeMillis()
> - start));
> }
> {code}
> This code takes about 300 000 - 400 000 ms (5-6 minutes).
> If I run this with JDK-builtin java.util.zip.ZipFile, same code takes 300 ms
> (less than a second).
> I'm not totally sure what it is the problem but I did some debugging and
> basically all time is spent in
> {code:java}
> private void resolveLocalFileHeaderData(final Map NameAndComment> entriesWithoutUTF8Flag)
> {code}
> Anything that can be done to improve this?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
