[jira] [Commented] (RNG-36) Variation of the Box-Muller algorithm

[Gilles (JIRA)]

[ 
https://issues.apache.org/jira/browse/RNG-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15840632#comment-15840632
 ] 

Gilles commented on RNG-36:
---

Please review commit c14e09caa4161dc7cdbaa9fae3dbbd3cf02b70e3 (in branch 
"feature__RNG-35").

> Variation of the Box-Muller algorithm
> -
>
> Key: RNG-36
> URL: https://issues.apache.org/jira/browse/RNG-36
> Project: Commons RNG
>  Issue Type: New Feature
>Reporter: Gilles
>Assignee: Gilles
>Priority: Minor
>  Labels: performance
> Fix For: 1.1
>
>
> Alternative implementation that will include the performance improvements 
> suggested in [this presentation|http://haifux.org/lectures/79/random.pdf].



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (RNG-36) Variation of the Box-Muller algorithm

[Gilles (JIRA)]

Gilles created RNG-36:
-

 Summary: Variation of the Box-Muller algorithm
 Key: RNG-36
 URL: https://issues.apache.org/jira/browse/RNG-36
 Project: Commons RNG
  Issue Type: New Feature
Reporter: Gilles
Assignee: Gilles
Priority: Minor
 Fix For: 1.1


Alternative implementation that will include the performance improvements 
suggested in [this presentation|http://haifux.org/lectures/79/random.pdf].




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JCS-171) Multiple CacheEventQueue.QProcessor spawned for the same cache region

[Thomas Vandahl (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCS-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15840362#comment-15840362
 ] 

Thomas Vandahl commented on JCS-171:


AbortPolicy is the default RejectionHandler for a ThreadPoolExecutor. I will 
change it to CallerRunsPolicy, so these rejections should no longer be visible. 
(They still occur, however)

Speaking of which, I let the thread pool count the number of rejections in 
pooled mode and it was between 2.8 and 2.3 million for the test code running 50 
million puts. This did not change much for a queue size between 2 and 200. 
The smallest number of rejections I got with a queue size of 500. I'll probably 
need to stop trying to understand this behavior...


> Multiple CacheEventQueue.QProcessor spawned for the same cache region
> -
>
> Key: JCS-171
> URL: https://issues.apache.org/jira/browse/JCS-171
> Project: Commons JCS
>  Issue Type: Bug
>  Components: Composite Cache
>Affects Versions: jcs-2.0
>Reporter: Wiktor N
>Assignee: Thomas Vandahl
> Fix For: jcs-2.1
>
> Attachments: CacheEventQueue.patch, jcs-perf-test.zip
>
>
> I noticed that running on new version of JCS I get multiple 
> CacheEventQueue.QProcessor thread. They spawn from time to time.
> I've checked recent changes and changes few things in r1774925 look 
> suspicious:
> 1. In previous code we spawned a new thread in synchronized section. This got 
> us a guarantee, that there will be no two threads trying to spawn a new 
> thread in the same time. Maybe some locking is needed around thread creation?
> 2. QProcessor uses isAlive() method. But this is defined by Thread.isAlive() 
> while it should probably check for CacheEventQueue.this.isAlive()



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (JCS-172) MaxLife element attribute causing cache region to stop responding

[Thomas Vandahl (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCS-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Vandahl resolved JCS-172.

   Resolution: Fixed
Fix Version/s: jcs-2.1

Fixed in SVN

> MaxLife element attribute causing cache region to stop responding
> -
>
> Key: JCS-172
> URL: https://issues.apache.org/jira/browse/JCS-172
> Project: Commons JCS
>  Issue Type: Bug
>Affects Versions: jcs-2.0-beta-2, jcs-2.0
>Reporter: Tom Schroeder
>Assignee: Thomas Vandahl
> Fix For: jcs-2.1
>
> Attachments: cache.ccf
>
>
> We are using a cache region to stage some content, and have been using the 
> MaxLife attribute to expire content after a certain amount of time.  This 
> seemed to work when using the jcs-2.0-beta-1 version.  However, after 
> upgrading our project to either the jcs-2.0-beta-2 or the jcs-2.0 versions, 
> our staging cache seems to stop retaining content after the system has been 
> up for the MaxLife time.  After that is seems that any content placed in our 
> stagedContent region is immediately expired.  Placing an item in the cache 
> with a CacheAccess.put() and then immediately trying to retrieve it with a 
> CacheAccess.get() returns null.  I have attached a copy of our cache 
> configuration file for reference.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JCS-172) MaxLife element attribute causing cache region to stop responding

[Thomas Vandahl (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCS-172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15840341#comment-15840341
 ] 

Thomas Vandahl commented on JCS-172:


As you can configure the implementation to use for ElementAttributes, you may 
roll your own as a workaround. Like so:
{code:title=MyElementAttributes.java|borderStyle=solid}
/**
 * @see java.lang.Object#clone()
 */
@Override
public IElementAttributes clone()
{
ElementAttributes c = (ElementAttributes) super.clone();
c.setCreateTime();
return c;
}
{code}

> MaxLife element attribute causing cache region to stop responding
> -
>
> Key: JCS-172
> URL: https://issues.apache.org/jira/browse/JCS-172
> Project: Commons JCS
>  Issue Type: Bug
>Affects Versions: jcs-2.0-beta-2, jcs-2.0
>Reporter: Tom Schroeder
>Assignee: Thomas Vandahl
> Fix For: jcs-2.1
>
> Attachments: cache.ccf
>
>
> We are using a cache region to stage some content, and have been using the 
> MaxLife attribute to expire content after a certain amount of time.  This 
> seemed to work when using the jcs-2.0-beta-1 version.  However, after 
> upgrading our project to either the jcs-2.0-beta-2 or the jcs-2.0 versions, 
> our staging cache seems to stop retaining content after the system has been 
> up for the MaxLife time.  After that is seems that any content placed in our 
> stagedContent region is immediately expired.  Placing an item in the cache 
> with a CacheAccess.put() and then immediately trying to retrieve it with a 
> CacheAccess.get() returns null.  I have attached a copy of our cache 
> configuration file for reference.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JCS-172) MaxLife element attribute causing cache region to stop responding

[Tom Schroeder (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCS-172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15840213#comment-15840213
 ] 

Tom Schroeder commented on JCS-172:
---

In talking with Thomas Vandahl on the commons user list, I believe this issue 
is fixed in the latest trunk for commons-jcs-core-2.1-SNAPSHOT.  The relevant 
SVN commit info is:

Version: 1779938
Time: 1/23/17, 9:54AM
Commit Message: Fix creation time not updating during clone()

I built the latest jar from the trunk source and the problem we were seeing 
goes away.  Thanks a lot!

> MaxLife element attribute causing cache region to stop responding
> -
>
> Key: JCS-172
> URL: https://issues.apache.org/jira/browse/JCS-172
> Project: Commons JCS
>  Issue Type: Bug
>Affects Versions: jcs-2.0-beta-2, jcs-2.0
>Reporter: Tom Schroeder
> Attachments: cache.ccf
>
>
> We are using a cache region to stage some content, and have been using the 
> MaxLife attribute to expire content after a certain amount of time.  This 
> seemed to work when using the jcs-2.0-beta-1 version.  However, after 
> upgrading our project to either the jcs-2.0-beta-2 or the jcs-2.0 versions, 
> our staging cache seems to stop retaining content after the system has been 
> up for the MaxLife time.  After that is seems that any content placed in our 
> stagedContent region is immediately expired.  Placing an item in the cache 
> with a CacheAccess.put() and then immediately trying to retrieve it with a 
> CacheAccess.get() returns null.  I have attached a copy of our cache 
> configuration file for reference.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (NUMBERS-10) Revamp "Complex" representation ?

[Gilles (JIRA)]

[ 
https://issues.apache.org/jira/browse/NUMBERS-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15839753#comment-15839753
 ] 

Gilles edited comment on NUMBERS-10 at 1/26/17 6:00 PM:


The proposal intentionally avoids direct calls to a constructor ("builder" 
pattern).
As {{Complex}} is abstract, this statement
{code}
c = new Complex(1, 1); 
{code}
would not compile.
The user has to program against the interface ({{Complex}}), not the actual 
representation.
Moreover, a blatant shortcoming of the above constructor is that it ties the 
concept to a specific representation since you cannot overload it for polar 
(that also would require a constructor that takes two "double" arguments). An 
alternative is to use an {{enum}}, but this becomes uglier than the factory 
method.


was (Author: erans):
The proposal aims at avoiding direct calls to a constructor ("builder" pattern).
As {{Complex}} is abstract, this statement
{code}
c = new Complex(1, 1); 
{code}
is forbidden.
The user has to program against the interface ({{Complex}}), not the actual 
representation.
Moreover, as blatant shortcoming of the above constructor is that you get tied 
to a single representation since you cannot overload it for polar (that also 
would require a constructor that takes to "double" arguments. Or start to use 
an {{enum}} or the like, which becomes much longer to write than the factory 
method.

> Revamp "Complex" representation ?
> -
>
> Key: NUMBERS-10
> URL: https://issues.apache.org/jira/browse/NUMBERS-10
> Project: Commons Numbers
>  Issue Type: Wish
>Reporter: Gilles
>  Labels: API, design, review
> Fix For: 1.0
>
> Attachments: CartesianRepresentation.java, Complex.java, 
> MixedRepresentation.java, PolarRepresentation.java
>
>
> This is a proposal to enhance the internal representation of complex numbers.
> The purpose is to allow usage of both cartesian and polar representations, 
> with the aim that calculations are performed (transparently) with the one 
> that will be more accurate and/or faster. 
> The API would certainly be improved, from
> {code}
> final Complex c1 = Complex.valueOf(1, 2);
> final Complex c2 = ComplexUtils.polar2Complex(2, 7);
> final Complex r = c1.add(c2);
>  {code}
> with the current code, to
> {code}
> final Complex c1 = Complex.createCartesian(1, 2);
> final Complex c2 = Complex.createPolar(2, 7);
> final Complex r = c1.add(c2);
> {code}
> Please refer to the attached files (they are self-documenting, but of course, 
> Javadoc must be added if the proposal is validated).
> Would there be merit in pursuing in that direction?
> Or is there any show-stopper?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] commons-lang issue #229: Update RELEASE-NOTES.txt - typo "vom"

[PascalSchumacher]

Github user PascalSchumacher commented on the issue:

https://github.com/apache/commons-lang/pull/229
  
Thanks!


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] commons-lang pull request #229: Update RELEASE-NOTES.txt - typo "vom"

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/commons-lang/pull/229


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Resolved] (CONFIGURATION-650) Should throw Initialization error when no database table exists

[Alexander Scott (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Scott resolved CONFIGURATION-650.
---
Resolution: Not A Problem

> Should throw Initialization error when no database table exists
> ---
>
> Key: CONFIGURATION-650
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-650
> Project: Commons Configuration
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Alexander Scott
>
> I have created a unit test using the H2 database. If I try and simulate a new 
> configuration when no database table has been created, I would expect a 
> ConfigurationException to be thrown.
> But instead it seems to create the config fine.
> {code}
> @Test
> public void databaseNotPresent2() throws Exception {
> EmbeddedDatabase db = new EmbeddedDatabaseBuilder()
> .setType(EmbeddedDatabaseType.H2)
> .build();
> BasicConfigurationBuilder builder = new 
> BasicConfigurationBuilder(DatabaseConfiguration.class);
> Parameters params = new Parameters();
> builder.configure(
> params.database()
> .setDataSource(db)
> .setTable("BADTABLE")
> .setKeyColumn("BADKEY")
> .setValueColumn("BADVALUE")
> //.setThrowExceptionOnMissing(true)
> );
> DatabaseConfiguration missingTableConfig = builder.getConfiguration();
> String missing = missingTableConfig.getString("MISSING_KEY");
> assertEquals(null, missing);
> missingTableConfig.addProperty("PRESENT_KEY", "some value");
> String present = missingTableConfig.getString("PRESENT_KEY");
> assertEquals(null, present);
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CONFIGURATION-650) Should throw Initialization error when no database table exists

[Alexander Scott (JIRA)]

[ 
https://issues.apache.org/jira/browse/CONFIGURATION-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15840079#comment-15840079
 ] 

Alexander Scott commented on CONFIGURATION-650:
---

Looks like I need to add the following line to enable Exceptions;

{code}
ConfigurationUtils.enableRuntimeExceptions(missingTableConfig);
{code}

> Should throw Initialization error when no database table exists
> ---
>
> Key: CONFIGURATION-650
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-650
> Project: Commons Configuration
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Alexander Scott
>
> I have created a unit test using the H2 database. If I try and simulate a new 
> configuration when no database table has been created, I would expect a 
> ConfigurationException to be thrown.
> But instead it seems to create the config fine.
> {code}
> @Test
> public void databaseNotPresent2() throws Exception {
> EmbeddedDatabase db = new EmbeddedDatabaseBuilder()
> .setType(EmbeddedDatabaseType.H2)
> .build();
> BasicConfigurationBuilder builder = new 
> BasicConfigurationBuilder(DatabaseConfiguration.class);
> Parameters params = new Parameters();
> builder.configure(
> params.database()
> .setDataSource(db)
> .setTable("BADTABLE")
> .setKeyColumn("BADKEY")
> .setValueColumn("BADVALUE")
> //.setThrowExceptionOnMissing(true)
> );
> DatabaseConfiguration missingTableConfig = builder.getConfiguration();
> String missing = missingTableConfig.getString("MISSING_KEY");
> assertEquals(null, missing);
> missingTableConfig.addProperty("PRESENT_KEY", "some value");
> String present = missingTableConfig.getString("PRESENT_KEY");
> assertEquals(null, present);
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CONFIGURATION-650) Should throw Initialization error when no database table exists

[Alexander Scott (JIRA)]

[ 
https://issues.apache.org/jira/browse/CONFIGURATION-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15839923#comment-15839923
 ] 

Alexander Scott edited comment on CONFIGURATION-650 at 1/26/17 4:46 PM:


Assume this isn't just some weird H2/Spring EmbeddedDatabase quirk?


was (Author: alexjasc...@gmail.com):
Assume this isn't just some weird H2 quirk?

> Should throw Initialization error when no database table exists
> ---
>
> Key: CONFIGURATION-650
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-650
> Project: Commons Configuration
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Alexander Scott
>
> I have created a unit test using the H2 database. If I try and simulate a new 
> configuration when no database table has been created, I would expect a 
> ConfigurationException to be thrown.
> But instead it seems to create the config fine.
> {code}
> @Test
> public void databaseNotPresent2() throws Exception {
> EmbeddedDatabase db = new EmbeddedDatabaseBuilder()
> .setType(EmbeddedDatabaseType.H2)
> .build();
> BasicConfigurationBuilder builder = new 
> BasicConfigurationBuilder(DatabaseConfiguration.class);
> Parameters params = new Parameters();
> builder.configure(
> params.database()
> .setDataSource(db)
> .setTable("BADTABLE")
> .setKeyColumn("BADKEY")
> .setValueColumn("BADVALUE")
> //.setThrowExceptionOnMissing(true)
> );
> DatabaseConfiguration missingTableConfig = builder.getConfiguration();
> String missing = missingTableConfig.getString("MISSING_KEY");
> assertEquals(null, missing);
> missingTableConfig.addProperty("PRESENT_KEY", "some value");
> String present = missingTableConfig.getString("PRESENT_KEY");
> assertEquals(null, present);
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CONFIGURATION-650) Should throw Initialization error when no database table exists

[Alexander Scott (JIRA)]

[ 
https://issues.apache.org/jira/browse/CONFIGURATION-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15839982#comment-15839982
 ] 

Alexander Scott commented on CONFIGURATION-650:
---

You can even have a null datasource, with the same behaviour.

> Should throw Initialization error when no database table exists
> ---
>
> Key: CONFIGURATION-650
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-650
> Project: Commons Configuration
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Alexander Scott
>
> I have created a unit test using the H2 database. If I try and simulate a new 
> configuration when no database table has been created, I would expect a 
> ConfigurationException to be thrown.
> But instead it seems to create the config fine.
> {code}
> @Test
> public void databaseNotPresent2() throws Exception {
> EmbeddedDatabase db = new EmbeddedDatabaseBuilder()
> .setType(EmbeddedDatabaseType.H2)
> .build();
> BasicConfigurationBuilder builder = new 
> BasicConfigurationBuilder(DatabaseConfiguration.class);
> Parameters params = new Parameters();
> builder.configure(
> params.database()
> .setDataSource(db)
> .setTable("BADTABLE")
> .setKeyColumn("BADKEY")
> .setValueColumn("BADVALUE")
> //.setThrowExceptionOnMissing(true)
> );
> DatabaseConfiguration missingTableConfig = builder.getConfiguration();
> String missing = missingTableConfig.getString("MISSING_KEY");
> assertEquals(null, missing);
> missingTableConfig.addProperty("PRESENT_KEY", "some value");
> String present = missingTableConfig.getString("PRESENT_KEY");
> assertEquals(null, present);
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CONFIGURATION-650) Should throw Initialization error when no database table exists

[Alexander Scott (JIRA)]

[ 
https://issues.apache.org/jira/browse/CONFIGURATION-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15839923#comment-15839923
 ] 

Alexander Scott commented on CONFIGURATION-650:
---

Assume this isn't just some weird H2 quirk?

> Should throw Initialization error when no database table exists
> ---
>
> Key: CONFIGURATION-650
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-650
> Project: Commons Configuration
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Alexander Scott
>
> I have created a unit test using the H2 database. If I try and simulate a new 
> configuration when no database table has been created, I would expect a 
> ConfigurationException to be thrown.
> But instead it seems to create the config fine.
> {code}
> @Test
> public void databaseNotPresent2() throws Exception {
> EmbeddedDatabase db = new EmbeddedDatabaseBuilder()
> .setType(EmbeddedDatabaseType.H2)
> .build();
> BasicConfigurationBuilder builder = new 
> BasicConfigurationBuilder(DatabaseConfiguration.class);
> Parameters params = new Parameters();
> builder.configure(
> params.database()
> .setDataSource(db)
> .setTable("BADTABLE")
> .setKeyColumn("BADKEY")
> .setValueColumn("BADVALUE")
> //.setThrowExceptionOnMissing(true)
> );
> DatabaseConfiguration missingTableConfig = builder.getConfiguration();
> String missing = missingTableConfig.getString("MISSING_KEY");
> assertEquals(null, missing);
> missingTableConfig.addProperty("PRESENT_KEY", "some value");
> String present = missingTableConfig.getString("PRESENT_KEY");
> assertEquals(null, present);
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CONFIGURATION-650) Should throw Initialization error when no database table exists

[Alexander Scott (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Scott updated CONFIGURATION-650:
--
Description: 
I have created a unit test using the H2 database. If I try and simulate a new 
configuration when no database table has been created, I would expect a 
ConfigurationException to be thrown.

But instead it seems to create the config fine.

{code}
@Test
public void databaseNotPresent2() throws Exception {
EmbeddedDatabase db = new EmbeddedDatabaseBuilder()
.setType(EmbeddedDatabaseType.H2)
.build();

BasicConfigurationBuilder builder = new 
BasicConfigurationBuilder(DatabaseConfiguration.class);
Parameters params = new Parameters();
builder.configure(
params.database()
.setDataSource(db)
.setTable("BADTABLE")
.setKeyColumn("BADKEY")
.setValueColumn("BADVALUE")
//.setThrowExceptionOnMissing(true)
);

DatabaseConfiguration missingTableConfig = builder.getConfiguration();
String missing = missingTableConfig.getString("MISSING_KEY");
assertEquals(null, missing);
missingTableConfig.addProperty("PRESENT_KEY", "some value");
String present = missingTableConfig.getString("PRESENT_KEY");
assertEquals(null, present);
}
{code}

  was:
I have created a unit test using the H2 database. If I try and simulate a new 
configuration when no database table has been created, I would expect a 
ConfigurationException to be thrown.

But instead it seems to create the config fine.


> Should throw Initialization error when no database table exists
> ---
>
> Key: CONFIGURATION-650
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-650
> Project: Commons Configuration
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Alexander Scott
>
> I have created a unit test using the H2 database. If I try and simulate a new 
> configuration when no database table has been created, I would expect a 
> ConfigurationException to be thrown.
> But instead it seems to create the config fine.
> {code}
> @Test
> public void databaseNotPresent2() throws Exception {
> EmbeddedDatabase db = new EmbeddedDatabaseBuilder()
> .setType(EmbeddedDatabaseType.H2)
> .build();
> BasicConfigurationBuilder builder = new 
> BasicConfigurationBuilder(DatabaseConfiguration.class);
> Parameters params = new Parameters();
> builder.configure(
> params.database()
> .setDataSource(db)
> .setTable("BADTABLE")
> .setKeyColumn("BADKEY")
> .setValueColumn("BADVALUE")
> //.setThrowExceptionOnMissing(true)
> );
> DatabaseConfiguration missingTableConfig = builder.getConfiguration();
> String missing = missingTableConfig.getString("MISSING_KEY");
> assertEquals(null, missing);
> missingTableConfig.addProperty("PRESENT_KEY", "some value");
> String present = missingTableConfig.getString("PRESENT_KEY");
> assertEquals(null, present);
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CONFIGURATION-650) Should throw Initialization error when no database table exists

[Alexander Scott (JIRA)]

Alexander Scott created CONFIGURATION-650:
-

 Summary: Should throw Initialization error when no database table 
exists
 Key: CONFIGURATION-650
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-650
 Project: Commons Configuration
  Issue Type: Bug
Affects Versions: 2.1
Reporter: Alexander Scott


I have created a unit test using the H2 database. If I try and simulate a new 
configuration when no database table has been created, I would expect a 
ConfigurationException to be thrown.

But instead it seems to create the config fine.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (NUMBERS-11) Resolve two competing Precision methods

[Gilles (JIRA)]

[ 
https://issues.apache.org/jira/browse/NUMBERS-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15839616#comment-15839616
 ] 

Gilles edited comment on NUMBERS-11 at 1/26/17 2:58 PM:


bq. Remove \[the class in "commons-rng-complex" module\]?

Sure; that was the intention when I created "core".


was (Author: erans):
bs Remove \[the class in "commons-rng-complex" module\]?

Sure; that was the intention when I created "core".

> Resolve two competing Precision methods
> ---
>
> Key: NUMBERS-11
> URL: https://issues.apache.org/jira/browse/NUMBERS-11
> Project: Commons Numbers
>  Issue Type: Improvement
>Reporter: Eric Barnhill
>Priority: Minor
>
> numbers-complex contains a Precision method and so does numbers-core . 
> Running meld, the numbers-core seems to remove any need for the complex 
> Precision() . Remove?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (COMMONSRDF-51) RDF-1.1 specifies that language tags need to be compared using lower-case

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMMONSRDF-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15839778#comment-15839778
 ] 

ASF GitHub Bot commented on COMMONSRDF-51:
--

Github user stain commented on the issue:

https://github.com/apache/commons-rdf/pull/30
  
I propose now to merge this branch following COMMONSRDF-55 fixing. Thanks 
everyone!


> RDF-1.1 specifies that language tags need to be compared using lower-case
> -
>
> Key: COMMONSRDF-51
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-51
> Project: Apache Commons RDF
>  Issue Type: Bug
>  Components: api
>Affects Versions: 0.3.0
>Reporter: Peter Ansell
>Assignee: Stian Soiland-Reyes
>
> The [RDF-1.1 specification states that the [value space of Literal language 
> tags is 
> lowercase|https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal], which 
> does not conflict with the case-insensitive specification in BCP47. The 
> Literal.equals and Literal.hashCode API contracts should specify that 
> language tags must be compared using lowercase, even if they are otherwise 
> stored and returned as upper-case by getLanguageTag. The API currently has 
> incorrect language by saying "character-by-character" for language tag 
> comparisons, as that implies case-sensitive comparisons are used.
> The lowercasing must also be done using a locale that is consistent (known 
> example where lowercase and uppercase do not roundtrip as expected for 
> US-ASCII characters is Turkish [1]), so I would recommend actually stating 
> that .toLowerCase(Locale.ENGLISH) is used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (COMMONSRDF-55) Stream of Jena quads use wrong IRI for default graph

[Stian Soiland-Reyes (JIRA)]

Stian Soiland-Reyes created COMMONSRDF-55:
-

 Summary: Stream of Jena quads use wrong IRI for default graph
 Key: COMMONSRDF-55
 URL: https://issues.apache.org/jira/browse/COMMONSRDF-55
 Project: Apache Commons RDF
  Issue Type: Bug
  Components: jena
Affects Versions: 0.3.0
Reporter: Stian Soiland-Reyes
 Fix For: 1.0.0


See https://travis-ci.org/apache/commons-rdf/builds/195548479

{code}
org.apache.commons.rdf.jena.DatasetJenaTest
streamLanguageTagsCaseInsensitive(org.apache.commons.rdf.jena.DatasetJenaTest)  
Time elapsed: 0.012 sec  <<< FAILURE!
java.lang.AssertionError: expected:< 
 "Hello"@EN-GB .> but 
was:<  "Hello"@en-GB .>
{code}

Jena uses the IRI `` internally to represent the 
default graph within datasets - we need to recognize that on the way out of a 
`JenaDatasetImpl.stream()` and possibly in the `asQuad(JenaQuad)` converter and 
replace it with `Optional.empty()` so the default graph appears the same across 
implementations.

The `AbstractDatasetTest`  should be augmented to do more tests on the default 
graph, including `.stream()`, `.iterate()`, `.contains()` and `.remove()`1.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (COMMONSRDF-51) RDF-1.1 specifies that language tags need to be compared using lower-case

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMMONSRDF-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15839771#comment-15839771
 ] 

ASF GitHub Bot commented on COMMONSRDF-51:
--

Github user stain commented on the issue:

https://github.com/apache/commons-rdf/pull/30
  
Thanks @afs , that makes sense, `JenaGraphImpl` was indeed using 
`graph.delete()`. 

I have fixed in both `JenaGraphImpl` and `JenaDatasetImpl`.  See comment - 
do you think there is much performance gain from not splitting into pattern but 
passing the original Jena Triple (safe only when there's no Literal object with 
langtag) - or shall we always use the pattern?

(e.g. would Jena TDB do things like get an internal Triple row ID out of 
the jena `Triple` for faster delete?)

I added tests for Dataset that reveals that statements in default graph 
come back from Jena in the named graph `` - that's a 
separate bug in `JenaDatasetImpl` and the converters - we should represent that 
always as `Optional.empty()` in Commons RDF land.



> RDF-1.1 specifies that language tags need to be compared using lower-case
> -
>
> Key: COMMONSRDF-51
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-51
> Project: Apache Commons RDF
>  Issue Type: Bug
>  Components: api
>Affects Versions: 0.3.0
>Reporter: Peter Ansell
>Assignee: Stian Soiland-Reyes
>
> The [RDF-1.1 specification states that the [value space of Literal language 
> tags is 
> lowercase|https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal], which 
> does not conflict with the case-insensitive specification in BCP47. The 
> Literal.equals and Literal.hashCode API contracts should specify that 
> language tags must be compared using lowercase, even if they are otherwise 
> stored and returned as upper-case by getLanguageTag. The API currently has 
> incorrect language by saying "character-by-character" for language tag 
> comparisons, as that implies case-sensitive comparisons are used.
> The lowercasing must also be done using a locale that is consistent (known 
> example where lowercase and uppercase do not roundtrip as expected for 
> US-ASCII characters is Turkish [1]), so I would recommend actually stating 
> that .toLowerCase(Locale.ENGLISH) is used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] commons-lang issue #229: Update RELEASE-NOTES.txt - typo "vom"

[coveralls]

Github user coveralls commented on the issue:

https://github.com/apache/commons-lang/pull/229
  

[![Coverage 
Status](https://coveralls.io/builds/9855971/badge)](https://coveralls.io/builds/9855971)

Coverage remained the same at 94.455% when pulling 
**bdece46a29d1d2f82088f110b8e75085f715d196 on stonio:patch-1** into 
**86a082e8be8c51f07079ded82d6d125c9efc1791 on apache:master**.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (NUMBERS-10) Revamp "Complex" representation ?

[Gilles (JIRA)]

[ 
https://issues.apache.org/jira/browse/NUMBERS-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15839753#comment-15839753
 ] 

Gilles commented on NUMBERS-10:
---

The proposal aims at avoiding direct calls to a constructor ("builder" pattern).
As {{Complex}} is abstract, this statement
{code}
c = new Complex(1, 1); 
{code}
is forbidden.
The user has to program against the interface ({{Complex}}), not the actual 
representation.
Moreover, as blatant shortcoming of the above constructor is that you get tied 
to a single representation since you cannot overload it for polar (that also 
would require a constructor that takes to "double" arguments. Or start to use 
an {{enum}} or the like, which becomes much longer to write than the factory 
method.

> Revamp "Complex" representation ?
> -
>
> Key: NUMBERS-10
> URL: https://issues.apache.org/jira/browse/NUMBERS-10
> Project: Commons Numbers
>  Issue Type: Wish
>Reporter: Gilles
>  Labels: API, design, review
> Fix For: 1.0
>
> Attachments: CartesianRepresentation.java, Complex.java, 
> MixedRepresentation.java, PolarRepresentation.java
>
>
> This is a proposal to enhance the internal representation of complex numbers.
> The purpose is to allow usage of both cartesian and polar representations, 
> with the aim that calculations are performed (transparently) with the one 
> that will be more accurate and/or faster. 
> The API would certainly be improved, from
> {code}
> final Complex c1 = Complex.valueOf(1, 2);
> final Complex c2 = ComplexUtils.polar2Complex(2, 7);
> final Complex r = c1.add(c2);
>  {code}
> with the current code, to
> {code}
> final Complex c1 = Complex.createCartesian(1, 2);
> final Complex c2 = Complex.createPolar(2, 7);
> final Complex r = c1.add(c2);
> {code}
> Please refer to the attached files (they are self-documenting, but of course, 
> Javadoc must be added if the proposal is validated).
> Would there be merit in pursuing in that direction?
> Or is there any show-stopper?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] commons-lang pull request #229: Update RELEASE-NOTES.txt - typo "vom"

[stonio]

GitHub user stonio opened a pull request:

https://github.com/apache/commons-lang/pull/229

Update RELEASE-NOTES.txt - typo "vom"

Replace `vom` by `from`.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/stonio/commons-lang patch-1

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-lang/pull/229.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 #229


commit bdece46a29d1d2f82088f110b8e75085f715d196
Author: stonio 
Date:   2017-01-26T14:30:28Z

Update RELEASE-NOTES.txt - typo "vom"

Replace `vom` by `from`.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (COMMONSRDF-54) overloaded versions of RDF4J#asRDFTerm(org.eclipse.rdf4j.model.Value)

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMMONSRDF-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15839720#comment-15839720
 ] 

ASF GitHub Bot commented on COMMONSRDF-54:
--

Github user stain commented on the issue:

https://github.com/apache/commons-rdf/pull/31
  
Thanks, this looks sensible to me! 

Should we add unit test for each of the new `asRDFTerm` methods? They are 
in a way already tested through `createLiteral` etc.., but just so we don't 
break it later?


> overloaded versions of RDF4J#asRDFTerm(org.eclipse.rdf4j.model.Value)
> -
>
> Key: COMMONSRDF-54
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-54
> Project: Apache Commons RDF
>  Issue Type: Improvement
>  Components: rdf4j
>Reporter: Guohui Xiao
>Priority: Minor
> Fix For: 1.0.0
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> In the class org.apache.commons.rdf.rdf4j.RDF4J, there is a  method
> public RDF4JTerm asRDFTerm(final Value value)
> Suppose that we declare a variable iri of the type 
> org.eclipse.rdf4j.model.IRI, then asRDFTerm(iri) returns RDF4JTerm but not 
> RDF4JIRI. To use the result as RDF4JIRI, I always need to explicitly cast.
> Therefore, I would like to add three overloaded versions of this method:
> - RDF4JBlankNode asRDFTerm(final org.eclipse.rdf4j.model.BNode value) 
> - RDF4JLiteral asRDFTerm(final org.eclipse.rdf4j.model.Literal value)
> - RDF4JIRI asRDFTerm(final org.eclipse.rdf4j.model.IRI value)
> So that we can avoid unnecessary casts.
> There is also a similar situation in 
> org.apache.commons.rdf.jena.JenaRDF#asRDFTerm(org.apache.jena.graph.Node)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (NUMBERS-11) Resolve two competing Precision methods

[Eric Barnhill (JIRA)]

[ 
https://issues.apache.org/jira/browse/NUMBERS-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15839644#comment-15839644
 ] 

Eric Barnhill edited comment on NUMBERS-11 at 1/26/17 12:52 PM:


Okay I will move some method calls from within complex over to core.


was (Author: ericbarnhill):
Okay I will move some things from Complex to core then.

> Resolve two competing Precision methods
> ---
>
> Key: NUMBERS-11
> URL: https://issues.apache.org/jira/browse/NUMBERS-11
> Project: Commons Numbers
>  Issue Type: Improvement
>Reporter: Eric Barnhill
>Priority: Minor
>
> numbers-complex contains a Precision method and so does numbers-core . 
> Running meld, the numbers-core seems to remove any need for the complex 
> Precision() . Remove?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NUMBERS-11) Resolve two competing Precision methods

[Eric Barnhill (JIRA)]

[ 
https://issues.apache.org/jira/browse/NUMBERS-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15839644#comment-15839644
 ] 

Eric Barnhill commented on NUMBERS-11:
--

Okay I will move some things from Complex to core then.

> Resolve two competing Precision methods
> ---
>
> Key: NUMBERS-11
> URL: https://issues.apache.org/jira/browse/NUMBERS-11
> Project: Commons Numbers
>  Issue Type: Improvement
>Reporter: Eric Barnhill
>Priority: Minor
>
> numbers-complex contains a Precision method and so does numbers-core . 
> Running meld, the numbers-core seems to remove any need for the complex 
> Precision() . Remove?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NUMBERS-11) Resolve two competing Precision methods

[Gilles (JIRA)]

[ 
https://issues.apache.org/jira/browse/NUMBERS-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15839616#comment-15839616
 ] 

Gilles commented on NUMBERS-11:
---

bs Remove \[the class in "commons-rng-complex" module\]?

Sure; that was the intention when I created "core".

> Resolve two competing Precision methods
> ---
>
> Key: NUMBERS-11
> URL: https://issues.apache.org/jira/browse/NUMBERS-11
> Project: Commons Numbers
>  Issue Type: Improvement
>Reporter: Eric Barnhill
>Priority: Minor
>
> numbers-complex contains a Precision method and so does numbers-core . 
> Running meld, the numbers-core seems to remove any need for the complex 
> Precision() . Remove?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (NUMBERS-11) Resolve two competing Precision methods

[Eric Barnhill (JIRA)]

Eric Barnhill created NUMBERS-11:


 Summary: Resolve two competing Precision methods
 Key: NUMBERS-11
 URL: https://issues.apache.org/jira/browse/NUMBERS-11
 Project: Commons Numbers
  Issue Type: Improvement
Reporter: Eric Barnhill
Priority: Minor


numbers-complex contains a Precision method and so does numbers-core . Running 
meld, the numbers-core seems to remove any need for the complex Precision() . 
Remove?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NUMBERS-10) Revamp "Complex" representation ?

[Eric Barnhill (JIRA)]

[ 
https://issues.apache.org/jira/browse/NUMBERS-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15839604#comment-15839604
 ] 

Eric Barnhill commented on NUMBERS-10:
--

This sounds great to me. I would think while speed could be an advantage to 
this approach a bigger advantage would be that some mathematical quantities are 
much more numerically stable in one representation or the other. 

I would lean toward adding to this, the creation of a simple constructor 

c = new Complex(1, 1); 

that creates a mixed representation for people who don't care.

> Revamp "Complex" representation ?
> -
>
> Key: NUMBERS-10
> URL: https://issues.apache.org/jira/browse/NUMBERS-10
> Project: Commons Numbers
>  Issue Type: Wish
>Reporter: Gilles
>  Labels: API, design, review
> Fix For: 1.0
>
> Attachments: CartesianRepresentation.java, Complex.java, 
> MixedRepresentation.java, PolarRepresentation.java
>
>
> This is a proposal to enhance the internal representation of complex numbers.
> The purpose is to allow usage of both cartesian and polar representations, 
> with the aim that calculations are performed (transparently) with the one 
> that will be more accurate and/or faster. 
> The API would certainly be improved, from
> {code}
> final Complex c1 = Complex.valueOf(1, 2);
> final Complex c2 = ComplexUtils.polar2Complex(2, 7);
> final Complex r = c1.add(c2);
>  {code}
> with the current code, to
> {code}
> final Complex c1 = Complex.createCartesian(1, 2);
> final Complex c2 = Complex.createPolar(2, 7);
> final Complex r = c1.add(c2);
> {code}
> Please refer to the attached files (they are self-documenting, but of course, 
> Javadoc must be added if the proposal is validated).
> Would there be merit in pursuing in that direction?
> Or is there any show-stopper?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (COMPRESS-380) Support for ENHANCED_DEFLATED (Deflate64) in ZIP files

[Dawid Weiss (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15839531#comment-15839531
 ] 

Dawid Weiss commented on COMPRESS-380:
--

Not necessarily bad wording -- I may be slow in the morning, Stefan, no 
worries. Indeed, native ZIP in Java is faster, but it comes with its own 
quirks, so not everything is rosy. We use commons-codec as a fallback and I 
thought DEFLATE64, even though considered a "proprietary" extension is 
widespread enough that it'd be nice to have it for completeness. I assume that 
if zlib has public sources to decompress it, the lawyers wouldn't get 
involved... (?).



> Support for ENHANCED_DEFLATED (Deflate64) in ZIP files
> --
>
> Key: COMPRESS-380
> URL: https://issues.apache.org/jira/browse/COMPRESS-380
> Project: Commons Compress
>  Issue Type: New Feature
>Reporter: Dawid Weiss
>
> Some of the (large) ZIP files we try to process currently will throw this:
> {code}
> UnsupportedZipFeatureException: unsupported feature method 
> 'ENHANCED_DEFLATED' 
> {code}
> which is a bummer since JDK's implementation also doesn't support Deflate64. 
> This seems to be PKWare's extensions, although code to decrypt it exists in 
> zlib (and is appropriately licensed, I believe).
> https://github.com/madler/zlib/tree/master/contrib/infback9



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (COMPRESS-380) Support for ENHANCED_DEFLATED (Deflate64) in ZIP files

[Stefan Bodewig (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15839521#comment-15839521
 ] 

Stefan Bodewig commented on COMPRESS-380:
-

Ah, bad wording.

No the JDK's zip package doesn't support DEFLATE64 only DEFLATE, the little 
brother. DEFLATE64 really only has a bigger buffer size so back-references may 
go back for a bit further AFAIK.

What I was trying to say is that a DEFLATE64 we implement in Java will be 
slower than DEFLATE itself, probably quite a bit. But of course a slow 
DEFLATE64 will be better than none at all for people trying to read archives 
created with it. Once we implement DEFLATE64 we probably should advice people 
to not use it when creating new archives.

> Support for ENHANCED_DEFLATED (Deflate64) in ZIP files
> --
>
> Key: COMPRESS-380
> URL: https://issues.apache.org/jira/browse/COMPRESS-380
> Project: Commons Compress
>  Issue Type: New Feature
>Reporter: Dawid Weiss
>
> Some of the (large) ZIP files we try to process currently will throw this:
> {code}
> UnsupportedZipFeatureException: unsupported feature method 
> 'ENHANCED_DEFLATED' 
> {code}
> which is a bummer since JDK's implementation also doesn't support Deflate64. 
> This seems to be PKWare's extensions, although code to decrypt it exists in 
> zlib (and is appropriately licensed, I believe).
> https://github.com/madler/zlib/tree/master/contrib/infback9



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (COMPRESS-380) Support for ENHANCED_DEFLATED (Deflate64) in ZIP files

[Dawid Weiss (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15839517#comment-15839517
 ] 

Dawid Weiss commented on COMPRESS-380:
--

zip4j doesn't support DEFLATE64 either, just checked.

> Support for ENHANCED_DEFLATED (Deflate64) in ZIP files
> --
>
> Key: COMPRESS-380
> URL: https://issues.apache.org/jira/browse/COMPRESS-380
> Project: Commons Compress
>  Issue Type: New Feature
>Reporter: Dawid Weiss
>
> Some of the (large) ZIP files we try to process currently will throw this:
> {code}
> UnsupportedZipFeatureException: unsupported feature method 
> 'ENHANCED_DEFLATED' 
> {code}
> which is a bummer since JDK's implementation also doesn't support Deflate64. 
> This seems to be PKWare's extensions, although code to decrypt it exists in 
> zlib (and is appropriately licensed, I believe).
> https://github.com/madler/zlib/tree/master/contrib/infback9



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (COMPRESS-380) Support for ENHANCED_DEFLATED (Deflate64) in ZIP files

[Dawid Weiss (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15839507#comment-15839507
 ] 

Dawid Weiss commented on COMPRESS-380:
--

bq. A pure Java DEFLATE64 will certainly be slower than the JNI based DEFLATE 
built into the JDK (which we re-use as well).

I don't think Java supports DEFLATE64 -- tried Java8 and Java9 and they don't 
(Oracle and IBM). This tool does, supposedly (and is Apache licensed):

http://www.lingala.net/zip4j/

But I haven't tried it.

> Support for ENHANCED_DEFLATED (Deflate64) in ZIP files
> --
>
> Key: COMPRESS-380
> URL: https://issues.apache.org/jira/browse/COMPRESS-380
> Project: Commons Compress
>  Issue Type: New Feature
>Reporter: Dawid Weiss
>
> Some of the (large) ZIP files we try to process currently will throw this:
> {code}
> UnsupportedZipFeatureException: unsupported feature method 
> 'ENHANCED_DEFLATED' 
> {code}
> which is a bummer since JDK's implementation also doesn't support Deflate64. 
> This seems to be PKWare's extensions, although code to decrypt it exists in 
> zlib (and is appropriately licensed, I believe).
> https://github.com/madler/zlib/tree/master/contrib/infback9



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (COMPRESS-381) performance issue when using default Wiki/docs bzip2 compression Factory methods

[Stefan Bodewig (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15839453#comment-15839453
 ] 

Stefan Bodewig commented on COMPRESS-381:
-

Oh, I really thought {{Files.readAllBytes}} would be performing some kind of 
magic under the covers like memory mapping the file or so. I would have 
expected that using a {{BufferedInputStream}} would roughly provide the same 
performance numbers as reading the file in a loop before starting. Your result 
comes as a surprise.

> performance issue when using default Wiki/docs bzip2 compression Factory 
> methods
> 
>
> Key: COMPRESS-381
> URL: https://issues.apache.org/jira/browse/COMPRESS-381
> Project: Commons Compress
>  Issue Type: Improvement
>  Components: Documentation
>Affects Versions: 1.13
> Environment: Windows/All
>Reporter: Dominique De Munck
>Priority: Minor
>  Labels: documentation, easyfix, performance
>
> Hello
> We are going to use this project's bzip2 implementation as it performed best 
> for our use case (tested using 
> https://github.com/ning/jvm-compressor-benchmark).
> However, when following the default examples using the wiki/example/javadoc 
> pages (*), we were hitting a serious performance bottleneck.
> The reason: the default "compress" operation on a file which is suggested, is 
> very slow, maybe because of disk I/O and lack of caching.
> For a 2 MB tiff file, bzip2 compression takes about 3 seconds with code (A), 
> whereas code (B) takes only about 0.5 seconds!
> So it would be good to adapt documentation or take a look at bottle neck.
> Kind regards
> Dominique
> >>>
> FileInputStream fin = new FileInputStream(infile);
> BufferedInputStream bufferin = new BufferedInputStream(fin);
> final FileOutputStream outStream = new FileOutputStream(outfile);
> CompressorOutputStream cos = new CompressorStreamFactory()
>  .createCompressorOutputStream(CompressorStreamFactory.BZIP2, outStream);
> IOUtils.copy(fin, cos);
> cos.close();
> >>>
> B:
> <
> final byte[] uncompressed = Files.readAllBytes(infile.toPath());
> ByteArrayOutputStream rawOut = new ByteArrayOutputStream(uncompressed.length);
>   
> BZip2CompressorOutputStream out = new BZip2CompressorOutputStream(rawOut, 
> COMPRESSION_LEVEL);
> out.write(uncompressed);
> out.close();
> FileOutputStream fos = new FileOutputStream(outfile);
> rawOut.writeTo(fos);
> fos.close();
> 
> (*)
> Pages with documentation:
> https://wiki.apache.org/commons/Compress
> https://commons.apache.org/proper/commons-compress/examples.html
> https://commons.apache.org/proper/commons-compress/javadocs/api-release/index.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (COMPRESS-380) Support for ENHANCED_DEFLATED (Deflate64) in ZIP files

[Stefan Bodewig (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15839449#comment-15839449
 ] 

Stefan Bodewig commented on COMPRESS-380:
-

Of course. I just wanted to leave a pointer for anybody who wants to implement 
this (which might even be my future self).

A pure Java DEFLATE64 will certainly be slower than the JNI based DEFLATE built 
into the JDK (which we re-use as well).

> Support for ENHANCED_DEFLATED (Deflate64) in ZIP files
> --
>
> Key: COMPRESS-380
> URL: https://issues.apache.org/jira/browse/COMPRESS-380
> Project: Commons Compress
>  Issue Type: New Feature
>Reporter: Dawid Weiss
>
> Some of the (large) ZIP files we try to process currently will throw this:
> {code}
> UnsupportedZipFeatureException: unsupported feature method 
> 'ENHANCED_DEFLATED' 
> {code}
> which is a bummer since JDK's implementation also doesn't support Deflate64. 
> This seems to be PKWare's extensions, although code to decrypt it exists in 
> zlib (and is appropriately licensed, I believe).
> https://github.com/madler/zlib/tree/master/contrib/infback9



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)