[jira] [Commented] (NET-408) problem connecting to ProFTPD with FTPES
[
https://issues.apache.org/jira/browse/NET-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17362034#comment-17362034
]
Bernd Eckenfels commented on NET-408:
-
You can use a explicite `––add–opens` this will work besides the removed
`—illegal-access` option in java 17. but it’s really strange that we get no api
support in this area for years
> problem connecting to ProFTPD with FTPES
>
>
> Key: NET-408
> URL: https://issues.apache.org/jira/browse/NET-408
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 2.2, 3.0
> Environment: ProFTPD 1.3.3d on SUSE Linux Enterprise Server 10.1
> 32bit, Kernel 2.6.16.46-0.12-default (config file attached)
> ProFTPD 1.3.3d on OpenSUSE 64bit Linux 2.6.34.8-0.2-desktop
> Java 1.5
>Reporter: Michael Voigt
>Priority: Major
> Attachments: BCFTPSClient.java, FTPSClientWithTLSResumption.zip,
> PTFTPSClient.java, ftpes.jpg, proftpd.conf
>
>
> I have a problem with the FTPClient connecting to a ProFTPD server.
> If the server uses the configuration option "TLSProtocol TLSv1", I
> cannot connect to it at all. I recieve the following error message:
> - javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection
> On the server side I see in the log:
> unable to accept TLS connection: protocol error:
> - (1) error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate unknown
> - TLS/TLS-C negotiation failed on control channel
> If the server uses the configuration option "TLSProtocol SSLv23", I
> can connect to it but I cant transfer any files. In the server log I
> see:
> - starting TLS negotiation on data connection
> - TLSv1/SSLv3 renegotiation accepted, using cipher RC4-MD5 (128 bits)
> - client did not reuse SSL session, rejecting data connection (see
> TLSOption NoSessionReuseRequired)
> - unable to open data connection: TLS negotiation failed
> If I add the NoSessionReuseRequired parameter to the ProFTPD config
> everything works fine.
> Here is my code:
>FTPClient ftpClient = new FTPClient();
>ftpClient = new FTPSClient("TLS");
>// this throws an exception with TLSProtocol TLSv1
>ftpClient.connect(host, port);
>int reply = ftpClient.getReplyCode();
>if (!FTPReply.isPositiveCompletion(reply)) {
>ftpClient.disconnect();
>log.error("The FTP Server did not return a positive
> completion reply!");
>throw new
> FtpTransferException(ECCUtils.ERROR_FTP_CONNECTION);
>}
>boolean loginSuccessful = ftpClient.login(userName, password);
>if (!loginSuccessful) {
>log.error("Login to the FTP Server failed! The
> credentials are not valid.");
>throw new
> FtpTransferException(ECCUtils.ERROR_FTP_LOGIN);
>}
>ftpClient.execPBSZ(0);
>ftpClient.execPROT("P");
>boolean success = ftpClient.storeFile(fileName, fis);
>if (!success) {
>// this is false if "NoSessionReuseRequired" is not set
>}
> Now my question is if it is generally possible to connect to a server
> with "TLSProtocol TLSv1" or "TLSProtocol SSLv23" without the
> "NoSessionReuseRequired" parameter? Could someone provide a piece of
> example code for this?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NET-408) problem connecting to ProFTPD with FTPES
[
https://issues.apache.org/jira/browse/NET-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361859#comment-17361859
]
Stefan commented on NET-408:
Soon we have a problem. Java 17 - the next LTS - will change the reflection
warning to an error. Then our workaround can not be used anymore. If this does
not get higher priority then Java will be unable to connect to modern FTPS
server. Or we get another property to switch to old behaviour...
BouncyCastle is working on session reuse. But I could not run it with
FTPSClient. And I do not like to switch one part of our application to
BouncyCastle because Java ignores this (security) issue.
[~eduardo-rs] I found this for Java 16:
{code:java}
In Java 16, it is still possible to restore the situation that existed
previously by using the --illegal-access command-line switch to allow general
reflective access to the JDK internals. However, in Java 17, the situation
changes again: This release removes that command-line switch.{code}
> problem connecting to ProFTPD with FTPES
>
>
> Key: NET-408
> URL: https://issues.apache.org/jira/browse/NET-408
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 2.2, 3.0
> Environment: ProFTPD 1.3.3d on SUSE Linux Enterprise Server 10.1
> 32bit, Kernel 2.6.16.46-0.12-default (config file attached)
> ProFTPD 1.3.3d on OpenSUSE 64bit Linux 2.6.34.8-0.2-desktop
> Java 1.5
>Reporter: Michael Voigt
>Priority: Major
> Attachments: BCFTPSClient.java, FTPSClientWithTLSResumption.zip,
> PTFTPSClient.java, ftpes.jpg, proftpd.conf
>
>
> I have a problem with the FTPClient connecting to a ProFTPD server.
> If the server uses the configuration option "TLSProtocol TLSv1", I
> cannot connect to it at all. I recieve the following error message:
> - javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection
> On the server side I see in the log:
> unable to accept TLS connection: protocol error:
> - (1) error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate unknown
> - TLS/TLS-C negotiation failed on control channel
> If the server uses the configuration option "TLSProtocol SSLv23", I
> can connect to it but I cant transfer any files. In the server log I
> see:
> - starting TLS negotiation on data connection
> - TLSv1/SSLv3 renegotiation accepted, using cipher RC4-MD5 (128 bits)
> - client did not reuse SSL session, rejecting data connection (see
> TLSOption NoSessionReuseRequired)
> - unable to open data connection: TLS negotiation failed
> If I add the NoSessionReuseRequired parameter to the ProFTPD config
> everything works fine.
> Here is my code:
>FTPClient ftpClient = new FTPClient();
>ftpClient = new FTPSClient("TLS");
>// this throws an exception with TLSProtocol TLSv1
>ftpClient.connect(host, port);
>int reply = ftpClient.getReplyCode();
>if (!FTPReply.isPositiveCompletion(reply)) {
>ftpClient.disconnect();
>log.error("The FTP Server did not return a positive
> completion reply!");
>throw new
> FtpTransferException(ECCUtils.ERROR_FTP_CONNECTION);
>}
>boolean loginSuccessful = ftpClient.login(userName, password);
>if (!loginSuccessful) {
>log.error("Login to the FTP Server failed! The
> credentials are not valid.");
>throw new
> FtpTransferException(ECCUtils.ERROR_FTP_LOGIN);
>}
>ftpClient.execPBSZ(0);
>ftpClient.execPROT("P");
>boolean success = ftpClient.storeFile(fileName, fis);
>if (!success) {
>// this is false if "NoSessionReuseRequired" is not set
>}
> Now my question is if it is generally possible to connect to a server
> with "TLSProtocol TLSv1" or "TLSProtocol SSLv23" without the
> "NoSessionReuseRequired" parameter? Could someone provide a piece of
> example code for this?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NUMBERS-155) About modules "arrays" and "rootfinder"
[
https://issues.apache.org/jira/browse/NUMBERS-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361819#comment-17361819
]
Alex Herbert commented on NUMBERS-155:
--
Re: Triangle array.
I have a class that implements an API as a helper to generate indices into an
index of a upper triangular array. I wrote this to store all-vs-all comparison
matrices. Thus it does not support i==j as the self-comparison score is known.
It suited my use case. But I think it could be modified to support the i==j
index. I cannot remember if I worked out the indexing math or copied it. The
methods are below. The reverse method has a sqrt so will not be fast.
{code:java}
/**
* Convert from ij to linear index. Index j must be greater than i.
*
* Behaviour is undefined if i==j.
*
* @param n the size of the array in 1 dimension
* @param i the index i
* @param j the index j
* @return the linear index
*/
public static int toIndex(int n, int i, int j) {
return (n * (n - 1) / 2) - (n - i) * ((n - i) - 1) / 2 + j - i - 1;
}
/**
* Convert from linear index to ij.
*
* @param n the size of the array in 1 dimension (total length = n*(n-1)/2)
* @param k the linear index (Must be with the bound 0:length-1)
* @param ij the ij data (Must be size 2 or greater)
*/
public static void fromIndex(int n, int k, int[] ij) {
final int i = n - 2 - (int) Math.floor(Math.sqrt(-8.0 * k + 4 * n * (n - 1) -
7) / 2.0 - 0.5);
ij[0] = i;
ij[1] = k + i + 1 - (n * (n - 1) / 2) + (n - i) * ((n - i) - 1) / 2;
}
{code}
This was all in a class that could precompute some values and provided methods
for fast iteration over rows or columns by initialising the row/column then
outputting the indices in a separate call to be used in a loop.
What type of API do you want? A simple version is:
{code:java}
// Upper or lower triangle
TriangularArrayIndex index = TriangularArrayIndex.of(n, true);
double[] data = new double[index.size()];
for (int i = 0; i < n; i++) {
// Upper
for (int j = i; j < n; j++) {
data[index.get(i, j)] = i * j;
}
}
TriangularArrayIndex index = TriangularArrayIndex.of(n, false);
double[] data = new double[index.size()];
for (int i = 0; i < n; i++) {
// Lower
for (int j = 0; j <= i; j++) {
data[index.get(i, j)] = i * j;
}
}
{code}
> About modules "arrays" and "rootfinder"
> ---
>
> Key: NUMBERS-155
> URL: https://issues.apache.org/jira/browse/NUMBERS-155
> Project: Commons Numbers
> Issue Type: Task
> Components: arrays, core
>Affects Versions: 1.0-beta1
>Reporter: Gilles Sadowski
>Priority: Major
> Labels: refactoring
> Fix For: 1.0
>
>
> Shouldn't some functionality currently in module {{commons-numbers-arrays}}
> be moved to {{commons-number-core}}?
> Rationale is that the utilities focus on extended precision of some
> computations (on numbers that happen to be stored in an array).
> Wouldn't the Brent solver (in module {{commons-numbers-rootfinder}}) benefit
> from a version based on the new {{ExtendedPrecision}} class?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NUMBERS-156) SafeNorm 3D overload
[
https://issues.apache.org/jira/browse/NUMBERS-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361817#comment-17361817
]
Gilles Sadowski commented on NUMBERS-156:
-
OK to remove {{Norms}}?
On my machine, the benchmarks reports similar performance, although the unit
tests run about 20% slower with {{Norm}}.
> SafeNorm 3D overload
>
>
> Key: NUMBERS-156
> URL: https://issues.apache.org/jira/browse/NUMBERS-156
> Project: Commons Numbers
> Issue Type: Improvement
>Reporter: Matt Juntunen
>Priority: Major
> Attachments: performance-all.png, performance-len-1-5.png,
> performance2-1-5.png, performance2-all.png, performance3-1-5.png,
> performance3-all.png, performance4-1-5.png, performance4-all.png,
> performance5-1-5.png, performance5-all.png
>
> Time Spent: 5.5h
> Remaining Estimate: 0h
>
> We should create an overload of {{SafeNorm.value}} that accepts 3 arguments
> to potentially improve performance for 3D vectors.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NUMBERS-155) About modules "arrays" and "rootfinder"
[
https://issues.apache.org/jira/browse/NUMBERS-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361812#comment-17361812
]
Gilles Sadowski commented on NUMBERS-155:
-
{quote}
{code}
public int[] toMulti(int index, int[] indices);
{code}
{quote}
Yes but we should first assess the performance cost of creating many small
arrays (given that this is handled at the JVM level).
bq. If you are repeat accessing a single dimension array via the counter then
there are a lot of calls to create an index
Indeed; but maybe there should be another API for such cases, e.g. passing a
"transformer" that modifies the elements in-place or return a stream.
> About modules "arrays" and "rootfinder"
> ---
>
> Key: NUMBERS-155
> URL: https://issues.apache.org/jira/browse/NUMBERS-155
> Project: Commons Numbers
> Issue Type: Task
> Components: arrays, core
>Affects Versions: 1.0-beta1
>Reporter: Gilles Sadowski
>Priority: Major
> Labels: refactoring
> Fix For: 1.0
>
>
> Shouldn't some functionality currently in module {{commons-numbers-arrays}}
> be moved to {{commons-number-core}}?
> Rationale is that the utilities focus on extended precision of some
> computations (on numbers that happen to be stored in an array).
> Wouldn't the Brent solver (in module {{commons-numbers-rootfinder}}) benefit
> from a version based on the new {{ExtendedPrecision}} class?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NUMBERS-155) About modules "arrays" and "rootfinder"
[
https://issues.apache.org/jira/browse/NUMBERS-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361796#comment-17361796
]
Alex Herbert commented on NUMBERS-155:
--
{quote}However, for each access to an element of a virtual multidimensional
array, the utility must instantiate an int[].
{quote}
Requires an API change?
Which method is the main problem:
{noformat}
// Creates an int[] for the result
public int[] toMulti(int index);
// Creates an int[] for the arguments
public int toUni(int... c);
{noformat}
The first can be solved by accepting the output array as an argument:
{noformat}
// Reuses the int[] for the result.
// If null -> exception or create the array
// If too small -> exception or create the array
// If too big -> exception or use it anyway
public int[] toMulti(int index, int[] indices);
{noformat}
The second just requires the user to maintain an array to be passed in.
For single access to elements the performance may be negligible. If you are
repeat accessing a single dimension array via the counter then there are a lot
of calls to create an index. When repeat accessing elements this is either
random positions or a series. In the later case the API does not cater for
iterating over columns as it does not expose the stride length offsets. Here is
an example of using the offset of a given dimension:
{code:java}
int[] size = {2, 3, 4};
MultidimensionalCounter mc = MultidimensionalCounter.of(size);
double[] data = new double[mc.getSize()];
int x = 1;
int z = 2;
for (int y = 0,
index = mc.toUni(x, y, z),
stride = mc.getOffset(1); y < size[1]; y++, index += stride) {
data[index] = 42;
}
{code}
The class could be made more efficient with specialisations for 2D, 3D, etc.
But to be optimal they would have to declare their own toUni method:
{code:java}
public int toUni(int i, int j);
public int toUni(int i, int j, int k);
public int toUni(int i, int j, int k, int l);
{code}
If they all stick to using {{toUni(int...)}} then the factory constructor can
still return specialised instances which would improve performance by
eliminating the loop over the dimension and storing the sizes and offsets as
primitives.
> About modules "arrays" and "rootfinder"
> ---
>
> Key: NUMBERS-155
> URL: https://issues.apache.org/jira/browse/NUMBERS-155
> Project: Commons Numbers
> Issue Type: Task
> Components: arrays, core
>Affects Versions: 1.0-beta1
>Reporter: Gilles Sadowski
>Priority: Major
> Labels: refactoring
> Fix For: 1.0
>
>
> Shouldn't some functionality currently in module {{commons-numbers-arrays}}
> be moved to {{commons-number-core}}?
> Rationale is that the utilities focus on extended precision of some
> computations (on numbers that happen to be stored in an array).
> Wouldn't the Brent solver (in module {{commons-numbers-rootfinder}}) benefit
> from a version based on the new {{ExtendedPrecision}} class?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NUMBERS-155) About modules "arrays" and "rootfinder"
[
https://issues.apache.org/jira/browse/NUMBERS-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361749#comment-17361749
]
Gilles Sadowski commented on NUMBERS-155:
-
{quote}Q. What is the implication of moving these class to the core module,
under the same package names, and then creating an arrays module and/or
rootfinder module in a future release?That is, can any packages released in the
core jar be later moved to a separate module for those packages if they are to
be expanded.
{quote}
I'd keep away of the trouble which you mention in the "A."
[In these components, Maven modules are also intended as JPMS modules.]
bq. other use cases for an arrays package.
The primary rationale was for representing multidimensional arrays (that are
inordinately costly in Java) by a single array.
However, for each access to an element of a virtual multidimensional array, the
utility must instantiate an {{int[]}}. I have no idea whether it entails a
performance hit that would prohibit usage in all but trivial use cases.
bq. Or a 2D MatrixTranspose wrapper that reverses the input indices to allow
addressing an underlying 2D matrix as its transpose.
Cf. transpose in the API proposed in MATH-928.
More than 7 years old... :-}
bq. symmetric matrix data structure [...] halving the memory requirement by
storing the square matrix as a triangle.
+1
I have a use-case for such a utility. Choice of row- or column-major storage
should be available.
> About modules "arrays" and "rootfinder"
> ---
>
> Key: NUMBERS-155
> URL: https://issues.apache.org/jira/browse/NUMBERS-155
> Project: Commons Numbers
> Issue Type: Task
> Components: arrays, core
>Affects Versions: 1.0-beta1
>Reporter: Gilles Sadowski
>Priority: Major
> Labels: refactoring
> Fix For: 1.0
>
>
> Shouldn't some functionality currently in module {{commons-numbers-arrays}}
> be moved to {{commons-number-core}}?
> Rationale is that the utilities focus on extended precision of some
> computations (on numbers that happen to be stored in an array).
> Wouldn't the Brent solver (in module {{commons-numbers-rootfinder}}) benefit
> from a version based on the new {{ExtendedPrecision}} class?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IO-740) RegexFileFilter matches on full path instead of filename
[
https://issues.apache.org/jira/browse/IO-740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361744#comment-17361744
]
Tom Jorissen commented on IO-740:
-
Sorry, I searched for issues with RegexFileFilter before and nothing showed up
but now I see multiple..
> RegexFileFilter matches on full path instead of filename
>
>
> Key: IO-740
> URL: https://issues.apache.org/jira/browse/IO-740
> Project: Commons IO
> Issue Type: Bug
> Components: Filters
>Affects Versions: 2.9.0
>Reporter: Tom Jorissen
>Priority: Minor
> Fix For: 2.10.0
>
>
> org.apache.commons.io.filefilter.RegexFileFilter#accept(java.nio.file.Path,
> java.nio.file.attribute.BasicFileAttributes) is a new method added in 2.9.0
> and it's javadoc states:
> {code:java}
> /**
> * Checks to see if the file name matches one of the regular expressions.
> *
> * @param path the path
> * @param attributes the path attributes
> * @return true if the file name matches one of the regular expressions
> */
> {code}
> However in it's implementation:
> {code:java}
> return toFileVisitResult(pattern.matcher(path.toString()).matches(), path);
> {code}
> it matches on path.toString() which will be the full path instead of the
> filename.
>
> This is also inconsistent with the other method
> org.apache.commons.io.filefilter.RegexFileFilter#accept(java.io.File,
> java.lang.String) which does match only on filename.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IO-740) RegexFileFilter matches on full path instead of filename
[
https://issues.apache.org/jira/browse/IO-740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved IO-740.
Fix Version/s: 2.10.0
Resolution: Fixed
Please check Jira before creating a duplicate ticket.
Please test with git master and reopen this issue if this does not address your
use case.
> RegexFileFilter matches on full path instead of filename
>
>
> Key: IO-740
> URL: https://issues.apache.org/jira/browse/IO-740
> Project: Commons IO
> Issue Type: Bug
> Components: Filters
>Affects Versions: 2.9.0
>Reporter: Tom Jorissen
>Priority: Minor
> Fix For: 2.10.0
>
>
> org.apache.commons.io.filefilter.RegexFileFilter#accept(java.nio.file.Path,
> java.nio.file.attribute.BasicFileAttributes) is a new method added in 2.9.0
> and it's javadoc states:
> {code:java}
> /**
> * Checks to see if the file name matches one of the regular expressions.
> *
> * @param path the path
> * @param attributes the path attributes
> * @return true if the file name matches one of the regular expressions
> */
> {code}
> However in it's implementation:
> {code:java}
> return toFileVisitResult(pattern.matcher(path.toString()).matches(), path);
> {code}
> it matches on path.toString() which will be the full path instead of the
> filename.
>
> This is also inconsistent with the other method
> org.apache.commons.io.filefilter.RegexFileFilter#accept(java.io.File,
> java.lang.String) which does match only on filename.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (RNG-144) AhrensDieterExponentialSampler can infinite loop
[
https://issues.apache.org/jira/browse/RNG-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Herbert resolved RNG-144.
--
Fix Version/s: 1.4
Resolution: Fixed
Resolved by creating the first uniform deviate in the interval {{(0, 1]}}, i.e.
non-zero. If the first uniform deviate is 1 the method creates a valid sample.
The rest of the sample method is robust to zeros from the underlying generator
nextDouble() method.
Fixed in commits:
585e205cb3266c6fc3074699946a080c61aa5c3e
c7779b1e32ce3533d2f9f440b46106bb1907be46
> AhrensDieterExponentialSampler can infinite loop
>
>
> Key: RNG-144
> URL: https://issues.apache.org/jira/browse/RNG-144
> Project: Commons RNG
> Issue Type: Bug
> Components: sampling
>Affects Versions: 1.3
>Reporter: Alex Herbert
>Priority: Minor
> Fix For: 1.4
>
>
> If the RNG provides a value of 0 for a uniform deviate the sampler will
> infinite loop. Here is the initial part of the sample method:
> {code:java}
> public double sample() {
> // Step 1:
> double a = 0;
> // *** u can be zero ***
> double u = rng.nextDouble();
> // Step 2 and 3:
> while (u < 0.5) {
> a += EXPONENTIAL_SA_QI[0];
> // *** u is always zero => infinite loop ***
> u *= 2;
> }
> {code}
> The origin of the method is not stated in the source; the reference from the
> original source in Commons Math 3 is to a dead link. A brief search did not
> find a reference with this method.
> It is assumed the variable u should be in the open interval (0, 1), not the
> interval [0, 1) typically provided by a RNG supplying the 2^53 dyadic
> rationals in the interval 0 to 1.
> This can be fixed by using an open interval or changing the interval to (0,
> 1]:
> {code:java}
> double nextDouble() {
> // A value in [0, 1)
> double x = rng.nextDouble();
> // recursion if zero
> return x == 0 ? nextDouble() : x;
> }
> double nextDouble() {
> // A value in (0, 1].
> return 0x1.0p-53 * ((rng.nextLong() >>> 11) + 1L);
> }
> {code}
> Either method fixes this test:
> {code:java}
> @Test
> public void testSamplerWithZeroFromFirstRandomDeviate() {
> // Create a zero for the first call to the sampler, then non-zero after
> final UniformRandomProvider rng = new SplitMix64(0) {
> private long l = 0;
> @Override
> public long nextLong() { return l++; }
> };
> final SharedStateContinuousSampler sampler =
> AhrensDieterExponentialSampler.of(rng, 1);
> // Infinite loop
> sampler.sample();
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NUMBERS-155) About modules "arrays" and "rootfinder"
[
https://issues.apache.org/jira/browse/NUMBERS-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361664#comment-17361664
]
Alex Herbert commented on NUMBERS-155:
--
Looking at the entire numbers codebase each package is in a separate module. So
if the code does not fit as a core number utility it should not go into core,
it should be in a different package and hence different module.
I think it fine to keep these modules with single classes. This is the current
case for complex.
Q. What is the implication of moving these class to the core module, under the
same package names, and then creating an arrays module and/or rootfinder module
in a future release?That is, can any packages released in the core jar be later
moved to a separate module for those packages if they are to be expanded.
A. Such a moved would keep source compatibility for downstream projects but
with a change of their dependencies. If they are updating their version numbers
then they can also add a new module dependency. One issue would be a transitive
dependency resolving a newer version of numbers core that had a package moved
to a new module. Any code assuming the previous version would be missing
classes. So this could be bad. A safer option is to keep packages in modules.
I can think of a few other use cases for an arrays package. The cases are for
methods of indexing into arrays. MultidimensionalCounter is one example. A
trivial example would be to have a wrapper object that translates 1-based
indexing to 0-based indexing into an underlying array data structure. This
would be for users familiar with 1-based indexing such as matlab. Or a 2D
MatrixTranspose wrapper that reverses the input indices to allow addressing an
underlying 2D matrix as its transpose. Or a 2D symmetric matrix data structure
where [i][j] == [j][i], thus halving the memory requirement by storing the
square matrix as a triangle.
> About modules "arrays" and "rootfinder"
> ---
>
> Key: NUMBERS-155
> URL: https://issues.apache.org/jira/browse/NUMBERS-155
> Project: Commons Numbers
> Issue Type: Task
> Components: arrays, core
>Affects Versions: 1.0-beta1
>Reporter: Gilles Sadowski
>Priority: Major
> Labels: refactoring
> Fix For: 1.0
>
>
> Shouldn't some functionality currently in module {{commons-numbers-arrays}}
> be moved to {{commons-number-core}}?
> Rationale is that the utilities focus on extended precision of some
> computations (on numbers that happen to be stored in an array).
> Wouldn't the Brent solver (in module {{commons-numbers-rootfinder}}) benefit
> from a version based on the new {{ExtendedPrecision}} class?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (NUMBERS-155) About modules "arrays" and "rootfinder"
[
https://issues.apache.org/jira/browse/NUMBERS-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361596#comment-17361596
]
Gilles Sadowski edited comment on NUMBERS-155 at 6/11/21, 10:30 AM:
bq. Shouldn't some functionality currently in module commons-numbers-arrays be
moved to commons-number-core?
Done in NUMBERS-159.
There it was mentioned that module {{commons-numbers-arrays}} (only containing
the {{MultidimensionalCounter}} class) might not be part of the v1.0 release.
However, I've just found a usage occurrence (through CM v3.6.1) of that class.
was (Author: erans):
bq. Shouldn't some functionality currently in module commons-numbers-arrays be
moved to commons-number-core?
Done in NUMBERS-159.
> About modules "arrays" and "rootfinder"
> ---
>
> Key: NUMBERS-155
> URL: https://issues.apache.org/jira/browse/NUMBERS-155
> Project: Commons Numbers
> Issue Type: Task
> Components: arrays, core
>Affects Versions: 1.0-beta1
>Reporter: Gilles Sadowski
>Priority: Major
> Labels: refactoring
> Fix For: 1.0
>
>
> Shouldn't some functionality currently in module {{commons-numbers-arrays}}
> be moved to {{commons-number-core}}?
> Rationale is that the utilities focus on extended precision of some
> computations (on numbers that happen to be stored in an array).
> Wouldn't the Brent solver (in module {{commons-numbers-rootfinder}}) benefit
> from a version based on the new {{ExtendedPrecision}} class?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NUMBERS-155) About modules "arrays" and "rootfinder"
[
https://issues.apache.org/jira/browse/NUMBERS-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361596#comment-17361596
]
Gilles Sadowski commented on NUMBERS-155:
-
bq. Shouldn't some functionality currently in module commons-numbers-arrays be
moved to commons-number-core?
Done in NUMBERS-159.
> About modules "arrays" and "rootfinder"
> ---
>
> Key: NUMBERS-155
> URL: https://issues.apache.org/jira/browse/NUMBERS-155
> Project: Commons Numbers
> Issue Type: Task
> Components: arrays, core
>Affects Versions: 1.0-beta1
>Reporter: Gilles Sadowski
>Priority: Major
> Labels: refactoring
> Fix For: 1.0
>
>
> Shouldn't some functionality currently in module {{commons-numbers-arrays}}
> be moved to {{commons-number-core}}?
> Rationale is that the utilities focus on extended precision of some
> computations (on numbers that happen to be stored in an array).
> Wouldn't the Brent solver (in module {{commons-numbers-rootfinder}}) benefit
> from a version based on the new {{ExtendedPrecision}} class?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (NUMBERS-25) Check list for first release
[
https://issues.apache.org/jira/browse/NUMBERS-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles Sadowski updated NUMBERS-25:
---
Description:
List of tasks to complete before considering a first release.
* (x) Review public API
* Ensure clean project reports
** (/) JIRA
** (/) Surefire
** (/) RAT
** (/) Jacoco
** (/) SpotBugs
** (/) Checkstyle
** (x) PMD
** (x) CPD
* Ensure that "Commons Math" ("master" branch) compiles and pass all unit
tests when
** (x) dependencies to "Commons Numbers" modules are added and
** (x) all classes that have an equivalent in "Commons Numbers" are deleted
(MATH-1416).
* (x) User guide
* (/) Rename licence files (NUMBERS-146)
* (/)
[Jenkins|https://builds.apache.org/view/Apache%20Commons/job/Commons_Numbers]
* (/) [Web site|http://commons.apache.org/numbers]
* (/) [GitHub|https://github.com/apache/commons-numbers]
* (/) [Travis|https://travis-ci.com/apache/commons-numbers]
* (/) [Coveralls|https://coveralls.io/github/apache/commons-numbers]
* (/) Remove "@since" Javadoc tags
* (/) Code coverage (Jacoco)
Modules *not* to be released in v1.0:
* commons-numbers-complex-streams
was:
List of tasks to complete before considering a first release.
* (x) Review public API
* Ensure clean project reports
** (/) JIRA
** (/) Surefire
** (/) RAT
** (/) Jacoco
** (/) SpotBugs
** (/) Checkstyle
** (x) PMD
** (x) CPD
* Ensure that "Commons Math" ("master" branch) compiles and pass all unit
tests when
** (x) dependencies to "Commons Numbers" modules are added and
** (x) all classes that have an equivalent in "Commons Numbers" are deleted
(MATH-1416).
* (x) User guide
* (/) Rename licence files (NUMBERS-146)
* (/)
[Jenkins|https://builds.apache.org/view/Apache%20Commons/job/Commons_Numbers]
* (/) [Web site|http://commons.apache.org/numbers]
* (/) [GitHub|https://github.com/apache/commons-numbers]
* (/) [Travis|https://travis-ci.com/apache/commons-numbers]
* (/) [Coveralls|https://coveralls.io/github/apache/commons-numbers]
* (/) Remove "@since" Javadoc tags
* (/) Code coverage (Jacoco)
Modules *not* to be released in v1.0:
* commons-numbers-arrays
* commons-numbers-complex-streams
> Check list for first release
>
>
> Key: NUMBERS-25
> URL: https://issues.apache.org/jira/browse/NUMBERS-25
> Project: Commons Numbers
> Issue Type: Task
>Reporter: Gilles Sadowski
>Priority: Major
> Labels: release, tasks
> Fix For: 1.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> List of tasks to complete before considering a first release.
> * (x) Review public API
> * Ensure clean project reports
> ** (/) JIRA
> ** (/) Surefire
> ** (/) RAT
> ** (/) Jacoco
> ** (/) SpotBugs
> ** (/) Checkstyle
> ** (x) PMD
> ** (x) CPD
> * Ensure that "Commons Math" ("master" branch) compiles and pass all unit
> tests when
> ** (x) dependencies to "Commons Numbers" modules are added and
> ** (x) all classes that have an equivalent in "Commons Numbers" are deleted
> (MATH-1416).
> * (x) User guide
> * (/) Rename licence files (NUMBERS-146)
> * (/)
> [Jenkins|https://builds.apache.org/view/Apache%20Commons/job/Commons_Numbers]
> * (/) [Web site|http://commons.apache.org/numbers]
> * (/) [GitHub|https://github.com/apache/commons-numbers]
> * (/) [Travis|https://travis-ci.com/apache/commons-numbers]
> * (/) [Coveralls|https://coveralls.io/github/apache/commons-numbers]
> * (/) Remove "@since" Javadoc tags
> * (/) Code coverage (Jacoco)
> Modules *not* to be released in v1.0:
> * commons-numbers-complex-streams
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IO-740) RegexFileFilter matches on full path instead of filename
Tom Jorissen created IO-740:
---
Summary: RegexFileFilter matches on full path instead of filename
Key: IO-740
URL: https://issues.apache.org/jira/browse/IO-740
Project: Commons IO
Issue Type: Bug
Components: Filters
Affects Versions: 2.9.0
Reporter: Tom Jorissen
org.apache.commons.io.filefilter.RegexFileFilter#accept(java.nio.file.Path,
java.nio.file.attribute.BasicFileAttributes) is a new method added in 2.9.0 and
it's javadoc states:
{code:java}
/**
* Checks to see if the file name matches one of the regular expressions.
*
* @param path the path
* @param attributes the path attributes
* @return true if the file name matches one of the regular expressions
*/
{code}
However in it's implementation:
{code:java}
return toFileVisitResult(pattern.matcher(path.toString()).matches(), path);
{code}
it matches on path.toString() which will be the full path instead of the
filename.
This is also inconsistent with the other method
org.apache.commons.io.filefilter.RegexFileFilter#accept(java.io.File,
java.lang.String) which does match only on filename.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
