[jira] [Commented] (COLLECTIONS-706) Add SetUtils.unmodifiableSet(T... items) method
[ https://issues.apache.org/jira/browse/COLLECTIONS-706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16717421#comment-16717421 ] Richard Eckart de Castilho commented on COLLECTIONS-706: Why the renaming? Arrays.asList(...) returns an unmodifiable set. > Add SetUtils.unmodifiableSet(T... items) method > --- > > Key: COLLECTIONS-706 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-706 > Project: Commons Collections > Issue Type: New Feature >Reporter: Richard Eckart de Castilho >Priority: Major > > Add an equivalent to the Arrays.asList() method for conveniently creating > sets. A trivial implementation would be: > SetUtils.asSet(T... items) -> return Collections.unmodifiableSet(new > HashSet<>(asList(items)); -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (COLLECTIONS-706) Add SetUtils.unmodifiableSet(T... items) method
[ https://issues.apache.org/jira/browse/COLLECTIONS-706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16717429#comment-16717429 ] Richard Eckart de Castilho commented on COLLECTIONS-706: How about then having a `asSet(...)` which does return a modifiable set... in addition? "asSet(...)" is simply shorter and more expected as a name considering Arrays.asList(...). > Add SetUtils.unmodifiableSet(T... items) method > --- > > Key: COLLECTIONS-706 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-706 > Project: Commons Collections > Issue Type: New Feature >Reporter: Richard Eckart de Castilho >Priority: Major > Fix For: 4.3 > > > Add an equivalent to the Arrays.asList() method for conveniently creating > sets. A trivial implementation would be: > SetUtils.asSet(T... items) -> return Collections.unmodifiableSet(new > HashSet<>(asList(items)); -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (COLLECTIONS-706) Add SetUtils.asSet(T... items) method
[ https://issues.apache.org/jira/browse/COLLECTIONS-706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Eckart de Castilho updated COLLECTIONS-706: --- Description: Add an equivalent to the Arrays.asList() method for conveniently creating sets. A trivial implementation would be: SetUtils.asSet(T... items) -> return Collections.unmodifiableSet(new HashSet<>(asList(items)); > Add SetUtils.asSet(T... items) method > - > > Key: COLLECTIONS-706 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-706 > Project: Commons Collections > Issue Type: New Feature >Reporter: Richard Eckart de Castilho >Priority: Major > > Add an equivalent to the Arrays.asList() method for conveniently creating > sets. A trivial implementation would be: > SetUtils.asSet(T... items) -> return Collections.unmodifiableSet(new > HashSet<>(asList(items)); -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (COLLECTIONS-706) Add SetUtils.asSet(T... items) method
Richard Eckart de Castilho created COLLECTIONS-706: -- Summary: Add SetUtils.asSet(T... items) method Key: COLLECTIONS-706 URL: https://issues.apache.org/jira/browse/COLLECTIONS-706 Project: Commons Collections Issue Type: New Feature Reporter: Richard Eckart de Castilho -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (LANG-1596) ArrayUtils.toPrimitive(Object) does not support boolean and other types
[
https://issues.apache.org/jira/browse/LANG-1596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17178212#comment-17178212
]
Richard Eckart de Castilho commented on LANG-1596:
--
Looks good. I cannot set the ticket assignee to myself though...
> ArrayUtils.toPrimitive(Object) does not support boolean and other types
> ---
>
> Key: LANG-1596
> URL: https://issues.apache.org/jira/browse/LANG-1596
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.11
>Reporter: Richard Eckart de Castilho
>Priority: Major
> Fix For: 3.12
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> ArrayUtils.toPrimitive(Object) supports only Integer, Long, Short, Double and
> Float. Boolean, Byte, and Character are not supported.
> This causes e.g. also calls to MethodUtils.invokeStaticMethod(...) to fail if
> e.g. a Boolean array is provided as the argument for a primitive boolean
> vararg because getVarArgs does expect ArrayUtils to do the right thing:
> {code}
> if (varArgComponentType.isPrimitive()) {
> // unbox from wrapper type to primitive type
> varArgsArray = ArrayUtils.toPrimitive(varArgsArray);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (LANG-1596) ArrayUtils.toPrimitive(Object) does not support boolean and other types
[
https://issues.apache.org/jira/browse/LANG-1596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard Eckart de Castilho updated LANG-1596:
-
Description:
ArrayUtils.toPrimitive(Object) supports only Integer, Long, Short, Double and
Float. Boolean, Byte, and Character are not supported.
This causes e.g. also calls to MethodUtils.invokeStaticMethod(...) to fail if
e.g. a Boolean array is provided as the argument for a primitive boolean vararg
because getVarArgs does expect ArrayUtils to do the right thing:
{code}
if (varArgComponentType.isPrimitive()) {
// unbox from wrapper type to primitive type
varArgsArray = ArrayUtils.toPrimitive(varArgsArray);
}
{code}
was:
ArrayUtils.toPrimitive(Object) supports only Integer, Long, Short, Double and
Float. Boolean, Byte, and Character are not supported.
This causes e.g. also calls to MethodUtils.invokeStaticMethod(...) to fail if
e.g. a Boolean array is provided as the argument for a primitive boolean vararg
because getVarArgs does expect ArrayUtils to do the right thing:
if (varArgComponentType.isPrimitive()) {
// unbox from wrapper type to primitive type
varArgsArray = ArrayUtils.toPrimitive(varArgsArray);
}
> ArrayUtils.toPrimitive(Object) does not support boolean and other types
> ---
>
> Key: LANG-1596
> URL: https://issues.apache.org/jira/browse/LANG-1596
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.11
>Reporter: Richard Eckart de Castilho
>Priority: Major
>
> ArrayUtils.toPrimitive(Object) supports only Integer, Long, Short, Double and
> Float. Boolean, Byte, and Character are not supported.
> This causes e.g. also calls to MethodUtils.invokeStaticMethod(...) to fail if
> e.g. a Boolean array is provided as the argument for a primitive boolean
> vararg because getVarArgs does expect ArrayUtils to do the right thing:
> {code}
> if (varArgComponentType.isPrimitive()) {
> // unbox from wrapper type to primitive type
> varArgsArray = ArrayUtils.toPrimitive(varArgsArray);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (LANG-1596) ArrayUtils.toPrimitive(Object) does not support boolean and other types
Richard Eckart de Castilho created LANG-1596:
Summary: ArrayUtils.toPrimitive(Object) does not support boolean
and other types
Key: LANG-1596
URL: https://issues.apache.org/jira/browse/LANG-1596
Project: Commons Lang
Issue Type: Bug
Components: lang.*
Affects Versions: 3.11
Reporter: Richard Eckart de Castilho
ArrayUtils.toPrimitive(Object) supports only Integer, Long, Short, Double and
Float. Boolean, Byte, and Character are not supported.
This causes e.g. also calls to MethodUtils.invokeStaticMethod(...) to fail if
e.g. a Boolean array is provided as the argument for a primitive boolean vararg
because getVarArgs does expect ArrayUtils to do the right thing:
if (varArgComponentType.isPrimitive()) {
// unbox from wrapper type to primitive type
varArgsArray = ArrayUtils.toPrimitive(varArgsArray);
}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (LANG-1597) Invocation fails because matching varargs method found but then discarded
Richard Eckart de Castilho created LANG-1597:
Summary: Invocation fails because matching varargs method found
but then discarded
Key: LANG-1597
URL: https://issues.apache.org/jira/browse/LANG-1597
Project: Commons Lang
Issue Type: Bug
Components: lang.reflect.*
Affects Versions: 3.11
Reporter: Richard Eckart de Castilho
{{getMatchingAccessibleMethod(Class, String, Class...)}} is able to find
proper match for a method to call but then discards it.
Consider the situation you have a varargs method like {{Baz.foo(X... X)}}. We
call {{getMatchingAccessibleMethod(Baz.class, "foo", z}} where {{z instance of
Z extends Y extends X}}. {{getMatchingAccessibleMethod}} finds {{foo}} as the
candidate, but then discards it because for varargs, it requires either the
argument is directly is of type X or that the supertype of the argument X. It
does not properly check the entire inheritance hierarchy in this code (3.11):
{code}
if (bestMatch != null && bestMatch.isVarArgs() &&
bestMatch.getParameterTypes().length > 0 && parameterTypes.length > 0) {
final Class[] methodParameterTypes =
bestMatch.getParameterTypes();
final Class methodParameterComponentType =
methodParameterTypes[methodParameterTypes.length - 1].getComponentType();
final String methodParameterComponentTypeName =
ClassUtils.primitiveToWrapper(methodParameterComponentType).getName();
final Class lastParameterType =
parameterTypes[parameterTypes.length - 1];
final String parameterTypeName = (lastParameterType==null) ? null :
lastParameterType.getName();
final String parameterTypeSuperClassName =
(lastParameterType==null) ? null : lastParameterType.getSuperclass().getName();
if (parameterTypeName!= null && parameterTypeSuperClassName != null
&& !methodParameterComponentTypeName.equals(parameterTypeName)
&&
!methodParameterComponentTypeName.equals(parameterTypeSuperClassName)) {
return null;
}
}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (LANG-1597) Invocation fails because matching varargs method found but then discarded
[
https://issues.apache.org/jira/browse/LANG-1597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17234309#comment-17234309
]
Richard Eckart de Castilho commented on LANG-1597:
--
As a quick measure, I can only provide the code where I wanted to rely on the
method but had to work around the bug:
{code}
boolean isFeatureStructureValue = FeatureStructure.class
.isAssignableFrom(aValue.getClass());
boolean isFeatureStructureVarArgValue = aValue.getClass().isArray()
&& FeatureStructure.class
.isAssignableFrom(aValue.getClass().getComponentType());
// Workaround for https://issues.apache.org/jira/browse/LANG-1597
if (isFeatureStructureValue || isFeatureStructureVarArgValue) {
// MethodUtils.invokeStaticMethod has a "bug" that vararg
methods are only
// properly found/matched if the parameter value type or the
supertype of the
// parameter value matches the varargs type. So here we have
FeatureStructure...
// as the varargs definition, but we may want to set a value of
type Annotation
// and from Annotation to FeatureStructure is a long way
through the inheritance
// hierarchy.
// Note: this bug exists at least up to commons-lang3 3.11 - it
might be fixed
// in later versions.
MethodUtils.invokeStaticMethod(FSUtil.class, "setFeature",
new Object[] { aFS, aName, aValue },
new Class[] { FeatureStructure.class, String.class,
FeatureStructure[].class });
return;
}
{code}
> Invocation fails because matching varargs method found but then discarded
> -
>
> Key: LANG-1597
> URL: https://issues.apache.org/jira/browse/LANG-1597
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.reflect.*
>Affects Versions: 3.11
>Reporter: Richard Eckart de Castilho
>Priority: Major
>
> {{getMatchingAccessibleMethod(Class, String, Class...)}} is able to
> find proper match for a method to call but then discards it.
> Consider the situation you have a varargs method like {{Baz.foo(X... X)}}. We
> call {{getMatchingAccessibleMethod(Baz.class, "foo", z}} where {{z instance
> of Z extends Y extends X}}. {{getMatchingAccessibleMethod}} finds {{foo}} as
> the candidate, but then discards it because for varargs, it requires either
> the argument is directly is of type X or that the supertype of the argument
> X. It does not properly check the entire inheritance hierarchy in this code
> (3.11):
> {code}
> if (bestMatch != null && bestMatch.isVarArgs() &&
> bestMatch.getParameterTypes().length > 0 && parameterTypes.length > 0) {
> final Class[] methodParameterTypes =
> bestMatch.getParameterTypes();
> final Class methodParameterComponentType =
> methodParameterTypes[methodParameterTypes.length - 1].getComponentType();
> final String methodParameterComponentTypeName =
> ClassUtils.primitiveToWrapper(methodParameterComponentType).getName();
> final Class lastParameterType =
> parameterTypes[parameterTypes.length - 1];
> final String parameterTypeName = (lastParameterType==null) ? null
> : lastParameterType.getName();
> final String parameterTypeSuperClassName =
> (lastParameterType==null) ? null :
> lastParameterType.getSuperclass().getName();
> if (parameterTypeName!= null && parameterTypeSuperClassName !=
> null && !methodParameterComponentTypeName.equals(parameterTypeName)
> &&
> !methodParameterComponentTypeName.equals(parameterTypeSuperClassName)) {
> return null;
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (POOL-411) Potential NPE when deregistering key at end of borrow
Richard Eckart de Castilho created POOL-411:
---
Summary: Potential NPE when deregistering key at end of borrow
Key: POOL-411
URL: https://issues.apache.org/jira/browse/POOL-411
Project: Commons Pool
Issue Type: Task
Affects Versions: 2.11.1
Reporter: Richard Eckart de Castilho
There is a potential for an NPE happening in the finally block of borrowObject:
{noformat}
Caused by: java.lang.NullPointerException: Cannot invoke
"org.apache.commons.pool2.impl.GenericKeyedObjectPool$ObjectDeque.getNumInterested()"
because "objectDeque" is null
at
org.apache.commons.pool2.impl.GenericKeyedObjectPool.deregister(GenericKeyedObjectPool.java:821)
at
org.apache.commons.pool2.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:507)
at
org.apache.commons.pool2.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:350)
{noformat}
>From reading the code, it seems this could happen e.g. if a pool is
>concurrently cleared while a borrow is in progress.
Not sure what a proper solution here would be. Maybe deregister should silently
do nothing if poolMap.get(k) returns null?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (POOL-411) NPE when deregistering key at end of borrow
[
https://issues.apache.org/jira/browse/POOL-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696566#comment-17696566
]
Richard Eckart de Castilho commented on POOL-411:
-
[~ggregory] I have only ever seen this exception once so far in hundreds if not
thousands of builds. I'm afraid, I won't be able to reproduce it.
> NPE when deregistering key at end of borrow
> ---
>
> Key: POOL-411
> URL: https://issues.apache.org/jira/browse/POOL-411
> Project: Commons Pool
> Issue Type: Task
>Affects Versions: 2.11.1
>Reporter: Richard Eckart de Castilho
>Priority: Major
>
> There is a potential for an NPE happening in the finally block of
> borrowObject:
> {noformat}
> Caused by: java.lang.NullPointerException: Cannot invoke
> "org.apache.commons.pool2.impl.GenericKeyedObjectPool$ObjectDeque.getNumInterested()"
> because "objectDeque" is null
> at
> org.apache.commons.pool2.impl.GenericKeyedObjectPool.deregister(GenericKeyedObjectPool.java:821)
> at
> org.apache.commons.pool2.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:507)
> at
> org.apache.commons.pool2.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:350)
>
> {noformat}
> From reading the code, it seems this could happen e.g. if a pool is
> concurrently cleared while a borrow is in progress.
> Not sure what a proper solution here would be. Maybe deregister should
> silently do nothing if poolMap.get(k) returns null?
--
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] [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)
[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] [Created] (RNG-186) Commons-RNG Simple imports package that Commons-RNG Core does not export
Richard Eckart de Castilho created RNG-186:
--
Summary: 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
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)
