[PR] new Validator CASNumberCheckDigit for Chemical Registry CAS Numbers [commons-validator]
homebeaver opened a new pull request, #210: URL: https://github.com/apache/commons-validator/pull/210 CASNumberCheckDigit - CAS Chemical Abstracts Service RN Registry No CAS Numbers are unique identification numbers used to identify chemical substance described in the open scientific literature. see [wikipedia CAS_Registry_Number](https://en.wikipedia.org/wiki/CAS_Registry_Number) regards -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (LANG-1729) NumberUtils.isParsable() returns true for Fullwidth Unicode digits
[
https://issues.apache.org/jira/browse/LANG-1729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840426#comment-17840426
]
Gary D. Gregory edited comment on LANG-1729 at 4/24/24 8:45 PM:
The links to JDK bugs seem broken.
Maybe this one instead: https://bugs.openjdk.org/browse/JDK-8326627
Note that is (need to test some more) if fixed in Java 23-ea
{noformat}
openjdk version "23-ea" 2024-09-17
OpenJDK Runtime Environment (build 23-ea+18-1469)
OpenJDK 64-Bit Server VM (build 23-ea+18-1469, mixed mode, sharing)
{noformat}
See org.apache.commons.lang3.math.NumberUtilsTest.testIsParsableLang1729()
was (Author: garydgregory):
The links to JDK bugs seem broken.
Note that is (need to test some more) if fixed in Java 23-ea
{noformat}
openjdk version "23-ea" 2024-09-17
OpenJDK Runtime Environment (build 23-ea+18-1469)
OpenJDK 64-Bit Server VM (build 23-ea+18-1469, mixed mode, sharing)
{noformat}
See org.apache.commons.lang3.math.NumberUtilsTest.testIsParsableLang1729()
> NumberUtils.isParsable() returns true for Fullwidth Unicode digits
> --
>
> Key: LANG-1729
> URL: https://issues.apache.org/jira/browse/LANG-1729
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.math.*
>Affects Versions: 3.14.0
>Reporter: Andrei Anischevici
>Priority: Major
>
> *NumberUtils.isParsable()* returns *true* for Fullwidth Unicode digits
> (U+FF10 to U+FF19, see
> [https://en.wikipedia.org/wiki/Halfwidth_and_Fullwidth_Forms_(Unicode_block)]),
> even though these cannot be parsed by *Double.parseDouble()* and
> {*}Float.parseFloat(){*}, as {*}NumberFormatException{*}s are thrown when
> trying to parse these.
> I've also opened a JDK bug, see
> [https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8326627] and
> [https://bugs.openjdk.org/projects/JDK/issues/JDK-8326627]
> Since the underlying issue is that *Character.isDigit()* returns *true* for
> fullwidth digits and until this is fixed in the JDK, it would be great to fix
> this in *NumberUtils.isParsable()* so that it would return *false* for
> Fullwidth Unicode digits.
> Gist reproducing the issue:
> [https://gist.github.com/XDex/2e300189a07e8224524100f26b5f6b46]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (LANG-1729) NumberUtils.isParsable() returns true for Fullwidth Unicode digits
[
https://issues.apache.org/jira/browse/LANG-1729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840426#comment-17840426
]
Gary D. Gregory edited comment on LANG-1729 at 4/24/24 8:44 PM:
The links to JDK bugs seem broken.
Note that is (need to test some more) if fixed in Java 23-ea
{noformat}
openjdk version "23-ea" 2024-09-17
OpenJDK Runtime Environment (build 23-ea+18-1469)
OpenJDK 64-Bit Server VM (build 23-ea+18-1469, mixed mode, sharing)
{noformat}
See org.apache.commons.lang3.math.NumberUtilsTest.testIsParsableLang1729()
was (Author: garydgregory):
Note that is if fixed in Java 23-ea
{noformat}
openjdk version "23-ea" 2024-09-17
OpenJDK Runtime Environment (build 23-ea+18-1469)
OpenJDK 64-Bit Server VM (build 23-ea+18-1469, mixed mode, sharing)
{noformat}
See org.apache.commons.lang3.math.NumberUtilsTest.testIsParsableLang1729()
> NumberUtils.isParsable() returns true for Fullwidth Unicode digits
> --
>
> Key: LANG-1729
> URL: https://issues.apache.org/jira/browse/LANG-1729
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.math.*
>Affects Versions: 3.14.0
>Reporter: Andrei Anischevici
>Priority: Major
>
> *NumberUtils.isParsable()* returns *true* for Fullwidth Unicode digits
> (U+FF10 to U+FF19, see
> [https://en.wikipedia.org/wiki/Halfwidth_and_Fullwidth_Forms_(Unicode_block)]),
> even though these cannot be parsed by *Double.parseDouble()* and
> {*}Float.parseFloat(){*}, as {*}NumberFormatException{*}s are thrown when
> trying to parse these.
> I've also opened a JDK bug, see
> [https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8326627] and
> [https://bugs.openjdk.org/projects/JDK/issues/JDK-8326627]
> Since the underlying issue is that *Character.isDigit()* returns *true* for
> fullwidth digits and until this is fixed in the JDK, it would be great to fix
> this in *NumberUtils.isParsable()* so that it would return *false* for
> Fullwidth Unicode digits.
> Gist reproducing the issue:
> [https://gist.github.com/XDex/2e300189a07e8224524100f26b5f6b46]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] (LANG-1729) NumberUtils.isParsable() returns true for Fullwidth Unicode digits
[ https://issues.apache.org/jira/browse/LANG-1729 ]
Gary D. Gregory deleted comment on LANG-1729:
---
was (Author: garydgregory):
But Integer.parseInt() works.
> NumberUtils.isParsable() returns true for Fullwidth Unicode digits
> --
>
> Key: LANG-1729
> URL: https://issues.apache.org/jira/browse/LANG-1729
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.math.*
>Affects Versions: 3.14.0
>Reporter: Andrei Anischevici
>Priority: Major
>
> *NumberUtils.isParsable()* returns *true* for Fullwidth Unicode digits
> (U+FF10 to U+FF19, see
> [https://en.wikipedia.org/wiki/Halfwidth_and_Fullwidth_Forms_(Unicode_block)]),
> even though these cannot be parsed by *Double.parseDouble()* and
> {*}Float.parseFloat(){*}, as {*}NumberFormatException{*}s are thrown when
> trying to parse these.
> I've also opened a JDK bug, see
> [https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8326627] and
> [https://bugs.openjdk.org/projects/JDK/issues/JDK-8326627]
> Since the underlying issue is that *Character.isDigit()* returns *true* for
> fullwidth digits and until this is fixed in the JDK, it would be great to fix
> this in *NumberUtils.isParsable()* so that it would return *false* for
> Fullwidth Unicode digits.
> Gist reproducing the issue:
> [https://gist.github.com/XDex/2e300189a07e8224524100f26b5f6b46]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CONFIGURATION-831) Unresolved (non-existend) environment variables should return null
[
https://issues.apache.org/jira/browse/CONFIGURATION-831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840565#comment-17840565
]
Ricardo Mendes edited comment on CONFIGURATION-831 at 4/24/24 8:20 PM:
---
As someone who uses this quite often I always have to find unorthodox ways of
validating the return of a variable which is not set.
*Config File*
{code:sh}
#test.properties
NOT_FOUND=${env:NOT_FOUND}{code}
*Example*
{code:java}
System.out.println(config.getString("NOT_FOUND")); {code}
*Output*
{code:bash}
${env:NOT_FOUND} {code}
{{{}$\{env:VARIABLE{ pointing to no value should either return
*{{(prefered)}}* {{empty string }}or {{null}} and not the unexpanded variable.
I would like to work on this. Do you guys think it is worth it?
was (Author: JIRAUSER305224):
As someone who uses this quite often I always have to find unorthodox ways of
validating the return of a variable which is not set.
*Config File*
{code:sh}
#test.properties
NOT_FOUND=${env:NOT_FOUND}{code}
*Example*
{code:java}
System.out.println(config.getString("NOT_FOUND")); {code}
*Output*
{code:bash}
${env:NOT_FOUND} {code}
{{{}$\{env:VARIABLE{ pointing to no value should either return
*{{(prefered)}}* {{empty string }}or {{null}} and not the unexpanded variable.
I would like to work on this. Do you guys think it is worth it?
> Unresolved (non-existend) environment variables should return null
> --
>
> Key: CONFIGURATION-831
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-831
> Project: Commons Configuration
> Issue Type: New Feature
> Components: Interpolation
>Affects Versions: 2.9.0
>Reporter: Wojtek
>Priority: Minor
>
> Currently Interpolation of environment variables
> (https://commons.apache.org/proper/commons-configuration/userguide/howto_basicfeatures.html#Variable_Interpolation)
> return un-interpolated string if the environment variable doesn't exists at
> all.
> It would be very convenient and (I feel) more consistent if, in that case,
> 'null' would be returned.
>
> Alternatively, option to specify default if the variable doesn't exist would
> also work.
> I.e. something along the lines:
> ```
> ${env:JAVA_HOME:}
> ```
>
> From my experiments, even if we try to register custom interpolator it's not
> possible to explicitly return `null` from it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CONFIGURATION-831) Unresolved (non-existend) environment variables should return null
[
https://issues.apache.org/jira/browse/CONFIGURATION-831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840565#comment-17840565
]
Ricardo Mendes commented on CONFIGURATION-831:
--
As someone who uses this quite often I always have to find unorthodox ways of
validating the return of a variable which is not set.
*Config File*
{code:sh}
#test.properties
NOT_FOUND=${env:NOT_FOUND}{code}
*Example*
{code:java}
System.out.println(config.getString("NOT_FOUND")); {code}
*Output*
{code:bash}
${env:NOT_FOUND} {code}
{{{}$\{env:VARIABLE{ pointing to no value should either return
*{{(prefered)}}* {{empty string }}or {{null}} and not the unexpanded variable.
I would like to work on this. Do you guys think it is worth it?
> Unresolved (non-existend) environment variables should return null
> --
>
> Key: CONFIGURATION-831
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-831
> Project: Commons Configuration
> Issue Type: New Feature
> Components: Interpolation
>Affects Versions: 2.9.0
>Reporter: Wojtek
>Priority: Minor
>
> Currently Interpolation of environment variables
> (https://commons.apache.org/proper/commons-configuration/userguide/howto_basicfeatures.html#Variable_Interpolation)
> return un-interpolated string if the environment variable doesn't exists at
> all.
> It would be very convenient and (I feel) more consistent if, in that case,
> 'null' would be returned.
>
> Alternatively, option to specify default if the variable doesn't exist would
> also work.
> I.e. something along the lines:
> ```
> ${env:JAVA_HOME:}
> ```
>
> From my experiments, even if we try to register custom interpolator it's not
> possible to explicitly return `null` from it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LANG-1729) NumberUtils.isParsable() returns true for Fullwidth Unicode digits
[
https://issues.apache.org/jira/browse/LANG-1729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840553#comment-17840553
]
Gary D. Gregory commented on LANG-1729:
---
But Integer.parseInt() works.
> NumberUtils.isParsable() returns true for Fullwidth Unicode digits
> --
>
> Key: LANG-1729
> URL: https://issues.apache.org/jira/browse/LANG-1729
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.math.*
>Affects Versions: 3.14.0
>Reporter: Andrei Anischevici
>Priority: Major
>
> *NumberUtils.isParsable()* returns *true* for Fullwidth Unicode digits
> (U+FF10 to U+FF19, see
> [https://en.wikipedia.org/wiki/Halfwidth_and_Fullwidth_Forms_(Unicode_block)]),
> even though these cannot be parsed by *Double.parseDouble()* and
> {*}Float.parseFloat(){*}, as {*}NumberFormatException{*}s are thrown when
> trying to parse these.
> I've also opened a JDK bug, see
> [https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8326627] and
> [https://bugs.openjdk.org/projects/JDK/issues/JDK-8326627]
> Since the underlying issue is that *Character.isDigit()* returns *true* for
> fullwidth digits and until this is fixed in the JDK, it would be great to fix
> this in *NumberUtils.isParsable()* so that it would return *false* for
> Fullwidth Unicode digits.
> Gist reproducing the issue:
> [https://gist.github.com/XDex/2e300189a07e8224524100f26b5f6b46]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (LANG-1702) TypeUtils.unrollVariables can cause a StackException for parameterized inner class
[ https://issues.apache.org/jira/browse/LANG-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved LANG-1702. --- Fix Version/s: 3.15.0 Resolution: Fixed > TypeUtils.unrollVariables can cause a StackException for parameterized inner > class > -- > > Key: LANG-1702 > URL: https://issues.apache.org/jira/browse/LANG-1702 > Project: Commons Lang > Issue Type: Bug > Components: lang.reflect.* >Affects Versions: 3.12.0 >Reporter: Renny Barrett >Priority: Major > Fix For: 3.15.0 > > Attachments: TestTypeUtilsUnwrap.java > > > If TypeUtils.unrollVariables is called for a type which is a non-static inner > class where the inner class and its enclosing class both have type > parameters, then there's an infinite recursion which results in a > StackOverflow error. > > Simple test code that recreates the issue is attached. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LANG-1702) TypeUtils.unrollVariables can cause a StackException for parameterized inner class
[
https://issues.apache.org/jira/browse/LANG-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840541#comment-17840541
]
Gary D. Gregory commented on LANG-1702:
---
OP attachment for easier viewing:
{code:java}
package com.test;
import java.lang.reflect.Type;
import java.lang.reflect.TypeVariable;
import java.util.Collections;
import java.util.Map;
import org.apache.commons.lang3.reflect.TypeUtils;
//this top-level class is parameterised
public class TestTypeUtilsUnwrap {
// this non-static inner class is parameterised
public class MyInnerClass {
}
// the inner class is used as a return type from a method
public MyInnerClass aMethod() {
return null;
}
public static void main(final String... args) throws NoSuchMethodException,
SecurityException {
final Type type =
TestTypeUtilsUnwrap.class.getDeclaredMethod("aMethod").getGenericReturnType();
// any map will do
final Map, Type> typeArguments = Collections.emptyMap();
// this fails with a stack overflow
final Type unrolledType = TypeUtils.unrollVariables(typeArguments,
type);
}
}
{code}
> TypeUtils.unrollVariables can cause a StackException for parameterized inner
> class
> --
>
> Key: LANG-1702
> URL: https://issues.apache.org/jira/browse/LANG-1702
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.reflect.*
>Affects Versions: 3.12.0
>Reporter: Renny Barrett
>Priority: Major
> Attachments: TestTypeUtilsUnwrap.java
>
>
> If TypeUtils.unrollVariables is called for a type which is a non-static inner
> class where the inner class and its enclosing class both have type
> parameters, then there's an infinite recursion which results in a
> StackOverflow error.
>
> Simple test code that recreates the issue is attached.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (COMPRESS-677) ZipArchiveOutputStream:setEncoding(String) with a null value throws IllegalArgumentException
[
https://issues.apache.org/jira/browse/COMPRESS-677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeffrey Adamson updated COMPRESS-677:
-
Description:
Javadocs specify that ZipArchiveOutputStream setEncoding(java.lang.String) with
null should use the platform's default encoding. In 1.26.1 a null value throws
an IllegalArgumentException.
{code:java}
import java.io.File;
import org.apache.commons.compress.archivers.zip.ZipArchiveOutputStream;
public class Main {
public static void main(String[] args)
throws Exception {
ZipArchiveOutputStream zaos = new ZipArchiveOutputStream(new
File("/dev/null"));
zaos.setEncoding((String)null);
System.out.println("Success");
}
} {code}
In commons-compress 1.26.0 and earlier this code prints "Success" and exits
without exception.
In commons-compress 1.26.1 the result is a stack trace:
{noformat}
Exception in thread "main" java.lang.IllegalArgumentException: Null charset name
at java.base/java.nio.charset.Charset.lookup(Charset.java:455)
at java.base/java.nio.charset.Charset.forName(Charset.java:526)
at
org.apache.commons.compress.archivers.zip.ZipArchiveOutputStream.setEncoding(ZipArchiveOutputStream.java:1340)
at Main.main(Test:11)
{noformat}
This appears to be related to the change in the method implementation during
03c253335fe9c61f14eb9bb95324de1ec383ec48 2024-03-04 16:52:22
was:
Javadocs specify that ZipArchiveOutputStream setEncoding(java.lang.String) with
null should use the platform's default encoding. In 1.26.1 a null value throws
an IllegalArgumentException.
{code:java}
import java.io.File;
import org.apache.commons.compress.archivers.zip.ZipArchiveOutputStream;
public class Main {
public static void main(String[] args)
throws Exception {
ZipArchiveOutputStream zaos = new ZipArchiveOutputStream(new
File("/dev/null"));
zaos.setEncoding((String)null);
System.out.println("Success");
}
} {code}
In commons-compress 1.26.0 and earlier this code prints "Success" and exists
without exception.
In commons-compress 1.26.1 the result is a stack trace:
{noformat}
Exception in thread "main" java.lang.IllegalArgumentException: Null charset name
at java.base/java.nio.charset.Charset.lookup(Charset.java:455)
at java.base/java.nio.charset.Charset.forName(Charset.java:526)
at
org.apache.commons.compress.archivers.zip.ZipArchiveOutputStream.setEncoding(ZipArchiveOutputStream.java:1340)
at Main.main(Test:11)
{noformat}
This appears to be related to the change in the method implementation during
03c253335fe9c61f14eb9bb95324de1ec383ec48 2024-03-04 16:52:22
> ZipArchiveOutputStream:setEncoding(String) with a null value throws
> IllegalArgumentException
>
>
> Key: COMPRESS-677
> URL: https://issues.apache.org/jira/browse/COMPRESS-677
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.26.1
>Reporter: Jeffrey Adamson
>Priority: Major
>
> Javadocs specify that ZipArchiveOutputStream setEncoding(java.lang.String)
> with null should use the platform's default encoding. In 1.26.1 a null value
> throws an IllegalArgumentException.
> {code:java}
> import java.io.File;
> import org.apache.commons.compress.archivers.zip.ZipArchiveOutputStream;
> public class Main {
> public static void main(String[] args)
> throws Exception {
> ZipArchiveOutputStream zaos = new ZipArchiveOutputStream(new
> File("/dev/null"));
> zaos.setEncoding((String)null);
> System.out.println("Success");
> }
> } {code}
> In commons-compress 1.26.0 and earlier this code prints "Success" and exits
> without exception.
> In commons-compress 1.26.1 the result is a stack trace:
> {noformat}
> Exception in thread "main" java.lang.IllegalArgumentException: Null charset
> name
> at java.base/java.nio.charset.Charset.lookup(Charset.java:455)
> at java.base/java.nio.charset.Charset.forName(Charset.java:526)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveOutputStream.setEncoding(ZipArchiveOutputStream.java:1340)
> at Main.main(Test:11)
> {noformat}
> This appears to be related to the change in the method implementation during
> 03c253335fe9c61f14eb9bb95324de1ec383ec48 2024-03-04 16:52:22
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (COMPRESS-677) ZipArchiveOutputStream:setEncoding(String) with a null value throws IllegalArgumentException
[
https://issues.apache.org/jira/browse/COMPRESS-677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeffrey Adamson updated COMPRESS-677:
-
Description:
Javadocs specify that ZipArchiveOutputStream setEncoding(java.lang.String) with
null should use the platform's default encoding. In 1.26.1 a null value throws
an IllegalArgumentException.
{code:java}
import java.io.File;
import org.apache.commons.compress.archivers.zip.ZipArchiveOutputStream;
public class Main {
public static void main(String[] args)
throws Exception {
ZipArchiveOutputStream zaos = new ZipArchiveOutputStream(new
File("/dev/null"));
zaos.setEncoding((String)null);
System.out.println("Success");
}
} {code}
In commons-compress 1.26.0 and earlier this code prints "Success" and exists
without exception.
In commons-compress 1.26.1 the result is a stack trace:
{noformat}
Exception in thread "main" java.lang.IllegalArgumentException: Null charset name
at java.base/java.nio.charset.Charset.lookup(Charset.java:455)
at java.base/java.nio.charset.Charset.forName(Charset.java:526)
at
org.apache.commons.compress.archivers.zip.ZipArchiveOutputStream.setEncoding(ZipArchiveOutputStream.java:1340)
at Main.main(Test:11)
{noformat}
This appears to be related to the change in the method implementation during
03c253335fe9c61f14eb9bb95324de1ec383ec48 2024-03-04 16:52:22
was:
Javadocs specify that ZipArchiveOutputStream setEncoding(java.lang.String)
should use the platform's default encoding. In 1.26.1 a null value throws an
IllegalArgumentException.
{code:java}
import java.io.File;
import org.apache.commons.compress.archivers.zip.ZipArchiveOutputStream;
public class Main {
public static void main(String[] args)
throws Exception {
ZipArchiveOutputStream zaos = new ZipArchiveOutputStream(new
File("/dev/null"));
zaos.setEncoding((String)null);
System.out.println("Success");
}
} {code}
In commons-compress 1.26.0 and earlier this code prints "Success" and exists
without exception.
In commons-compress 1.26.1 the result is a stack trace:
{noformat}
Exception in thread "main" java.lang.IllegalArgumentException: Null charset name
at java.base/java.nio.charset.Charset.lookup(Charset.java:455)
at java.base/java.nio.charset.Charset.forName(Charset.java:526)
at
org.apache.commons.compress.archivers.zip.ZipArchiveOutputStream.setEncoding(ZipArchiveOutputStream.java:1340)
at Main.main(Test:11)
{noformat}
This appears to be related to the change in the method implementation during
03c253335fe9c61f14eb9bb95324de1ec383ec48 2024-03-04 16:52:22
> ZipArchiveOutputStream:setEncoding(String) with a null value throws
> IllegalArgumentException
>
>
> Key: COMPRESS-677
> URL: https://issues.apache.org/jira/browse/COMPRESS-677
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.26.1
>Reporter: Jeffrey Adamson
>Priority: Major
>
> Javadocs specify that ZipArchiveOutputStream setEncoding(java.lang.String)
> with null should use the platform's default encoding. In 1.26.1 a null value
> throws an IllegalArgumentException.
> {code:java}
> import java.io.File;
> import org.apache.commons.compress.archivers.zip.ZipArchiveOutputStream;
> public class Main {
> public static void main(String[] args)
> throws Exception {
> ZipArchiveOutputStream zaos = new ZipArchiveOutputStream(new
> File("/dev/null"));
> zaos.setEncoding((String)null);
> System.out.println("Success");
> }
> } {code}
> In commons-compress 1.26.0 and earlier this code prints "Success" and exists
> without exception.
> In commons-compress 1.26.1 the result is a stack trace:
> {noformat}
> Exception in thread "main" java.lang.IllegalArgumentException: Null charset
> name
> at java.base/java.nio.charset.Charset.lookup(Charset.java:455)
> at java.base/java.nio.charset.Charset.forName(Charset.java:526)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveOutputStream.setEncoding(ZipArchiveOutputStream.java:1340)
> at Main.main(Test:11)
> {noformat}
> This appears to be related to the change in the method implementation during
> 03c253335fe9c61f14eb9bb95324de1ec383ec48 2024-03-04 16:52:22
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (COMPRESS-677) ZipArchiveOutputStream:setEncoding(String) with a null value throws IllegalArgumentException
Jeffrey Adamson created COMPRESS-677:
Summary: ZipArchiveOutputStream:setEncoding(String) with a null
value throws IllegalArgumentException
Key: COMPRESS-677
URL: https://issues.apache.org/jira/browse/COMPRESS-677
Project: Commons Compress
Issue Type: Bug
Affects Versions: 1.26.1
Reporter: Jeffrey Adamson
Javadocs specify that ZipArchiveOutputStream setEncoding(java.lang.String)
should use the platform's default encoding. In 1.26.1 a null value throws an
IllegalArgumentException.
{code:java}
import java.io.File;
import org.apache.commons.compress.archivers.zip.ZipArchiveOutputStream;
public class Main {
public static void main(String[] args)
throws Exception {
ZipArchiveOutputStream zaos = new ZipArchiveOutputStream(new
File("/dev/null"));
zaos.setEncoding((String)null);
System.out.println("Success");
}
} {code}
In commons-compress 1.26.0 and earlier this code prints "Success" and exists
without exception.
In commons-compress 1.26.1 the result is a stack trace:
{noformat}
Exception in thread "main" java.lang.IllegalArgumentException: Null charset name
at java.base/java.nio.charset.Charset.lookup(Charset.java:455)
at java.base/java.nio.charset.Charset.forName(Charset.java:526)
at
org.apache.commons.compress.archivers.zip.ZipArchiveOutputStream.setEncoding(ZipArchiveOutputStream.java:1340)
at Main.main(Test:11)
{noformat}
This appears to be related to the change in the method implementation during
03c253335fe9c61f14eb9bb95324de1ec383ec48 2024-03-04 16:52:22
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [LANG-1524] : Added cycle detection check in toString for classes [commons-lang]
garydgregory commented on PR #657: URL: https://github.com/apache/commons-lang/pull/657#issuecomment-2075206328 Hello @aakashgupta96 Thank you for your PR. This issue has been addressed differently in git master by always returning a string, not throwing an exception. You have nevertheless been credited in `changes.xml` :-) Closing this PR. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] [LANG-1524] : Added cycle detection check in toString for classes [commons-lang]
garydgregory closed pull request #657: [LANG-1524] : Added cycle detection check in toString for classes URL: https://github.com/apache/commons-lang/pull/657 -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Resolved] (LANG-1524) TypeUtils.toString StackOverflowError for an inner class in the inner class parameterized enclosing class.
[
https://issues.apache.org/jira/browse/LANG-1524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved LANG-1524.
---
Fix Version/s: 3.15.0
Resolution: Fixed
> TypeUtils.toString StackOverflowError for an inner class in the inner class
> parameterized enclosing class.
> --
>
> Key: LANG-1524
> URL: https://issues.apache.org/jira/browse/LANG-1524
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.reflect.*
>Affects Versions: 3.9
>Reporter: kijong.youn
>Priority: Major
> Fix For: 3.15.0
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> StackOverflowError occurred on toString for an inner class in the inner class
> parameterized enclosing class.
>
> source:
> {code:java}
> public class Test {
> public static class Inner {
> }
> public static void main(final String[] args) {
> System.out.println(TypeUtils.toString(Inner.class));
> }
> } {code}
> result:
> {code:java}
> Exception in thread "main" java.lang.StackOverflowErrorException in thread
> "main" java.lang.StackOverflowError at
> java.lang.Class.getEnclosingMethodInfo(Class.java:1072) at
> java.lang.Class.getEnclosingClass(Class.java:1272) at
> org.apache.commons.lang3.reflect.TypeUtils.classToString(TypeUtils.java:1751)
> at org.apache.commons.lang3.reflect.TypeUtils.toString(TypeUtils.java:1663)
> at org.apache.commons.lang3.reflect.TypeUtils.toString(TypeUtils.java:1891)
> at
> org.apache.commons.lang3.reflect.TypeUtils.appendAllTo(TypeUtils.java:1882)
> at
> org.apache.commons.lang3.reflect.TypeUtils.typeVariableToString(TypeUtils.java:1775)
> at org.apache.commons.lang3.reflect.TypeUtils.toString(TypeUtils.java:1672)
> at org.apache.commons.lang3.reflect.TypeUtils.toString(TypeUtils.java:1891)
> at
> org.apache.commons.lang3.reflect.TypeUtils.appendAllTo(TypeUtils.java:1882)
> at
> org.apache.commons.lang3.reflect.TypeUtils.classToString(TypeUtils.java:1758)
> at
> org.apache.commons.lang3.reflect.TypeUtils.classToString(TypeUtils.java:1752)
> ...{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (LANG-1524) TypeUtils.toString StackOverflowError for an inner class in the inner class parameterized enclosing class.
[
https://issues.apache.org/jira/browse/LANG-1524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840483#comment-17840483
]
Gary D. Gregory edited comment on LANG-1524 at 4/24/24 3:20 PM:
Resolved in git master.
was (Author: garydgregory):
> TypeUtils.toString StackOverflowError for an inner class in the inner class
> parameterized enclosing class.
> --
>
> Key: LANG-1524
> URL: https://issues.apache.org/jira/browse/LANG-1524
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.reflect.*
>Affects Versions: 3.9
>Reporter: kijong.youn
>Priority: Major
> Fix For: 3.15.0
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> StackOverflowError occurred on toString for an inner class in the inner class
> parameterized enclosing class.
>
> source:
> {code:java}
> public class Test {
> public static class Inner {
> }
> public static void main(final String[] args) {
> System.out.println(TypeUtils.toString(Inner.class));
> }
> } {code}
> result:
> {code:java}
> Exception in thread "main" java.lang.StackOverflowErrorException in thread
> "main" java.lang.StackOverflowError at
> java.lang.Class.getEnclosingMethodInfo(Class.java:1072) at
> java.lang.Class.getEnclosingClass(Class.java:1272) at
> org.apache.commons.lang3.reflect.TypeUtils.classToString(TypeUtils.java:1751)
> at org.apache.commons.lang3.reflect.TypeUtils.toString(TypeUtils.java:1663)
> at org.apache.commons.lang3.reflect.TypeUtils.toString(TypeUtils.java:1891)
> at
> org.apache.commons.lang3.reflect.TypeUtils.appendAllTo(TypeUtils.java:1882)
> at
> org.apache.commons.lang3.reflect.TypeUtils.typeVariableToString(TypeUtils.java:1775)
> at org.apache.commons.lang3.reflect.TypeUtils.toString(TypeUtils.java:1672)
> at org.apache.commons.lang3.reflect.TypeUtils.toString(TypeUtils.java:1891)
> at
> org.apache.commons.lang3.reflect.TypeUtils.appendAllTo(TypeUtils.java:1882)
> at
> org.apache.commons.lang3.reflect.TypeUtils.classToString(TypeUtils.java:1758)
> at
> org.apache.commons.lang3.reflect.TypeUtils.classToString(TypeUtils.java:1752)
> ...{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] Bump commons.bytebuddy.version from 1.14.13 to 1.14.14 [commons-io]
garydgregory merged PR #615: URL: https://github.com/apache/commons-io/pull/615 -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Add StringUtils.notEqual and StringUtils.notEqualIgnoreCase methods [commons-lang]
tomohavvk closed pull request #1205: Add StringUtils.notEqual and StringUtils.notEqualIgnoreCase methods URL: https://github.com/apache/commons-lang/pull/1205 -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Amend description of FilenameUtils#getFullPathNoEndSeparator(String) to reflect correct named user result with trailing slash [commons-io]
garydgregory commented on PR #553: URL: https://github.com/apache/commons-io/pull/553#issuecomment-2075044939 Hello @Philzen It looks to me like git master already contains the Javadoc change. What about all the callers of the API? -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Amend description of FilenameUtils#getFullPathNoEndSeparator(String) to reflect correct named user result with trailing slash [commons-io]
Philzen commented on PR #553: URL: https://github.com/apache/commons-io/pull/553#issuecomment-2074997446 @elharo @garydgregory i totally see the points you've raised and agree it may be worth tackling the current behaviour in a bugfix. However, until that happens, i believe it will be worthwhile to sync the JavaDoc with the current behavior to minimize bad surprises when consuming the library. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Amend description to reflect empty string result for windows drive [commons-io]
Philzen commented on PR #552: URL: https://github.com/apache/commons-io/pull/552#issuecomment-2074987853 > Possibly we should deprecate this method and rethink the API here. @elharo Agreed. For the time being, any objection merging this PR to bring the JavaDoc inline with the method's actual behavior? -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Amend getFullPathNoEndSeparator description for trailing slash home path behaviour [commons-io]
Philzen commented on PR #551: URL: https://github.com/apache/commons-io/pull/551#issuecomment-2074983670 Any objections merging this? -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Resolved] (LANG-1713) ArrayUtils will return null when adding two null arrays, but undocumented
[
https://issues.apache.org/jira/browse/LANG-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved LANG-1713.
---
Resolution: Fixed
> ArrayUtils will return null when adding two null arrays, but undocumented
> -
>
> Key: LANG-1713
> URL: https://issues.apache.org/jira/browse/LANG-1713
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.13.0
>Reporter: John Hendrikx
>Priority: Minor
> Labels: Null-Safety, null
> Fix For: 3.15.0
>
>
>
> {color:#00}The code below makes use of `clone`; however `clone` will
> return `null` when the array is null.{color}
>
> {color:#00}This means that doing ArrayUtils.addAll(null, null) can return
> null. The documentation however makes it appear that this can never happen
> ("it is always a new array", and "@return The new boolean[] array."){color}
>
>
> {color:#3f5fbf}/**{color}
> {color:#3f5fbf} * {color}{color:#7f7f9f}{color}{color:#3f5fbf}Adds all the
> elements of the given arrays into a new array.{color}
> {color:#3f5fbf} * {color}{color:#7f7f9f}{color}{color:#3f5fbf}The new
> array contains all of the element of \{@code array1} followed{color}
> {color:#3f5fbf} * by all of the elements \{@code array2}. When an array is
> returned, it is always{color}
> {color:#3f5fbf} * a new array.{color}
> {color:#3f5fbf} *{color}
> {color:#3f5fbf} * {color}{color:#7f7f9f}{color}
> {color:#3f5fbf} * ArrayUtils.addAll(array1, null) = cloned copy of
> array1{color}
> {color:#3f5fbf} * ArrayUtils.addAll(null, array2) = cloned copy of
> array2{color}
> {color:#3f5fbf} * ArrayUtils.addAll([], []) = []{color}
> {color:#3f5fbf} * {color}{color:#7f7f9f}{color}
> {color:#3f5fbf} *{color}
> {color:#3f5fbf} * {color}{color:#7f9fbf}@param{color}{color:#3f5fbf} array1
> the first array whose elements are added to the new array.{color}
> {color:#3f5fbf} * {color}{color:#7f9fbf}@param{color}{color:#3f5fbf} array2
> the second array whose elements are added to the new array.{color}
> {color:#3f5fbf} * {color}{color:#7f9fbf}@return{color}{color:#3f5fbf} The new
> boolean[] array.{color}
> {color:#3f5fbf} * {color}{color:#7f9fbf}@since{color}{color:#3f5fbf}
> 2.1{color}
> {color:#3f5fbf} */{color}
> {color:#80}public{color}{color:#00}
> {color}{color:#80}static{color}{color:#00}
> {color}{color:#80}boolean{color}{color:#00}[]
> {color}{color:#00}addAll{color}{color:#00}({color}{color:#80}final{color}{color:#00}
> {color}{color:#80}boolean{color}{color:#00}[]
> {color}{color:#6a3e3e}array1{color}{color:#00},
> {color}{color:#80}final{color}{color:#00}
> {color}{color:#80}boolean{color}{color:#00}...
> {color}{color:#6a3e3e}array2{color}{color:#00}) {{color}
> {color:#80}if{color}{color:#00}
> ({color}{color:#6a3e3e}array1{color}{color:#00} ==
> {color}{color:#80}null{color}{color:#00}) {{color}
> {color:#7f0055}return{color}{color:#00}
> {color}{color:#00}clone{color}{color:#00}({color}{color:#6a3e3e}array2{color}{color:#00});{color}
> {color:#00} } {color}{color:#80}else{color}{color:#00}
> {color}{color:#80}if{color}{color:#00}
> ({color}{color:#6a3e3e}array2{color}{color:#00} ==
> {color}{color:#80}null{color}{color:#00}) {{color}
> {color:#7f0055}return{color}{color:#00}
> {color}{color:#00}clone{color}{color:#00}({color}{color:#6a3e3e}array1{color}{color:#00});{color}
> {color:#00} }{color}
> {color:#80}final{color}{color:#00}
> {color}{color:#80}boolean{color}{color:#00}[]
> {color}{color:#6a3e3e}joinedArray{color}{color:#00} =
> {color}{color:#80}new{color}{color:#00}
> {color}{color:#80}boolean{color}{color:#00}[{color}{color:#6a3e3e}array1{color}{color:#00}.{color}{color:#c0}length{color}{color:#00}
> +
> {color}{color:#6a3e3e}array2{color}{color:#00}.{color}{color:#c0}length{color}{color:#00}];{color}
> {color:#00}
> System.{color}{color:#00}arraycopy{color}{color:#00}({color}{color:#6a3e3e}array1{color}{color:#00},
> 0, {color}{color:#6a3e3e}joinedArray{color}{color:#00}, 0,
> {color}{color:#6a3e3e}array1{color}{color:#00}.{color}{color:#c0}length{color}{color:#00});{color}
> {color:#00}
> System.{color}{color:#00}arraycopy{color}{color:#00}({color}{color:#6a3e3e}array2{color}{color:#00},
> 0, {color}{color:#6a3e3e}joinedArray{color}{color:#00},
> {color}{color:#6a3e3e}array1{color}{color:#00}.{color}{color:#c0}length{color}{color:#00},
>
> {color}{color:#6a3e3e}array2{color}{color:#00}.{color}{color:#c0}length{color}{color:#00});{color}
>
[jira] [Comment Edited] (LANG-1729) NumberUtils.isParsable() returns true for Fullwidth Unicode digits
[
https://issues.apache.org/jira/browse/LANG-1729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840426#comment-17840426
]
Gary D. Gregory edited comment on LANG-1729 at 4/24/24 12:59 PM:
-
Note that is if fixed in Java 23-ea
{noformat}
openjdk version "23-ea" 2024-09-17
OpenJDK Runtime Environment (build 23-ea+18-1469)
OpenJDK 64-Bit Server VM (build 23-ea+18-1469, mixed mode, sharing)
{noformat}
See org.apache.commons.lang3.math.NumberUtilsTest.testIsParsableLang1729()
was (Author: garydgregory):
Note that is if fixed in Java 23-ea
{noformat}
openjdk version "23-ea" 2024-09-17
OpenJDK Runtime Environment (build 23-ea+18-1469)
OpenJDK 64-Bit Server VM (build 23-ea+18-1469, mixed mode, sharing) {noformat}
> NumberUtils.isParsable() returns true for Fullwidth Unicode digits
> --
>
> Key: LANG-1729
> URL: https://issues.apache.org/jira/browse/LANG-1729
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.math.*
>Affects Versions: 3.14.0
>Reporter: Andrei Anischevici
>Priority: Major
>
> *NumberUtils.isParsable()* returns *true* for Fullwidth Unicode digits
> (U+FF10 to U+FF19, see
> [https://en.wikipedia.org/wiki/Halfwidth_and_Fullwidth_Forms_(Unicode_block)]),
> even though these cannot be parsed by *Double.parseDouble()* and
> {*}Float.parseFloat(){*}, as {*}NumberFormatException{*}s are thrown when
> trying to parse these.
> I've also opened a JDK bug, see
> [https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8326627] and
> [https://bugs.openjdk.org/projects/JDK/issues/JDK-8326627]
> Since the underlying issue is that *Character.isDigit()* returns *true* for
> fullwidth digits and until this is fixed in the JDK, it would be great to fix
> this in *NumberUtils.isParsable()* so that it would return *false* for
> Fullwidth Unicode digits.
> Gist reproducing the issue:
> [https://gist.github.com/XDex/2e300189a07e8224524100f26b5f6b46]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LANG-1729) NumberUtils.isParsable() returns true for Fullwidth Unicode digits
[
https://issues.apache.org/jira/browse/LANG-1729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840426#comment-17840426
]
Gary D. Gregory commented on LANG-1729:
---
Note that is if fixed in Java 23-ea
{noformat}
openjdk version "23-ea" 2024-09-17
OpenJDK Runtime Environment (build 23-ea+18-1469)
OpenJDK 64-Bit Server VM (build 23-ea+18-1469, mixed mode, sharing) {noformat}
> NumberUtils.isParsable() returns true for Fullwidth Unicode digits
> --
>
> Key: LANG-1729
> URL: https://issues.apache.org/jira/browse/LANG-1729
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.math.*
>Affects Versions: 3.14.0
>Reporter: Andrei Anischevici
>Priority: Major
>
> *NumberUtils.isParsable()* returns *true* for Fullwidth Unicode digits
> (U+FF10 to U+FF19, see
> [https://en.wikipedia.org/wiki/Halfwidth_and_Fullwidth_Forms_(Unicode_block)]),
> even though these cannot be parsed by *Double.parseDouble()* and
> {*}Float.parseFloat(){*}, as {*}NumberFormatException{*}s are thrown when
> trying to parse these.
> I've also opened a JDK bug, see
> [https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8326627] and
> [https://bugs.openjdk.org/projects/JDK/issues/JDK-8326627]
> Since the underlying issue is that *Character.isDigit()* returns *true* for
> fullwidth digits and until this is fixed in the JDK, it would be great to fix
> this in *NumberUtils.isParsable()* so that it would return *false* for
> Fullwidth Unicode digits.
> Gist reproducing the issue:
> [https://gist.github.com/XDex/2e300189a07e8224524100f26b5f6b46]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] Codecov Action v4 requires token to upload coverage reports [commons-lang]
garydgregory commented on PR #1197: URL: https://github.com/apache/commons-lang/pull/1197#issuecomment-2074858535 Tracking https://issues.apache.org/jira/browse/INFRA-25729 -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (RNG-186) Commons-RNG Simple imports package that Commons-RNG Core does not export
[
https://issues.apache.org/jira/browse/RNG-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840414#comment-17840414
]
Alex Herbert commented on RNG-186:
--
In place of `Random`, at least consider `ThreadLocalRandom.current()` or a
`SplittableRandom` instance with the default increment. Both of those RNGs will
pass state-of-the-art tests for randomness (TestU01 BigCrush or PractRand for
several TiB of output). Their limitation is a period of 2^64, which is
sufficient for generating test data. They will also be faster for either true
concurrent usage (`ThreadLocalRandom`), or single thread usage
(`SplittableRandom`). Note that Random has a period of 2^48 and is effectively
synchronized using an AtomicLong for its state.
I can look at the bundle plugin. It is important for our multi-module builds to
ensure we do not get a repeat of this module issue again.
> Commons-RNG Simple imports package that Commons-RNG Core does not export
>
>
> Key: RNG-186
> URL: https://issues.apache.org/jira/browse/RNG-186
> Project: Commons RNG
> Issue Type: Task
> Components: core, simple
>Affects Versions: 1.5
>Reporter: Richard Eckart de Castilho
>Priority: Major
>
> Commons RNG Simple imports the following packages:
> {noformat}
> Bundle-SymbolicName: org.apache.commons.rng.simple
> Implementation-Version: 1.5
> Import-Package:
> org.apache.commons.rng,org.apache.commons.rng.core,
> org.apache.commons.rng.core.source32,
> org.apache.commons.rng.core.source64,
> org.apache.commons.rng.core.util
> {noformat}
> However, Commons RNG Core does not export the source packages:
> {noformat}
> Bundle-SymbolicName: org.apache.commons.rng.core
> Implementation-Version: 1.5
> Export-Package:
>
> org.apache.commons.rng.core;x-friends:="org.apache.commons.rng.simple";version="1.5.0"
> Private-Package:
> org.apache.commons.rng.core.source32,
> org.apache.commons.rng.core.source64,
> org.apache.commons.rng.core.util
> {noformat}
> Consequently, using Commons RNG simple fails in an OSGi environment as the
> bundle cannot be resolved.
> {noformat}
> [ERROR] Resolution failed. Capabilities satisfying the following requirements
> could not be found:
> [<>]
> ...
> ⇒ osgi.wiring.package:
> (&(osgi.wiring.package=org.apache.commons.rng.simple)(version>=1.5.0)(!(version>=2.0.0)))
> ⇒ [org.apache.commons.rng.simple version=1.5.0]
> ⇒ osgi.wiring.package:
> (osgi.wiring.package=org.apache.commons.rng.core.source32)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (RNG-186) Commons-RNG Simple imports package that Commons-RNG Core does not export
[
https://issues.apache.org/jira/browse/RNG-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840398#comment-17840398
]
Richard Eckart de Castilho edited comment on RNG-186 at 4/24/24 11:17 AM:
--
Thanks for the pointer for not using Random. In my case, it's a test case
though where I believe Random is quite sufficient ;) There reason I looked into
commons-rng was that it was recommended by Commons Lang as a replacement for
RandomUtils. But in my case, I think it is overkill.
was (Author: rec):
Thanks for the pointer for not using Random. In my case, it's a test case
though where I believe Random is quite sufficient ;)
> Commons-RNG Simple imports package that Commons-RNG Core does not export
>
>
> Key: RNG-186
> URL: https://issues.apache.org/jira/browse/RNG-186
> Project: Commons RNG
> Issue Type: Task
> Components: core, simple
>Affects Versions: 1.5
>Reporter: Richard Eckart de Castilho
>Priority: Major
>
> Commons RNG Simple imports the following packages:
> {noformat}
> Bundle-SymbolicName: org.apache.commons.rng.simple
> Implementation-Version: 1.5
> Import-Package:
> org.apache.commons.rng,org.apache.commons.rng.core,
> org.apache.commons.rng.core.source32,
> org.apache.commons.rng.core.source64,
> org.apache.commons.rng.core.util
> {noformat}
> However, Commons RNG Core does not export the source packages:
> {noformat}
> Bundle-SymbolicName: org.apache.commons.rng.core
> Implementation-Version: 1.5
> Export-Package:
>
> org.apache.commons.rng.core;x-friends:="org.apache.commons.rng.simple";version="1.5.0"
> Private-Package:
> org.apache.commons.rng.core.source32,
> org.apache.commons.rng.core.source64,
> org.apache.commons.rng.core.util
> {noformat}
> Consequently, using Commons RNG simple fails in an OSGi environment as the
> bundle cannot be resolved.
> {noformat}
> [ERROR] Resolution failed. Capabilities satisfying the following requirements
> could not be found:
> [<>]
> ...
> ⇒ osgi.wiring.package:
> (&(osgi.wiring.package=org.apache.commons.rng.simple)(version>=1.5.0)(!(version>=2.0.0)))
> ⇒ [org.apache.commons.rng.simple version=1.5.0]
> ⇒ osgi.wiring.package:
> (osgi.wiring.package=org.apache.commons.rng.core.source32)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (RNG-186) Commons-RNG Simple imports package that Commons-RNG Core does not export
[
https://issues.apache.org/jira/browse/RNG-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840398#comment-17840398
]
Richard Eckart de Castilho commented on RNG-186:
Thanks for the pointer for not using Random. In my case, it's a test case
though where I believe Random is quite sufficient ;)
> Commons-RNG Simple imports package that Commons-RNG Core does not export
>
>
> Key: RNG-186
> URL: https://issues.apache.org/jira/browse/RNG-186
> Project: Commons RNG
> Issue Type: Task
> Components: core, simple
>Affects Versions: 1.5
>Reporter: Richard Eckart de Castilho
>Priority: Major
>
> Commons RNG Simple imports the following packages:
> {noformat}
> Bundle-SymbolicName: org.apache.commons.rng.simple
> Implementation-Version: 1.5
> Import-Package:
> org.apache.commons.rng,org.apache.commons.rng.core,
> org.apache.commons.rng.core.source32,
> org.apache.commons.rng.core.source64,
> org.apache.commons.rng.core.util
> {noformat}
> However, Commons RNG Core does not export the source packages:
> {noformat}
> Bundle-SymbolicName: org.apache.commons.rng.core
> Implementation-Version: 1.5
> Export-Package:
>
> org.apache.commons.rng.core;x-friends:="org.apache.commons.rng.simple";version="1.5.0"
> Private-Package:
> org.apache.commons.rng.core.source32,
> org.apache.commons.rng.core.source64,
> org.apache.commons.rng.core.util
> {noformat}
> Consequently, using Commons RNG simple fails in an OSGi environment as the
> bundle cannot be resolved.
> {noformat}
> [ERROR] Resolution failed. Capabilities satisfying the following requirements
> could not be found:
> [<>]
> ...
> ⇒ osgi.wiring.package:
> (&(osgi.wiring.package=org.apache.commons.rng.simple)(version>=1.5.0)(!(version>=2.0.0)))
> ⇒ [org.apache.commons.rng.simple version=1.5.0]
> ⇒ osgi.wiring.package:
> (osgi.wiring.package=org.apache.commons.rng.core.source32)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (RNG-186) Commons-RNG Simple imports package that Commons-RNG Core does not export
[
https://issues.apache.org/jira/browse/RNG-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840396#comment-17840396
]
Gilles Sadowski commented on RNG-186:
-
bq. For my purposes, I have switched simply to using the Java Random class at
the moment.
https://commons.apache.org/proper/commons-rng/userguide/why_not_java_random.html
bq. You might consider using the
https://github.com/bndtools/bnd/blob/master/maven-plugins/bnd-testing-maven-plugin
[...]
Thanks for the suggestion
PR welcome that would set this up...
> Commons-RNG Simple imports package that Commons-RNG Core does not export
>
>
> Key: RNG-186
> URL: https://issues.apache.org/jira/browse/RNG-186
> Project: Commons RNG
> Issue Type: Task
> Components: core, simple
>Affects Versions: 1.5
>Reporter: Richard Eckart de Castilho
>Priority: Major
>
> Commons RNG Simple imports the following packages:
> {noformat}
> Bundle-SymbolicName: org.apache.commons.rng.simple
> Implementation-Version: 1.5
> Import-Package:
> org.apache.commons.rng,org.apache.commons.rng.core,
> org.apache.commons.rng.core.source32,
> org.apache.commons.rng.core.source64,
> org.apache.commons.rng.core.util
> {noformat}
> However, Commons RNG Core does not export the source packages:
> {noformat}
> Bundle-SymbolicName: org.apache.commons.rng.core
> Implementation-Version: 1.5
> Export-Package:
>
> org.apache.commons.rng.core;x-friends:="org.apache.commons.rng.simple";version="1.5.0"
> Private-Package:
> org.apache.commons.rng.core.source32,
> org.apache.commons.rng.core.source64,
> org.apache.commons.rng.core.util
> {noformat}
> Consequently, using Commons RNG simple fails in an OSGi environment as the
> bundle cannot be resolved.
> {noformat}
> [ERROR] Resolution failed. Capabilities satisfying the following requirements
> could not be found:
> [<>]
> ...
> ⇒ osgi.wiring.package:
> (&(osgi.wiring.package=org.apache.commons.rng.simple)(version>=1.5.0)(!(version>=2.0.0)))
> ⇒ [org.apache.commons.rng.simple version=1.5.0]
> ⇒ osgi.wiring.package:
> (osgi.wiring.package=org.apache.commons.rng.core.source32)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (RNG-186) Commons-RNG Simple imports package that Commons-RNG Core does not export
[
https://issues.apache.org/jira/browse/RNG-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840376#comment-17840376
]
Richard Eckart de Castilho edited comment on RNG-186 at 4/24/24 10:29 AM:
--
Thank you very much for your lightning-fast reaction (*)
For my purposes, I have switched simply to using the Java Random class at the
moment.
But your description of the remedy sounds correct, so I would expect it works
now.
You might consider using the
https://github.com/bndtools/bnd/blob/master/maven-plugins/bnd-testing-maven-plugin
in your build to check if bundles can in principle resolve.
was (Author: rec):
For my purposes, I have switched simply to using the Java Random class at the
moment.
But your description of the remedy sounds correct, so I would expect it works
now.
You might consider using the
https://github.com/bndtools/bnd/blob/master/maven-plugins/bnd-testing-maven-plugin
in your build to check if bundles can in principle resolve.
> Commons-RNG Simple imports package that Commons-RNG Core does not export
>
>
> Key: RNG-186
> URL: https://issues.apache.org/jira/browse/RNG-186
> Project: Commons RNG
> Issue Type: Task
> Components: core, simple
>Affects Versions: 1.5
>Reporter: Richard Eckart de Castilho
>Priority: Major
>
> Commons RNG Simple imports the following packages:
> {noformat}
> Bundle-SymbolicName: org.apache.commons.rng.simple
> Implementation-Version: 1.5
> Import-Package:
> org.apache.commons.rng,org.apache.commons.rng.core,
> org.apache.commons.rng.core.source32,
> org.apache.commons.rng.core.source64,
> org.apache.commons.rng.core.util
> {noformat}
> However, Commons RNG Core does not export the source packages:
> {noformat}
> Bundle-SymbolicName: org.apache.commons.rng.core
> Implementation-Version: 1.5
> Export-Package:
>
> org.apache.commons.rng.core;x-friends:="org.apache.commons.rng.simple";version="1.5.0"
> Private-Package:
> org.apache.commons.rng.core.source32,
> org.apache.commons.rng.core.source64,
> org.apache.commons.rng.core.util
> {noformat}
> Consequently, using Commons RNG simple fails in an OSGi environment as the
> bundle cannot be resolved.
> {noformat}
> [ERROR] Resolution failed. Capabilities satisfying the following requirements
> could not be found:
> [<>]
> ...
> ⇒ osgi.wiring.package:
> (&(osgi.wiring.package=org.apache.commons.rng.simple)(version>=1.5.0)(!(version>=2.0.0)))
> ⇒ [org.apache.commons.rng.simple version=1.5.0]
> ⇒ osgi.wiring.package:
> (osgi.wiring.package=org.apache.commons.rng.core.source32)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (RNG-186) Commons-RNG Simple imports package that Commons-RNG Core does not export
[
https://issues.apache.org/jira/browse/RNG-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840376#comment-17840376
]
Richard Eckart de Castilho commented on RNG-186:
For my purposes, I have switched simply to using the Java Random class at the
moment.
But your description of the remedy sounds correct, so I would expect it works
now.
You might consider using the
https://github.com/bndtools/bnd/blob/master/maven-plugins/bnd-testing-maven-plugin
in your build to check if bundles can in principle resolve.
> Commons-RNG Simple imports package that Commons-RNG Core does not export
>
>
> Key: RNG-186
> URL: https://issues.apache.org/jira/browse/RNG-186
> Project: Commons RNG
> Issue Type: Task
> Components: core, simple
>Affects Versions: 1.5
>Reporter: Richard Eckart de Castilho
>Priority: Major
>
> Commons RNG Simple imports the following packages:
> {noformat}
> Bundle-SymbolicName: org.apache.commons.rng.simple
> Implementation-Version: 1.5
> Import-Package:
> org.apache.commons.rng,org.apache.commons.rng.core,
> org.apache.commons.rng.core.source32,
> org.apache.commons.rng.core.source64,
> org.apache.commons.rng.core.util
> {noformat}
> However, Commons RNG Core does not export the source packages:
> {noformat}
> Bundle-SymbolicName: org.apache.commons.rng.core
> Implementation-Version: 1.5
> Export-Package:
>
> org.apache.commons.rng.core;x-friends:="org.apache.commons.rng.simple";version="1.5.0"
> Private-Package:
> org.apache.commons.rng.core.source32,
> org.apache.commons.rng.core.source64,
> org.apache.commons.rng.core.util
> {noformat}
> Consequently, using Commons RNG simple fails in an OSGi environment as the
> bundle cannot be resolved.
> {noformat}
> [ERROR] Resolution failed. Capabilities satisfying the following requirements
> could not be found:
> [<>]
> ...
> ⇒ osgi.wiring.package:
> (&(osgi.wiring.package=org.apache.commons.rng.simple)(version>=1.5.0)(!(version>=2.0.0)))
> ⇒ [org.apache.commons.rng.simple version=1.5.0]
> ⇒ osgi.wiring.package:
> (osgi.wiring.package=org.apache.commons.rng.core.source32)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
