[jira] [Updated] (LANG-916) CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations
[
https://issues.apache.org/jira/browse/LANG-916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-916:
---
Fix Version/s: (was: 2.5)
Commons Time?
CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in
certain situations
Key: LANG-916
URL: https://issues.apache.org/jira/browse/LANG-916
Project: Commons Lang
Issue Type: Bug
Components: lang.time.*
Affects Versions: 3.1
Environment: Sun JDK 1.6.0_45 and 1.7.0_21 on Fedora 17 (Linux
3.9.10-100.fc17.i686.PAE).
Reporter: Christian P. MOMON
Fix For: 2.7
In LANG-538 issue, there is an unit test:
{noformat}
public void testFormat_CalendarIsoMsZulu() {
final String dateTime = 2009-10-16T16:42:16.000Z;
GregorianCalendar cal = new
GregorianCalendar(TimeZone.getTimeZone(GMT-8));
cal.clear();
cal.set(2009, 9, 16, 8, 42, 16);
cal.getTime();
FastDateFormat format =
FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(GMT));
assertEquals(dateTime, dateTime, format.format(cal));
}
{noformat}
This test passes successfully in lang-2.6 but failed in lang3-3.1:
{noformat}
org.junit.ComparisonFailure: dateTime expected:2009-10-16T[16]:42:16.000Z
but was:2009-10-16T[08]:42:16.000Z
{noformat}
Reproduced whit Sun Java version: 1.6.0_45 and 1.7.0_21 on Fedora 17 (Linux
3.9.10-100.fc17.i686.PAE).
Moreover, I wrote another unit test showing that the timeZone parameter seems
to be ignored :
{noformat}
public void test() {
Calendar cal =
Calendar.getInstance(TimeZone.getTimeZone(Europe/Paris));
cal.set(2009, 9, 16, 8, 42, 16);
//
System.out.println(DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.format(cal));
System.out.println(long);
System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getDefault()));
System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getTimeZone(Asia/Kolkata)));
System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getTimeZone(Europe/London)));
System.out.println(calendar);
System.out.println(DateFormatUtils.format(cal,
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getDefault()));
System.out.println(DateFormatUtils.format(cal,
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getTimeZone(Asia/Kolkata)));
System.out.println(DateFormatUtils.format(cal,
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getTimeZone(Europe/London)));
System.out.println(calendar fast);
System.out.println(FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(Europe/Paris)).format(cal));
System.out.println(FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(Asia/Kolkata)).format(cal));
System.out.println(FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(Europe/London)).format(cal));
}
{noformat}
Gives the following console logs:
{noformat}
long
2009-10-16T08:42:16+02:00
2009-10-16T12:12:16+05:30
2009-10-16T07:42:16+01:00
calendar
2009-10-16T08:42:16+02:00
2009-10-16T08:42:16+02:00
2009-10-16T08:42:16+02:00
calendar fast
2009-10-16T08:42:16.975Z
2009-10-16T08:42:16.975Z
2009-10-16T08:42:16.975Z
{noformat}
When DateFormatUtils.format takes a long parameter, the time string is good.
When DateFormatUtils.format takes a Calendar parameter, the time string is
wrong, the timezone parameter is IGNORED.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (LANG-916) CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations
[
https://issues.apache.org/jira/browse/LANG-916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-916:
---
Fix Version/s: (was: Commons Time?)
2.7
CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in
certain situations
Key: LANG-916
URL: https://issues.apache.org/jira/browse/LANG-916
Project: Commons Lang
Issue Type: Bug
Components: lang.time.*
Affects Versions: 3.1
Environment: Sun JDK 1.6.0_45 and 1.7.0_21 on Fedora 17 (Linux
3.9.10-100.fc17.i686.PAE).
Reporter: Christian P. MOMON
Fix For: 2.7
In LANG-538 issue, there is an unit test:
{noformat}
public void testFormat_CalendarIsoMsZulu() {
final String dateTime = 2009-10-16T16:42:16.000Z;
GregorianCalendar cal = new
GregorianCalendar(TimeZone.getTimeZone(GMT-8));
cal.clear();
cal.set(2009, 9, 16, 8, 42, 16);
cal.getTime();
FastDateFormat format =
FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(GMT));
assertEquals(dateTime, dateTime, format.format(cal));
}
{noformat}
This test passes successfully in lang-2.6 but failed in lang3-3.1:
{noformat}
org.junit.ComparisonFailure: dateTime expected:2009-10-16T[16]:42:16.000Z
but was:2009-10-16T[08]:42:16.000Z
{noformat}
Reproduced whit Sun Java version: 1.6.0_45 and 1.7.0_21 on Fedora 17 (Linux
3.9.10-100.fc17.i686.PAE).
Moreover, I wrote another unit test showing that the timeZone parameter seems
to be ignored :
{noformat}
public void test() {
Calendar cal =
Calendar.getInstance(TimeZone.getTimeZone(Europe/Paris));
cal.set(2009, 9, 16, 8, 42, 16);
//
System.out.println(DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.format(cal));
System.out.println(long);
System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getDefault()));
System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getTimeZone(Asia/Kolkata)));
System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getTimeZone(Europe/London)));
System.out.println(calendar);
System.out.println(DateFormatUtils.format(cal,
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getDefault()));
System.out.println(DateFormatUtils.format(cal,
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getTimeZone(Asia/Kolkata)));
System.out.println(DateFormatUtils.format(cal,
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getTimeZone(Europe/London)));
System.out.println(calendar fast);
System.out.println(FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(Europe/Paris)).format(cal));
System.out.println(FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(Asia/Kolkata)).format(cal));
System.out.println(FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(Europe/London)).format(cal));
}
{noformat}
Gives the following console logs:
{noformat}
long
2009-10-16T08:42:16+02:00
2009-10-16T12:12:16+05:30
2009-10-16T07:42:16+01:00
calendar
2009-10-16T08:42:16+02:00
2009-10-16T08:42:16+02:00
2009-10-16T08:42:16+02:00
calendar fast
2009-10-16T08:42:16.975Z
2009-10-16T08:42:16.975Z
2009-10-16T08:42:16.975Z
{noformat}
When DateFormatUtils.format takes a long parameter, the time string is good.
When DateFormatUtils.format takes a Calendar parameter, the time string is
wrong, the timezone parameter is IGNORED.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (MATH-1037) Distribution tests are mostly meaningless due to high tolerance
[
https://issues.apache.org/jira/browse/MATH-1037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13794023#comment-13794023
]
Aleksei Dievskii commented on MATH-1037:
Glad to be of help!
Distribution tests are mostly meaningless due to high tolerance
---
Key: MATH-1037
URL: https://issues.apache.org/jira/browse/MATH-1037
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.2
Reporter: Aleksei Dievskii
Priority: Minor
Fix For: 3.3
The tolerance used for value comparison in
{{IntegerDistributionAbstractTest}} is {{1E-4}}. However, most values being
compared are much smaller, so they are considered equal even if they
otherwise differ by orders of magnitude. For example, a typo in
{{GeometricDistributionTest}} puts 29 in the test points instead of 19, while
the test probability value is correctly given for 19. The test passes,
disregarding the fact that {{2.437439e-05}} (test value for 19) and
{{1.473826e-07}} (actual value for 29) differ almost hundredfold.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Resolved] (POOL-211) Proxy support for pooled objects
[ https://issues.apache.org/jira/browse/POOL-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved POOL-211. -- Resolution: Fixed Fix Version/s: 2.0 This has been implemented. There is still some refactoring to do but the implementation is complete. Proxy support for pooled objects Key: POOL-211 URL: https://issues.apache.org/jira/browse/POOL-211 Project: Commons Pool Issue Type: Improvement Affects Versions: 1.6, 2.0 Reporter: Brad Koehn Labels: features, patch Fix For: 2.0 Attachments: src.jar, test.jar Original Estimate: 48h Remaining Estimate: 48h Attached are files and tests that would allow users of commons-pool to interact with a proxy to the pooled object rather than the pooled object itself. This provides two benefits: detection of leaked pooled objects (when returnObject() isn't called) with a stack trace and detection of using pooled objects after they have been returned to the pool. The system provides a delegate which can be placed in front of any ObjectPool, similar to calling Collections.unmodifiableCollection(). Callers do not know that they're working with a proxy rather than the pooled object itself. Implementations are provided to use Java proxies or CGLib (useful when the pooled object doesn't implement an interface). Unit tests are also provided. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (EMAIL-135) Make DataSourceUrlResolver#createUrl() protected
Andreas Kohn created EMAIL-135:
--
Summary: Make DataSourceUrlResolver#createUrl() protected
Key: EMAIL-135
URL: https://issues.apache.org/jira/browse/EMAIL-135
Project: Commons Email
Issue Type: Improvement
Affects Versions: 1.3.1
Reporter: Andreas Kohn
Priority: Minor
It would be nice if {{#createUrl()}} was protected, so that it can be used in
derived classes.
In the specific instance where I need that: we're sending emails using Amazon
Simple Email Service, which requires that attachments not just have a specific
content type, but also an extension matching that content type.
To implement this requirement I've extended DataSourceUrlResolver, and return a
URLDataSource that reports the original file name with the extension suitably
enforced.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (EMAIL-135) Make DataSourceUrlResolver#createUrl() protected
[
https://issues.apache.org/jira/browse/EMAIL-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Kohn updated EMAIL-135:
---
Attachment: email-135-datasourceurlresolver-createUrl-protected.diff
Trivial patch.
Make DataSourceUrlResolver#createUrl() protected
Key: EMAIL-135
URL: https://issues.apache.org/jira/browse/EMAIL-135
Project: Commons Email
Issue Type: Improvement
Affects Versions: 1.3.1
Reporter: Andreas Kohn
Priority: Minor
Attachments: email-135-datasourceurlresolver-createUrl-protected.diff
It would be nice if {{#createUrl()}} was protected, so that it can be used in
derived classes.
In the specific instance where I need that: we're sending emails using Amazon
Simple Email Service, which requires that attachments not just have a
specific content type, but also an extension matching that content type.
To implement this requirement I've extended DataSourceUrlResolver, and return
a URLDataSource that reports the original file name with the extension
suitably enforced.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Closed] (JCI-56) Incorrect Store read in EclipseJavaCompiler
[
https://issues.apache.org/jira/browse/JCI-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Bourg closed JCI-56.
-
Incorrect Store read in EclipseJavaCompiler
---
Key: JCI-56
URL: https://issues.apache.org/jira/browse/JCI-56
Project: Commons JCI
Issue Type: Bug
Components: compiler eclipse
Reporter: Mark Proctor
Assignee: Torsten Curdt
Fix For: 1.1
A while back the store was changed to store the resource name instead of the
class name - i.e. {{org.drools.Test}} is now stored as
{{org/drools/Test.class}}. In EclipseJavaCompiler you are reading via a
classname, rather than the converted resourceName:
{code}
final String resourceName =
ClassUtils.convertClassToResourcePath(pClazzName);
final byte[] clazzBytes = pStore.read(pClazzName);
if (clazzBytes != null) {
{code}
I believe that should be:
{code}pStore.read(resourceName);{code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Closed] (JCI-62) NullPointerException when calling stop() before calling start()
[ https://issues.apache.org/jira/browse/JCI-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg closed JCI-62. - NullPointerException when calling stop() before calling start() --- Key: JCI-62 URL: https://issues.apache.org/jira/browse/JCI-62 Project: Commons JCI Issue Type: Bug Components: fam Affects Versions: 1.0 Reporter: Mads Mohr Christensen Assignee: Torsten Curdt Fix For: 1.1 Attachments: FilesystemAlterationMonitor.java.patch To reproduce: fam = new FilesystemAlterationMonitor(); fam.stop(); -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (JCI-49) wrap logging statements via build
[ https://issues.apache.org/jira/browse/JCI-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg closed JCI-49. - wrap logging statements via build - Key: JCI-49 URL: https://issues.apache.org/jira/browse/JCI-49 Project: Commons JCI Issue Type: Improvement Components: compiler eclipse, compiler groovy, compiler janino, compiler javac, compiler jsr199, compiler jython, compiler rhino, core, examples, fam Reporter: Torsten Curdt Assignee: Torsten Curdt Fix For: 1.1 Wrapping the logging statements should be added during the build using just4log. (I hate clutter!) http://just4log.sourceforge.net/ Would be good to wrap it in a little maven plugin. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (JCI-61) Upgrade Asm (test) dependency to latest 3.1
[ https://issues.apache.org/jira/browse/JCI-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg closed JCI-61. - Upgrade Asm (test) dependency to latest 3.1 --- Key: JCI-61 URL: https://issues.apache.org/jira/browse/JCI-61 Project: Commons JCI Issue Type: Bug Components: core Affects Versions: 1.0 Reporter: Niall Pemberton Assignee: Niall Pemberton Priority: Minor Fix For: 1.1 JCI has a test dependency on Asm 2.2.1 and SimpleDump/ExtendedDump use the ClassWriter(boolean) constructor. This constructor has been replaced Asm 3.x by a ClassWriter(int) constructor. Currently gump is failing for JCI because of this. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (JCI-50) Javac 1.5 source and target parameters
[ https://issues.apache.org/jira/browse/JCI-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg closed JCI-50. - Javac 1.5 source and target parameters -- Key: JCI-50 URL: https://issues.apache.org/jira/browse/JCI-50 Project: Commons JCI Issue Type: Bug Components: compiler eclipse, compiler javac Affects Versions: 1.0 Reporter: Olexandr Zakordonskyy Assignee: Torsten Curdt Priority: Blocker Fix For: 1.1 Unable to set source and target version to 1.5. For javac its -source and -target arguments. Same for jci-eclipse. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (JCI-74) FilesystemAlterationMonitor.delay is not safely published
[ https://issues.apache.org/jira/browse/JCI-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg closed JCI-74. - FilesystemAlterationMonitor.delay is not safely published - Key: JCI-74 URL: https://issues.apache.org/jira/browse/JCI-74 Project: Commons JCI Issue Type: Bug Components: fam Affects Versions: 1.0 Reporter: Sebb Fix For: 1.1 The field FilesystemAlterationMonitor.delay is read by the daemon thread but the writer and reader do not use synchronisation. If the delay is changed after the thread is started, any changes may not be seen by the thread (unsafe publication). The delay field needs to be made volatile. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (JCI-53) Stack overflow on cross imports in commons-jci-janino
[
https://issues.apache.org/jira/browse/JCI-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Bourg closed JCI-53.
-
Stack overflow on cross imports in commons-jci-janino
-
Key: JCI-53
URL: https://issues.apache.org/jira/browse/JCI-53
Project: Commons JCI
Issue Type: Bug
Components: compiler janino
Affects Versions: 1.0
Reporter: Edson Tirelli
Assignee: Torsten Curdt
Priority: Blocker
Fix For: 1.1
A stack overflow occurs when trying to compile classes with cross references
using commons-jci-janino, because an infinite recursion. The simple presence
of cross reference import is enough to cause the problem.
Example: the following classes will recreate the problem:
{code}
package test;
import static test.Func2.func2;
public class Func1 {
public static boolean func1() throws Exception {
return true;
}
}
{code}
{code}
package test;
import static test.Func1.func1;
public class Func2 {
public static boolean func2() throws Exception {
return true;
}
}
{code}
The exception stack is:
{code}
java.lang.StackOverflowError
at org.codehaus.janino.Parser.parseAndExpression(Parser.java)
at org.codehaus.janino.Parser.parseExclusiveOrExpression(Parser.java)
at org.codehaus.janino.Parser.parseInclusiveOrExpression(Parser.java)
at org.codehaus.janino.Parser.parseConditionalAndExpression(Parser.java)
at org.codehaus.janino.Parser.parseConditionalOrExpression(Parser.java)
at org.codehaus.janino.Parser.parseConditionalExpression(Parser.java)
at org.codehaus.janino.Parser.parseAssignmentExpression(Parser.java)
at org.codehaus.janino.Parser.parseExpression(Parser.java)
at org.codehaus.janino.Parser.parseReturnStatement(Parser.java)
at org.codehaus.janino.Parser.parseStatement(Parser.java)
at org.codehaus.janino.Parser.parseBlockStatement(Parser.java)
at org.codehaus.janino.Parser.parseBlockStatements(Parser.java)
at org.codehaus.janino.Parser.parseBlock(Parser.java)
at org.codehaus.janino.Parser.parseMethodBody(Parser.java)
at org.codehaus.janino.Parser.parseMethodDeclarationRest(Parser.java)
at org.codehaus.janino.Parser.parseClassBodyDeclaration(Parser.java)
at org.codehaus.janino.Parser.parseClassBody(Parser.java)
at org.codehaus.janino.Parser.parseClassDeclarationRest(Parser.java)
at
org.codehaus.janino.Parser.parsePackageMemberTypeDeclaration(Parser.java)
at org.codehaus.janino.Parser.parseCompilationUnit(Parser.java)
at
org.drools.commons.jci.compilers.JaninoJavaCompiler$CompilingIClassLoader.findIClass(JaninoJavaCompiler.java:90)
at org.codehaus.janino.IClassLoader.loadIClass(IClassLoader.java)
at
org.codehaus.janino.UnitCompiler.loadFullyQualifiedClass(UnitCompiler.java)
at org.codehaus.janino.UnitCompiler.import2(UnitCompiler.java)
at org.codehaus.janino.UnitCompiler.access$2(UnitCompiler.java)
at
org.codehaus.janino.UnitCompiler$1.visitSingleStaticImportDeclaration(UnitCompiler.java)
at
org.codehaus.janino.Java$CompilationUnit$SingleStaticImportDeclaration.accept(Java.java)
at org.codehaus.janino.UnitCompiler.init(UnitCompiler.java)
at
org.drools.commons.jci.compilers.JaninoJavaCompiler$CompilingIClassLoader.findIClass(JaninoJavaCompiler.java:91)
at org.codehaus.janino.IClassLoader.loadIClass(IClassLoader.java)
at
org.codehaus.janino.UnitCompiler.loadFullyQualifiedClass(UnitCompiler.java)
at org.codehaus.janino.UnitCompiler.import2(UnitCompiler.java)
at org.codehaus.janino.UnitCompiler.access$2(UnitCompiler.java)
at
org.codehaus.janino.UnitCompiler$1.visitSingleStaticImportDeclaration(UnitCompiler.java)
at
org.codehaus.janino.Java$CompilationUnit$SingleStaticImportDeclaration.accept(Java.java)
at org.codehaus.janino.UnitCompiler.init(UnitCompiler.java)
at
org.drools.commons.jci.compilers.JaninoJavaCompiler$CompilingIClassLoader.findIClass(JaninoJavaCompiler.java:91)
at org.codehaus.janino.IClassLoader.loadIClass(IClassLoader.java)
at
org.codehaus.janino.UnitCompiler.loadFullyQualifiedClass(UnitCompiler.java)
at org.codehaus.janino.UnitCompiler.import2(UnitCompiler.java)
at org.codehaus.janino.UnitCompiler.access$2(UnitCompiler.java)
at
org.codehaus.janino.UnitCompiler$1.visitSingleStaticImportDeclaration(UnitCompiler.java)
at
org.codehaus.janino.Java$CompilationUnit$SingleStaticImportDeclaration.accept(Java.java)
at org.codehaus.janino.UnitCompiler.init(UnitCompiler.java)
at
org.drools.commons.jci.compilers.JaninoJavaCompiler$CompilingIClassLoader.findIClass(JaninoJavaCompiler.java:91)
[jira] [Closed] (JCI-52) Patch for tool_api-5.0-fr-spec
[ https://issues.apache.org/jira/browse/JCI-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg closed JCI-52. - Patch for tool_api-5.0-fr-spec -- Key: JCI-52 URL: https://issues.apache.org/jira/browse/JCI-52 Project: Commons JCI Issue Type: Improvement Components: compiler jsr199 Reporter: Tuomas Kiviaho Assignee: Torsten Curdt Fix For: 1.1 Attachments: tool_api-5.0-fr-spec.20070726.patch JSR199 compiler is outdated, but here's a patch that at least removes the compiler errors. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (JCI-72) jsr199 module refers to itself as jsr166
[ https://issues.apache.org/jira/browse/JCI-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg closed JCI-72. - jsr199 module refers to itself as jsr166 Key: JCI-72 URL: https://issues.apache.org/jira/browse/JCI-72 Project: Commons JCI Issue Type: Bug Reporter: Sebb Fix For: 1.1 The JSR199 module POM contains the following: artifactIdcommons-jci-jsr166/artifactId namecompiler-jsr166/name It should not matter changing the name, however the artifactId could cause issues. Luckily it does not seem to have been released. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (JCI-69) Upgrade the dependency on Janino
[ https://issues.apache.org/jira/browse/JCI-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg closed JCI-69. - Upgrade the dependency on Janino Key: JCI-69 URL: https://issues.apache.org/jira/browse/JCI-69 Project: Commons JCI Issue Type: Improvement Components: compiler janino Affects Versions: 1.0 Reporter: Emmanuel Bourg Fix For: 1.1 JCI is not compatible with the latest version of Janino (2.6.1). Debian has a patch performing this upgrade: http://anonscm.debian.org/viewvc/pkg-java/trunk/commons-jci/debian/patches/01_janino_version_change.diff?revision=17151 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (JCI-41) [jci] icl.loadIClass(Descriptor.fromClassName(pClasses[i])) now throws ClassNotFoundException
[ https://issues.apache.org/jira/browse/JCI-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg closed JCI-41. - [jci] icl.loadIClass(Descriptor.fromClassName(pClasses[i])) now throws ClassNotFoundException - Key: JCI-41 URL: https://issues.apache.org/jira/browse/JCI-41 Project: Commons JCI Issue Type: Improvement Components: compiler janino Reporter: Mark Proctor Assignee: Torsten Curdt Fix For: 1.1 For Janino 2.5.5 icl.loadIClass(Descriptor.fromClassName(pClasses[i])) now throws ClassNotFoundException. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (JCI-68) FilesystemAlterationMonitor NullPointerException when directory not readable
[ https://issues.apache.org/jira/browse/JCI-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg closed JCI-68. - FilesystemAlterationMonitor NullPointerException when directory not readable Key: JCI-68 URL: https://issues.apache.org/jira/browse/JCI-68 Project: Commons JCI Issue Type: Bug Components: fam Affects Versions: 1.1 Environment: Linux Reporter: Jan Labels: fam, permissions Fix For: 1.1 Attachments: FileAlteration.java When one of the directories monitored by the FilesystemAlterationMonitor is not readable by the proess, the monitoring crashes with a NullPointerException -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (JCI-58) EclipseJavaCompiler fails to close inputstream
[
https://issues.apache.org/jira/browse/JCI-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Bourg closed JCI-58.
-
EclipseJavaCompiler fails to close inputstream
--
Key: JCI-58
URL: https://issues.apache.org/jira/browse/JCI-58
Project: Commons JCI
Issue Type: Bug
Components: compiler eclipse
Affects Versions: 1.1
Environment: Java 1.5, WinXP
Reporter: Michael Gannon
Assignee: Torsten Curdt
Fix For: 1.1
The method isPackage(final String pClaszzName) calls
classLoader.getResourceAsStream() but fails to close the stream if it is
opened successfully. On Windows this means all other file access to this file
is not permitted. The inputstream should be closed. Here is a replacement
method:
{code}
private boolean isPackage( final String pClazzName ) {
final InputStream is =
pClassLoader.getResourceAsStream(ConversionUtils.convertClassToResourcePath(pClazzName));
if (is != null) {
log.debug(found the class for + pClazzName + - no package);
try {
is.close();
} catch (final IOException ie) {
log.error(could not close input stream, ie);
}
return false;
}
// FIXME: this should not be tied to the extension
final String source = pClazzName.replace('.', '/') + .java;
if (pReader.isAvailable(source)) {
log.debug(found the source + source + for + pClazzName +
- no package );
return false;
}
return true;
}
{code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Closed] (JCI-43) javac fails on 1.6
[ https://issues.apache.org/jira/browse/JCI-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg closed JCI-43. - javac fails on 1.6 -- Key: JCI-43 URL: https://issues.apache.org/jira/browse/JCI-43 Project: Commons JCI Issue Type: Bug Components: compiler javac Environment: JDK 1.6 Reporter: Torsten Curdt Assignee: Torsten Curdt Fix For: 1.1 For some reason we still have a backslash in there while it should be a simple slash [sebb: this is because of a change in the tools classes] junit.framework.AssertionFailedError: Failure executing javac, but could not parse the error: javac: file not found: jci\Simple.java Usage: javac options source files use -help for a list of possible options , expected:0 but was:1 at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.failNotEquals(Assert.java:282) at junit.framework.Assert.assertEquals(Assert.java:64) at junit.framework.Assert.assertEquals(Assert.java:201) at org.apache.commons.jci.compilers.AbstractCompilerTestCase.testSimpleCompile(AbstractCompilerTestCase.java:56) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (JCI-66) fam module not in root pom
[ https://issues.apache.org/jira/browse/JCI-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg closed JCI-66. - fam module not in root pom -- Key: JCI-66 URL: https://issues.apache.org/jira/browse/JCI-66 Project: Commons JCI Issue Type: Improvement Components: fam Reporter: Christian Trimble Assignee: Torsten Curdt Fix For: 1.1 The current trunk will not build from the root of the project with a clean repository, because the fam module is not referenced from the modules section of the root pom. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (JCI-65) Make FilesystemAlterationMonitor Thread a Daemon thread
[ https://issues.apache.org/jira/browse/JCI-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg closed JCI-65. - Make FilesystemAlterationMonitor Thread a Daemon thread --- Key: JCI-65 URL: https://issues.apache.org/jira/browse/JCI-65 Project: Commons JCI Issue Type: Bug Components: fam Affects Versions: 1.0 Reporter: Dave Marion Assignee: Torsten Curdt Fix For: 1.1 JVM won't shutdown if there are no other threads running. It will wait for the FAM thread to stop, which you can't interrupt. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (JCI-38) jdt 3.1 backend
[ https://issues.apache.org/jira/browse/JCI-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg closed JCI-38. - jdt 3.1 backend --- Key: JCI-38 URL: https://issues.apache.org/jira/browse/JCI-38 Project: Commons JCI Issue Type: New Feature Components: compiler eclipse Reporter: Mark Proctor Assignee: Torsten Curdt Fix For: 1.1 Tomcat is stil using JDT Core 3.1, any chance we could have a backend for that, otherwise Tomcat users have to use Janino. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (JCI-51) Eclipse compiler settings are ignored
[
https://issues.apache.org/jira/browse/JCI-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Bourg closed JCI-51.
-
Eclipse compiler settings are ignored
-
Key: JCI-51
URL: https://issues.apache.org/jira/browse/JCI-51
Project: Commons JCI
Issue Type: Bug
Components: compiler eclipse
Affects Versions: 1.0, 1.0RC2, 1.0RC1
Reporter: Torsten Curdt
Assignee: Torsten Curdt
Fix For: 1.1
JavaCompilerSettings does nothing for eclipse
{code}
public Map getMap() {
final Map map = new HashMap( defaultEclipseSettings );
map.put( CompilerOptions.OPTION_ReportDeprecation,
CompilerOptions.GENERATE );
map.put( CompilerOptions.OPTION_TargetPlatform,
CompilerOptions.VERSION_1_4 );
map.put( CompilerOptions.OPTION_Source,
CompilerOptions.VERSION_1_4 );
map.put( CompilerOptions.OPTION_Encoding,
UTF-8 );
return map;
}
{code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Closed] (JCI-67) Dubious use of mkdirs() return code
[
https://issues.apache.org/jira/browse/JCI-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Bourg closed JCI-67.
-
Dubious use of mkdirs() return code
---
Key: JCI-67
URL: https://issues.apache.org/jira/browse/JCI-67
Project: Commons JCI
Issue Type: Bug
Reporter: Sebb
Priority: Minor
Fix For: 1.1
FileRestoreStore.java uses mkdirs() as follows:
{code}
final File parent = file.getParentFile();
if (!parent.exists()) {
if (!parent.mkdirs()) {
throw new IOException(could not create + parent);
}
}
{code}
Now mkdirs() returns true *only* if the method actually created the
directories; it's theoretically possible for the directory to be created in
the window between the exists() and mkdirs() invocations.
Also, the initial exists() call is redundant, because that's what mkdirs()
does anyway (in the RI implementation, at least).
I suggest the following instead:
{code}
final File parent = file.getParentFile();
if (!parent.mkdirs() !parent.exists()) {
throw new IOException(could not create + parent);
}
}
{code}
If mkdirs() returns false, the code then checks to see if the directory
exists, so the throws clause will only be invoked if the parent really cannot
be created.
The same code also appears in AbstractTestCase and
FilesystemAlterationMonitorTestCase.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Closed] (JCI-73) Drop javac compiler; it only works on Java 1.5
[ https://issues.apache.org/jira/browse/JCI-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg closed JCI-73. - Drop javac compiler; it only works on Java 1.5 -- Key: JCI-73 URL: https://issues.apache.org/jira/browse/JCI-73 Project: Commons JCI Issue Type: Task Reporter: Sebb Fix For: 1.1 The Javac compiler builds OK on 1.5/1.6/1.7, but only runs on 1.5 because it uses proprietary APIs. There are two other Java compilers (Janino and Eclipse) which can run on Java 1.5, and it is EOL anyway, so there seems little point keeping the javac compiler code. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (POOL-211) Proxy support for pooled objects
[ https://issues.apache.org/jira/browse/POOL-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13794144#comment-13794144 ] Brad Koehn commented on POOL-211: - Thanks! Glad the patch got accepted. Proxy support for pooled objects Key: POOL-211 URL: https://issues.apache.org/jira/browse/POOL-211 Project: Commons Pool Issue Type: Improvement Affects Versions: 1.6, 2.0 Reporter: Brad Koehn Labels: features, patch Fix For: 2.0 Attachments: src.jar, test.jar Original Estimate: 48h Remaining Estimate: 48h Attached are files and tests that would allow users of commons-pool to interact with a proxy to the pooled object rather than the pooled object itself. This provides two benefits: detection of leaked pooled objects (when returnObject() isn't called) with a stack trace and detection of using pooled objects after they have been returned to the pool. The system provides a delegate which can be placed in front of any ObjectPool, similar to calling Collections.unmodifiableCollection(). Callers do not know that they're working with a proxy rather than the pooled object itself. Implementations are provided to use Java proxies or CGLib (useful when the pooled object doesn't implement an interface). Unit tests are also provided. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (LANG-919) Provide TypeLiteral class similar to javax.enterprise.util.TypeLiteral
[
https://issues.apache.org/jira/browse/LANG-919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Benson resolved LANG-919.
--
Resolution: Fixed
Done:
{{Committed revision 1531968.}}
Provide TypeLiteral class similar to javax.enterprise.util.TypeLiteral
--
Key: LANG-919
URL: https://issues.apache.org/jira/browse/LANG-919
Project: Commons Lang
Issue Type: Improvement
Components: lang.reflect.*
Affects Versions: 3.1
Reporter: Matt Benson
Assignee: Matt Benson
Fix For: 3.2
Attachments: LANG-919.patch.txt
This is more or less a necessity for thorough typesafe APIs that handle more
than just Class types, and IMO clearly falls within the mandate of Commons
Lang to provide the items that are missing from the JDK. The suggested
patch also includes a {{Typed}} interface that generalizes {{TypeLiteral}} in
an extensible way.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (SCXML-169) Archive current trunk (0.10) development as a branch (0.xx) and promote/copy the J6 branch (1.0) as new trunk
Ate Douma created SCXML-169: --- Summary: Archive current trunk (0.10) development as a branch (0.xx) and promote/copy the J6 branch (1.0) as new trunk Key: SCXML-169 URL: https://issues.apache.org/jira/browse/SCXML-169 Project: Commons SCXML Issue Type: Task Affects Versions: 1.0 Reporter: Ate Douma Assignee: Ate Douma Fix For: 1.0 The current trunk development towards version 0.10 has stalled and be dormant for several years already, while the J6 branch (towards 1.0) already is further advanced. With this task the current trunk will be moved and archived as a 0.xx branch and thereafter the J6 branch can be copied as new trunk (not moved, so this branch will remain as archive too). Further development thereafter thus will continue towards next major version 1.0 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (SCXML-169) Archive current trunk (0.10) development as a branch (0.xx) and promote/copy the J6 branch (1.0) as new trunk
[ https://issues.apache.org/jira/browse/SCXML-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ate Douma resolved SCXML-169. - Resolution: Fixed Archive current trunk (0.10) development as a branch (0.xx) and promote/copy the J6 branch (1.0) as new trunk - Key: SCXML-169 URL: https://issues.apache.org/jira/browse/SCXML-169 Project: Commons SCXML Issue Type: Task Affects Versions: 1.0 Reporter: Ate Douma Assignee: Ate Douma Fix For: 1.0 The current trunk development towards version 0.10 has stalled and be dormant for several years already, while the J6 branch (towards 1.0) already is further advanced. With this task the current trunk will be moved and archived as a 0.xx branch and thereafter the J6 branch can be copied as new trunk (not moved, so this branch will remain as archive too). Further development thereafter thus will continue towards next major version 1.0 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (SCXML-168) Test failure in SCXMLWriterTest using Java 7
[ https://issues.apache.org/jira/browse/SCXML-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ate Douma resolved SCXML-168. - Resolution: Fixed Patch applied (myself) Test failure in SCXMLWriterTest using Java 7 Key: SCXML-168 URL: https://issues.apache.org/jira/browse/SCXML-168 Project: Commons SCXML Issue Type: Bug Affects Versions: 1.0 Environment: Oracle Java 1.7.0_40-b43 Reporter: Ate Douma Assignee: Ate Douma Fix For: 1.0 Attachments: SCXML-168.patch Tests in the SCXMLWriterTest use StaX to transform SCXML to a pretty printed output and then compare this to a predefined expected output. However this is not reliable across Java compilers as to how pretty printing is precisely done. In this case, with (Oracle) Java 6, a newline is inserted between the XML declaration and the root element, while on (Oracle) Java 7 no such newline is added. As result these tests fail with Java 7. For these tests I think it is easy to fix: there is no functional need (here) to compare the XML output pretty formatted, so I simply removed the pretty printing and adjusted the predefined String to compare against. I'll attach a patch file shortly. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (LANG-869) add randomXMLText
[
https://issues.apache.org/jira/browse/LANG-869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13794808#comment-13794808
]
Henri Yandell commented on LANG-869:
This feels a little specific. Namely:
Random tag of name random text, containing random number of attributes, each of
random text, and random number of sub tags, each of random subtext.
Perhaps an example in the Javadoc would be useful. I'm not seeing a good
generic feature.
---
Alternatively the request is for XML safe random text. In that case, running
the random text through xml escape would seem the way to go.
add randomXMLText
-
Key: LANG-869
URL: https://issues.apache.org/jira/browse/LANG-869
Project: Commons Lang
Issue Type: Improvement
Components: lang.*
Reporter: Jin Kwon
Priority: Trivial
Labels: random
Please add some random method for values of XML elements or attributes.
I tried RandomStringUtils#random() for XML tag values and got
{{An invalid XML character (Unicode: 0x11) was found in the element content
of the document.}}
#randomAxxx and #randomNxxx may not enough.
Thanks.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (MATH-1038) Add methods to find confidence intervals for the mean of a binomial distribution
[ https://issues.apache.org/jira/browse/MATH-1038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13794834#comment-13794834 ] Phil Steitz commented on MATH-1038: --- Sorry for the slow response. Thanks for the patch! I like the idea and implementation. I do have a few small comments: 1. I am not sure the generification of the confidence interval type is buying anything and in fact I think it is an annoyance / in the way. I get that maybe we would one day want to have Integer there; but to actually do anything with the interval (like compute its width, half-width, etc.) or even to validate its parameters you have to immediately get doubleValue. Number is just too weak a type to be worth much here, IMO. It does not even implement Comparable. So I would favor just using doubles and eliminating the type signature. 2. There is a lot of missing javadoc. Thanks again for the patch. Add methods to find confidence intervals for the mean of a binomial distribution Key: MATH-1038 URL: https://issues.apache.org/jira/browse/MATH-1038 Project: Commons Math Issue Type: Wish Affects Versions: 3.2 Reporter: Thorsten Schäfer Priority: Minor Attachments: binomialConfidenceInterval.patch, binomialConfidenceInterval.patch -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Comment Edited] (MATH-1038) Add methods to find confidence intervals for the mean of a binomial distribution
[ https://issues.apache.org/jira/browse/MATH-1038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13794834#comment-13794834 ] Phil Steitz edited comment on MATH-1038 at 10/15/13 3:32 AM: - Sorry for the slow response. Thanks for the patch! I like the idea and implementation. I do have a few small comments: 1. I am not sure the generification of the confidence interval type is buying anything and in fact I think it is an annoyance / in the way. I get that maybe we would one day want to have Integer there; but to actually do anything with the interval (like compute its width, half-width, etc.) or even to validate its parameters you have to immediately get doubleValue. Number is just too weak a type to be worth much here, IMO. It does not even implement Comparable. So I would favor just using doubles and eliminating the type signature. 2. There is a lot of missing javadoc. 3. We should make it clear what confidence level means and how it is measured. I assume it will be between 0 and 1 and for confidence intervals it should be .95 means 95% confidence. Thanks again for the patch. was (Author: psteitz): Sorry for the slow response. Thanks for the patch! I like the idea and implementation. I do have a few small comments: 1. I am not sure the generification of the confidence interval type is buying anything and in fact I think it is an annoyance / in the way. I get that maybe we would one day want to have Integer there; but to actually do anything with the interval (like compute its width, half-width, etc.) or even to validate its parameters you have to immediately get doubleValue. Number is just too weak a type to be worth much here, IMO. It does not even implement Comparable. So I would favor just using doubles and eliminating the type signature. 2. There is a lot of missing javadoc. Thanks again for the patch. Add methods to find confidence intervals for the mean of a binomial distribution Key: MATH-1038 URL: https://issues.apache.org/jira/browse/MATH-1038 Project: Commons Math Issue Type: Wish Affects Versions: 3.2 Reporter: Thorsten Schäfer Priority: Minor Attachments: binomialConfidenceInterval.patch, binomialConfidenceInterval.patch -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (LANG-842) Lack of consistency in comparaison api
[ https://issues.apache.org/jira/browse/LANG-842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13794845#comment-13794845 ] Henri Yandell commented on LANG-842: I think we can ignore comparison with the time.* API. We've long favoured JODA Time to using the central Java classes and if we get a new date/time API in Java 8, I can see Lang 4.0 dropping the time.* package and porting whichever functions are considered valuable on top of the new API. Lack of consistency in comparaison api -- Key: LANG-842 URL: https://issues.apache.org/jira/browse/LANG-842 Project: Commons Lang Issue Type: Improvement Components: lang.*, lang.time.* Affects Versions: 3.2 Reporter: Pier-Luc Caron St-Pierre Priority: Trivial The comparaison api is lacking of consistency with null. Few instances : org.apache.commons.lang3.StringUtils#equals returns false if one of the parameter is null. org.apache.commons.lang3.ObjectUtils#equals returns false if one of the parameter is null. org.apache.commons.lang3.time.DateUtils#truncatedCompareTo throws IllegalArgumentException if one of the parameter is null org.apache.commons.lang3.time.DateUtils#isSameInstant throws IllegalArgumentException if one of the parameter is null I do not have any suggestion to fix that problem because any solution would break backward compatibility. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MATH-1039) Logarithmic probability and density calculations for the distributions
[ https://issues.apache.org/jira/browse/MATH-1039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13794846#comment-13794846 ] Phil Steitz commented on MATH-1039: --- This looks very good and useful. Thanks for the patch! Just a couple of quick comments and I can commit. 1. For 3.3 we can't add to the interfaces, so I suggest to add impls to the abstract parents and hold the add to the interfaces until 4.0. Unless someone screams, I will do that (so just omit the changes to the distribution interfaces) 2. Thanks so much for the careful job on the test cases. Where does the reference data come from? I like to include the source of reference data where possible. Logarithmic probability and density calculations for the distributions -- Key: MATH-1039 URL: https://issues.apache.org/jira/browse/MATH-1039 Project: Commons Math Issue Type: New Feature Reporter: Aleksei Dievskii Priority: Minor Labels: features, patch Attachments: LOGDENSITY.patch A person working with fairly small probabilities and densities often employs their logarithms to increase precision and decrease the chance of an underflow. However, just taking a log of the probability() or density() return value doesn't necessary solve the problem, as these methods themselves could have lost precision or underflowed. This patch introduces new logProbability() and logDensity() methods overriden for many relevant distribution. The patch also introduces tests of these new methods. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (MATH-1025) Create a CombinatoricsUtils class, move combinatorics utiilities there and add a method to enumerate combinations.
[ https://issues.apache.org/jira/browse/MATH-1025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz resolved MATH-1025. --- Resolution: Fixed Create a CombinatoricsUtils class, move combinatorics utiilities there and add a method to enumerate combinations. -- Key: MATH-1025 URL: https://issues.apache.org/jira/browse/MATH-1025 Project: Commons Math Issue Type: Improvement Reporter: Phil Steitz Assignee: Phil Steitz Priority: Minor Fix For: 4.0, 3.3 The methods to compute binomial coefficients, factorials and Stirling numbers should be deprecated in ArithmeticUtils and moved to a new class CombinatoricsUtils in o.a.c.m.util. This class can also house the combinations enumerator. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MATH-1002) AbstractUnivariateStatistic.test(double[] values, int begin, int length, boolean allowEmpty) has uses outside subclasses
[ https://issues.apache.org/jira/browse/MATH-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13794853#comment-13794853 ] Phil Steitz commented on MATH-1002: --- +1 to deprecate (they are protected, so can't just rip them out) and move to MathArrays. AbstractUnivariateStatistic.test(double[] values, int begin, int length, boolean allowEmpty) has uses outside subclasses Key: MATH-1002 URL: https://issues.apache.org/jira/browse/MATH-1002 Project: Commons Math Issue Type: Improvement Reporter: Sebb The methods AbstractUnivariateStatistic.test(double[] values, int begin, int length, boolean allowEmpty) and AbstractUnivariateStatistic.test(double[] values, int begin, int length) have uses outside that particular class hierarchy. In particular, they might be useful in StatUtils. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MATH-1034) Add binomial test
[ https://issues.apache.org/jira/browse/MATH-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13794857#comment-13794857 ] Phil Steitz commented on MATH-1034: --- Thorsten - are you OK moving to significance level instead of confidence level? Add binomial test - Key: MATH-1034 URL: https://issues.apache.org/jira/browse/MATH-1034 Project: Commons Math Issue Type: Wish Affects Versions: 3.2 Reporter: Thorsten Schäfer Priority: Minor Attachments: binomialTest.patch, binomialTest.patch A binomial test would be a nice addition to commons-math. I might supply a patch in the near future. I guess the interface should be similar to the other tests, i.e., a method to get the p-value and a method returning a boolean indicating reject/non-reject. Is there a policy about using Enumerations in commons-math? For instance, in R you can test two-sided, less or greater. This could be done using an enumeration in Java, but I'm not sure if this is discouraged for backward compatibility reasons... -- This message was sent by Atlassian JIRA (v6.1#6144)
