[GitHub] [commons-vfs] woonsan commented on issue #52: VFS-686: webdav4 provider based on the latest Jackrabbit 2.x
woonsan commented on issue #52: VFS-686: webdav4 provider based on the latest Jackrabbit 2.x URL: https://github.com/apache/commons-vfs/pull/52#issuecomment-479304944 Hi @garydgregory , Yet not ready status because jackrabbit3 submodule depends on the following (in root pom): > 2.19.2-SNAPSHOT I need to get the release out soon but will take some time. Woonsan This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-vfs] garydgregory commented on issue #52: VFS-686: webdav4 provider based on the latest Jackrabbit 2.x
garydgregory commented on issue #52: VFS-686: webdav4 provider based on the latest Jackrabbit 2.x URL: https://github.com/apache/commons-vfs/pull/52#issuecomment-479299314 Hi @woonsan, What is the status of this PR? Is it still "Not ready for merge"? Gary This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-geometry] darkma773r commented on a change in pull request #31: Geometry 29 2 sven
darkma773r commented on a change in pull request #31: Geometry 29 2 sven
URL: https://github.com/apache/commons-geometry/pull/31#discussion_r271548380
##
File path:
commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/threed/Line.java
##
@@ -236,5 +238,29 @@ public Vector3D intersection(final Line line) {
public SubLine wholeLine() {
return new SubLine(this, new IntervalsSet(precision));
}
+
+
+@Override
+public int hashCode() {
+throw new IllegalStateException("Must not be used in maps.");
Review comment:
We should provide an actual implementation of this method, especially since
`equals()` is overridden.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [commons-vfs] woonsan commented on issue #52: VFS-686: webdav4 provider based on the latest Jackrabbit 2.x
woonsan commented on issue #52: VFS-686: webdav4 provider based on the latest Jackrabbit 2.x URL: https://github.com/apache/commons-vfs/pull/52#issuecomment-479279513 Hi @garydgregory , I think I found the cause. It's all my bad. For some reason -- probably due to my git env setting, some resource files were not committed/pushed. e.g, commons-vfs2-jackrabbit2/src/test/resources/test-data/read-tests/subdir4.jar and its descendants, commons-vfs2-jackrabbit2/src/test/resources/test-data/*.gz, *.jar, *.tar, ... Sorry and thanks for noticing this problem! I'll fix it asap. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-geometry] darkma773r commented on a change in pull request #31: Geometry 29 2 sven
darkma773r commented on a change in pull request #31: Geometry 29 2 sven
URL: https://github.com/apache/commons-geometry/pull/31#discussion_r271548014
##
File path:
commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/threed/Plane.java
##
@@ -16,174 +16,193 @@
*/
package org.apache.commons.geometry.euclidean.threed;
+import java.util.Objects;
+
import org.apache.commons.geometry.core.exception.IllegalNormException;
import org.apache.commons.geometry.core.partitioning.Embedding;
import org.apache.commons.geometry.core.partitioning.Hyperplane;
import org.apache.commons.geometry.core.precision.DoublePrecisionContext;
-import org.apache.commons.geometry.euclidean.internal.Vectors;
import org.apache.commons.geometry.euclidean.oned.Vector1D;
import
org.apache.commons.geometry.euclidean.threed.rotation.QuaternionRotation;
import org.apache.commons.geometry.euclidean.twod.PolygonsSet;
import org.apache.commons.geometry.euclidean.twod.Vector2D;
-/** The class represent planes in a three dimensional space.
+/**
+ * The class represents a plane in a three dimensional space.
*/
-public class Plane implements Hyperplane, Embedding {
-
-/** Offset of the origin with respect to the plane. */
-private double originOffset;
+public final class Plane implements Hyperplane, Embedding {
-/** Origin of the plane frame. */
-private Vector3D origin;
+/** First normalized vector of the plane frame (in plane). */
+private final Vector3D u;
-/** First vector of the plane frame (in plane). */
-private Vector3D u;
+/** Second normalized vector of the plane frame (in plane). */
+private final Vector3D v;
-/** Second vector of the plane frame (in plane). */
-private Vector3D v;
+/** Normalized plane normal. */
+private final Vector3D w;
-/** Third vector of the plane frame (plane normal). */
-private Vector3D w;
+/** Offset of the origin with respect to the plane. */
+private final double originOffset;
+/** orthogonal projection of the 3D-space origin in the plane. */
+private final Vector3D projectedOrigin;
+
/** Precision context used to compare floating point numbers. */
private final DoublePrecisionContext precision;
-/** Build a plane normal to a given direction and containing the origin.
- * @param normal normal direction to the plane
+/**
+ * Constructor to build a new plane with the given values.
+ * Made private to prevent inheritance.
+ * @param u u vector (on plane)
+ * @param v v vector (on plane)
+ * @param w unit normal vector
+ * @param projectedOrigin orthogonal projection of the 3D-space origin in
the plane.
* @param precision precision context used to compare floating point values
- * @exception IllegalArgumentException if the normal norm is too small
+ * @throws IllegalArgumentException if the provided vectors are coplanar
or not normalized
*/
-public Plane(final Vector3D normal, final DoublePrecisionContext precision)
-throws IllegalArgumentException {
-setNormal(normal);
+private Plane(Vector3D u, Vector3D v, Vector3D w, Vector3D
projectedOrigin, double originOffset,
+DoublePrecisionContext precision) {
+this.u = u;
+this.v = v;
+this.w = w;
+
+if (!areVectorsNormalized(u, v, w, precision))
+{
+throw new IllegalArgumentException("Provided vectors must be
normalized.");
+}
+if (Vector3D.areCoplanar(u, v, w, precision))
+{
+throw new IllegalArgumentException("Provided vectors must not be
coplanar.");
+}
+this.projectedOrigin = projectedOrigin;
+this.originOffset = originOffset;
this.precision = precision;
-originOffset = 0;
-setFrame();
}
-
-/** Build a plane from a point and a normal.
- * @param p point belonging to the plane
- * @param normal normal direction to the plane
+
+/**
+ * Build a plane from a point and two (on plane) vectors.
+ * @param p the provided point (on plane)
+ * @param u u vector (on plane)
+ * @param v v vector (on plane)
* @param precision precision context used to compare floating point values
- * @exception IllegalArgumentException if the normal norm is too small
+ * @return a new plane
+ * @throws IllegalNormException if the norm of the given values is zero,
NaN, or infinite.
+ * @throws IllegalArgumentException if the provided vectors are collinear
*/
-public Plane(final Vector3D p, final Vector3D normal, final
DoublePrecisionContext precision)
-throws IllegalArgumentException {
-setNormal(normal);
-this.precision = precision;
-this.originOffset = -p.dot(w);
-setFrame();
+public static Plane fromPointAndPlaneVectors (Vector3D p, final Vector3D
u, final
[GitHub] [commons-vfs] woonsan commented on issue #52: VFS-686: webdav4 provider based on the latest Jackrabbit 2.x
woonsan commented on issue #52: VFS-686: webdav4 provider based on the latest Jackrabbit 2.x URL: https://github.com/apache/commons-vfs/pull/52#issuecomment-479276504 @garydgregory , just fyi, I'm trying to figure out how to reproduce this locally. Strangely, my local tests were successful... :( > junit.framework.AssertionFailedError: webdav://admin@localhost:36382/repository/default/read-tests/dir1/subdir4.jar > ... This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (STATISTICS-8) Implementation of regression libraries within common-statistics framework
Eric Barnhill created STATISTICS-8: -- Summary: Implementation of regression libraries within common-statistics framework Key: STATISTICS-8 URL: https://issues.apache.org/jira/browse/STATISTICS-8 Project: Apache Commons Statistics Issue Type: Task Reporter: Eric Barnhill Apache commons is one of the most widely used resources by Java programmers around the world. Data related applications are soaring and Java is one of the most commonly used languages for data engineering. Consequently the commons-statistics library, currently under development, is likely to find a widespread audience. For this project we aim to implement regression methods, arguably the most widely used techniques in statistics and machine learning, within the Apache commons framework, in particular within the new commons-statistics library. The assignee will: * Use core functionality from the regression sub-libraries of the deprecated commons-math 4 framework as a starting point * Create a new, standalone commons component for regression statistics, focusing first on linear and logistic regression * Make architectural and design decisions in the commons philosophy, that is, lightweight standalone components easy to understand and use by a wide range of Java developers (i.e. not a large, omnibus mathematical library with many degrees of abstraction) * Draw inspiration from widely used libraries in scikit-learn and R to design an up-to-date statistics package * Design unit testing and documentation for these libraries Particularly challenging design decisions include how to incorporate core matrix libraries with a minimum of dependencies and redundancies. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (POOL-348) The commons-pool-evictor-thread should run as a Deamon
[ https://issues.apache.org/jira/browse/POOL-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808151#comment-16808151 ] Gary Gregory edited comment on POOL-348 at 4/2/19 9:04 PM: --- Duplicate of the now fixed [POOL-363]. [~neerup]: Please verify and close. was (Author: garydgregory): Duplicate of [POOL-363]. > The commons-pool-evictor-thread should run as a Deamon > -- > > Key: POOL-348 > URL: https://issues.apache.org/jira/browse/POOL-348 > Project: Commons Pool > Issue Type: Bug >Affects Versions: 2.6.0 >Reporter: Thomas Neerup >Priority: Major > Fix For: 2.6.2 > > > The thread "commons-pool-evictor-thread" does not run as a Deamon and keeps > the JVM alive when all other non Deamon threads has ended. > Is there any reason for this behaviour? Otherwise the thread should be > started as a Deamon. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (POOL-348) The commons-pool-evictor-thread should run as a Deamon
[ https://issues.apache.org/jira/browse/POOL-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory resolved POOL-348. --- Resolution: Fixed Fix Version/s: 2.6.2 Duplicate of [POOL-363]. > The commons-pool-evictor-thread should run as a Deamon > -- > > Key: POOL-348 > URL: https://issues.apache.org/jira/browse/POOL-348 > Project: Commons Pool > Issue Type: Bug >Affects Versions: 2.6.0 >Reporter: Thomas Neerup >Priority: Major > Fix For: 2.6.2 > > > The thread "commons-pool-evictor-thread" does not run as a Deamon and keeps > the JVM alive when all other non Deamon threads has ended. > Is there any reason for this behaviour? Otherwise the thread should be > started as a Deamon. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (STATISTICS-7) Stream-based Java statistical processing
[ https://issues.apache.org/jira/browse/STATISTICS-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807991#comment-16807991 ] Eric Barnhill edited comment on STATISTICS-7 at 4/2/19 6:19 PM: Yes you are in the right place. And I realize the deadline is coming up and will look at the draft proposals soon. Also please discuss on the dev list. was (Author: ericbarnhill): Yes you are in the right place. And I realize the deadline is coming up and will look at the draft proposals soon. > Stream-based Java statistical processing > > > Key: STATISTICS-7 > URL: https://issues.apache.org/jira/browse/STATISTICS-7 > Project: Apache Commons Statistics > Issue Type: New Feature >Reporter: Eric Barnhill >Priority: Major > Labels: GSoC2019, gsoc2019, statistics, streams > > The new component aims to be a library of commons statistics functions > synchronized with the latest developments in the Java language, in particular > Java's functional programming syntax. > The library will make commonly used statistical functions available to an end > user through a simple grammar comparable to commons-math-statistics or > scikit-learn, while under the hood will implement Java's mapping, streaming, > and other producer and consumer functions to ensure the statistical methods > run optimally in new Java implementations. > Developers working on the project will have the opportunity to demonstrate > Java programming, functional programming, algorithm design, and data science > skills and receive authorship on a commons project that is likely to be > widely used. > The ideal contributor will also be able to help with important architectural > decision making. The old source of these libraries, commons-math, grew too > large, hierarchically complex and interdependent for the commons mission. The > developers on this project need to make architectural choices that will > enable the statiscal code to be lightweight and reusable, with a minimum of > outside dependencies while avoiding redundancy. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (STATISTICS-7) Stream-based Java statistical processing
[ https://issues.apache.org/jira/browse/STATISTICS-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807991#comment-16807991 ] Eric Barnhill commented on STATISTICS-7: Yes you are in the right place. And I realize the deadline is coming up and will look at the draft proposals soon. > Stream-based Java statistical processing > > > Key: STATISTICS-7 > URL: https://issues.apache.org/jira/browse/STATISTICS-7 > Project: Apache Commons Statistics > Issue Type: New Feature >Reporter: Eric Barnhill >Priority: Major > Labels: GSoC2019, gsoc2019, statistics, streams > > The new component aims to be a library of commons statistics functions > synchronized with the latest developments in the Java language, in particular > Java's functional programming syntax. > The library will make commonly used statistical functions available to an end > user through a simple grammar comparable to commons-math-statistics or > scikit-learn, while under the hood will implement Java's mapping, streaming, > and other producer and consumer functions to ensure the statistical methods > run optimally in new Java implementations. > Developers working on the project will have the opportunity to demonstrate > Java programming, functional programming, algorithm design, and data science > skills and receive authorship on a commons project that is likely to be > widely used. > The ideal contributor will also be able to help with important architectural > decision making. The old source of these libraries, commons-math, grew too > large, hierarchically complex and interdependent for the commons mission. The > developers on this project need to make architectural choices that will > enable the statiscal code to be lightweight and reusable, with a minimum of > outside dependencies while avoiding redundancy. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Deleted] (MATH-1474) bug reports
[ https://issues.apache.org/jira/browse/MATH-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles deleted MATH-1474: - > bug reports > --- > > Key: MATH-1474 > URL: https://issues.apache.org/jira/browse/MATH-1474 > Project: Commons Math > Issue Type: Bug >Reporter: KUNDANA Gangam >Priority: Critical > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MATH-1474) bug reports
[ https://issues.apache.org/jira/browse/MATH-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] KUNDANA Gangam closed MATH-1474. Resolution: Auto Closed > bug reports > --- > > Key: MATH-1474 > URL: https://issues.apache.org/jira/browse/MATH-1474 > Project: Commons Math > Issue Type: Bug >Reporter: KUNDANA Gangam >Priority: Critical > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (STATISTICS-7) Stream-based Java statistical processing
[ https://issues.apache.org/jira/browse/STATISTICS-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807976#comment-16807976 ] Virendra Singh commented on STATISTICS-7: - Hey [~ericbarnhill] & [~erans], Even I submitted the draft proposal for _stat.descriptive.* ._ Is there any other ticket or Am I good here? Because, I can see the discussion is moved mainly towards _regression_. But, also , summary statistics is the basic & core of Statistics so I think I'm at right place. Also, I'm waiting for feedback on draft proposal, [~ericbarnhill] . Tell me if any changes to make. > Stream-based Java statistical processing > > > Key: STATISTICS-7 > URL: https://issues.apache.org/jira/browse/STATISTICS-7 > Project: Apache Commons Statistics > Issue Type: New Feature >Reporter: Eric Barnhill >Priority: Major > Labels: GSoC2019, gsoc2019, statistics, streams > > The new component aims to be a library of commons statistics functions > synchronized with the latest developments in the Java language, in particular > Java's functional programming syntax. > The library will make commonly used statistical functions available to an end > user through a simple grammar comparable to commons-math-statistics or > scikit-learn, while under the hood will implement Java's mapping, streaming, > and other producer and consumer functions to ensure the statistical methods > run optimally in new Java implementations. > Developers working on the project will have the opportunity to demonstrate > Java programming, functional programming, algorithm design, and data science > skills and receive authorship on a commons project that is likely to be > widely used. > The ideal contributor will also be able to help with important architectural > decision making. The old source of these libraries, commons-math, grew too > large, hierarchically complex and interdependent for the commons mission. The > developers on this project need to make architectural choices that will > enable the statiscal code to be lightweight and reusable, with a minimum of > outside dependencies while avoiding redundancy. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MATH-1474) bug reports
KUNDANA Gangam created MATH-1474: Summary: bug reports Key: MATH-1474 URL: https://issues.apache.org/jira/browse/MATH-1474 Project: Commons Math Issue Type: Bug Reporter: KUNDANA Gangam -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NUMBERS-98) Port commons-math.linear to commons-numbers.linear
[ https://issues.apache.org/jira/browse/NUMBERS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807943#comment-16807943 ] Udit Arora commented on NUMBERS-98: --- Sir I have started watching this issue as well. I will dig deeper and see if I am suitable for this project. Thanks sir for guiding me. > Port commons-math.linear to commons-numbers.linear > -- > > Key: NUMBERS-98 > URL: https://issues.apache.org/jira/browse/NUMBERS-98 > Project: Commons Numbers > Issue Type: Task >Reporter: Eric Barnhill >Priority: Major > Labels: GSoC2019, gsoc2019 > > Apache commons is one of the most widely used supplementary resources by Java > programmers and its mathematical functions are widely used. > Basic operations of linear algebra such as matrix factorization are not only > in use in scientific and technical fields but widely in industry, and an > accessible and standalone library for this functionality would have a wide > potential audience. > This ticket is in three parts: > # Port the libraries from commons-math.linear into commons-numbers.linear, > removing unnecessary layers of abstraction and creating a simple, intuitive, > standalone library. > # The developer should familiarize themselves with best bractices in linear > algebra such as those in the EJML, and redevelop the linear library to > contain best practice implementations. > # The developer should work with developers of other math and statistics > projects to integrate their work where it can benefit those projects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (STATISTICS-7) Stream-based Java statistical processing
[ https://issues.apache.org/jira/browse/STATISTICS-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807899#comment-16807899 ] Eric Barnhill commented on STATISTICS-7: [~Udit Arora] https://issues.apache.org/jira/browse/NUMBERS-98 > Stream-based Java statistical processing > > > Key: STATISTICS-7 > URL: https://issues.apache.org/jira/browse/STATISTICS-7 > Project: Apache Commons Statistics > Issue Type: New Feature >Reporter: Eric Barnhill >Priority: Major > Labels: GSoC2019, gsoc2019, statistics, streams > > The new component aims to be a library of commons statistics functions > synchronized with the latest developments in the Java language, in particular > Java's functional programming syntax. > The library will make commonly used statistical functions available to an end > user through a simple grammar comparable to commons-math-statistics or > scikit-learn, while under the hood will implement Java's mapping, streaming, > and other producer and consumer functions to ensure the statistical methods > run optimally in new Java implementations. > Developers working on the project will have the opportunity to demonstrate > Java programming, functional programming, algorithm design, and data science > skills and receive authorship on a commons project that is likely to be > widely used. > The ideal contributor will also be able to help with important architectural > decision making. The old source of these libraries, commons-math, grew too > large, hierarchically complex and interdependent for the commons mission. The > developers on this project need to make architectural choices that will > enable the statiscal code to be lightweight and reusable, with a minimum of > outside dependencies while avoiding redundancy. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NUMBERS-98) Port commons-math.linear to commons-numbers.linear
[ https://issues.apache.org/jira/browse/NUMBERS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Barnhill updated NUMBERS-98: - Labels: GSoC2019 gsoc2019 (was: ) > Port commons-math.linear to commons-numbers.linear > -- > > Key: NUMBERS-98 > URL: https://issues.apache.org/jira/browse/NUMBERS-98 > Project: Commons Numbers > Issue Type: Task >Reporter: Eric Barnhill >Priority: Major > Labels: GSoC2019, gsoc2019 > > Apache commons is one of the most widely used supplementary resources by Java > programmers and its mathematical functions are widely used. > Basic operations of linear algebra such as matrix factorization are not only > in use in scientific and technical fields but widely in industry, and an > accessible and standalone library for this functionality would have a wide > potential audience. > This ticket is in three parts: > # Port the libraries from commons-math.linear into commons-numbers.linear, > removing unnecessary layers of abstraction and creating a simple, intuitive, > standalone library. > # The developer should familiarize themselves with best bractices in linear > algebra such as those in the EJML, and redevelop the linear library to > contain best practice implementations. > # The developer should work with developers of other math and statistics > projects to integrate their work where it can benefit those projects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (NUMBERS-98) Port commons-math.linear to commons-numbers.linear
Eric Barnhill created NUMBERS-98: Summary: Port commons-math.linear to commons-numbers.linear Key: NUMBERS-98 URL: https://issues.apache.org/jira/browse/NUMBERS-98 Project: Commons Numbers Issue Type: Task Reporter: Eric Barnhill Apache commons is one of the most widely used supplementary resources by Java programmers and its mathematical functions are widely used. Basic operations of linear algebra such as matrix factorization are not only in use in scientific and technical fields but widely in industry, and an accessible and standalone library for this functionality would have a wide potential audience. This ticket is in three parts: # Port the libraries from commons-math.linear into commons-numbers.linear, removing unnecessary layers of abstraction and creating a simple, intuitive, standalone library. # The developer should familiarize themselves with best bractices in linear algebra such as those in the EJML, and redevelop the linear library to contain best practice implementations. # The developer should work with developers of other math and statistics projects to integrate their work where it can benefit those projects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DAEMON-396) LibraryPath is broken for Java 11
[
https://issues.apache.org/jira/browse/DAEMON-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807893#comment-16807893
]
Gary Gregory commented on DAEMON-396:
-
This would be easier to review (for me) with a github PR.
> LibraryPath is broken for Java 11
> -
>
> Key: DAEMON-396
> URL: https://issues.apache.org/jira/browse/DAEMON-396
> Project: Commons Daemon
> Issue Type: Bug
> Components: Procrun
>Affects Versions: 1.1.1
>Reporter: Gerwin
>Priority: Critical
> Attachments: JAVA_HOME-bin-to-PATH.patch, apxAddToPathW.patch
>
>
> My application which runs on TomEE is broken when running on Java 11. I'm
> getting this error:
> {code:none}
> java.lang.UnsatisfiedLinkError: no xmlForJava in java.library.path:
> [C:\Program Files\TomEE\bin, <>, .]
> at
> java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2660)
> at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:829)
> at java.base/java.lang.System.loadLibrary(System.java:1867)
> {code}
> It works for Java 8 and 10, but fails for both Oracle JDK 11 and OpenJDK 11.
> The application installs the service with the {{--LibraryPath}} option and
> {{--StartMode jvm}}. When inspecting the {{java.library.path}} using JMX, I
> observe this:
> # With Java 8 {{java.library.path}} contains the value specified in the
> LibraryPath
> # With Java 11 {{java.library.path}} contains the value of the PATH
> environment variable
> From the sourcecode I see that procrun is executing code in this order:
> {code:none}
> _wputenv("PATH=;C:\\application\\lib");
> LoadLibraryW("jvm.dll")
> JNI_CreateJavaVM()
> SetDllDirectoryW(";C:\\application\\lib")
> {code}
> The JVM is supposed to take the value of the PATH variable into account when
> loaded, but it doesn't.
> I found these articles:
> * Stackoverflow: [Program uses outdated (not current) env variable
> value|https://stackoverflow.com/questions/9634905/program-uses-outdated-not-current-env-variable-value]
> * Microsoft Docs: [Potential Errors Passing CRT Objects Across DLL
> Boundaries#This example passes environment variables across a DLL
> boundary|https://docs.microsoft.com/en-us/cpp/c-runtime-library/potential-errors-passing-crt-objects-across-dll-boundaries?view=vs-2017#example-1]
> So the C-Runtime library has its own copy of the environment variables and
> behavior depends on how the binaries are compiled.
> * /MD means they share a single copy of the C-Runtime library.
> * /MT means that they use separate copies of the C-Runtime library.
> I expect that Java 11 is build differently, which causes this bug.
> Give this quote...
> {quote}
> Normally when Java is launched and a library path is not specified, the JVM
> will default to using the system PATH on Windows and the LD_LIBRARY_PATH on
> UNIX systems to locate any native libraries loaded by the application. This
> is akin to what happens with the CLASSPATH environment variable when a
> specific classpath is not specified when launching the JVM. The use of the
> CLASSPATH environment variable has fallen out of style because of all the
> conflict problems which can arise when multiple Java applications are
> installed on the same machine. The same issues are all there with the library
> path as well.
> In general, it is advised that you avoid potential problems when your
> application is deployed by being conservative about which directories will be
> included in the Java library path.
> https://wrapper.tanukisoftware.com/doc/english/prop-java-library-path-append-system-path.html
> {quote}
> .. I think it would be better to change the implementation of
> {{--LibraryPath}} to set the JVM option {{-Djava.library.path}} instead of
> the PATH env var.
> This will make procrun independent of how the jvm.dll is build.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [commons-vfs] boris-petrov opened a new pull request #57: Simplify adding files to DefaultFileMonitor
boris-petrov opened a new pull request #57: Simplify adding files to DefaultFileMonitor URL: https://github.com/apache/commons-vfs/pull/57 The original code tried adding recursively the children twice - once in `doAddFile` and then again in `addFile` itself. This is now simplified. Also fix a test which should work only in recursive mode and add another one. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (NUMBERS-70) Userguide and reports
[ https://issues.apache.org/jira/browse/NUMBERS-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807839#comment-16807839 ] Abhishek Chaudhary commented on NUMBERS-70: --- Those link given by you were useful, I got an idea how to make usage and index for common-numbers. How can i share my proposal with you ? > Userguide and reports > - > > Key: NUMBERS-70 > URL: https://issues.apache.org/jira/browse/NUMBERS-70 > Project: Commons Numbers > Issue Type: Wish >Reporter: Gilles >Priority: Minor > Labels: benchmark, documentation, gsoc2019 > Fix For: 1.0 > > Attachments: 0001-Angles-xdoc-is-added.patch, > 0001-Prime-xdoc-file-is-added.patch, 0001-Primes-xdoc-is-added.patch > > > Review contents of the component towards providing an up-to-date userguide > and write benchmarking code for generating performance reports > ([JMH|http://openjdk.java.net/projects/code-tools/jmh/]). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NUMBERS-70) Userguide and reports
[ https://issues.apache.org/jira/browse/NUMBERS-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807838#comment-16807838 ] Abhishek Chaudhary commented on NUMBERS-70: --- [^0001-Angles-xdoc-is-added.patch] Example and information about angles is added. > Userguide and reports > - > > Key: NUMBERS-70 > URL: https://issues.apache.org/jira/browse/NUMBERS-70 > Project: Commons Numbers > Issue Type: Wish >Reporter: Gilles >Priority: Minor > Labels: benchmark, documentation, gsoc2019 > Fix For: 1.0 > > Attachments: 0001-Angles-xdoc-is-added.patch, > 0001-Prime-xdoc-file-is-added.patch, 0001-Primes-xdoc-is-added.patch > > > Review contents of the component towards providing an up-to-date userguide > and write benchmarking code for generating performance reports > ([JMH|http://openjdk.java.net/projects/code-tools/jmh/]). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NUMBERS-70) Userguide and reports
[ https://issues.apache.org/jira/browse/NUMBERS-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Chaudhary updated NUMBERS-70: -- Attachment: 0001-Angles-xdoc-is-added.patch > Userguide and reports > - > > Key: NUMBERS-70 > URL: https://issues.apache.org/jira/browse/NUMBERS-70 > Project: Commons Numbers > Issue Type: Wish >Reporter: Gilles >Priority: Minor > Labels: benchmark, documentation, gsoc2019 > Fix For: 1.0 > > Attachments: 0001-Angles-xdoc-is-added.patch, > 0001-Prime-xdoc-file-is-added.patch, 0001-Primes-xdoc-is-added.patch > > > Review contents of the component towards providing an up-to-date userguide > and write benchmarking code for generating performance reports > ([JMH|http://openjdk.java.net/projects/code-tools/jmh/]). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (STATISTICS-7) Stream-based Java statistical processing
[ https://issues.apache.org/jira/browse/STATISTICS-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807832#comment-16807832 ] Udit Arora edited comment on STATISTICS-7 at 4/2/19 3:04 PM: - Sir I am interested in both. But since I have been following this discussion, I plan to stick to this. But now that I know I might send a proposal there as well, I would be thankful if you could send the link for that project on matrix algebra, thanks in advance. But currently this project is my priority. was (Author: udit arora): Sir I am interested in both. But since I have been following this discussion, I plan to stick to this. But now that I know I might send a proposal there as well. But currently this project is my priority. > Stream-based Java statistical processing > > > Key: STATISTICS-7 > URL: https://issues.apache.org/jira/browse/STATISTICS-7 > Project: Apache Commons Statistics > Issue Type: New Feature >Reporter: Eric Barnhill >Priority: Major > Labels: GSoC2019, gsoc2019, statistics, streams > > The new component aims to be a library of commons statistics functions > synchronized with the latest developments in the Java language, in particular > Java's functional programming syntax. > The library will make commonly used statistical functions available to an end > user through a simple grammar comparable to commons-math-statistics or > scikit-learn, while under the hood will implement Java's mapping, streaming, > and other producer and consumer functions to ensure the statistical methods > run optimally in new Java implementations. > Developers working on the project will have the opportunity to demonstrate > Java programming, functional programming, algorithm design, and data science > skills and receive authorship on a commons project that is likely to be > widely used. > The ideal contributor will also be able to help with important architectural > decision making. The old source of these libraries, commons-math, grew too > large, hierarchically complex and interdependent for the commons mission. The > developers on this project need to make architectural choices that will > enable the statiscal code to be lightweight and reusable, with a minimum of > outside dependencies while avoiding redundancy. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (STATISTICS-7) Stream-based Java statistical processing
[ https://issues.apache.org/jira/browse/STATISTICS-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807832#comment-16807832 ] Udit Arora commented on STATISTICS-7: - Sir I am interested in both. But since I have been following this discussion, I plan to stick to this. But now that I know I might send a proposal there as well. But currently this project is my priority. > Stream-based Java statistical processing > > > Key: STATISTICS-7 > URL: https://issues.apache.org/jira/browse/STATISTICS-7 > Project: Apache Commons Statistics > Issue Type: New Feature >Reporter: Eric Barnhill >Priority: Major > Labels: GSoC2019, gsoc2019, statistics, streams > > The new component aims to be a library of commons statistics functions > synchronized with the latest developments in the Java language, in particular > Java's functional programming syntax. > The library will make commonly used statistical functions available to an end > user through a simple grammar comparable to commons-math-statistics or > scikit-learn, while under the hood will implement Java's mapping, streaming, > and other producer and consumer functions to ensure the statistical methods > run optimally in new Java implementations. > Developers working on the project will have the opportunity to demonstrate > Java programming, functional programming, algorithm design, and data science > skills and receive authorship on a commons project that is likely to be > widely used. > The ideal contributor will also be able to help with important architectural > decision making. The old source of these libraries, commons-math, grew too > large, hierarchically complex and interdependent for the commons mission. The > developers on this project need to make architectural choices that will > enable the statiscal code to be lightweight and reusable, with a minimum of > outside dependencies while avoiding redundancy. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DAEMON-396) LibraryPath is broken for Java 11
[
https://issues.apache.org/jira/browse/DAEMON-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807809#comment-16807809
]
Gerwin commented on DAEMON-396:
---
[~markt], [~ggregory]: can you help here?
This ticket is required for [Tomcat
63310|https://bz.apache.org/bugzilla/show_bug.cgi?id=63310] and TOMEE-2505.
> LibraryPath is broken for Java 11
> -
>
> Key: DAEMON-396
> URL: https://issues.apache.org/jira/browse/DAEMON-396
> Project: Commons Daemon
> Issue Type: Bug
> Components: Procrun
>Affects Versions: 1.1.1
>Reporter: Gerwin
>Priority: Critical
> Attachments: JAVA_HOME-bin-to-PATH.patch, apxAddToPathW.patch
>
>
> My application which runs on TomEE is broken when running on Java 11. I'm
> getting this error:
> {code:none}
> java.lang.UnsatisfiedLinkError: no xmlForJava in java.library.path:
> [C:\Program Files\TomEE\bin, <>, .]
> at
> java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2660)
> at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:829)
> at java.base/java.lang.System.loadLibrary(System.java:1867)
> {code}
> It works for Java 8 and 10, but fails for both Oracle JDK 11 and OpenJDK 11.
> The application installs the service with the {{--LibraryPath}} option and
> {{--StartMode jvm}}. When inspecting the {{java.library.path}} using JMX, I
> observe this:
> # With Java 8 {{java.library.path}} contains the value specified in the
> LibraryPath
> # With Java 11 {{java.library.path}} contains the value of the PATH
> environment variable
> From the sourcecode I see that procrun is executing code in this order:
> {code:none}
> _wputenv("PATH=;C:\\application\\lib");
> LoadLibraryW("jvm.dll")
> JNI_CreateJavaVM()
> SetDllDirectoryW(";C:\\application\\lib")
> {code}
> The JVM is supposed to take the value of the PATH variable into account when
> loaded, but it doesn't.
> I found these articles:
> * Stackoverflow: [Program uses outdated (not current) env variable
> value|https://stackoverflow.com/questions/9634905/program-uses-outdated-not-current-env-variable-value]
> * Microsoft Docs: [Potential Errors Passing CRT Objects Across DLL
> Boundaries#This example passes environment variables across a DLL
> boundary|https://docs.microsoft.com/en-us/cpp/c-runtime-library/potential-errors-passing-crt-objects-across-dll-boundaries?view=vs-2017#example-1]
> So the C-Runtime library has its own copy of the environment variables and
> behavior depends on how the binaries are compiled.
> * /MD means they share a single copy of the C-Runtime library.
> * /MT means that they use separate copies of the C-Runtime library.
> I expect that Java 11 is build differently, which causes this bug.
> Give this quote...
> {quote}
> Normally when Java is launched and a library path is not specified, the JVM
> will default to using the system PATH on Windows and the LD_LIBRARY_PATH on
> UNIX systems to locate any native libraries loaded by the application. This
> is akin to what happens with the CLASSPATH environment variable when a
> specific classpath is not specified when launching the JVM. The use of the
> CLASSPATH environment variable has fallen out of style because of all the
> conflict problems which can arise when multiple Java applications are
> installed on the same machine. The same issues are all there with the library
> path as well.
> In general, it is advised that you avoid potential problems when your
> application is deployed by being conservative about which directories will be
> included in the Java library path.
> https://wrapper.tanukisoftware.com/doc/english/prop-java-library-path-append-system-path.html
> {quote}
> .. I think it would be better to change the implementation of
> {{--LibraryPath}} to set the JVM option {{-Djava.library.path}} instead of
> the PATH env var.
> This will make procrun independent of how the jvm.dll is build.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (VALIDATOR-455) Add IBAN validator for VA – Vatican City State
Eugen Hanussek created VALIDATOR-455: Summary: Add IBAN validator for VA – Vatican City State Key: VALIDATOR-455 URL: https://issues.apache.org/jira/browse/VALIDATOR-455 Project: Commons Validator Issue Type: Improvement Components: Routines Affects Versions: 1.6 Reporter: Eugen Hanussek Fix For: 1.7 since Nov-18 in IBAN_Registry.pdf IBAN for VA is listed. There is no in 1.6 neither in 1.7 example: VA5900112312345678 IBAN structure : VA2!n3!n15!n IBAN length : 22 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (DAEMON-398) Java 11 jvm.dll startup error messages not available on stdout/stderr
Gerwin created DAEMON-398:
-
Summary: Java 11 jvm.dll startup error messages not available on
stdout/stderr
Key: DAEMON-398
URL: https://issues.apache.org/jira/browse/DAEMON-398
Project: Commons Daemon
Issue Type: Bug
Components: Procrun
Affects Versions: 1.1.1
Environment: Windows
Reporter: Gerwin
Attachments: set-stdout.patch
*Steps to reproduce*
# Install Java 11
# Install prunsrv.exe using jvm.dll and specify stdout and stderr file.
# Using prunmgr, add a Java Option '-invalid'
# Start the service
# stdout and stderr files are empty!
# Install Java 10
# Using prunmgr, switch the Java Virtual Machine to Java 10
# Start the service
# {code:none|title=stderr}
Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option MaxPermSize; support
was removed in 8.0
Unrecognized option: -invalid
{code}
*Analysis*
* It works for Java 8, 9 and 10, fails for 11, 12 and 13-ea.
* I followed this guide: [Redirecting standard I/O from within a
program|https://jdebp.eu/FGA/redirecting-standard-io.html] (see
[^set-stdout.patch]), but it didn't help.
* Even when I compile prunsrv with Visual Studio 2017 15.9 (linker 14.16) and
test with Java 13-ea, which is also compiled with the same version (hence using
the same C-runtime library) it does not work.
* The guide ends with what the probably causing the issue:
{quote}
... the one problem that remains with redirecting Win32 file handles:
It doesn't affect anything in the program using a different C runtime library
(such as a third-party DLL, for example).
{quote}
* Setting registry value Log/LogJniMessages=1, which is using the {{vfprintf}}
option of the
[JNI_CreateJavaVM|https://docs.oracle.com/en/java/javase/11/docs/specs/jni/invocation.html#jni_createjavavm]
does not help. Maybe because is is added after the user-specified Java Options?
*Ideas*
# Make {{vfprintf}} the first parameter
Downside of {{vfprintf}} is that it is hard to distinct between stdout and
stderr. Maybe make a JNI call to {{System.out}} and {{System.err}} to be able
to recognize the {{*File}} pointer and map to stdout and stderr accordingly.
And I think that {{javajni.c/apxJavaSetOut()}} should not be required.
# Log a bug for OpenJDK and try to get it fixed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [commons-vfs] garydgregory commented on issue #52: VFS-686: webdav4 provider based on the latest Jackrabbit 2.x
garydgregory commented on issue #52: VFS-686: webdav4 provider based on the latest Jackrabbit 2.x URL: https://github.com/apache/commons-vfs/pull/52#issuecomment-478964021 Hi @woonsan , To be clear, the tests are still failing :-( Gary This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Resolved] (RNG-87) MultiplyWithCarry256
[
https://issues.apache.org/jira/browse/RNG-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex D Herbert resolved RNG-87.
---
Resolution: Implemented
In master.
> MultiplyWithCarry256
>
>
> Key: RNG-87
> URL: https://issues.apache.org/jira/browse/RNG-87
> Project: Commons RNG
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.3
>Reporter: Alex D Herbert
>Assignee: Alex D Herbert
>Priority: Minor
> Labels: performance
> Attachments: MWC_256.jpg, MWC_256_2.jpg, MWC_256_3.jpg,
> MWC_256_3.png, Shuffle.jpg, big.jpg, small.jpg
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The {{MultiplyWithCarry256}} currently uses a length 256 array for internal
> state. This is cycled through continuously. The current implementation
> refills the state every 256 calls to next:
> {code:java}
> public int next() {
> if (index == Q_SIZE) { // Whole state used up.
> // Refill.
> for (int i = 0; i < Q_SIZE; i++) {
> final long t = A * (state[i] & 0xL) + carry;
> carry = (int) (t >> 32);
> state[i] = (int) t;
> }
> // Reset current index.
> index = 0;
> }
> return state[index++];
> }
> {code}
> This can be changed to continuously update the state for only a single index
> on each call to next:
> {code:java}
> public int next() {
> // Produce an index in the range 0-255
> final int i = index++ & 0xFF;
> final long t = A * (state[i] & 0xL) + carry;
> carry = (int) (t >> 32);
> return state[i] = (int) t;
> }
> {code}
> This avoids an {{if}} statement check and *marginally* improves performance.
> It has the advantage of not advancing the state further ahead than necessary.
> MWC_256B is the new version. JMH results from the GenerationPerformance
> benchmark.
> {noformat}
> openjdk version "1.8.0_191"
> OpenJDK Runtime Environment (build 1.8.0_191-8u191-b12-2ubuntu0.16.04.1-b12)
> OpenJDK 64-Bit Server VM (build 25.191-b12, mixed mode)
> {noformat}
> ||numValues||randomSourceName||Method||Score||Error||Median||
> |1|SPLIT_MIX_64|nextInt|0.00478|4.45e-05|0.00477|
> |1|MWC_256|nextInt|0.00521|1.69e-05|0.00521|
> |1|MWC_256B|nextInt|0.00519|0.000321|0.00512|
> |100|SPLIT_MIX_64|nextInt|0.421|0.0131|0.418|
> |100|MWC_256|nextInt|0.452|0.000968|0.452|
> |100|MWC_256B|nextInt|0.443|0.00183|0.442|
> |1|SPLIT_MIX_64|nextInt|41.7|0.0725|41.7|
> |1|MWC_256|nextInt|44.5|2.25|43.9|
> |1|MWC_256B|nextInt|42.6|0.037|42.6|
> |100|SPLIT_MIX_64|nextInt|3.77e+03|21.2|3.77e+03|
> |100|MWC_256|nextInt|4.16e+03|12.8|4.16e+03|
> |100|MWC_256B|nextInt|3.98e+03|120|3.96e+03|
> {noformat}
> java version "11.0.2" 2019-01-15 LTS
> Java(TM) SE Runtime Environment 18.9 (build 11.0.2+9-LTS)
> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.2+9-LTS, mixed mode)
> {noformat}
> ||numValues||randomSourceName||Method||Score||Error||Median||
> |1|SPLIT_MIX_64|nextInt|0.00469|4.98e-06|0.00469|
> |1|MWC_256|nextInt|0.00553|2.09e-05|0.00553|
> |1|MWC_256B|nextInt|0.00493|4.32e-05|0.00492|
> |100|SPLIT_MIX_64|nextInt|0.435|0.000624|0.435|
> |100|MWC_256|nextInt|0.467|0.00284|0.466|
> |100|MWC_256B|nextInt|0.455|0.00105|0.455|
> |1|SPLIT_MIX_64|nextInt|43|4.94|41.9|
> |1|MWC_256|nextInt|45.8|0.132|45.8|
> |1|MWC_256B|nextInt|43|0.033|43|
> |100|SPLIT_MIX_64|nextInt|3.7e+03|7.88|3.7e+03|
> |100|MWC_256|nextInt|4.17e+03|45.3|4.15e+03|
> |100|MWC_256B|nextInt|4.12e+03|4.76|4.12e+03|
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [commons-vfs] garydgregory commented on issue #28: fixed for AbstractFileObject#toString leak password!
garydgregory commented on issue #28: fixed for AbstractFileObject#toString leak password! URL: https://github.com/apache/commons-vfs/pull/28#issuecomment-478961351 Any thoughts on the likelihood of this breaking existing apps? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-rng] asfgit merged pull request #33: RNG-87: Advance MultiplyWithCarry256 state one index per nextInt() call.
asfgit merged pull request #33: RNG-87: Advance MultiplyWithCarry256 state one index per nextInt() call. URL: https://github.com/apache/commons-rng/pull/33 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (NUMBERS-96) Port and redevelop interpolation libraries from commons-math
[ https://issues.apache.org/jira/browse/NUMBERS-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles updated NUMBERS-96: -- Description: The commons-math interpolation libraries ([https://commons.apache.org/proper/commons-math/javadocs/api-3.0/org/apache/commons/math3/analysis/interpolation/package-summary.html]) are an elegant, object-oriented approach to mathematical interpolation. We require porting of these libraries to the new commons-numbers replacement project, as well as updating the libraries to use features found in Java 8+ (e.g. lambdas) that will enable a more universally efficient performance (on e.g. heterogeneous systems), and writing more substantial documentation. was: The commons-math interpolation libraries ([https://commons.apache.org/proper/commons-math/javadocs/api-3.0/org/apache/commons/math3/analysis/interpolation/package-summary.html)] are an elegant, object-oriented approach to mathematical interpolation. We require porting of these libraries to the new commons-numbers replacement project, as well as updating the libraries to use features found in Java 8+ (e.g. lambdas) that will enable a more universally efficient performance (on e.g. heterogeneous systems), and writing more substantial documentation. > Port and redevelop interpolation libraries from commons-math > > > Key: NUMBERS-96 > URL: https://issues.apache.org/jira/browse/NUMBERS-96 > Project: Commons Numbers > Issue Type: New Feature >Reporter: Eric Barnhill >Priority: Major > Labels: GSoC2019, gsoc2019 > > The commons-math interpolation libraries > ([https://commons.apache.org/proper/commons-math/javadocs/api-3.0/org/apache/commons/math3/analysis/interpolation/package-summary.html]) > are an elegant, object-oriented approach to mathematical interpolation. > We require porting of these libraries to the new commons-numbers replacement > project, as well as updating the libraries to use features found in Java 8+ > (e.g. lambdas) that will enable a more universally efficient performance (on > e.g. heterogeneous systems), and writing more substantial documentation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
