[jira] [Comment Edited] (BCEL-286) signatureToString fails if multiple type arguments
[ https://issues.apache.org/jira/browse/BCEL-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15883650#comment-15883650 ] Mark Roberts edited comment on BCEL-286 at 2/24/17 10:39 PM: - I found more problems and have expanded the fix and the test case. The revised changes are in signature2.diff. The signature processing in BCEL has only a little support for generic types. I have been trying to add some more support but the code really needs a complete rewrite. It should probably be modified to use sun.reflect.generics.parser. was (Author: markro): I found more problems and have expanded the fix and the test case. The revised changes are in signature2.diff. > signatureToString fails if multiple type arguments > -- > > Key: BCEL-286 > URL: https://issues.apache.org/jira/browse/BCEL-286 > Project: Commons BCEL > Issue Type: Bug >Reporter: Mark Roberts > Attachments: signature2.diff > > > signatureToString (in classfile/Utility.java) gets confused if a method has > multiple type arguments. > I have included a patch for fix and update to test-case that demonstrates the > problem. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (BCEL-286) signatureToString fails if multiple type arguments
[ https://issues.apache.org/jira/browse/BCEL-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Roberts updated BCEL-286: -- Attachment: (was: signature.diff) > signatureToString fails if multiple type arguments > -- > > Key: BCEL-286 > URL: https://issues.apache.org/jira/browse/BCEL-286 > Project: Commons BCEL > Issue Type: Bug >Reporter: Mark Roberts > Attachments: signature2.diff > > > signatureToString (in classfile/Utility.java) gets confused if a method has > multiple type arguments. > I have included a patch for fix and update to test-case that demonstrates the > problem. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (BCEL-286) signatureToString fails if multiple type arguments
[ https://issues.apache.org/jira/browse/BCEL-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Roberts updated BCEL-286: -- Attachment: signature2.diff > signatureToString fails if multiple type arguments > -- > > Key: BCEL-286 > URL: https://issues.apache.org/jira/browse/BCEL-286 > Project: Commons BCEL > Issue Type: Bug >Reporter: Mark Roberts > Attachments: signature2.diff > > > signatureToString (in classfile/Utility.java) gets confused if a method has > multiple type arguments. > I have included a patch for fix and update to test-case that demonstrates the > problem. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (BCEL-286) signatureToString fails if multiple type arguments
[ https://issues.apache.org/jira/browse/BCEL-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15883650#comment-15883650 ] Mark Roberts commented on BCEL-286: --- I found more problems and have expanded the fix and the test case. The revised changes are in signature2.diff. > signatureToString fails if multiple type arguments > -- > > Key: BCEL-286 > URL: https://issues.apache.org/jira/browse/BCEL-286 > Project: Commons BCEL > Issue Type: Bug >Reporter: Mark Roberts > Attachments: signature.diff > > > signatureToString (in classfile/Utility.java) gets confused if a method has > multiple type arguments. > I have included a patch for fix and update to test-case that demonstrates the > problem. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (BCEL-279) Utility.methodSignature* throw ClassFormatException when converting binary names with generics.
[
https://issues.apache.org/jira/browse/BCEL-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15883626#comment-15883626
]
Mark Roberts edited comment on BCEL-279 at 2/24/17 10:23 PM:
-
The signature processing in BCEL has not been updated to support generic types.
I have been trying to add some support (see
https://issues.apache.org/jira/browse/BCEL-286) but the code really needs a
complete rewrite. It should probably be modified to use
sun.reflect.generics.parser.
was (Author: markro):
The signature processing in BCEL has not been updated to support generic types.
I have been trying to add some support (see
https://issues.apache.org/jira/browse/BCEL-285) but the code really needs a
complete rewrite. It should probably be modified to use
sun.reflect.generics.parser.
> Utility.methodSignature* throw ClassFormatException when converting binary
> names with generics.
> ---
>
> Key: BCEL-279
> URL: https://issues.apache.org/jira/browse/BCEL-279
> Project: Commons BCEL
> Issue Type: Bug
> Components: Parser
>Affects Versions: 6.0
>Reporter: Dongsun Kim
> Fix For: 6.1
>
>
> When I try the following, Utility class throws ClassFormatException:
> {code}
> String sig =
> "(Lcom/google/common/io/ByteProcessor;)TT;"
> Utility.methodSignatureArgumentTypes(sig, false)
> {code}
> The above signature actually exists in com.google.common.io.ByteSource in
> Google Guava.
> Utility.methodSignatureReturnType does not throw any exception but its return
> value does not look valid.
> When I try this:
> {code}
> String sig =
> "(Lcom/google/common/io/ByteProcessor;)TT;"
> Utility.methodSignaturerReturnType(sig, false)
> {code}
> expected: java.lang.Object
> actual: T
> It seems that org.apache.bcel.generic.Type.java also has the same issue.
> Dongsun.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (BCEL-279) Utility.methodSignature* throw ClassFormatException when converting binary names with generics.
[
https://issues.apache.org/jira/browse/BCEL-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15883626#comment-15883626
]
Mark Roberts commented on BCEL-279:
---
The signature processing in BCEL has not been updated to support generic types.
I have been trying to add some support (see
https://issues.apache.org/jira/browse/BCEL-285) but the code really needs a
complete rewrite. It should probably be modified to use
sun.reflect.generics.parser.
> Utility.methodSignature* throw ClassFormatException when converting binary
> names with generics.
> ---
>
> Key: BCEL-279
> URL: https://issues.apache.org/jira/browse/BCEL-279
> Project: Commons BCEL
> Issue Type: Bug
> Components: Parser
>Affects Versions: 6.0
>Reporter: Dongsun Kim
> Fix For: 6.1
>
>
> When I try the following, Utility class throws ClassFormatException:
> {code}
> String sig =
> "(Lcom/google/common/io/ByteProcessor;)TT;"
> Utility.methodSignatureArgumentTypes(sig, false)
> {code}
> The above signature actually exists in com.google.common.io.ByteSource in
> Google Guava.
> Utility.methodSignatureReturnType does not throw any exception but its return
> value does not look valid.
> When I try this:
> {code}
> String sig =
> "(Lcom/google/common/io/ByteProcessor;)TT;"
> Utility.methodSignaturerReturnType(sig, false)
> {code}
> expected: java.lang.Object
> actual: T
> It seems that org.apache.bcel.generic.Type.java also has the same issue.
> Dongsun.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CLI-269) Introduce CommandLineBuilder
[ https://issues.apache.org/jira/browse/CLI-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15883600#comment-15883600 ] Robert Scholte commented on CLI-269: Yeah, auto-save formatting, will reduce the noice > Introduce CommandLineBuilder > > > Key: CLI-269 > URL: https://issues.apache.org/jira/browse/CLI-269 > Project: Commons CLI > Issue Type: New Feature > Components: Build >Affects Versions: 1.3.1 >Reporter: Robert Scholte > Attachments: commandlinebuilder.patch > > > For Maven there are several places where one can define the commandline > arguments. These should be merged to 1 new commandline, but we need to have > control over the order in which these are merged. > Best solution seems to be to introduce a CommandLineBuilder. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLI-269) Introduce CommandLineBuilder
[ https://issues.apache.org/jira/browse/CLI-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15883597#comment-15883597 ] Pascal Schumacher commented on CLI-269: --- Hi Robert, nice to see somebody doing some work on commons-cli. :-) It would be nice if you could remove the formatting changes (looks like you changed the formatting to maven code style) from the patch. > Introduce CommandLineBuilder > > > Key: CLI-269 > URL: https://issues.apache.org/jira/browse/CLI-269 > Project: Commons CLI > Issue Type: New Feature > Components: Build >Affects Versions: 1.3.1 >Reporter: Robert Scholte > Attachments: commandlinebuilder.patch > > > For Maven there are several places where one can define the commandline > arguments. These should be merged to 1 new commandline, but we need to have > control over the order in which these are merged. > Best solution seems to be to introduce a CommandLineBuilder. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (BCEL-287) IINC does not handle -128 properly
[ https://issues.apache.org/jira/browse/BCEL-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Roberts updated BCEL-287: -- Attachment: IINC.diff > IINC does not handle -128 properly > -- > > Key: BCEL-287 > URL: https://issues.apache.org/jira/browse/BCEL-287 > Project: Commons BCEL > Issue Type: Bug >Reporter: Mark Roberts > Attachments: IINC.diff > > > src/main/java/org/apache/bcel/generic/IINC.java is only allowing -127 to +127 > as an argument. it should allow -128 as well. I have attached a patch. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (BCEL-287) IINC does not handle -128 properly
Mark Roberts created BCEL-287: - Summary: IINC does not handle -128 properly Key: BCEL-287 URL: https://issues.apache.org/jira/browse/BCEL-287 Project: Commons BCEL Issue Type: Bug Reporter: Mark Roberts src/main/java/org/apache/bcel/generic/IINC.java is only allowing -127 to +127 as an argument. it should allow -128 as well. I have attached a patch. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] commons-lang pull request #245: Use foreach
Github user asfgit closed the pull request at: https://github.com/apache/commons-lang/pull/245 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] commons-lang issue #245: Use foreach
Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/245 Thanks! :+1: --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Updated] (LANG-1238) Overload Operations in StringUtils that take a regex to take precompiled Pattern
[ https://issues.apache.org/jira/browse/LANG-1238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Schumacher updated LANG-1238: Fix Version/s: Patch Needed > Overload Operations in StringUtils that take a regex to take precompiled > Pattern > > > Key: LANG-1238 > URL: https://issues.apache.org/jira/browse/LANG-1238 > Project: Commons Lang > Issue Type: Improvement > Components: lang.* >Affects Versions: 3.4 >Reporter: Christopher Cordeiro >Priority: Minor > Fix For: Patch Needed > > > For performance reasons, it would be nice if the operations in StringUtils > that take a regular expression (removePattern/replacePattern) were overloaded > to optionally take a precompiled Pattern. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (BCEL-285) "ClassFormatException: Invalid signature" thrown on generics
[
https://issues.apache.org/jira/browse/BCEL-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15883584#comment-15883584
]
Mark Roberts commented on BCEL-285:
---
This does look like an invalid signature to me. The error message does not
show the entire signature, just the part it could not parse. The "\!" should
not be there. The remainder of the signature (after the \!) looks correct and
corresponds to "extends Object" the "?" should have been compiled into a "\*"
in the signature. Perhaps this is a bug in the compiler you mention that it is
using "\!" instead of "\*"?
> "ClassFormatException: Invalid signature" thrown on generics
>
>
> Key: BCEL-285
> URL: https://issues.apache.org/jira/browse/BCEL-285
> Project: Commons BCEL
> Issue Type: Bug
> Components: Parser
>Affects Versions: 6.0
> Environment: java 8, macOS 10.12.2
>Reporter: Tom Brus
>
> The following stripped down example throws an Exception in {{BCEL}}:
> {code:title=Bar.java|borderStyle=solid}
> import java.io.IOException;
> import java.util.stream.Stream;
> import org.apache.bcel.classfile.ClassParser;
> public class Main {
> public static void main(String[] args) throws IOException {
> ClassParser parser = new
> ClassParser(Main.class.getResourceAsStream("Main.class"), "Main.class");
> parser.parse().getMethods()[2].getCode().toString(); /* <- EXCEPTION
> thrown */
>
> ((Stream)null).peek(x -> {}); /* <- problem spot */
> }
> }
> {code}
> The exception is:
> {code}
> Exception in thread "main" org.apache.bcel.classfile.ClassFormatException:
> Invalid signature: `!+Ljava/lang/Object;'
> at org.apache.bcel.classfile.Utility.signatureToString(Utility.java:930)
> at
> org.apache.bcel.classfile.LocalVariable.toStringShared(LocalVariable.java:187)
> at
> org.apache.bcel.classfile.LocalVariableTypeTable.toString(LocalVariableTypeTable.java:121)
> at java.lang.String.valueOf(String.java:2994)
> at java.lang.StringBuilder.append(StringBuilder.java:131)
> at org.apache.bcel.classfile.Code.toString(Code.java:316)
> at org.apache.bcel.classfile.Code.toString(Code.java:328)
> at Main.main(Main.java:9)
> {code}
> This problem only occurs in eclipse (I am using NEON.2) and does not occur in
> Intellij (I am using 2016.3.2). This probably indicates that {{ecj}} and
> {{javac}} differ in their class code generator.
> Since our project uses {{sonar:findbugs}} which uses {{BCEL}} this is a major
> problem for us.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] commons-lang issue #245: Use foreach
Github user mureinik commented on the issue: https://github.com/apache/commons-lang/pull/245 @PascalSchumacher Missed that discussion somehow. I've reduced the scope of the patch to handle only for loops that go over arrays. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] commons-lang issue #245: Use foreach
Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/245 For time to time there are discussion concerning the use of the for-each loop on the mailing list. (e.g. http://markmail.org/thread/wmedbgqmewmpiptk#query:+page:1+mid:gbo5cpywwfxl5p4w+state:results) As far as I remember the consensus was to use it only for arrays, because there it does not have any negative impact on performance. When used with iterables it has some impact on performance (because it requires the creation of an iterator). Therefore some contributors were against using it with iterables in a low level library like commons-lang. Most of your changes concern arrays, so if you remove the iterable parts I think this is safe to merge. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] commons-lang pull request #245: Use foreach
GitHub user mureinik opened a pull request: https://github.com/apache/commons-lang/pull/245 Use foreach Since the project no longer supports Java versions older than 6, it's safe to use the enhanced for loop syntax introduced in Java 5. This patch employs this syntax where possible to clean up the code. You can merge this pull request into a Git repository by running: $ git pull https://github.com/mureinik/commons-lang foreach Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-lang/pull/245.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #245 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Resolved] (JCS-173) cdi integration doesnt find static annotations on interfaces of (java) proxies
[ https://issues.apache.org/jira/browse/JCS-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved JCS-173. Resolution: Fixed > cdi integration doesnt find static annotations on interfaces of (java) proxies > -- > > Key: JCS-173 > URL: https://issues.apache.org/jira/browse/JCS-173 > Project: Commons JCS > Issue Type: Improvement >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau > Fix For: jcs-2.2 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (JCS-173) cdi integration doesnt find static annotations on interfaces of (java) proxies
Romain Manni-Bucau created JCS-173: -- Summary: cdi integration doesnt find static annotations on interfaces of (java) proxies Key: JCS-173 URL: https://issues.apache.org/jira/browse/JCS-173 Project: Commons JCS Issue Type: Improvement Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau Fix For: jcs-2.2 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (LANG-1265) Build failures when building with Java 9 EA
[
https://issues.apache.org/jira/browse/LANG-1265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15883202#comment-15883202
]
ASF GitHub Bot commented on LANG-1265:
--
GitHub user PascalSchumacher opened a pull request:
https://github.com/apache/commons-lang/pull/244
LANG-1265: Build failures when building with Java 9 EA
Fix build on Java 9 Build 157 by adding a java-9 maven profile. This is
activated by default on Java 9 and opens up java.base classes for reflection
which makes all unit tests pass.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/PascalSchumacher/commons-lang
fix_build_on_java_9
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/commons-lang/pull/244.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #244
commit e0b8d45ac7d7f2f15d670298fe5e1d4762efbce2
Author: pascalschumacher
Date: 2017-02-24T17:51:03Z
LANG-1265: Build failures when building with Java 9 EA
Fix build on Java 9 Build 157 by adding a java-9 maven profile. This is
activated by default on Java 9 and opens up java.base classes for reflection
which makes all unit tests pass.
> Build failures when building with Java 9 EA
> ---
>
> Key: LANG-1265
> URL: https://issues.apache.org/jira/browse/LANG-1265
> Project: Commons Lang
> Issue Type: Bug
>Reporter: Benedikt Ritter
> Fix For: 3.6
>
>
> When building with Java 9 EA I get:
> {code}
> Failed tests:
>
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_LongNoEra_AD:304->FastDateParserTest.testLocales:342
> Locale no failed with /////ss// era AD
> java.text.ParseException: Unparseable date:
> 2003/februar/0010/0012//00/AM/mandag
>
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_LongNoEra_BC:309->FastDateParserTest.testLocales:342
> Locale no failed with /////ss// era BC
> java.text.ParseException: Unparseable date:
> 2003/februar/0010/0012//00/AM/lørdag
>
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_Long_AD:284->FastDateParserTest.testLocales:342
> Locale no failed with //////ss// era AD
> java.text.ParseException: Unparseable date:
> AD/2003/februar/0010/0012//00/AM/mandag
>
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_Long_BC:289->FastDateParserTest.testLocales:342
> Locale qu_EC failed with //////ss// era BC
> java.text.ParseException: Unparseable date: "/2003/Hatun
> puquy/0010/0012//00/a.m./Sábado"
>
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_ShortNoEra_AD:314->FastDateParserTest.testLocales:342
> Locale no failed with y/M/d/h/a/m/s/E era AD
> java.text.ParseException: Unparseable date: 2003/2/10/12/AM/0/0/ma
>
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_ShortNoEra_BC:319->FastDateParserTest.testLocales:342
> Locale no failed with y/M/d/h/a/m/s/E era BC
> java.text.ParseException: Unparseable date: 2003/2/10/12/AM/0/0/lø
>
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_Short_AD:294->FastDateParserTest.testLocales:342
> Locale no failed with G/y/M/d/h/a/m/s/E era AD
> java.text.ParseException: Unparseable date: e.Kr./2003/2/10/12/AM/0/0/ma
>
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_Short_BC:299->FastDateParserTest.testLocales:342
> Locale qu_EC failed with G/y/M/d/h/a/m/s/E era BC
> java.text.ParseException: Unparseable date: "/2003/2/10/12/a.m./0/0/Sab"
> FastDateParserTest.testLocales_LongNoEra_AD:304->testLocales:342 Locale no
> failed with /////ss// era AD
> java.text.ParseException: Unparseable date:
> 2003/februar/0010/0012//00/AM/mandag
> FastDateParserTest.testLocales_LongNoEra_BC:309->testLocales:342 Locale no
> failed with /////ss// era BC
> java.text.ParseException: Unparseable date:
> 2003/februar/0010/0012//00/AM/lørdag
> FastDateParserTest.testLocales_Long_AD:284->testLocales:342 Locale no
> failed with //////ss// era AD
> java.text.ParseException: Unparseable date:
> AD/2003/februar/0010/0012//00/AM/mandag
> FastDateParserTest.testLocales_Long_BC:289->testLocales:342 Locale qu_EC
> failed with //////ss// era BC
> java.text.ParseException: Unparseable date: "/2003/Hatun
> puquy/0010/0012//00/a.m./Sábado"
> FastDateParserTest.testLocales_ShortNoEra_AD:314->testLocales:342 Locale no
> failed with y/M/d/h/a/m/s/E era AD
> java.text.ParseException: Unparseable date: 2003/2/10/12/AM/0/0/ma
> F
[GitHub] commons-lang pull request #244: LANG-1265: Build failures when building with...
GitHub user PascalSchumacher opened a pull request: https://github.com/apache/commons-lang/pull/244 LANG-1265: Build failures when building with Java 9 EA Fix build on Java 9 Build 157 by adding a java-9 maven profile. This is activated by default on Java 9 and opens up java.base classes for reflection which makes all unit tests pass. You can merge this pull request into a Git repository by running: $ git pull https://github.com/PascalSchumacher/commons-lang fix_build_on_java_9 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-lang/pull/244.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #244 commit e0b8d45ac7d7f2f15d670298fe5e1d4762efbce2 Author: pascalschumacher Date: 2017-02-24T17:51:03Z LANG-1265: Build failures when building with Java 9 EA Fix build on Java 9 Build 157 by adding a java-9 maven profile. This is activated by default on Java 9 and opens up java.base classes for reflection which makes all unit tests pass. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (LANG-1238) Overload Operations in StringUtils that take a regex to take precompiled Pattern
[ https://issues.apache.org/jira/browse/LANG-1238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15883058#comment-15883058 ] Pascal Schumacher commented on LANG-1238: - I think patches for this are welcome. > Overload Operations in StringUtils that take a regex to take precompiled > Pattern > > > Key: LANG-1238 > URL: https://issues.apache.org/jira/browse/LANG-1238 > Project: Commons Lang > Issue Type: Improvement > Components: lang.* >Affects Versions: 3.4 >Reporter: Christopher Cordeiro >Priority: Minor > > For performance reasons, it would be nice if the operations in StringUtils > that take a regular expression (removePattern/replacePattern) were overloaded > to optionally take a precompiled Pattern. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] commons-lang pull request #243: Fix JsonToStringStyleTest.NestingPerson java...
Github user asfgit closed the pull request at: https://github.com/apache/commons-lang/pull/243 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] commons-lang issue #243: Fix JsonToStringStyleTest.NestingPerson javadoc
Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/243 Thanks! --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Created] (POOL-319) Lost ID Badge
Garrett Lucking created POOL-319: Summary: Lost ID Badge Key: POOL-319 URL: https://issues.apache.org/jira/browse/POOL-319 Project: Commons Pool Issue Type: Wish Reporter: Garrett Lucking Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MATH-1403) Collinearity test: QR Decomposition rank incorrect (SVD ok)
[
https://issues.apache.org/jira/browse/MATH-1403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15882686#comment-15882686
]
Gilles commented on MATH-1403:
--
It looks wrong indeed.
The Javadoc mentions "When a large fall in norm is seen, the rank is returned"
which seems fairly unhelpful in order to select an appropriate threshold value.
As human resources have become scarce for the Commons Math project, you are
most welcome to look at the code in order to find the bug.
I've slightly modified your example (transformed into a unit test):
{code}
@Test
public void testMath1403() {
final double delta = 1e-7; // Test fails when delta <= 1e-8.
final double[][] m = {
{1, 1, 1, 1 + delta, 1, 1},
{1, 1, 1, delta, 0, 0},
{0, 0, 0, 1, 1, 1},
{1, 0, 0, 1, 0, 0},
{0, 0, 1, 0, 0, 1}
};
final RRQRDecomposition qr = new RRQRDecomposition(new
Array2DRowRealMatrix(m));
final double dropThreshold = 1e-7; // Test fails when dropThreshold <=
1e-8.
Assert.assertEquals(4, qr.getRank(dropThreshold));
}
{code}
It hints at a numerical problem...
> Collinearity test: QR Decomposition rank incorrect (SVD ok)
> ---
>
> Key: MATH-1403
> URL: https://issues.apache.org/jira/browse/MATH-1403
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.6.1
> Environment: Linux ubuntu
> JDK 8
>Reporter: Hugo Ferrira
>
> Hello,
> I am aware that such a question have been asked before but I cannot seem to
> solve this issue for a very simple example. The closest example I have is:
> https://issues.apache.org/jira/browse/MATH-1100
> from which I could not get an answer.
> I am trying to copy an algorithm from R's Caret package that identifies
> collinear columns of a matrix [1]. I am assuming a "long" matrix and and am
> using the trivial example from the reference above. However I cannot get this
> to work because the QR's rank result is incorrect.
> I have the following example:
> import org.apache.commons.math3.linear.RealMatrix;
> import org.apache.commons.math3.linear.RRQRDecomposition;
> import org.apache.commons.math3.linear.Array2DRowRealMatrix;
> import org.apache.commons.math3.linear.SingularValueDecomposition ;
> public class QRIssue {
> public static void main(String[] args) {
> double[][] am = new double[5][];
> double[] c1 = new double[] {1.0, 1.0, 1.0, 1.0, 1.0, 1.0} ;
> double[] c2 = new double[] {1.0, 1.0, 1.0, 0.0, 0.0, 0.0} ;
> double[] c3 = new double[] {0.0, 0.0, 0.0, 1.0, 1.0, 1.0} ;
> double[] c4 = new double[] {1.0, 0.0, 0.0, 1.0, 0.0, 0.0 } ;
> double[] c6 = new double[] {0.0, 0.0, 1.0, 0.0, 0.0, 1.0 } ;
> am[0] = c1 ;
> am[1] = c2 ;
> am[2] = c3 ;
> am[3] = c4 ;
> am[4] = c6 ;
> Double threshold = 1e-1;
> Array2DRowRealMatrix m = new Array2DRowRealMatrix( am, false ) ; // use
> array, don't copy
> RRQRDecomposition qr = new RRQRDecomposition( m, threshold) ;
> RealMatrix r = qr.getR() ;
> int numColumns = r.getColumnDimension() ;
> int rank = qr.getRank( threshold ) ;
> System.out.println("QR rank: " + rank) ;
> System.out.println("QR is singular: " + !qr.getSolver().isNonSingular()) ;
> System.out.println("QR is singular: " + (numColumns == rank) ) ;
> SingularValueDecomposition sv2 = new
> org.apache.commons.math3.linear.SingularValueDecomposition(m);
> System.out.println("SVD rank: " + sv2.getRank()) ;
> }
> }
> For SVD I get a rank of 4 which is correct (columns 0,1,2 are collinear : c0
> = c1 + c2). But for QR I get 5. I have tried several thresholds with no
> success. For several subsets of the columns above (example only 0,1,2 I get
> the correct answer). What am I doing wrong?
> TIA,
> Hugo F.
> 1. https://topepo.github.io/caret/pre-processing.html#lindep
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
