[jira] [Commented] (BCEL-304) ClassPath.getClassFile does not work with JDK 9 and higher
[
https://issues.apache.org/jira/browse/BCEL-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16560631#comment-16560631
]
ASF GitHub Bot commented on BCEL-304:
-
Github user asfgit closed the pull request at:
https://github.com/apache/commons-bcel/pull/22
> ClassPath.getClassFile does not work with JDK 9 and higher
> --
>
> Key: BCEL-304
> URL: https://issues.apache.org/jira/browse/BCEL-304
> Project: Commons BCEL
> Issue Type: Bug
> Components: Main
>Affects Versions: 6.2
>Reporter: Ed Pavlak
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 6.3
>
>
> When trying to get the class file for Java classes (ie. java.lang.String), an
> IOException is thrown:
> Exception in thread "main" java.io.IOException: Couldn't find:
> java.lang.String.class
> at org.apache.bcel.util.ClassPath.getClassFile(ClassPath.java:279)
> at org.apache.bcel.util.ClassPath.getClassFile(ClassPath.java:301)
> at bcel.test.GetClassFileTest.main(GetClassFileTest.java:12)
>
> The root cause appears to be the restructuring of Java starting with Java 9.
> Specifically, the removal of the rt.jar. The above excpetion can be
> reproduced using a simple application:
> package bcel.test;
> import java.io.IOException;
> import org.apache.bcel.util.ClassPath;
> public class GetClassFileTest {
> public static void main(String[] args) throws IOException {
> String className = "java.lang.String";
> System.out.println("Looking up ClassPath.ClassFile for: " + className);
> ClassPath.ClassFile classFile =
> ClassPath.SYSTEM_CLASS_PATH.getClassFile(className);
> if (classFile != null) {
> System.out.println("Class file base: " + classFile.getBase());
> System.out.println("Class file path: " + classFile.getPath());
> }
> }
> }
>
> Running this on Java 8 produces the following output, whereas running it on
> Java 9+ produces the IOException:
> Class file base: C:\jdk1.8.0_161\jre\lib\rt.jar
> Class file path: java/lang/String.class
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (BCEL-304) ClassPath.getClassFile does not work with JDK 9 and higher
[
https://issues.apache.org/jira/browse/BCEL-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16560616#comment-16560616
]
Gary Gregory edited comment on BCEL-304 at 7/28/18 5:03 AM:
I applied a quite reworked version of the patch and changed this ticket
description to say "JDK" instead of "Java". Dealing with a JRE will be in a new
ticket.
[~epavlak]: Please verifty and close.
was (Author: garydgregory):
I applied a quite reworked version of the patch and changed this ticket
description to say "JDK" instead of "Java". Dealing with a JRE will be in a new
ticket.
> ClassPath.getClassFile does not work with JDK 9 and higher
> --
>
> Key: BCEL-304
> URL: https://issues.apache.org/jira/browse/BCEL-304
> Project: Commons BCEL
> Issue Type: Bug
> Components: Main
>Affects Versions: 6.2
>Reporter: Ed Pavlak
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 6.3
>
>
> When trying to get the class file for Java classes (ie. java.lang.String), an
> IOException is thrown:
> Exception in thread "main" java.io.IOException: Couldn't find:
> java.lang.String.class
> at org.apache.bcel.util.ClassPath.getClassFile(ClassPath.java:279)
> at org.apache.bcel.util.ClassPath.getClassFile(ClassPath.java:301)
> at bcel.test.GetClassFileTest.main(GetClassFileTest.java:12)
>
> The root cause appears to be the restructuring of Java starting with Java 9.
> Specifically, the removal of the rt.jar. The above excpetion can be
> reproduced using a simple application:
> package bcel.test;
> import java.io.IOException;
> import org.apache.bcel.util.ClassPath;
> public class GetClassFileTest {
> public static void main(String[] args) throws IOException {
> String className = "java.lang.String";
> System.out.println("Looking up ClassPath.ClassFile for: " + className);
> ClassPath.ClassFile classFile =
> ClassPath.SYSTEM_CLASS_PATH.getClassFile(className);
> if (classFile != null) {
> System.out.println("Class file base: " + classFile.getBase());
> System.out.println("Class file path: " + classFile.getPath());
> }
> }
> }
>
> Running this on Java 8 produces the following output, whereas running it on
> Java 9+ produces the IOException:
> Class file base: C:\jdk1.8.0_161\jre\lib\rt.jar
> Class file path: java/lang/String.class
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (BCEL-305) ClassPath.getClassFile does not work with JRE 9 and higher
Gary Gregory created BCEL-305: - Summary: ClassPath.getClassFile does not work with JRE 9 and higher Key: BCEL-305 URL: https://issues.apache.org/jira/browse/BCEL-305 Project: Commons BCEL Issue Type: New Feature Reporter: Gary Gregory See BCEL-304 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (BCEL-304) ClassPath.getClassFile does not work with JDK 9 and higher
[
https://issues.apache.org/jira/browse/BCEL-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory resolved BCEL-304.
---
Resolution: Fixed
Assignee: Gary Gregory
Fix Version/s: 6.3
I applied a quite reworked version of the patch and changed this ticket
description to say "JDK" instead of "Java". Dealing with a JRE will be in a new
ticket.
> ClassPath.getClassFile does not work with JDK 9 and higher
> --
>
> Key: BCEL-304
> URL: https://issues.apache.org/jira/browse/BCEL-304
> Project: Commons BCEL
> Issue Type: Bug
> Components: Main
>Affects Versions: 6.2
>Reporter: Ed Pavlak
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 6.3
>
>
> When trying to get the class file for Java classes (ie. java.lang.String), an
> IOException is thrown:
> Exception in thread "main" java.io.IOException: Couldn't find:
> java.lang.String.class
> at org.apache.bcel.util.ClassPath.getClassFile(ClassPath.java:279)
> at org.apache.bcel.util.ClassPath.getClassFile(ClassPath.java:301)
> at bcel.test.GetClassFileTest.main(GetClassFileTest.java:12)
>
> The root cause appears to be the restructuring of Java starting with Java 9.
> Specifically, the removal of the rt.jar. The above excpetion can be
> reproduced using a simple application:
> package bcel.test;
> import java.io.IOException;
> import org.apache.bcel.util.ClassPath;
> public class GetClassFileTest {
> public static void main(String[] args) throws IOException {
> String className = "java.lang.String";
> System.out.println("Looking up ClassPath.ClassFile for: " + className);
> ClassPath.ClassFile classFile =
> ClassPath.SYSTEM_CLASS_PATH.getClassFile(className);
> if (classFile != null) {
> System.out.println("Class file base: " + classFile.getBase());
> System.out.println("Class file path: " + classFile.getPath());
> }
> }
> }
>
> Running this on Java 8 produces the following output, whereas running it on
> Java 9+ produces the IOException:
> Class file base: C:\jdk1.8.0_161\jre\lib\rt.jar
> Class file path: java/lang/String.class
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (BCEL-304) ClassPath.getClassFile does not work with JDK 9 and higher
[
https://issues.apache.org/jira/browse/BCEL-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated BCEL-304:
--
Summary: ClassPath.getClassFile does not work with JDK 9 and higher (was:
ClassPath.getClassFile does not work with Java 9 and higher)
> ClassPath.getClassFile does not work with JDK 9 and higher
> --
>
> Key: BCEL-304
> URL: https://issues.apache.org/jira/browse/BCEL-304
> Project: Commons BCEL
> Issue Type: Bug
> Components: Main
>Affects Versions: 6.2
>Reporter: Ed Pavlak
>Priority: Major
>
> When trying to get the class file for Java classes (ie. java.lang.String), an
> IOException is thrown:
> Exception in thread "main" java.io.IOException: Couldn't find:
> java.lang.String.class
> at org.apache.bcel.util.ClassPath.getClassFile(ClassPath.java:279)
> at org.apache.bcel.util.ClassPath.getClassFile(ClassPath.java:301)
> at bcel.test.GetClassFileTest.main(GetClassFileTest.java:12)
>
> The root cause appears to be the restructuring of Java starting with Java 9.
> Specifically, the removal of the rt.jar. The above excpetion can be
> reproduced using a simple application:
> package bcel.test;
> import java.io.IOException;
> import org.apache.bcel.util.ClassPath;
> public class GetClassFileTest {
> public static void main(String[] args) throws IOException {
> String className = "java.lang.String";
> System.out.println("Looking up ClassPath.ClassFile for: " + className);
> ClassPath.ClassFile classFile =
> ClassPath.SYSTEM_CLASS_PATH.getClassFile(className);
> if (classFile != null) {
> System.out.println("Class file base: " + classFile.getBase());
> System.out.println("Class file path: " + classFile.getPath());
> }
> }
> }
>
> Running this on Java 8 produces the following output, whereas running it on
> Java 9+ produces the IOException:
> Class file base: C:\jdk1.8.0_161\jre\lib\rt.jar
> Class file path: java/lang/String.class
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (BCEL-304) ClassPath.getClassFile does not work with Java 9 and higher
[
https://issues.apache.org/jira/browse/BCEL-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16560504#comment-16560504
]
Gary Gregory commented on BCEL-304:
---
Hi [~epavlak],
Thank you for your patch.
The patch only works on a JDK, it does not solve the problem when running on a
JRE since there is no jmods directory in a JRE :-(
Gary
> ClassPath.getClassFile does not work with Java 9 and higher
> ---
>
> Key: BCEL-304
> URL: https://issues.apache.org/jira/browse/BCEL-304
> Project: Commons BCEL
> Issue Type: Bug
> Components: Main
>Affects Versions: 6.2
>Reporter: Ed Pavlak
>Priority: Major
>
> When trying to get the class file for Java classes (ie. java.lang.String), an
> IOException is thrown:
> Exception in thread "main" java.io.IOException: Couldn't find:
> java.lang.String.class
> at org.apache.bcel.util.ClassPath.getClassFile(ClassPath.java:279)
> at org.apache.bcel.util.ClassPath.getClassFile(ClassPath.java:301)
> at bcel.test.GetClassFileTest.main(GetClassFileTest.java:12)
>
> The root cause appears to be the restructuring of Java starting with Java 9.
> Specifically, the removal of the rt.jar. The above excpetion can be
> reproduced using a simple application:
> package bcel.test;
> import java.io.IOException;
> import org.apache.bcel.util.ClassPath;
> public class GetClassFileTest {
> public static void main(String[] args) throws IOException {
> String className = "java.lang.String";
> System.out.println("Looking up ClassPath.ClassFile for: " + className);
> ClassPath.ClassFile classFile =
> ClassPath.SYSTEM_CLASS_PATH.getClassFile(className);
> if (classFile != null) {
> System.out.println("Class file base: " + classFile.getBase());
> System.out.println("Class file path: " + classFile.getPath());
> }
> }
> }
>
> Running this on Java 8 produces the following output, whereas running it on
> Java 9+ produces the IOException:
> Class file base: C:\jdk1.8.0_161\jre\lib\rt.jar
> Class file path: java/lang/String.class
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (RNG-50) PoissonSampler single use speed improvements
[
https://issues.apache.org/jira/browse/RNG-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16560475#comment-16560475
]
Gilles commented on RNG-50:
---
bq. Off topic: Where would be a good place to provide feedback on the library?
On the project's mailing lists.
Feature requests are handled by JIRA reports too.
Thanks for the feedback!
> PoissonSampler single use speed improvements
>
>
> Key: RNG-50
> URL: https://issues.apache.org/jira/browse/RNG-50
> Project: Commons RNG
> Issue Type: Improvement
>Affects Versions: 1.0
>Reporter: Alex D Herbert
>Priority: Minor
> Attachments: PoissonSamplerTest.java
>
>
> The Sampler architecture of {{org.apache.commons.rng.sampling.distribution}}
> is nicely written for fast sampling of small dataset sizes. The constructors
> for the samplers do not check the input parameters are valid for the
> respective distributions (in contrast to the old
> {{org.apache.commons.math3.random.distribution}} classes). I assume this is a
> design choice for speed. Thus most of the samplers can be used within a loop
> to sample just one value with very little overhead.
> The {{PoissonSampler}} precomputes log factorial numbers upon construction if
> the mean is above 40. This is done using the {{InternalUtils.FactorialLog}}
> class. As of version 1.0 this internal class is currently only used in the
> {{PoissonSampler}}.
> The cache size is limited to 2*PIVOT (where PIVOT=40). But it creates and
> precomputes the cache every time a PoissonSampler is constructed if the mean
> is above the PIVOT value.
> Why not create this once in a static block for the PoissonSampler?
> {code:java}
> /** {@code log(n!)}. */
> private static final FactorialLog factorialLog;
>
> static
> {
> factorialLog = FactorialLog.create().withCache((int) (2 *
> PoissonSampler.PIVOT));
> }
> {code}
> This will make the construction cost of a new {{PoissonSampler}} negligible.
> If the table is computed dynamically as a static construction method then the
> overhead will be in the first use. Thus the following call will be much
> faster:
> {code:java}
> UniformRandomProvider rng = ...;
> int value = new PoissonSampler(rng, 50).sample();
> {code}
> I have tested this modification (see attached file) and the results are:
> {noformat}
> Mean 40 Single construction ( 7330792) vs Loop construction
> (24334724) (3.319522.2x faster)
> Mean 40 Single construction ( 7330792) vs Loop construction with static
> FactorialLog ( 7990656) (1.090013.2x faster)
> Mean 50 Single construction ( 6390303) vs Loop construction
> (19389026) (3.034132.2x faster)
> Mean 50 Single construction ( 6390303) vs Loop construction with static
> FactorialLog ( 6146556) (0.961857.2x faster)
> Mean 60 Single construction ( 6041165) vs Loop construction
> (21337678) (3.532047.2x faster)
> Mean 60 Single construction ( 6041165) vs Loop construction with static
> FactorialLog ( 5329129) (0.882136.2x faster)
> Mean 70 Single construction ( 6064003) vs Loop construction
> (23963516) (3.951765.2x faster)
> Mean 70 Single construction ( 6064003) vs Loop construction with static
> FactorialLog ( 5306081) (0.875013.2x faster)
> Mean 80 Single construction ( 6064772) vs Loop construction
> (26381365) (4.349935.2x faster)
> Mean 80 Single construction ( 6064772) vs Loop construction with static
> FactorialLog ( 6341274) (1.045591.2x faster)
> {noformat}
> Thus the speed improvements would be approximately 3-4 fold for single use
> Poisson sampling.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LANG-1405) Remove checks for java versions below the minimum supported one
[
https://issues.apache.org/jira/browse/LANG-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16560468#comment-16560468
]
ASF GitHub Bot commented on LANG-1405:
--
Github user asfgit closed the pull request at:
https://github.com/apache/commons-lang/pull/338
> Remove checks for java versions below the minimum supported one
> ---
>
> Key: LANG-1405
> URL: https://issues.apache.org/jira/browse/LANG-1405
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.5, 3.6, 3.7
>Reporter: Lars Grefer
>Priority: Minor
> Fix For: 3.8
>
>
> The minimum java version for 3.x is java 1.7, so checks like
> {{SystemUtils.isJavaVersionAtLeast(JavaVersion.JAVA_1_5)}} will always be
> true and are therefore redundant
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (LANG-1405) Remove checks for java versions below the minimum supported one
[
https://issues.apache.org/jira/browse/LANG-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory resolved LANG-1405.
Resolution: Fixed
[~larsgrefer],
Patch applied, in git master. Please verify and close.
Thank you,
Gary
> Remove checks for java versions below the minimum supported one
> ---
>
> Key: LANG-1405
> URL: https://issues.apache.org/jira/browse/LANG-1405
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.5, 3.6, 3.7
>Reporter: Lars Grefer
>Priority: Minor
> Fix For: 3.8
>
>
> The minimum java version for 3.x is java 1.7, so checks like
> {{SystemUtils.isJavaVersionAtLeast(JavaVersion.JAVA_1_5)}} will always be
> true and are therefore redundant
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] commons-lang pull request #338: LANG-1405 Remove check for Java 1.5
Github user asfgit closed the pull request at: https://github.com/apache/commons-lang/pull/338 ---
[jira] [Commented] (LANG-1405) Remove checks for java versions below the minimum supported one
[
https://issues.apache.org/jira/browse/LANG-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16560406#comment-16560406
]
Sebb commented on LANG-1405:
My bad, I misunderstood the intent of the original issue. The API is not
affected by this change.
> Remove checks for java versions below the minimum supported one
> ---
>
> Key: LANG-1405
> URL: https://issues.apache.org/jira/browse/LANG-1405
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.5, 3.6, 3.7
>Reporter: Lars Grefer
>Priority: Minor
> Fix For: 3.8
>
>
> The minimum java version for 3.x is java 1.7, so checks like
> {{SystemUtils.isJavaVersionAtLeast(JavaVersion.JAVA_1_5)}} will always be
> true and are therefore redundant
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LANG-1405) Remove checks for java versions below the minimum supported one
[
https://issues.apache.org/jira/browse/LANG-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16560394#comment-16560394
]
ASF GitHub Bot commented on LANG-1405:
--
Github user coveralls commented on the issue:
https://github.com/apache/commons-lang/pull/338
[](https://coveralls.io/builds/18205077)
Coverage decreased (-0.04%) to 95.244% when pulling
**7d5a3984a893b3dd91a68cbe70211e2e58a6ff74 on larsgrefer:simplify-classUtils**
into **2cc524380830ba76a9a7e60e37d726e2aaf743a9 on apache:master**.
> Remove checks for java versions below the minimum supported one
> ---
>
> Key: LANG-1405
> URL: https://issues.apache.org/jira/browse/LANG-1405
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.5, 3.6, 3.7
>Reporter: Lars Grefer
>Priority: Minor
> Fix For: 3.8
>
>
> The minimum java version for 3.x is java 1.7, so checks like
> {{SystemUtils.isJavaVersionAtLeast(JavaVersion.JAVA_1_5)}} will always be
> true and are therefore redundant
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] commons-lang issue #338: LANG-1405 Remove check for Java 1.5
Github user coveralls commented on the issue: https://github.com/apache/commons-lang/pull/338 [](https://coveralls.io/builds/18205077) Coverage decreased (-0.04%) to 95.244% when pulling **7d5a3984a893b3dd91a68cbe70211e2e58a6ff74 on larsgrefer:simplify-classUtils** into **2cc524380830ba76a9a7e60e37d726e2aaf743a9 on apache:master**. ---
[jira] [Commented] (LANG-1405) Remove checks for java versions below the minimum supported one
[
https://issues.apache.org/jira/browse/LANG-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16560388#comment-16560388
]
Lars Grefer commented on LANG-1405:
---
Just have a look at my PR on github. The change is pretty small and doesn't
change any method signatures.
> Remove checks for java versions below the minimum supported one
> ---
>
> Key: LANG-1405
> URL: https://issues.apache.org/jira/browse/LANG-1405
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.5, 3.6, 3.7
>Reporter: Lars Grefer
>Priority: Minor
> Fix For: 3.8
>
>
> The minimum java version for 3.x is java 1.7, so checks like
> {{SystemUtils.isJavaVersionAtLeast(JavaVersion.JAVA_1_5)}} will always be
> true and are therefore redundant
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LANG-1405) Remove checks for java versions below the minimum supported one
[
https://issues.apache.org/jira/browse/LANG-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16560383#comment-16560383
]
ASF GitHub Bot commented on LANG-1405:
--
GitHub user larsgrefer opened a pull request:
https://github.com/apache/commons-lang/pull/338
LANG-1405 Remove check for Java 1.5
Since the minimum Java version for commons-lang 3.x is 1.7, the check for
Java 1.5 will always be true
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/larsgrefer/commons-lang simplify-classUtils
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/commons-lang/pull/338.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 #338
commit 7d5a3984a893b3dd91a68cbe70211e2e58a6ff74
Author: Lars Grefer
Date: 2018-07-27T21:36:23Z
LANG-1405 Remove check for Java 1.5
Since the minimum Java version for commons-lang 3.x is 1.7, the check for
Java 1.5 will always be true
> Remove checks for java versions below the minimum supported one
> ---
>
> Key: LANG-1405
> URL: https://issues.apache.org/jira/browse/LANG-1405
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.5, 3.6, 3.7
>Reporter: Lars Grefer
>Priority: Minor
> Fix For: 3.8
>
>
> The minimum java version for 3.x is java 1.7, so checks like
> {{SystemUtils.isJavaVersionAtLeast(JavaVersion.JAVA_1_5)}} will always be
> true and are therefore redundant
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] commons-lang pull request #338: LANG-1405 Remove check for Java 1.5
GitHub user larsgrefer opened a pull request: https://github.com/apache/commons-lang/pull/338 LANG-1405 Remove check for Java 1.5 Since the minimum Java version for commons-lang 3.x is 1.7, the check for Java 1.5 will always be true You can merge this pull request into a Git repository by running: $ git pull https://github.com/larsgrefer/commons-lang simplify-classUtils Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-lang/pull/338.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 #338 commit 7d5a3984a893b3dd91a68cbe70211e2e58a6ff74 Author: Lars Grefer Date: 2018-07-27T21:36:23Z LANG-1405 Remove check for Java 1.5 Since the minimum Java version for commons-lang 3.x is 1.7, the check for Java 1.5 will always be true ---
[jira] [Commented] (LANG-1405) Remove checks for java versions below the minimum supported one
[
https://issues.apache.org/jira/browse/LANG-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16560379#comment-16560379
]
Sebb commented on LANG-1405:
This will break binary and source compatibility.
> Remove checks for java versions below the minimum supported one
> ---
>
> Key: LANG-1405
> URL: https://issues.apache.org/jira/browse/LANG-1405
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.5, 3.6, 3.7
>Reporter: Lars Grefer
>Priority: Minor
> Fix For: 3.8
>
>
> The minimum java version for 3.x is java 1.7, so checks like
> {{SystemUtils.isJavaVersionAtLeast(JavaVersion.JAVA_1_5)}} will always be
> true and are therefore redundant
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (LANG-1405) Remove checks for java versions below the minimum supported one
Lars Grefer created LANG-1405:
-
Summary: Remove checks for java versions below the minimum
supported one
Key: LANG-1405
URL: https://issues.apache.org/jira/browse/LANG-1405
Project: Commons Lang
Issue Type: Improvement
Components: lang.*
Affects Versions: 3.7, 3.6, 3.5
Reporter: Lars Grefer
Fix For: 3.8
The minimum java version for 3.x is java 1.7, so checks like
{{SystemUtils.isJavaVersionAtLeast(JavaVersion.JAVA_1_5)}} will always be true
and are therefore redundant
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IO-582) ObservableInputStream.Observer are package-private
[ https://issues.apache.org/jira/browse/IO-582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16560324#comment-16560324 ] Sebb commented on IO-582: - Oops, my bad, overlooked that. However, I wonder whether it makes sense to have to override the nested Observer class in order to use the ObservableInputStream. Seems a bit messy. Would it not be better to use an interface instead? That aspect of the design can be changed now without breaking compatibility. Once the methods are made protected they become part of the API. > ObservableInputStream.Observer are package-private > -- > > Key: IO-582 > URL: https://issues.apache.org/jira/browse/IO-582 > Project: Commons IO > Issue Type: Bug > Components: Streams/Writers >Affects Versions: 2.6 >Reporter: Bruno Palos >Assignee: Jochen Wiedmann >Priority: Minor > Fix For: 2.7 > > > Hi, > According with the documentation of `ObservableInputStream` and > `ObservableInputStream.Observer`, it should be possible to use those classes > as part of the `commons-io` utilities. However, > `ObservableInputStream.Observer`'s methods are package private and can't be > extended outside the project's source code. > My suggestion is to make `ObservableInputStream.Observer`'s methods protected. > I'm happy to open a PR for this. > Thank you > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (RNG-50) PoissonSampler single use speed improvements
[
https://issues.apache.org/jira/browse/RNG-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16560319#comment-16560319
]
Alex D Herbert commented on RNG-50:
---
{quote}Would it be good enough for your use-case?{quote}
Yes. That is what I mocked up in the simple test attached to this ticket. The
effect is that repeated single use of the {{PoissonSampler}} is very close to
re-use with the same sampler.
Off topic: Where would be a good place to provide feedback on the library? For
example there is no way to programatically obtain the information that is in
the Javadoc of {{org.apache.commons.rng.simple.RandomSource}}. This could be
done with e.g:
{code:java}
public enum RandomSource {
/**
* Source of randomness is {@link
org.apache.commons.rng.core.source32.JDKRandom}.
*
* Native seed type: {@code Long}.
* Native seed size: 1.
*
*/
JDK(ProviderBuilder.RandomSourceInternal.JDK) {
public int getSeedSize() { return 1; },
},
// etc ...
;
public Class getSeedType() { getInternalIdentifier().getSeed(); }
public abstract int getSeedSize();
}
{code}
There is obviously some overlap with the
{{ProviderBuilder.RandomSourceInternal}} and it would be good to at least
expose the arguments required for
{code:java}
public static RestorableUniformRandomProvider create(RandomSource source,
Object seed,
Object ... data)
{code}
I am only asking as I am creating a seed for the {{Well19937c}} class that I
can use to create it repeatedly with little cost. If I know the seed length
then I can store the seed and use it for the constructor. I can then change the
type of RNG dynamically and appropriately store the correct seed. At the moment
I would have to create a function to return the seed size and type for each RNG
I want to support using the information in the Javadocs.
As far as I can see the use of the {{RestorableUniformRandomProvider}} requires
that you first construct a provider (so paying the seeding cost) and then you
can restore it to a previous state. So the initialisation with the constructor
seed is a waste. It would be nice to have a constructor or factory method that
accepts a {{RandomProviderState}} instead.
I am sure as a I get more familiar with the library I'd like to give more
feedback so is this the best place for that (i.e. new feature request tickets)?
> PoissonSampler single use speed improvements
>
>
> Key: RNG-50
> URL: https://issues.apache.org/jira/browse/RNG-50
> Project: Commons RNG
> Issue Type: Improvement
>Affects Versions: 1.0
>Reporter: Alex D Herbert
>Priority: Minor
> Attachments: PoissonSamplerTest.java
>
>
> The Sampler architecture of {{org.apache.commons.rng.sampling.distribution}}
> is nicely written for fast sampling of small dataset sizes. The constructors
> for the samplers do not check the input parameters are valid for the
> respective distributions (in contrast to the old
> {{org.apache.commons.math3.random.distribution}} classes). I assume this is a
> design choice for speed. Thus most of the samplers can be used within a loop
> to sample just one value with very little overhead.
> The {{PoissonSampler}} precomputes log factorial numbers upon construction if
> the mean is above 40. This is done using the {{InternalUtils.FactorialLog}}
> class. As of version 1.0 this internal class is currently only used in the
> {{PoissonSampler}}.
> The cache size is limited to 2*PIVOT (where PIVOT=40). But it creates and
> precomputes the cache every time a PoissonSampler is constructed if the mean
> is above the PIVOT value.
> Why not create this once in a static block for the PoissonSampler?
> {code:java}
> /** {@code log(n!)}. */
> private static final FactorialLog factorialLog;
>
> static
> {
> factorialLog = FactorialLog.create().withCache((int) (2 *
> PoissonSampler.PIVOT));
> }
> {code}
> This will make the construction cost of a new {{PoissonSampler}} negligible.
> If the table is computed dynamically as a static construction method then the
> overhead will be in the first use. Thus the following call will be much
> faster:
> {code:java}
> UniformRandomProvider rng = ...;
> int value = new PoissonSampler(rng, 50).sample();
> {code}
> I have tested this modification (see attached file) and the results are:
> {noformat}
> Mean 40 Single construction ( 7330792) vs Loop construction
> (24334724) (3.319522.2x faster)
> Mean 40 Single construction ( 7330792) vs Loop construction with static
> FactorialLog ( 7990656) (1.090013.2x faster)
> Mean 50 Single construction ( 6390303) vs Loop construction
[jira] [Commented] (BCEL-304) ClassPath.getClassFile does not work with Java 9 and higher
[
https://issues.apache.org/jira/browse/BCEL-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16560235#comment-16560235
]
ASF GitHub Bot commented on BCEL-304:
-
GitHub user epavlak opened a pull request:
https://github.com/apache/commons-bcel/pull/22
[BCEL-304] Include Java 9+ modules in path used by ClassPath.java
With the restructuring of Java .class files in Java 9 and higher to be in
modules instead of the rt.jar, the ClassPath.getClassFile method would fail to
find Java class files (ex: String.class). These modifications include the Java
9+ modules in the path used by ClassPath.java so that the .class files can be
located.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/epavlak/commons-bcel BCEL-304
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/commons-bcel/pull/22.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 #22
commit e331171f168ab335b9756294406e85d9995731bd
Author: epavlak
Date: 2018-07-27T19:50:30Z
[BCEL-304] Include Java 9+ modules in path used by ClassPath.java
commit 98157fb61a547d8d4fe40826d1f863a1c1f1c374
Author: epavlak
Date: 2018-07-27T19:53:58Z
[BCEL-304] Include Java 9+ modules in path used by ClassPath.java
commit d5a73b6987eb262d90f809e3a2b77845fcce95d2
Author: epavlak
Date: 2018-07-27T19:56:57Z
[BCEL-304] Include Java 9+ modules in path used by ClassPath.java
> ClassPath.getClassFile does not work with Java 9 and higher
> ---
>
> Key: BCEL-304
> URL: https://issues.apache.org/jira/browse/BCEL-304
> Project: Commons BCEL
> Issue Type: Bug
> Components: Main
>Affects Versions: 6.2
>Reporter: Ed Pavlak
>Priority: Major
>
> When trying to get the class file for Java classes (ie. java.lang.String), an
> IOException is thrown:
> Exception in thread "main" java.io.IOException: Couldn't find:
> java.lang.String.class
> at org.apache.bcel.util.ClassPath.getClassFile(ClassPath.java:279)
> at org.apache.bcel.util.ClassPath.getClassFile(ClassPath.java:301)
> at bcel.test.GetClassFileTest.main(GetClassFileTest.java:12)
>
> The root cause appears to be the restructuring of Java starting with Java 9.
> Specifically, the removal of the rt.jar. The above excpetion can be
> reproduced using a simple application:
> package bcel.test;
> import java.io.IOException;
> import org.apache.bcel.util.ClassPath;
> public class GetClassFileTest {
> public static void main(String[] args) throws IOException {
> String className = "java.lang.String";
> System.out.println("Looking up ClassPath.ClassFile for: " + className);
> ClassPath.ClassFile classFile =
> ClassPath.SYSTEM_CLASS_PATH.getClassFile(className);
> if (classFile != null) {
> System.out.println("Class file base: " + classFile.getBase());
> System.out.println("Class file path: " + classFile.getPath());
> }
> }
> }
>
> Running this on Java 8 produces the following output, whereas running it on
> Java 9+ produces the IOException:
> Class file base: C:\jdk1.8.0_161\jre\lib\rt.jar
> Class file path: java/lang/String.class
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (BCEL-304) ClassPath.getClassFile does not work with Java 9 and higher
[
https://issues.apache.org/jira/browse/BCEL-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16560239#comment-16560239
]
Ed Pavlak commented on BCEL-304:
I have created a PR. This is my first time doing so. If I have done anything
incorrectly, please let me know.
> ClassPath.getClassFile does not work with Java 9 and higher
> ---
>
> Key: BCEL-304
> URL: https://issues.apache.org/jira/browse/BCEL-304
> Project: Commons BCEL
> Issue Type: Bug
> Components: Main
>Affects Versions: 6.2
>Reporter: Ed Pavlak
>Priority: Major
>
> When trying to get the class file for Java classes (ie. java.lang.String), an
> IOException is thrown:
> Exception in thread "main" java.io.IOException: Couldn't find:
> java.lang.String.class
> at org.apache.bcel.util.ClassPath.getClassFile(ClassPath.java:279)
> at org.apache.bcel.util.ClassPath.getClassFile(ClassPath.java:301)
> at bcel.test.GetClassFileTest.main(GetClassFileTest.java:12)
>
> The root cause appears to be the restructuring of Java starting with Java 9.
> Specifically, the removal of the rt.jar. The above excpetion can be
> reproduced using a simple application:
> package bcel.test;
> import java.io.IOException;
> import org.apache.bcel.util.ClassPath;
> public class GetClassFileTest {
> public static void main(String[] args) throws IOException {
> String className = "java.lang.String";
> System.out.println("Looking up ClassPath.ClassFile for: " + className);
> ClassPath.ClassFile classFile =
> ClassPath.SYSTEM_CLASS_PATH.getClassFile(className);
> if (classFile != null) {
> System.out.println("Class file base: " + classFile.getBase());
> System.out.println("Class file path: " + classFile.getPath());
> }
> }
> }
>
> Running this on Java 8 produces the following output, whereas running it on
> Java 9+ produces the IOException:
> Class file base: C:\jdk1.8.0_161\jre\lib\rt.jar
> Class file path: java/lang/String.class
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (LANG-1401) Typo in JavaDoc for lastIndexOf
[
https://issues.apache.org/jira/browse/LANG-1401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pascal Schumacher resolved LANG-1401.
-
Resolution: Fixed
Assignee: Pascal Schumacher
Fix Version/s: 3.8
Thanks for reporting!
> Typo in JavaDoc for lastIndexOf
> ---
>
> Key: LANG-1401
> URL: https://issues.apache.org/jira/browse/LANG-1401
> Project: Commons Lang
> Issue Type: Bug
>Reporter: Alex Mamedov
>Assignee: Pascal Schumacher
>Priority: Minor
> Fix For: 3.8
>
>
> Typo in Java doc for lastIndexOf.
> You could check on following page:
> [https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/StringUtils.html#lastIndexOf-java.lang.CharSequence-java.lang.CharSequence-int-]
> In example of execution two last row have same arguments but result differ:
> StringUtils.lastIndexOf("aabaabaa", "ba", 2) = -1
> StringUtils.lastIndexOf("aabaabaa", "ba", 2) = 2
>
> Thanks
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (RNG-50) PoissonSampler single use speed improvements
[
https://issues.apache.org/jira/browse/RNG-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16560033#comment-16560033
]
Gilles commented on RNG-50:
---
bq. I still think that the simple solution of a one time cache construction
inside PoissonSampler is the best option
That's certainly the least intrusive.
Would it be good enough for your use-case?
> PoissonSampler single use speed improvements
>
>
> Key: RNG-50
> URL: https://issues.apache.org/jira/browse/RNG-50
> Project: Commons RNG
> Issue Type: Improvement
>Affects Versions: 1.0
>Reporter: Alex D Herbert
>Priority: Minor
> Attachments: PoissonSamplerTest.java
>
>
> The Sampler architecture of {{org.apache.commons.rng.sampling.distribution}}
> is nicely written for fast sampling of small dataset sizes. The constructors
> for the samplers do not check the input parameters are valid for the
> respective distributions (in contrast to the old
> {{org.apache.commons.math3.random.distribution}} classes). I assume this is a
> design choice for speed. Thus most of the samplers can be used within a loop
> to sample just one value with very little overhead.
> The {{PoissonSampler}} precomputes log factorial numbers upon construction if
> the mean is above 40. This is done using the {{InternalUtils.FactorialLog}}
> class. As of version 1.0 this internal class is currently only used in the
> {{PoissonSampler}}.
> The cache size is limited to 2*PIVOT (where PIVOT=40). But it creates and
> precomputes the cache every time a PoissonSampler is constructed if the mean
> is above the PIVOT value.
> Why not create this once in a static block for the PoissonSampler?
> {code:java}
> /** {@code log(n!)}. */
> private static final FactorialLog factorialLog;
>
> static
> {
> factorialLog = FactorialLog.create().withCache((int) (2 *
> PoissonSampler.PIVOT));
> }
> {code}
> This will make the construction cost of a new {{PoissonSampler}} negligible.
> If the table is computed dynamically as a static construction method then the
> overhead will be in the first use. Thus the following call will be much
> faster:
> {code:java}
> UniformRandomProvider rng = ...;
> int value = new PoissonSampler(rng, 50).sample();
> {code}
> I have tested this modification (see attached file) and the results are:
> {noformat}
> Mean 40 Single construction ( 7330792) vs Loop construction
> (24334724) (3.319522.2x faster)
> Mean 40 Single construction ( 7330792) vs Loop construction with static
> FactorialLog ( 7990656) (1.090013.2x faster)
> Mean 50 Single construction ( 6390303) vs Loop construction
> (19389026) (3.034132.2x faster)
> Mean 50 Single construction ( 6390303) vs Loop construction with static
> FactorialLog ( 6146556) (0.961857.2x faster)
> Mean 60 Single construction ( 6041165) vs Loop construction
> (21337678) (3.532047.2x faster)
> Mean 60 Single construction ( 6041165) vs Loop construction with static
> FactorialLog ( 5329129) (0.882136.2x faster)
> Mean 70 Single construction ( 6064003) vs Loop construction
> (23963516) (3.951765.2x faster)
> Mean 70 Single construction ( 6064003) vs Loop construction with static
> FactorialLog ( 5306081) (0.875013.2x faster)
> Mean 80 Single construction ( 6064772) vs Loop construction
> (26381365) (4.349935.2x faster)
> Mean 80 Single construction ( 6064772) vs Loop construction with static
> FactorialLog ( 6341274) (1.045591.2x faster)
> {noformat}
> Thus the speed improvements would be approximately 3-4 fold for single use
> Poisson sampling.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (COMMONSSITE-118) Create a Maven BOM containing all Commons dependencies
Dylan Piergies created COMMONSSITE-118: -- Summary: Create a Maven BOM containing all Commons dependencies Key: COMMONSSITE-118 URL: https://issues.apache.org/jira/browse/COMMONSSITE-118 Project: Commons All Issue Type: New Feature Components: Commons Build Reporter: Dylan Piergies It would be really useful if there were a Maven BOM that could be imported to set up dependency management for the latest versions of all of the commons libraries. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (COLLECTIONS-692) Replace use of deprecated Class#newInstance() #49
[
https://issues.apache.org/jira/browse/COLLECTIONS-692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed COLLECTIONS-692.
Resolution: Fixed
Fix Version/s: 4.3
In git master.
> Replace use of deprecated Class#newInstance() #49
> -
>
> Key: COLLECTIONS-692
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-692
> Project: Commons Collections
> Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 4.3
>
>
> Java 9 deprecates [SetUniqueList] Class#newInstance().
> Fix two call sites:
> -
> {{org.apache.commons.collections4.map.MultiValueMap.ReflectionFactory.create()}}
> -
> {{org.apache.commons.collections4.list.SetUniqueList.createSetBasedOnList(Set,
> List)}}
> The patch https://github.com/apache/commons-collections/pull/49 is incomplete
> and incorrect:
> - Fix to
> {{org.apache.commons.collections4.map.MultiValueMap.ReflectionFactory.create()}}
> is missing
> - Patch to
> {{org.apache.commons.collections4.list.SetUniqueList.createSetBasedOnList(Set,
> List)}} performs extra work by adding the initial values to the new set
> twice.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (COLLECTIONS-692) Replace use of deprecated Class#newInstance() #49
Gary Gregory created COLLECTIONS-692:
Summary: Replace use of deprecated Class#newInstance() #49
Key: COLLECTIONS-692
URL: https://issues.apache.org/jira/browse/COLLECTIONS-692
Project: Commons Collections
Issue Type: New Feature
Reporter: Gary Gregory
Assignee: Gary Gregory
Java 9 deprecates [SetUniqueList] Class#newInstance().
Fix two call sites:
-
{{org.apache.commons.collections4.map.MultiValueMap.ReflectionFactory.create()}}
-
{{org.apache.commons.collections4.list.SetUniqueList.createSetBasedOnList(Set,
List)}}
The patch https://github.com/apache/commons-collections/pull/49 is incomplete
and incorrect:
- Fix to
{{org.apache.commons.collections4.map.MultiValueMap.ReflectionFactory.create()}}
is missing
- Patch to
{{org.apache.commons.collections4.list.SetUniqueList.createSetBasedOnList(Set,
List)}} performs extra work by adding the initial values to the new set
twice.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IO-582) ObservableInputStream.Observer are package-private
[ https://issues.apache.org/jira/browse/IO-582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16559794#comment-16559794 ] Bruno Palos commented on IO-582: Thank you! > ObservableInputStream.Observer are package-private > -- > > Key: IO-582 > URL: https://issues.apache.org/jira/browse/IO-582 > Project: Commons IO > Issue Type: Bug > Components: Streams/Writers >Affects Versions: 2.6 >Reporter: Bruno Palos >Assignee: Jochen Wiedmann >Priority: Minor > Fix For: 2.7 > > > Hi, > According with the documentation of `ObservableInputStream` and > `ObservableInputStream.Observer`, it should be possible to use those classes > as part of the `commons-io` utilities. However, > `ObservableInputStream.Observer`'s methods are package private and can't be > extended outside the project's source code. > My suggestion is to make `ObservableInputStream.Observer`'s methods protected. > I'm happy to open a PR for this. > Thank you > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (IO-582) ObservableInputStream.Observer are package-private
[ https://issues.apache.org/jira/browse/IO-582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann reopened IO-582: Assignee: Jochen Wiedmann I disagree, sebb, because the MessageCalculatingInputStream is in the same package, thus can easily use package-private methods. > ObservableInputStream.Observer are package-private > -- > > Key: IO-582 > URL: https://issues.apache.org/jira/browse/IO-582 > Project: Commons IO > Issue Type: Bug > Components: Streams/Writers >Affects Versions: 2.6 >Reporter: Bruno Palos >Assignee: Jochen Wiedmann >Priority: Minor > Fix For: 2.7 > > > Hi, > According with the documentation of `ObservableInputStream` and > `ObservableInputStream.Observer`, it should be possible to use those classes > as part of the `commons-io` utilities. However, > `ObservableInputStream.Observer`'s methods are package private and can't be > extended outside the project's source code. > My suggestion is to make `ObservableInputStream.Observer`'s methods protected. > I'm happy to open a PR for this. > Thank you > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IO-582) ObservableInputStream.Observer are package-private
[ https://issues.apache.org/jira/browse/IO-582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann resolved IO-582. Resolution: Fixed Fix Version/s: 2.7 Fixed, will be in 2.7, whenever that comes. > ObservableInputStream.Observer are package-private > -- > > Key: IO-582 > URL: https://issues.apache.org/jira/browse/IO-582 > Project: Commons IO > Issue Type: Bug > Components: Streams/Writers >Affects Versions: 2.6 >Reporter: Bruno Palos >Assignee: Jochen Wiedmann >Priority: Minor > Fix For: 2.7 > > > Hi, > According with the documentation of `ObservableInputStream` and > `ObservableInputStream.Observer`, it should be possible to use those classes > as part of the `commons-io` utilities. However, > `ObservableInputStream.Observer`'s methods are package private and can't be > extended outside the project's source code. > My suggestion is to make `ObservableInputStream.Observer`'s methods protected. > I'm happy to open a PR for this. > Thank you > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (RNG-50) PoissonSampler single use speed improvements
[
https://issues.apache.org/jira/browse/RNG-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16559674#comment-16559674
]
Alex D Herbert commented on RNG-50:
---
{quote}I'd be inclined to introduce sanity checks. Do you think that it would
make such a big difference?{quote}
The sanity checks are likely to be small compared to the cost of even one
random sample. I just mentioned it as I thought it could have been a design
choice.
I agree that passing a null RNG into the method is wrong. You'll get a null
pointer exception on first use. I'm generally happy with that. I'll leave it to
you to decide based on the rest of your framework. If you do not check it then
you could document the fact.
{quote}I don't quite understand why "each pixel value is likely to be unique"
entails that the sampler is to be thrown away after a single call to the
sample() method. Is the mean different for each pixel and frame?{quote}
Yes, the mean is different for each pixel. Imagine a perfect image of anything
in the real world. The pixel values are all likely to be different.
{quote}I'm no multi-thread expert but I suspect that your code does not
synchronize consistently: Couldn't
{code:java}
getLogF(n)
{code}
read the table before a new value has been written to slot "n", thus returning
0?{quote}
The idea is that the table is only ever modified inside a synchronised block
using the same locking object. I've rewritten it to use a
{{java.util.concurrent.locks.ReadWriteLock}} to guard access instead with
better documentation of what is happening.
I've also used {{volatile}} to ensure threads have the same value of the table.
This code is an example I put together for functions that use a range of
{{log(n!)}} values. The range is likely to be between 0 and 65535 (the range of
an unsigned 16-bit image). However not all the range is required at any one
time so pre-computing up to 65535 is an overhead I removed by adding the
{{ensureRange(int,int)}} function.
There are several caveats when using the class that I hope to have now
documented. The design is not sensible outside of my own use case where the
range is known and the function is used across many classes. For more general
use then perhaps the safest is back to allowing only immutable instances to be
created, perhaps with a static internal cache of a limited size that can be
reused when creating instances.
{quote}A new class should provide a sample(double mean) method (It would not
fit the DiscreteSampler API).{quote}
I'd be OK with that. I use custom version of Commons Math
{org.apache.commons.math3.random.distribution} classes that do just that at the
moment anyway. They've just been modified to allow the constructor arguments to
be set as properties.
{quote}Wouldn't it be sufficient to define a constructor where the
(precomputed, immutable) cache is passed as an argument?{quote}
That would also be a solution. But then you have to expose the cache API.
Perhaps use the {{with}} pattern to add a method such as
{code:java}
public PoissonSampler with(double mean)
{
return new PoissonSampler(this.getUniformRandomProvider(), mean,
this.factorialLog);
}
{code}
But then the {{SamplerBase#rng}} is private so this needs to be exposed. And
currently there is no method to duplicate it so it would be a reference to the
same object.
I still think that the simple solution of a one time cache construction inside
{{PoissonSampler}} is the best option:
{code:java}
/** {@code log(n!)}. */
private static final FactorialLog factorialLog;
static
{
factorialLog = FactorialLog.create().withCache((int) (2 *
PoissonSampler.PIVOT));
}
{code}
> PoissonSampler single use speed improvements
>
>
> Key: RNG-50
> URL: https://issues.apache.org/jira/browse/RNG-50
> Project: Commons RNG
> Issue Type: Improvement
>Affects Versions: 1.0
>Reporter: Alex D Herbert
>Priority: Minor
> Attachments: PoissonSamplerTest.java
>
>
> The Sampler architecture of {{org.apache.commons.rng.sampling.distribution}}
> is nicely written for fast sampling of small dataset sizes. The constructors
> for the samplers do not check the input parameters are valid for the
> respective distributions (in contrast to the old
> {{org.apache.commons.math3.random.distribution}} classes). I assume this is a
> design choice for speed. Thus most of the samplers can be used within a loop
> to sample just one value with very little overhead.
> The {{PoissonSampler}} precomputes log factorial numbers upon construction if
> the mean is above 40. This is done using the {{InternalUtils.FactorialLog}}
> class. As of version 1.0 this internal class is currently only used in the
> {{PoissonSampler}}.
> The cache size is limited to 2*PIVOT (where PIVOT=40). But it creates and
> precomputes
[jira] [Commented] (IO-582) ObservableInputStream.Observer are package-private
[ https://issues.apache.org/jira/browse/IO-582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16559554#comment-16559554 ] Sebb commented on IO-582: - No need; you can extend Observer with your own class and pass that to ObservableInputStream#add(Observer) See for example MessageDigestCalculatingInputStream.MessageDigestMaintainingObserver > ObservableInputStream.Observer are package-private > -- > > Key: IO-582 > URL: https://issues.apache.org/jira/browse/IO-582 > Project: Commons IO > Issue Type: Bug > Components: Streams/Writers >Affects Versions: 2.6 >Reporter: Bruno Palos >Priority: Minor > > Hi, > According with the documentation of `ObservableInputStream` and > `ObservableInputStream.Observer`, it should be possible to use those classes > as part of the `commons-io` utilities. However, > `ObservableInputStream.Observer`'s methods are package private and can't be > extended outside the project's source code. > My suggestion is to make `ObservableInputStream.Observer`'s methods protected. > I'm happy to open a PR for this. > Thank you > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IO-582) ObservableInputStream.Observer are package-private
[ https://issues.apache.org/jira/browse/IO-582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved IO-582. - Resolution: Information Provided > ObservableInputStream.Observer are package-private > -- > > Key: IO-582 > URL: https://issues.apache.org/jira/browse/IO-582 > Project: Commons IO > Issue Type: Bug > Components: Streams/Writers >Affects Versions: 2.6 >Reporter: Bruno Palos >Priority: Minor > > Hi, > According with the documentation of `ObservableInputStream` and > `ObservableInputStream.Observer`, it should be possible to use those classes > as part of the `commons-io` utilities. However, > `ObservableInputStream.Observer`'s methods are package private and can't be > extended outside the project's source code. > My suggestion is to make `ObservableInputStream.Observer`'s methods protected. > I'm happy to open a PR for this. > Thank you > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (RNG-50) PoissonSampler single use speed improvements
[
https://issues.apache.org/jira/browse/RNG-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16559070#comment-16559070
]
Gilles edited comment on RNG-50 at 7/27/18 10:37 AM:
-
{quote}It doesn't check the RNG is not null.
{quote}
Passing {{null}} is a programming error, and the check is going to be performed
by the JVM; since the call is quite low-level, the NPE will be thrown fairly
close to the error; so indeed no need (IMHO) to duplicate such checks.
{quote}AhrensDieterMarsagliaTsangGammaSampler where the constructors params are
not checked.
{quote}
Oh. That was not intentional; I'd be inclined to introduce sanity checks. ;)
Do you think that it would make such a big difference?
{quote}use case of the Poisson sampling is to model photon shot noise on a
camera image, e.g 512x512 is 262,144 pixels. Each pixel value is likely to be
unique during a simulation that creates floating-point images.
{quote}
Interesting!
I don't quite understand why "each pixel value is likely to be unique" entails
that the sampler is to be thrown away after a single call to the {{sample()}}
method. Is the {{mean}} different for each pixel and frame?
I'm asking because if there is no other way than instantiating an sampler for
a single sample, the API is not good for that: there is more overhead than the
factorial cache (instantiation of 2 other objects). A new class should provide
a {{sample(double mean)}} method (It would not fit the {{DiscreteSampler}} API).
{quote}This is a sub-optimal cache.
{quote}
I know; it was under the assumption that the number of calls to {{sample()}},
with all its non-trivial computations, would generally overwhelm the running
time.
{quote}Subsequent uses would not suffer.
{quote}
Sure, I agree. But the concern was to avoid multi-thread complication.
{quote}A better solution [...] LogFactorial [...]
{quote}
Using {{synchronized}} has a performance impact.
I'm no multi-thread expert but I suspect that your code does not synchronize
consistently: Couldn't
{code:java}
getLogF(n){code}
read the table before a new value has been written to slot "n", thus returning
0?
{quote}The master table can be increased in size and reduced.
{quote}
When would one want to reduce it?
{quote}If the FactorialLog class is modified then when it is used by other
samplers then they can take advantage of any already computed values.
{quote}
Sure. But is the performance gain worth the added complexity? And how much is
that gain? Aren't there cases where there is a loss in performance due to the
synchronization?
Wouldn't it be sufficient to define a constructor where the (precomputed,
immutable) cache is passed as an argument?
was (Author: erans):
{quote}It doesn't check the RNG is not null.
{quote}
Passing {{null }}is a programming error, and the check is going to be performed
by the JVM; since the call is quite low-level, the NPE will be thrown fairly
close to the error; so indeed no need (IMHO) to duplicate such checks.
{quote}AhrensDieterMarsagliaTsangGammaSampler where the constructors params are
not checked.
{quote}
Oh. That was not intentional; I'd be inclined to introduce sanity checks. ;)
Do you think that it would make such a big difference?
{quote}use case of the Poisson sampling is to model photon shot noise on a
camera image, e.g 512x512 is 262,144 pixels. Each pixel value is likely to be
unique during a simulation that creates floating-point images.
{quote}
Interesting!
I don't quite understand why "each pixel value is likely to be unique" entails
that the sampler is to be thrown away after a single call to the {{sample()}}
method. Is the {{mean}} different for each pixel and frame?
I'm asking because if there is no other way than instantiating an sampler for
a single sample, the API is not good for that: there is more overhead than the
factorial cache (instantiation of 2 other objects). A new class should provide
a {{sample(double mean)}} method (It would not fit the {{DiscreteSampler}} API).
{quote}This is a sub-optimal cache.
{quote}
I know; it was under the assumption that the number of calls to {{sample()}},
with all its non-trivial computations, would generally overwhelm the running
time.
{quote}Subsequent uses would not suffer.
{quote}
Sure, I agree. But the concern was to avoid multi-thread complication.
{quote}A better solution [...] LogFactorial [...]
{quote}
Using {{synchronized}} has a performance impact.
I'm no multi-thread expert but I suspect that your code does not synchronize
consistently: Couldn't
{code:java}
getLogF(n){code}
read the table before a new value has been written to slot "n", thus returning
0?
{quote}The master table can be increased in size and reduced.
{quote}
When would one want to reduce it?
{quote}If the FactorialLog class is modified then when it is used by other
samplers then they can take advantage of any already computed values.
{quote}
Sure. But
[jira] [Comment Edited] (RNG-50) PoissonSampler single use speed improvements
[
https://issues.apache.org/jira/browse/RNG-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16559070#comment-16559070
]
Gilles edited comment on RNG-50 at 7/27/18 10:36 AM:
-
{quote}It doesn't check the RNG is not null.
{quote}
Passing {{null }}is a programming error, and the check is going to be performed
by the JVM; since the call is quite low-level, the NPE will be thrown fairly
close to the error; so indeed no need (IMHO) to duplicate such checks.
{quote}AhrensDieterMarsagliaTsangGammaSampler where the constructors params are
not checked.
{quote}
Oh. That was not intentional; I'd be inclined to introduce sanity checks. ;)
Do you think that it would make such a big difference?
{quote}use case of the Poisson sampling is to model photon shot noise on a
camera image, e.g 512x512 is 262,144 pixels. Each pixel value is likely to be
unique during a simulation that creates floating-point images.
{quote}
Interesting!
I don't quite understand why "each pixel value is likely to be unique" entails
that the sampler is to be thrown away after a single call to the {{sample()}}
method. Is the {{mean}} different for each pixel and frame?
I'm asking because if there is no other way than instantiating an sampler for
a single sample, the API is not good for that: there is more overhead than the
factorial cache (instantiation of 2 other objects). A new class should provide
a {{sample(double mean)}} method (It would not fit the {{DiscreteSampler}} API).
{quote}This is a sub-optimal cache.
{quote}
I know; it was under the assumption that the number of calls to {{sample()}},
with all its non-trivial computations, would generally overwhelm the running
time.
{quote}Subsequent uses would not suffer.
{quote}
Sure, I agree. But the concern was to avoid multi-thread complication.
{quote}A better solution [...] LogFactorial [...]
{quote}
Using {{synchronized}} has a performance impact.
I'm no multi-thread expert but I suspect that your code does not synchronize
consistently: Couldn't
{code:java}
getLogF(n){code}
read the table before a new value has been written to slot "n", thus returning
0?
{quote}The master table can be increased in size and reduced.
{quote}
When would one want to reduce it?
{quote}If the FactorialLog class is modified then when it is used by other
samplers then they can take advantage of any already computed values.
{quote}
Sure. But is the performance gain worth the added complexity? And how much is
that gain? Aren't there cases where there is a loss in performance due to the
synchronization?
Wouldn't it be sufficient to define a constructor where the (precomputed,
immutable) cache is passed as an argument?
was (Author: erans):
{quote}It doesn't check the RNG is not null.
{quote}
Passing \{{null} is a programming error, and the check is going to be performed
by the JVM; since the call is quite low-level, the NPE will be thrown fairly
close to the error; so indeed no need (IMHO) to duplicate such checks.
{quote}AhrensDieterMarsagliaTsangGammaSampler where the constructors params are
not checked.
{quote}
Oh. That was not intentional; I'd be inclined to introduce sanity checks. ;)
Do you think that it would make such a big difference?
{quote}use case of the Poisson sampling is to model photon shot noise on a
camera image, e.g 512x512 is 262,144 pixels. Each pixel value is likely to be
unique during a simulation that creates floating-point images.
{quote}
Interesting!
I don't quite understand why "each pixel value is likely to be unique" entails
that the sampler is to be thrown away after a single call to the {{sample()}}
method. Is the {{mean}} different for each pixel and frame?
I'm asking because if there is no other way than instantiating an sampler for
a single sample, the API is not good for that: there is more overhead than the
factorial cache (instantiation of 2 other objects). A new class should provide
a {{sample(double mean)}} method (It would not fit the {{DiscreteSampler}} API).
bq. This is a sub-optimal cache.
I know; it was under the assumption that the number of calls to {{sample()}},
with all its non-trivial computations, would generally overwhelm the running
time.
bq. Subsequent uses would not suffer.
Sure, I agree. But the concern was to avoid multi-thread complication.
bq. A better solution \[...\] LogFactorial \[...\]
Using {{synchronized}} has a performance impact.
I'm no multi-thread expert but I suspect that your code does not synchronize
consistently: Couldn't {code}getLogF(n){code} read the table before a new value
has been written to slot "n", thus returning 0?
bq. The master table can be increased in size and reduced.
When would one want to reduce it?
bq. If the FactorialLog class is modified then when it is used by other
samplers then they can take advantage of any already computed values.
Sure. But is the performance gain worth the added
[jira] [Comment Edited] (RNG-50) PoissonSampler single use speed improvements
[
https://issues.apache.org/jira/browse/RNG-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16559070#comment-16559070
]
Gilles edited comment on RNG-50 at 7/27/18 10:34 AM:
-
{quote}It doesn't check the RNG is not null.
{quote}
Passing \{{null} is a programming error, and the check is going to be performed
by the JVM; since the call is quite low-level, the NPE will be thrown fairly
close to the error; so indeed no need (IMHO) to duplicate such checks.
{quote}AhrensDieterMarsagliaTsangGammaSampler where the constructors params are
not checked.
{quote}
Oh. That was not intentional; I'd be inclined to introduce sanity checks. ;)
Do you think that it would make such a big difference?
{quote}use case of the Poisson sampling is to model photon shot noise on a
camera image, e.g 512x512 is 262,144 pixels. Each pixel value is likely to be
unique during a simulation that creates floating-point images.
{quote}
Interesting!
I don't quite understand why "each pixel value is likely to be unique" entails
that the sampler is to be thrown away after a single call to the {{sample()}}
method. Is the {{mean}} different for each pixel and frame?
I'm asking because if there is no other way than instantiating an sampler for
a single sample, the API is not good for that: there is more overhead than the
factorial cache (instantiation of 2 other objects). A new class should provide
a {{sample(double mean)}} method (It would not fit the {{DiscreteSampler}} API).
bq. This is a sub-optimal cache.
I know; it was under the assumption that the number of calls to {{sample()}},
with all its non-trivial computations, would generally overwhelm the running
time.
bq. Subsequent uses would not suffer.
Sure, I agree. But the concern was to avoid multi-thread complication.
bq. A better solution \[...\] LogFactorial \[...\]
Using {{synchronized}} has a performance impact.
I'm no multi-thread expert but I suspect that your code does not synchronize
consistently: Couldn't {code}getLogF(n){code} read the table before a new value
has been written to slot "n", thus returning 0?
bq. The master table can be increased in size and reduced.
When would one want to reduce it?
bq. If the FactorialLog class is modified then when it is used by other
samplers then they can take advantage of any already computed values.
Sure. But is the performance gain worth the added complexity? And how much is
that gain? Aren't there cases where there is a loss in performance due to the
synchronization?
Wouldn't it be sufficient to define a constructor where the (precomputed,
immutable) cache is passed as an argument?
was (Author: erans):
{quote}It doesn't check the RNG is not null.
{quote}
Passing \{{null} is a programming error, and the check is going to be performed
by the JVM; since the call is quite low-level, the NPE will be thrown fairly
close to the error; so indeed no need (IMHO) to duplicate such checks.
{quote}AhrensDieterMarsagliaTsangGammaSampler where the constructors params are
not checked.
{quote}
Oh. That was not intentional; I'd be inclined to introduce sanity checks. ;)
Do you think that it would make such a big difference?
{quote}use case of the Poisson sampling is to model photon shot noise on a
camera image, e.g 512x512 is 262,144 pixels. Each pixel value is likely to be
unique during a simulation that creates floating-point images.
{quote}
Interesting!
I don't quite understand why "each pixel value is likely to be unique" entails
that the sampler is to be thrown away after a single call to the {{sample()}}
method. Is the {{mean}} different for each pixel and frame?
I'm asking because if there is no other way than instantiating an sampler for
a single sample, the API is not good for that: there is more overhead than the
factorial cache (instantiation of 2 other objects). A new class should provide
a {{sample(double mean)}} method (It would not fit the {{DiscreteSampler}} API).
bq. This is a sub-optimal cache.
I know; it was under the assumption that the number of calls to {{sample()}},
with all its non-trivial computations, would generally overwhelm the running
time.
bq. Subsequent uses would not suffer.
Sure, I agree. But the concern was to avoid multi-thread complication.
bq. A better solution \[...\] LogFactorial \[...\]
Using {{synchronized}} has a performance impact.
I'm no multi-thread expert but I suspect that your code does not synchronize
consistently: Couldn't {{getLogF(n)}} read the table before a new value has
been written to slot "n", thus returning 0?
bq. The master table can be increased in size and reduced.
When would one want to reduce it?
bq. If the FactorialLog class is modified then when it is used by other
samplers then they can take advantage of any already computed values.
Sure. But is the performance gain worth the added complexity? And how much is
that gain? Aren't there cases where
[jira] [Updated] (IO-582) ObservableInputStream.Observer are package-private
[ https://issues.apache.org/jira/browse/IO-582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno Palos updated IO-582: --- Description: Hi, According with the documentation of `ObservableInputStream` and `ObservableInputStream.Observer`, it should be possible to use those classes as part of the `commons-io` utilities. However, `ObservableInputStream.Observer`'s methods are package private and can't be extended outside the project's source code. My suggestion is to make `ObservableInputStream.Observer`'s methods protected. I'm happy to open a PR for this. Thank you was: Hi, According with the documentation of `ObservableInputStream` and `ObservableInputStream.Observer`, it should be possible to use those classes as part of the `commons-io` utilities. However, `ObservableInputStream.Observer`'s methods are package private and can't be extended outside the project's source code. My suggestion is to make `ObservableInputStream.Observer`'s methods public. I'm happy to open a PR for this. Thank you > ObservableInputStream.Observer are package-private > -- > > Key: IO-582 > URL: https://issues.apache.org/jira/browse/IO-582 > Project: Commons IO > Issue Type: Bug > Components: Streams/Writers >Affects Versions: 2.6 >Reporter: Bruno Palos >Priority: Minor > > Hi, > According with the documentation of `ObservableInputStream` and > `ObservableInputStream.Observer`, it should be possible to use those classes > as part of the `commons-io` utilities. However, > `ObservableInputStream.Observer`'s methods are package private and can't be > extended outside the project's source code. > My suggestion is to make `ObservableInputStream.Observer`'s methods protected. > I'm happy to open a PR for this. > Thank you > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IO-582) ObservableInputStream.Observer are package-private
[ https://issues.apache.org/jira/browse/IO-582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno Palos updated IO-582: --- Description: Hi, According with the documentation of `ObservableInputStream` and `ObservableInputStream.Observer`, it should be possible to use those classes as part of the `commons-io` utilities. However, `ObservableInputStream.Observer`'s methods are package private and can't be extended outside the project's source code. My suggestion is to make `ObservableInputStream.Observer`'s methods public. I'm happy to open a PR for this. Thank you was: Hi, According with the documentation of `ObservableInputStream` and `ObservableInputStream.Observer`, it should be possible to use those classes as part of the `commons-io` utilities. However, `ObservableInputStream.Observer`'s methods are package private and can't be used outside the project's source code. My suggestion is to make `ObservableInputStream.Observer` methods public. I'm happy to open a PR for this. Thank you > ObservableInputStream.Observer are package-private > -- > > Key: IO-582 > URL: https://issues.apache.org/jira/browse/IO-582 > Project: Commons IO > Issue Type: Bug > Components: Streams/Writers >Affects Versions: 2.6 >Reporter: Bruno Palos >Priority: Minor > > Hi, > According with the documentation of `ObservableInputStream` and > `ObservableInputStream.Observer`, it should be possible to use those classes > as part of the `commons-io` utilities. However, > `ObservableInputStream.Observer`'s methods are package private and can't be > extended outside the project's source code. > My suggestion is to make `ObservableInputStream.Observer`'s methods public. > I'm happy to open a PR for this. > Thank you > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IO-582) ObservableInputStream.Observer are package-private
Bruno Palos created IO-582: -- Summary: ObservableInputStream.Observer are package-private Key: IO-582 URL: https://issues.apache.org/jira/browse/IO-582 Project: Commons IO Issue Type: Bug Components: Streams/Writers Affects Versions: 2.6 Reporter: Bruno Palos Hi, According with the documentation of `ObservableInputStream` and `ObservableInputStream.Observer`, it should be possible to use those classes as part of the `commons-io` utilities. However, `ObservableInputStream.Observer`'s methods are package private and can't be used outside the project's source code. My suggestion is to make `ObservableInputStream.Observer` methods public. I'm happy to open a PR for this. Thank you -- This message was sent by Atlassian JIRA (v7.6.3#76005)
