[jira] [Commented] (MATH-743) Use enums in package transform
[
https://issues.apache.org/jira/browse/MATH-743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13206365#comment-13206365
]
Sébastien Brisard commented on MATH-743:
Not sure I see how this is related to the changes discussed here, but by all
means, give it a try. You might want to wait for a couple of days, though, as I
still have a few API changes to do on package transform (mostly DCT and DST
related).
Good luck with the optimization!
> Use enums in package transform
> --
>
> Key: MATH-743
> URL: https://issues.apache.org/jira/browse/MATH-743
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Sébastien Brisard
>Assignee: Sébastien Brisard
> Labels: api-change, enum, transform
>
> As discussed on the mailing-list, enums could be used in the package
> {{transform}}
> # An enumeration {{FORWARD, INVERSE}} will be created to specify whether the
> inverse transform is to be computed. This will replace the pair
> {{transform}}/{{inverseTransform}}
> # An enumeration {{STANDARD, ORTHOGONAL}} will be introduced (where relevant)
> in each transform class, in order to specify the normalization that should be
> used. Then the factory methods {{create()}}/{{createOrthogonal()}} will be
> replaced by a parameter passed to the constructor, which will be made public.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-741) Univariate Function Series Abstract Factory Implementation
[ https://issues.apache.org/jira/browse/MATH-741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leandro Ariel Pezzente resolved MATH-741. - Resolution: Later This feature will we discussed in the ML before proper changes should be applied. > Univariate Function Series Abstract Factory Implementation > -- > > Key: MATH-741 > URL: https://issues.apache.org/jira/browse/MATH-741 > Project: Commons Math > Issue Type: New Feature >Affects Versions: 4.0 >Reporter: Leandro Ariel Pezzente >Priority: Minor > Attachments: Hypergeometric.java, TestHypergeometric.java, > UnivariateFunctionFactory.java > > > To Implement an abstract class for witch Univariate functions constructed > using functional series. This abstract class must resolve all terms sums > using recursive iterative methods. Classes subclassed by this abstract > function must implement UnivariateFunction interface. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-743) Use enums in package transform
[
https://issues.apache.org/jira/browse/MATH-743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13206320#comment-13206320
]
Leandro Ariel Pezzente commented on MATH-743:
-
I would love to give it a try at changing the transformer loops into a
recursive summation function just to see if it improves performance.
> Use enums in package transform
> --
>
> Key: MATH-743
> URL: https://issues.apache.org/jira/browse/MATH-743
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Sébastien Brisard
>Assignee: Sébastien Brisard
> Labels: api-change, enum, transform
>
> As discussed on the mailing-list, enums could be used in the package
> {{transform}}
> # An enumeration {{FORWARD, INVERSE}} will be created to specify whether the
> inverse transform is to be computed. This will replace the pair
> {{transform}}/{{inverseTransform}}
> # An enumeration {{STANDARD, ORTHOGONAL}} will be introduced (where relevant)
> in each transform class, in order to specify the normalization that should be
> used. Then the factory methods {{create()}}/{{createOrthogonal()}} will be
> replaced by a parameter passed to the constructor, which will be made public.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (MATH-728) Errors in BOBYQAOptimizer when numberOfInterpolationPoints is greater than 2*dim+1
[
https://issues.apache.org/jira/browse/MATH-728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13206296#comment-13206296
]
Gilles edited comment on MATH-728 at 2/11/12 11:47 PM:
---
Although the bug that triggered this issue is fixed, failures of the unit test
still miss an explanation...
The poor performance is to be expected given the current state of the code
(e.g. many matrix calculations are done explicitly, with getters and setters,
instead of calling methods of the matrix objects).
was (Author: erans):
Although the bug that triggered this issue is fixed, failures of the unit
test are still miss an explanation...
The poor performance is to be expected given the current state of the code
(e.g. many matrix calculations are done explicitly, with getters and setters,
instead of calling methods of the matrix objects).
> Errors in BOBYQAOptimizer when numberOfInterpolationPoints is greater than
> 2*dim+1
> --
>
> Key: MATH-728
> URL: https://issues.apache.org/jira/browse/MATH-728
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.0
> Environment: Mac Java(TM) SE Runtime Environment (build
> 1.6.0_29-b11-402-11M3527)
>Reporter: Bruce A Johnson
> Fix For: 3.0
>
>
> I've been having trouble getting BOBYQA to minimize a function (actually a
> non-linear least squares fit) so as one change I increased the number of
> interpolation points. It seems that anything larger than 2*dim+1 causes an
> error (typically at
> line 1662
>interpolationPoints.setEntry(nfm, ipt,
> interpolationPoints.getEntry(ipt, ipt));
> I'm guessing there is an off by one error in the translation from FORTRAN.
> Changing the BOBYQAOptimizerTest as follows (increasing number of
> interpolation points by one) will cause failures.
> Bruce
> Index:
> src/test/java/org/apache/commons/math/optimization/direct/BOBYQAOptimizerTest.java
> ===
> ---
> src/test/java/org/apache/commons/math/optimization/direct/BOBYQAOptimizerTest.java
> (revision 1221065)
> +++
> src/test/java/org/apache/commons/math/optimization/direct/BOBYQAOptimizerTest.java
> (working copy)
> @@ -258,7 +258,7 @@
> //RealPointValuePair result = optim.optimize(10, func, goal,
> startPoint);
> final double[] lB = boundaries == null ? null : boundaries[0];
> final double[] uB = boundaries == null ? null : boundaries[1];
> -BOBYQAOptimizer optim = new BOBYQAOptimizer(2 * dim + 1);
> +BOBYQAOptimizer optim = new BOBYQAOptimizer(2 * dim + 2);
> RealPointValuePair result = optim.optimize(maxEvaluations, func,
> goal, startPoint, lB, uB);
> //System.out.println(func.getClass().getName() + " = "
> // + optim.getEvaluations() + " f(");
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-728) Errors in BOBYQAOptimizer when numberOfInterpolationPoints is greater than 2*dim+1
[
https://issues.apache.org/jira/browse/MATH-728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles resolved MATH-728.
-
Resolution: Fixed
Fix Version/s: 3.0
Although the bug that triggered this issue is fixed, failures of the unit test
are still miss an explanation...
The poor performance is to be expected given the current state of the code
(e.g. many matrix calculations are done explicitly, with getters and setters,
instead of calling methods of the matrix objects).
> Errors in BOBYQAOptimizer when numberOfInterpolationPoints is greater than
> 2*dim+1
> --
>
> Key: MATH-728
> URL: https://issues.apache.org/jira/browse/MATH-728
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.0
> Environment: Mac Java(TM) SE Runtime Environment (build
> 1.6.0_29-b11-402-11M3527)
>Reporter: Bruce A Johnson
> Fix For: 3.0
>
>
> I've been having trouble getting BOBYQA to minimize a function (actually a
> non-linear least squares fit) so as one change I increased the number of
> interpolation points. It seems that anything larger than 2*dim+1 causes an
> error (typically at
> line 1662
>interpolationPoints.setEntry(nfm, ipt,
> interpolationPoints.getEntry(ipt, ipt));
> I'm guessing there is an off by one error in the translation from FORTRAN.
> Changing the BOBYQAOptimizerTest as follows (increasing number of
> interpolation points by one) will cause failures.
> Bruce
> Index:
> src/test/java/org/apache/commons/math/optimization/direct/BOBYQAOptimizerTest.java
> ===
> ---
> src/test/java/org/apache/commons/math/optimization/direct/BOBYQAOptimizerTest.java
> (revision 1221065)
> +++
> src/test/java/org/apache/commons/math/optimization/direct/BOBYQAOptimizerTest.java
> (working copy)
> @@ -258,7 +258,7 @@
> //RealPointValuePair result = optim.optimize(10, func, goal,
> startPoint);
> final double[] lB = boundaries == null ? null : boundaries[0];
> final double[] uB = boundaries == null ? null : boundaries[1];
> -BOBYQAOptimizer optim = new BOBYQAOptimizer(2 * dim + 1);
> +BOBYQAOptimizer optim = new BOBYQAOptimizer(2 * dim + 2);
> RealPointValuePair result = optim.optimize(maxEvaluations, func,
> goal, startPoint, lB, uB);
> //System.out.println(func.getClass().getName() + " = "
> // + optim.getEvaluations() + " f(");
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CODEC-133) Please add a function for the MD5/SHA1/SHA-512 based Unix crypt(3) hash variants
[ https://issues.apache.org/jira/browse/CODEC-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Hammers updated CODEC-133: Attachment: crypt3-with-utexas-licence.diff This is a patch agains svn trunk version 1241181. It includes the neccessary new classes as well as tests: M src/main/java/org/apache/commons/codec/digest/DigestUtils.java A src/main/java/org/apache/commons/codec/digest/Md5Crypt.java M src/main/java/org/apache/commons/codec/digest/package.html A src/main/java/org/apache/commons/codec/digest/README.WORK A src/main/java/org/apache/commons/codec/digest/Sha256Crypt.java A src/main/java/org/apache/commons/codec/digest/Sha512Crypt.java A src/main/java/org/apache/commons/codec/digest/UnixCrypt.java M src/test/java/org/apache/commons/codec/digest/DigestUtilsTest.java A src/test/java/org/apache/commons/codec/digest/Md5CryptTest.java A src/test/java/org/apache/commons/codec/digest/Sha256CryptTest.java A src/test/java/org/apache/commons/codec/digest/Sha512CryptTest.java A src/test/java/org/apache/commons/codec/digest/UnixCryptTest.java README.WORK contains some notes to the reviewer and should be deleted then. The files already include the Apache license text but the original utexas copyright notice is still left. I leave it for you to sort out the legal stuff with Jonathan Abbey. > Please add a function for the MD5/SHA1/SHA-512 based Unix crypt(3) hash > variants > > > Key: CODEC-133 > URL: https://issues.apache.org/jira/browse/CODEC-133 > Project: Commons Codec > Issue Type: New Feature >Affects Versions: 1.6 >Reporter: Christian Hammers > Labels: MD5, SHA-512, crypt(3), crypto, hash > Attachments: crypt3-with-utexas-licence.diff > > > The Linux libc6 crypt(3) function, which is used to generate e.g. the > password hashes in /etc/shadow, is available in nearly all other programming > languages (Perl, PHP, Python, C, C++, ...) and databases like MySQL and > offers MD5/SHA1/SHA-512 based algorithms that were improved by adding a salt > and several iterations to make rainbow table attacks harder. Thus they are > widely used to store user passwords. > Java, though, has due it's platform independence, no direct access to the > libc functions and still lacks an proper port of the crypt(3) function. > I already filed a wishlist bug (CODEC-104) for the traditional 56-bit DES > based crypt(3) method but would also like to see the much stronger algorithms. > There are other bug reports like DIRSTUDIO-738 that demand those crypt > variants for some specific applications so there it would benefit other > Apache projects as well. > Java ports of most of the specific crypt variants are already existing, but > they would have to be cleaned up, properly tested and license checked: > ftp://ftp.arlut.utexas.edu/pub/java_hashes/ > I would be willing to help here by cleaning the source code and writing unit > tests etc. but I'd like to generally know if you are interested and if > there's someone who can do a code review (it's security relevant after all > and I'm no crypto guy) > bye, > -christian- -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-728) Errors in BOBYQAOptimizer when numberOfInterpolationPoints is greater than 2*dim+1
[
https://issues.apache.org/jira/browse/MATH-728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13206281#comment-13206281
]
Bruce A Johnson commented on MATH-728:
--
I've been playing with BOBYQA (downloaded from svn repository today, and
commenting out the PathNotExplored exceptions). A couple observations.
1) I can't make it fail with large number of interpolation points (as long as
you stay under the (2n+1)*(2n+2)/2 recommended max. So this issue is resolved.
2) With large number of interpolation points the algorithm is significantly
slower. I'm minimizing a function with a 169 parameters. The function
evaluation takes ~50 msec. With n+2 interpolation points, the additional time
for each step is about 10 msec. With 2*n+1 points, the additional time is
about 50 msec, and with about 6*n, the additional time is 250 msec. So with
larger nInterpolation points a lot of time is spent in the algorithm, besides
evaluating the function. At some point I'll try to do some profiling of the
code.
3) It makes a big difference to normalize the parameters as the initial search
region is dependent on the point with the smallest boundary difference. So it
seems one shouldn't directly fit the "natural" parameters but normalized values.
> Errors in BOBYQAOptimizer when numberOfInterpolationPoints is greater than
> 2*dim+1
> --
>
> Key: MATH-728
> URL: https://issues.apache.org/jira/browse/MATH-728
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.0
> Environment: Mac Java(TM) SE Runtime Environment (build
> 1.6.0_29-b11-402-11M3527)
>Reporter: Bruce A Johnson
>
> I've been having trouble getting BOBYQA to minimize a function (actually a
> non-linear least squares fit) so as one change I increased the number of
> interpolation points. It seems that anything larger than 2*dim+1 causes an
> error (typically at
> line 1662
>interpolationPoints.setEntry(nfm, ipt,
> interpolationPoints.getEntry(ipt, ipt));
> I'm guessing there is an off by one error in the translation from FORTRAN.
> Changing the BOBYQAOptimizerTest as follows (increasing number of
> interpolation points by one) will cause failures.
> Bruce
> Index:
> src/test/java/org/apache/commons/math/optimization/direct/BOBYQAOptimizerTest.java
> ===
> ---
> src/test/java/org/apache/commons/math/optimization/direct/BOBYQAOptimizerTest.java
> (revision 1221065)
> +++
> src/test/java/org/apache/commons/math/optimization/direct/BOBYQAOptimizerTest.java
> (working copy)
> @@ -258,7 +258,7 @@
> //RealPointValuePair result = optim.optimize(10, func, goal,
> startPoint);
> final double[] lB = boundaries == null ? null : boundaries[0];
> final double[] uB = boundaries == null ? null : boundaries[1];
> -BOBYQAOptimizer optim = new BOBYQAOptimizer(2 * dim + 1);
> +BOBYQAOptimizer optim = new BOBYQAOptimizer(2 * dim + 2);
> RealPointValuePair result = optim.optimize(maxEvaluations, func,
> goal, startPoint, lB, uB);
> //System.out.println(func.getClass().getName() + " = "
> // + optim.getEvaluations() + " f(");
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-88) Make AsyncQueryRunner be a decorator around a QueryRunner
[ https://issues.apache.org/jira/browse/DBUTILS-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13206255#comment-13206255 ] William R. Speirs commented on DBUTILS-88: -- Note: The DBUTILS-99v1.patch includes changes to the unit tests which all pass now. > Make AsyncQueryRunner be a decorator around a QueryRunner > - > > Key: DBUTILS-88 > URL: https://issues.apache.org/jira/browse/DBUTILS-88 > Project: Commons DbUtils > Issue Type: Task >Reporter: Moandji Ezana >Priority: Minor > Attachments: AsyncQueryRunner_wraps_QueryRunner.txt, > DBUTILS-88v1.patch > > > AsyncQueryRunner duplicates much of the code in QueryRunner. Would it be > possible for AsyncQueryRunner to simply decorate a QueryRunner with async > functionality, in the same way a BufferedInputStream might decorate an > InputStream? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DBUTILS-88) Make AsyncQueryRunner be a decorator around a QueryRunner
[ https://issues.apache.org/jira/browse/DBUTILS-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William R. Speirs updated DBUTILS-88: - Attachment: DBUTILS-88v1.patch I took this patch one step further and removed the private methods in AsyncQueryRunner as they're not really needed. This also allowed me to remove extending AbstractQueryRunner. However, this has API issues. Unfortunately, the inner classes in AsyncQueryRunner were marked as protected not private, so removing them changes the API. The same is true with removing extending AbstractQueryRunner. For 1.5 we can always leave these classes and simply mark them as @Deprecated and then finally remove the extension of AbstractQueryRunner in v2.0. Thoughts? > Make AsyncQueryRunner be a decorator around a QueryRunner > - > > Key: DBUTILS-88 > URL: https://issues.apache.org/jira/browse/DBUTILS-88 > Project: Commons DbUtils > Issue Type: Task >Reporter: Moandji Ezana >Priority: Minor > Attachments: AsyncQueryRunner_wraps_QueryRunner.txt, > DBUTILS-88v1.patch > > > AsyncQueryRunner duplicates much of the code in QueryRunner. Would it be > possible for AsyncQueryRunner to simply decorate a QueryRunner with async > functionality, in the same way a BufferedInputStream might decorate an > InputStream? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (DBUTILS-88) Make AsyncQueryRunner be a decorator around a QueryRunner
[ https://issues.apache.org/jira/browse/DBUTILS-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13206255#comment-13206255 ] William R. Speirs edited comment on DBUTILS-88 at 2/11/12 8:34 PM: --- Note: The DBUTILS-88v1.patch includes changes to the unit tests which all pass now. was (Author: wspeirs): Note: The DBUTILS-99v1.patch includes changes to the unit tests which all pass now. > Make AsyncQueryRunner be a decorator around a QueryRunner > - > > Key: DBUTILS-88 > URL: https://issues.apache.org/jira/browse/DBUTILS-88 > Project: Commons DbUtils > Issue Type: Task >Reporter: Moandji Ezana >Priority: Minor > Attachments: AsyncQueryRunner_wraps_QueryRunner.txt, > DBUTILS-88v1.patch > > > AsyncQueryRunner duplicates much of the code in QueryRunner. Would it be > possible for AsyncQueryRunner to simply decorate a QueryRunner with async > functionality, in the same way a BufferedInputStream might decorate an > InputStream? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-650) FastMath has static code which slows the first access to FastMath
[ https://issues.apache.org/jira/browse/MATH-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13206208#comment-13206208 ] Gilles commented on MATH-650: - All right, it's not a issue of loading more bytes. If I'm not mistaken, Ted indicated that the bytecode for constructing an array from a list of elements was inefficient; I don't recall exactly why and I know nothing about bytecode... :( > FastMath has static code which slows the first access to FastMath > - > > Key: MATH-650 > URL: https://issues.apache.org/jira/browse/MATH-650 > Project: Commons Math > Issue Type: Improvement >Affects Versions: Nightly Builds > Environment: Android 2.3 (Dalvik VM with JIT) >Reporter: Alexis Robert >Priority: Minor > Fix For: 3.0 > > Attachments: FastMathLoadCheck.java, LucTestPerformance.java > > > Working on an Android application using Orekit, I've discovered that a simple > FastMath.floor() takes about 4 to 5 secs on a 1GHz Nexus One phone (only the > first time it's called). I've launched the Android profiling tool (traceview) > and the problem seems to be linked with the static portion of FastMath code > named "// Initialize tables" > The timing resulted in : > - FastMath.slowexp (40.8%) > - FastMath.expint (39.2%) > \- FastMath.quadmult() (95.6% of expint) > - FastMath.slowlog (18.2%) > Hoping that would help > Thanks! > Alexis Robert -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-743) Use enums in package transform
[
https://issues.apache.org/jira/browse/MATH-743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13206197#comment-13206197
]
Sébastien Brisard commented on MATH-743:
In {{r1243110}}, introduced {{TransformType}} in {{RealTransformer}}.
> Use enums in package transform
> --
>
> Key: MATH-743
> URL: https://issues.apache.org/jira/browse/MATH-743
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Sébastien Brisard
>Assignee: Sébastien Brisard
> Labels: api-change, enum, transform
>
> As discussed on the mailing-list, enums could be used in the package
> {{transform}}
> # An enumeration {{FORWARD, INVERSE}} will be created to specify whether the
> inverse transform is to be computed. This will replace the pair
> {{transform}}/{{inverseTransform}}
> # An enumeration {{STANDARD, ORTHOGONAL}} will be introduced (where relevant)
> in each transform class, in order to specify the normalization that should be
> used. Then the factory methods {{create()}}/{{createOrthogonal()}} will be
> replaced by a parameter passed to the constructor, which will be made public.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-650) FastMath has static code which slows the first access to FastMath
[ https://issues.apache.org/jira/browse/MATH-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13206195#comment-13206195 ] Sebb commented on MATH-650: --- bq. I would lean on the binary side, for "safety" reasons: unwanted modifications are less likely to occur. Now that the arrays are cloned, I don't see how modifications can occur at run time. Source modifications are of course easier. But if that's a concern, let's store all the code as resources! bq. reading a presumably longer table, and parsing a presumably larger number of octets for each double would result in a longer loading time Why should the literal case need parsing? The compiler already parsed the source when the class was compiled. I don't see why the literal case should use more octets either. I agree it would be nice to know the source of the "conventional wisdom" - maybe the assumptions it was based on no longer hold. > FastMath has static code which slows the first access to FastMath > - > > Key: MATH-650 > URL: https://issues.apache.org/jira/browse/MATH-650 > Project: Commons Math > Issue Type: Improvement >Affects Versions: Nightly Builds > Environment: Android 2.3 (Dalvik VM with JIT) >Reporter: Alexis Robert >Priority: Minor > Fix For: 3.0 > > Attachments: FastMathLoadCheck.java, LucTestPerformance.java > > > Working on an Android application using Orekit, I've discovered that a simple > FastMath.floor() takes about 4 to 5 secs on a 1GHz Nexus One phone (only the > first time it's called). I've launched the Android profiling tool (traceview) > and the problem seems to be linked with the static portion of FastMath code > named "// Initialize tables" > The timing resulted in : > - FastMath.slowexp (40.8%) > - FastMath.expint (39.2%) > \- FastMath.quadmult() (95.6% of expint) > - FastMath.slowlog (18.2%) > Hoping that would help > Thanks! > Alexis Robert -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-650) FastMath has static code which slows the first access to FastMath
[ https://issues.apache.org/jira/browse/MATH-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13206188#comment-13206188 ] Luc Maisonobe commented on MATH-650: I think the reason literal array are faster is that they is no real reading (no file to open, no loop, no read ...). Everything has already been prepared beforehand by the compiler and the loaded class is most probably already in a memory-mapped file. Remember that the array are literal and need to be parsed only by the compiler, not by the JVM at loading time. In fact in both cases what is loaded is binary. > FastMath has static code which slows the first access to FastMath > - > > Key: MATH-650 > URL: https://issues.apache.org/jira/browse/MATH-650 > Project: Commons Math > Issue Type: Improvement >Affects Versions: Nightly Builds > Environment: Android 2.3 (Dalvik VM with JIT) >Reporter: Alexis Robert >Priority: Minor > Fix For: 3.0 > > Attachments: FastMathLoadCheck.java, LucTestPerformance.java > > > Working on an Android application using Orekit, I've discovered that a simple > FastMath.floor() takes about 4 to 5 secs on a 1GHz Nexus One phone (only the > first time it's called). I've launched the Android profiling tool (traceview) > and the problem seems to be linked with the static portion of FastMath code > named "// Initialize tables" > The timing resulted in : > - FastMath.slowexp (40.8%) > - FastMath.expint (39.2%) > \- FastMath.quadmult() (95.6% of expint) > - FastMath.slowlog (18.2%) > Hoping that would help > Thanks! > Alexis Robert -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (MATH-650) FastMath has static code which slows the first access to FastMath
[ https://issues.apache.org/jira/browse/MATH-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13206188#comment-13206188 ] Luc Maisonobe edited comment on MATH-650 at 2/11/12 5:27 PM: - I think the reason literal array are faster is that there is no real reading (no file to open, no loop, no read ...). Everything has already been prepared beforehand by the compiler and the loaded class is most probably already in a memory-mapped file. Remember that the array are literal and need to be parsed only by the compiler, not by the JVM at loading time. In fact in both cases what is loaded is binary. was (Author: luc): I think the reason literal array are faster is that they is no real reading (no file to open, no loop, no read ...). Everything has already been prepared beforehand by the compiler and the loaded class is most probably already in a memory-mapped file. Remember that the array are literal and need to be parsed only by the compiler, not by the JVM at loading time. In fact in both cases what is loaded is binary. > FastMath has static code which slows the first access to FastMath > - > > Key: MATH-650 > URL: https://issues.apache.org/jira/browse/MATH-650 > Project: Commons Math > Issue Type: Improvement >Affects Versions: Nightly Builds > Environment: Android 2.3 (Dalvik VM with JIT) >Reporter: Alexis Robert >Priority: Minor > Fix For: 3.0 > > Attachments: FastMathLoadCheck.java, LucTestPerformance.java > > > Working on an Android application using Orekit, I've discovered that a simple > FastMath.floor() takes about 4 to 5 secs on a 1GHz Nexus One phone (only the > first time it's called). I've launched the Android profiling tool (traceview) > and the problem seems to be linked with the static portion of FastMath code > named "// Initialize tables" > The timing resulted in : > - FastMath.slowexp (40.8%) > - FastMath.expint (39.2%) > \- FastMath.quadmult() (95.6% of expint) > - FastMath.slowlog (18.2%) > Hoping that would help > Thanks! > Alexis Robert -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-650) FastMath has static code which slows the first access to FastMath
[
https://issues.apache.org/jira/browse/MATH-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13206181#comment-13206181
]
Gilles commented on MATH-650:
-
{quote}
I'm surprised though that binary files take longer to load than litteral. I
should have thought that reading a presumably longer table, and parsing a
presumably larger number of octets for each double would result in a longer
loading time. I must have missed something.
{quote}
Thank you for asking! ;)
I also raised this puzzling point on the ML, after having implemented the
resource loading approach following a suggestion by Ted Dunning, who also had
hinted that it would be faster.
Nobody came up with an explanation about why the implementation is indeed
slower. I'd have said that
* either there is a bug in my implementation (in the sense that is not done
correctly to get the best performance from this approach) and it would nice and
useful to find what is wrong there,
* or the loading of big literal arrays is faster and it would be interesting to
know why, in order to rectify the conventional wisdom that had us believe
otherwise.
> FastMath has static code which slows the first access to FastMath
> -
>
> Key: MATH-650
> URL: https://issues.apache.org/jira/browse/MATH-650
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: Nightly Builds
> Environment: Android 2.3 (Dalvik VM with JIT)
>Reporter: Alexis Robert
>Priority: Minor
> Fix For: 3.0
>
> Attachments: FastMathLoadCheck.java, LucTestPerformance.java
>
>
> Working on an Android application using Orekit, I've discovered that a simple
> FastMath.floor() takes about 4 to 5 secs on a 1GHz Nexus One phone (only the
> first time it's called). I've launched the Android profiling tool (traceview)
> and the problem seems to be linked with the static portion of FastMath code
> named "// Initialize tables"
> The timing resulted in :
> - FastMath.slowexp (40.8%)
> - FastMath.expint (39.2%)
> \- FastMath.quadmult() (95.6% of expint)
> - FastMath.slowlog (18.2%)
> Hoping that would help
> Thanks!
> Alexis Robert
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JEXL-127) Allow the creation of functions
[
https://issues.apache.org/jira/browse/JEXL-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13206176#comment-13206176
]
Henri Biestro commented on JEXL-127:
Moved Frame to Scope.Frame;
Refined exception handling;
Checkstyle
src/main/java/org/apache/commons/jexl3/JexlException.java
src/main/java/org/apache/commons/jexl3/internal/Engine.java
src/main/java/org/apache/commons/jexl3/internal/Frame.java
src/main/java/org/apache/commons/jexl3/internal/Interpreter.java
src/main/java/org/apache/commons/jexl3/internal/Scope.java
src/main/java/org/apache/commons/jexl3/internal/Script.java
src/main/java/org/apache/commons/jexl3/internal/TemplateEngine.java
src/main/java/org/apache/commons/jexl3/internal/introspection/Uberspect.java
src/main/java/org/apache/commons/jexl3/parser/ASTJexlLambda.java
src/main/java/org/apache/commons/jexl3/parser/ASTJexlScript.java
src/main/java/org/apache/commons/jexl3/parser/JexlParser.java
src/main/java/org/apache/commons/jexl3/parser/Parser.jjt
src/test/java/org/apache/commons/jexl3/ArithmeticTest.java
src/test/java/org/apache/commons/jexl3/IssuesTest.java
Committed revision 1243101.
> Allow the creation of functions
> ---
>
> Key: JEXL-127
> URL: https://issues.apache.org/jira/browse/JEXL-127
> Project: Commons JEXL
> Issue Type: Improvement
>Reporter: Henri Biestro
>Assignee: Henri Biestro
> Fix For: 3.0
>
>
> As script get richer, being able to create functions is a strong need.
> This only requires adding a new keyword ('function') and the syntax would be:
> var fn = function(x, y, z) {...}.
> It would be nice to allow those to behave as closures (thru local variable
> hoistering).
> This will bring JEXL closer to ECMAScript in functionality.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DBUTILS-88) Make AsyncQueryRunner be a decorator around a QueryRunner
[ https://issues.apache.org/jira/browse/DBUTILS-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Moandji Ezana updated DBUTILS-88: - Attachment: AsyncQueryRunner_wraps_QueryRunner.txt AsyncQueryRunner_wraps_QueryRunner.txt is a patch that demonstrates my idea. It does not update the tests, which currently fail. > Make AsyncQueryRunner be a decorator around a QueryRunner > - > > Key: DBUTILS-88 > URL: https://issues.apache.org/jira/browse/DBUTILS-88 > Project: Commons DbUtils > Issue Type: Task >Reporter: Moandji Ezana >Priority: Minor > Attachments: AsyncQueryRunner_wraps_QueryRunner.txt > > > AsyncQueryRunner duplicates much of the code in QueryRunner. Would it be > possible for AsyncQueryRunner to simply decorate a QueryRunner with async > functionality, in the same way a BufferedInputStream might decorate an > InputStream? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DBUTILS-88) Make AsyncQueryRunner be a decorator around a QueryRunner
Make AsyncQueryRunner be a decorator around a QueryRunner - Key: DBUTILS-88 URL: https://issues.apache.org/jira/browse/DBUTILS-88 Project: Commons DbUtils Issue Type: Task Reporter: Moandji Ezana Priority: Minor AsyncQueryRunner duplicates much of the code in QueryRunner. Would it be possible for AsyncQueryRunner to simply decorate a QueryRunner with async functionality, in the same way a BufferedInputStream might decorate an InputStream? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-650) FastMath has static code which slows the first access to FastMath
[ https://issues.apache.org/jira/browse/MATH-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13206119#comment-13206119 ] Sébastien Brisard commented on MATH-650: Hi Luc, thanks for taking care of this difficult issue. I would lean on the binary side, for "safety" reasons: unwanted modifications are less likely to occur. But I do realize that this can be endlessly debated over, and to be really honnest, I would be very happy with either solution (or even the runtime computation: as far as I am concerned, the typical timing of my computations is about 1 hour to one week... plenty of seconds...). If we opt for the binary option, maybe we could provide a binary-to-ascii method, for anyone to check the data (maybe that's already available). I'm surprised though that binary files take longer to load than litteral. I should have thought that reading a presumably longer table, and parsing a presumably larger number of octets for each double would result in a longer loading time. I must have missed something. > FastMath has static code which slows the first access to FastMath > - > > Key: MATH-650 > URL: https://issues.apache.org/jira/browse/MATH-650 > Project: Commons Math > Issue Type: Improvement >Affects Versions: Nightly Builds > Environment: Android 2.3 (Dalvik VM with JIT) >Reporter: Alexis Robert >Priority: Minor > Fix For: 3.0 > > Attachments: FastMathLoadCheck.java, LucTestPerformance.java > > > Working on an Android application using Orekit, I've discovered that a simple > FastMath.floor() takes about 4 to 5 secs on a 1GHz Nexus One phone (only the > first time it's called). I've launched the Android profiling tool (traceview) > and the problem seems to be linked with the static portion of FastMath code > named "// Initialize tables" > The timing resulted in : > - FastMath.slowexp (40.8%) > - FastMath.expint (39.2%) > \- FastMath.quadmult() (95.6% of expint) > - FastMath.slowlog (18.2%) > Hoping that would help > Thanks! > Alexis Robert -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (MATH-650) FastMath has static code which slows the first access to FastMath
[ https://issues.apache.org/jira/browse/MATH-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13206095#comment-13206095 ] Luc Maisonobe edited comment on MATH-650 at 2/11/12 12:44 PM: -- I would like to resolve this issue. I think everybody agreed pre-computation was an improvement, and the remaining discussions are about the way the pre-computed tables are loaded. We have two competing implementations for that: resources loaded from a binary file and literal arrays compiled in the library. In both cases, the data is generated beforehand by our own code, so in both case users who wants to re-generate them with different settings can do so. The advantages of resources are that they are more compact (binary) and don't clutter the sources with large tables. The advantages of literal arrays are that the can be checked by mere human beings and don't require any support code. The speed difference between the two implementation exists but is tiny. Two people have already expressed their preferences (one favoring resources the other one favoring literal arrays). I don't have a clear cut preference myself (only a slight bias toward one solution which I prefer to keep for myself). I would like to have the opinions of newer developers and users on this before selecting one approach. Could someone please provide another opinion ? was (Author: luc): I would like to resolve this issue. I think everybody agreed pre-computation was an improvement, and the remaining discussions are about the way the pre-computed tables are loaded. We have two competing implementations for that: resources loaded from a binary file and literal arrays compiled in the library. In both cases, the data is generated beforehand by our own code, so in both case users who wants to re-generate with different settings them can do so. The advantages of resources are that they are more compact (binary) and don't clutter the sources with large tables. The advantages of literal arrays are that the can be checked by mere human beings and don't require any support code. The speed difference between the two implementation exists but is tiny. Two people have already expressed their preferences (one favoring resources the other one favoring literal arrays). I don't have a clear cut preference myself (only a slight bias toward one solution which I prefer to keep for myself). I would like to have the opinions of newer developers and users on this before selecting one approach. Could someone please provide another opinion ? > FastMath has static code which slows the first access to FastMath > - > > Key: MATH-650 > URL: https://issues.apache.org/jira/browse/MATH-650 > Project: Commons Math > Issue Type: Improvement >Affects Versions: Nightly Builds > Environment: Android 2.3 (Dalvik VM with JIT) >Reporter: Alexis Robert >Priority: Minor > Fix For: 3.0 > > Attachments: FastMathLoadCheck.java, LucTestPerformance.java > > > Working on an Android application using Orekit, I've discovered that a simple > FastMath.floor() takes about 4 to 5 secs on a 1GHz Nexus One phone (only the > first time it's called). I've launched the Android profiling tool (traceview) > and the problem seems to be linked with the static portion of FastMath code > named "// Initialize tables" > The timing resulted in : > - FastMath.slowexp (40.8%) > - FastMath.expint (39.2%) > \- FastMath.quadmult() (95.6% of expint) > - FastMath.slowlog (18.2%) > Hoping that would help > Thanks! > Alexis Robert -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-650) FastMath has static code which slows the first access to FastMath
[ https://issues.apache.org/jira/browse/MATH-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13206095#comment-13206095 ] Luc Maisonobe commented on MATH-650: I would like to resolve this issue. I think everybody agreed pre-computation was an improvement, and the remaining discussions are about the way the pre-computed tables are loaded. We have two competing implementations for that: resources loaded from a binary file and literal arrays compiled in the library. In both cases, the data is generated beforehand by our own code, so in both case users who wants to re-generate with different settings them can do so. The advantages of resources are that they are more compact (binary) and don't clutter the sources with large tables. The advantages of literal arrays are that the can be checked by mere human beings and don't require any support code. The speed difference between the two implementation exists but is tiny. Two people have already expressed their preferences (one favoring resources the other one favoring literal arrays). I don't have a clear cut preference myself (only a slight bias toward one solution which I prefer to keep for myself). I would like to have the opinions of newer developers and users on this before selecting one approach. Could someone please provide another opinion ? > FastMath has static code which slows the first access to FastMath > - > > Key: MATH-650 > URL: https://issues.apache.org/jira/browse/MATH-650 > Project: Commons Math > Issue Type: Improvement >Affects Versions: Nightly Builds > Environment: Android 2.3 (Dalvik VM with JIT) >Reporter: Alexis Robert >Priority: Minor > Fix For: 3.0 > > Attachments: FastMathLoadCheck.java, LucTestPerformance.java > > > Working on an Android application using Orekit, I've discovered that a simple > FastMath.floor() takes about 4 to 5 secs on a 1GHz Nexus One phone (only the > first time it's called). I've launched the Android profiling tool (traceview) > and the problem seems to be linked with the static portion of FastMath code > named "// Initialize tables" > The timing resulted in : > - FastMath.slowexp (40.8%) > - FastMath.expint (39.2%) > \- FastMath.quadmult() (95.6% of expint) > - FastMath.slowlog (18.2%) > Hoping that would help > Thanks! > Alexis Robert -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-788) SerializationUtils throws ClassNotFoundException when cloning primitive classes
[
https://issues.apache.org/jira/browse/LANG-788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
René Link updated LANG-788:
---
Description:
If a serializable object contains a reference to a primitive class, e.g.
int.class or int[].class, the SerializationUtils throw a ClassNotFoundException
when trying to clone that object.
{noformat}
import org.apache.commons.lang3.SerializationUtils;
import org.junit.Test;
public class SerializationUtilsTest {
@Test
public void primitiveTypeClassSerialization(){
Class primitiveType = int.class;
Class clone = SerializationUtils.clone(primitiveType);
assertEquals(primitiveType, clone);
}
}
{noformat}
The problem was already reported as a java bug
http://bugs.sun.com/view_bug.do?bug_id=4171142 and ObjectInputStream is fixed
since java version 1.4.
The SerializationUtils problem arises because the SerializationUtils internally
use the ClassLoaderAwareObjectInputStream that overrides the ObjectInputStream's
resoleClass method without delegating to the super method in case of a
ClassNotFoundException.
I understand the intention of the ClassLoaderAwareObjectInputStream, but this
implementation should also implement a fallback to the original implementation.
For example:
{noformat}
protected Class resolveClass(ObjectStreamClass desc) throws
IOException, ClassNotFoundException {
String name = desc.getName();
try {
return Class.forName(name, false, classLoader);
} catch (ClassNotFoundException ex) {
try {
return Class.forName(name, false,
Thread.currentThread().getContextClassLoader());
} catch (Exception e) {
return super.resolveClass(desc);
}
}
}
{noformat}
Here is the code in ObjectInputStream that fixed the java bug.
{noformat}
protected Class resolveClass(ObjectStreamClass desc)
throws IOException, ClassNotFoundException
{
String name = desc.getName();
try {
return Class.forName(name, false, latestUserDefinedLoader());
} catch (ClassNotFoundException ex) {
Class cl = (Class) primClasses.get(name);
if (cl != null) {
return cl;
} else {
throw ex;
}
}
}
{noformat}
was:
If a serializable object contains a reference to a primitive class, e.g.
int.class or int[].class, the SerializationUtils throw a ClassNotFoundException
when trying to clone that object.
{noformat}
import org.apache.commons.lang3.SerializationUtils;
import org.junit.Test;
public class SerializationUtilsTest {
@Test
public void primitiveTypeClassSerialization(){
Class primitiveType = int.class;
Class clone = SerializationUtils.clone(primitiveType);
assertEquals(primitiveType, clone);
}
}
{noformat}
The problem was already reported as a java bug
http://bugs.sun.com/view_bug.do?bug_id=4171142 and ObjectInputStream is fixed
since java version 1.4.
The SerializationUtils problem arises because the SerializationUtils internally
use the ClassLoaderAwareObjectInputStream that overrides the ObjectInputStream's
resoleClass method without delegating to the super method in case of a
ClassNotFoundException.
I understand the intention of the ClassLoaderAwareObjectInputStream, but this
implementation should also implement a fallback to the original implementation.
For example:
{noformat}
protected Class resolveClass(ObjectStreamClass desc) throws
IOException, ClassNotFoundException {
String name = desc.getName();
try {
return Class.forName(name, false, classLoader);
} catch (ClassNotFoundException ex) {
try {
return Class.forName(name, false,
Thread.currentThread().getContextClassLoader());
} catch (Exception e) {
return super.resolveClass(desc);
}
}
}
{noformat}
> SerializationUtils throws ClassNotFoundException when cloning primitive
> classes
> ---
>
> Key: LANG-788
> URL: https://issues.apache.org/jira/browse/LANG-788
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: René Link
>
> If a serializable object contains a reference to a primitive class, e.g.
> int.class or int[].class, the SerializationUtils throw a
> ClassNotFoundException when trying to clone that object.
> {noformat}
> import org.apache.commons.lang3.SerializationUtils;
> import org.junit.Test;
> public class Seriali
[jira] [Created] (LANG-788) SerializationUtils throws ClassNotFoundException when cloning of primitive classes
SerializationUtils throws ClassNotFoundException when cloning of primitive
classes
--
Key: LANG-788
URL: https://issues.apache.org/jira/browse/LANG-788
Project: Commons Lang
Issue Type: Bug
Affects Versions: 3.1
Reporter: René Link
If a serializable object contains a reference to a primitive class, e.g.
int.class or int[].class, the SerializationUtils throw a ClassNotFoundException
when trying to clone that object.
{noformat}
import org.apache.commons.lang3.SerializationUtils;
import org.junit.Test;
public class SerializationUtilsTest {
@Test
public void primitiveTypeClassSerialization(){
Class primitiveType = int.class;
Class clone = SerializationUtils.clone(primitiveType);
assertEquals(primitiveType, clone);
}
}
{noformat}
The problem was already reported as a java bug
http://bugs.sun.com/view_bug.do?bug_id=4171142 and ObjectInputStream is fixed
since java version 1.4.
The SerializationUtils problem arises because the SerializationUtils internally
use the ClassLoaderAwareObjectInputStream that overrides the ObjectInputStream's
resoleClass method without delegating to the super method in case of a
ClassNotFoundException.
I understand the intention of the ClassLoaderAwareObjectInputStream, but this
implementation should also implement a fallback to the original implementation.
For example:
{noformat}
protected Class resolveClass(ObjectStreamClass desc) throws
IOException, ClassNotFoundException {
String name = desc.getName();
try {
return Class.forName(name, false, classLoader);
} catch (ClassNotFoundException ex) {
try {
return Class.forName(name, false,
Thread.currentThread().getContextClassLoader());
} catch (Exception e) {
return super.resolveClass(desc);
}
}
}
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-788) SerializationUtils throws ClassNotFoundException when cloning primitive classes
[
https://issues.apache.org/jira/browse/LANG-788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
René Link updated LANG-788:
---
Summary: SerializationUtils throws ClassNotFoundException when cloning
primitive classes (was: SerializationUtils throws ClassNotFoundException when
cloning of primitive classes)
> SerializationUtils throws ClassNotFoundException when cloning primitive
> classes
> ---
>
> Key: LANG-788
> URL: https://issues.apache.org/jira/browse/LANG-788
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: René Link
>
> If a serializable object contains a reference to a primitive class, e.g.
> int.class or int[].class, the SerializationUtils throw a
> ClassNotFoundException when trying to clone that object.
> {noformat}
> import org.apache.commons.lang3.SerializationUtils;
> import org.junit.Test;
> public class SerializationUtilsTest {
>
> @Test
> public void primitiveTypeClassSerialization(){
> Class primitiveType = int.class;
>
> Class clone = SerializationUtils.clone(primitiveType);
> assertEquals(primitiveType, clone);
> }
> }
> {noformat}
> The problem was already reported as a java bug
> http://bugs.sun.com/view_bug.do?bug_id=4171142 and ObjectInputStream is fixed
> since java version 1.4.
> The SerializationUtils problem arises because the SerializationUtils
> internally use the ClassLoaderAwareObjectInputStream that overrides the
> ObjectInputStream's
> resoleClass method without delegating to the super method in case of a
> ClassNotFoundException.
> I understand the intention of the ClassLoaderAwareObjectInputStream, but this
> implementation should also implement a fallback to the original
> implementation.
> For example:
> {noformat}
> protected Class resolveClass(ObjectStreamClass desc) throws
> IOException, ClassNotFoundException {
> String name = desc.getName();
> try {
> return Class.forName(name, false, classLoader);
> } catch (ClassNotFoundException ex) {
> try {
>return Class.forName(name, false,
> Thread.currentThread().getContextClassLoader());
> } catch (Exception e) {
>return super.resolveClass(desc);
> }
> }
> }
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (JEXL-126) Decimal numbers literals should be 'double' by default (instead of 'float')
[ https://issues.apache.org/jira/browse/JEXL-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro resolved JEXL-126. Resolution: Fixed Assignee: Henri Biestro Updated ASTNumberLiteral > Decimal numbers literals should be 'double' by default (instead of 'float') > --- > > Key: JEXL-126 > URL: https://issues.apache.org/jira/browse/JEXL-126 > Project: Commons JEXL > Issue Type: Improvement >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Minor > Fix For: 3.0 > > > Since Jexl 1.x, decimal number literals are 'float'; it would be more natural > (pun unintended) to create 'double' instead since they are used more often > (reduce 'surprise' effects). > Note that since 2.1, numbers literals notations allow typing; '123f' is a > float literal. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (JEXL-127) Allow the creation of functions
[
https://issues.apache.org/jira/browse/JEXL-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-127.
Resolution: Fixed
Assignee: Henri Biestro
Added support for 'function', includes variable hoisting"
pom.xmlsrc/main/java/org/apache/commons/jexl3/JexlException.java
src/main/java/org/apache/commons/jexl3/internal/Debugger.java
src/main/java/org/apache/commons/jexl3/internal/Engine.java
src/main/java/org/apache/commons/jexl3/internal/Frame.java
src/main/java/org/apache/commons/jexl3/internal/Interpreter.java
src/main/java/org/apache/commons/jexl3/internal/Scope.java
src/main/java/org/apache/commons/jexl3/internal/Script.java
src/main/java/org/apache/commons/jexl3/internal/TemplateEngine.java
src/main/java/org/apache/commons/jexl3/parser/ASTJexlLambda.java
src/main/java/org/apache/commons/jexl3/parser/ASTJexlScript.java
src/main/java/org/apache/commons/jexl3/parser/JexlParser.java
src/main/java/org/apache/commons/jexl3/parser/Parser.jjt
src/test/java/org/apache/commons/jexl3/ArithmeticTest.java
src/test/java/org/apache/commons/jexl3/ArrayAccessTest.java
src/test/java/org/apache/commons/jexl3/ArrayLiteralTest.java
src/test/java/org/apache/commons/jexl3/AssignTest.java
src/test/java/org/apache/commons/jexl3/IssuesTest.java
src/test/java/org/apache/commons/jexl3/JexlTest.java
src/test/java/org/apache/commons/jexl3/LambdaTest.java
src/test/java/org/apache/commons/jexl3/PropertyAccessTest.jav
src/test/java/org/apache/commons/jexl3/parser/ParserTest.java
Committed revision 1243029.
> Allow the creation of functions
> ---
>
> Key: JEXL-127
> URL: https://issues.apache.org/jira/browse/JEXL-127
> Project: Commons JEXL
> Issue Type: Improvement
>Reporter: Henri Biestro
>Assignee: Henri Biestro
> Fix For: 3.0
>
>
> As script get richer, being able to create functions is a strong need.
> This only requires adding a new keyword ('function') and the syntax would be:
> var fn = function(x, y, z) {...}.
> It would be nice to allow those to behave as closures (thru local variable
> hoistering).
> This will bring JEXL closer to ECMAScript in functionality.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (JEXL-128) ObjectContext<> should implement NamespaceResolver
[ https://issues.apache.org/jira/browse/JEXL-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro resolved JEXL-128. Resolution: Fixed Assignee: Henri Biestro Updated ObjectContext > ObjectContext<> should implement NamespaceResolver > -- > > Key: JEXL-128 > URL: https://issues.apache.org/jira/browse/JEXL-128 > Project: Commons JEXL > Issue Type: Improvement >Reporter: Matteo Trotta >Assignee: Henri Biestro >Priority: Minor > Fix For: 3.0 > > > On Matteo's behalf from his comment in JEXL-125, ObjectContext should > implement NamespaceResolver so methods on the wrapped object can be > automatically solved. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (JEXL-129) Inner type attributes cannot be resolved in expressions
[
https://issues.apache.org/jira/browse/JEXL-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-129.
Resolution: Won't Fix
Fix Version/s: 2.1.1
Assignee: Henri Biestro
As Joerg described, private classes/fields are not accessible to reflection
thus can not be called through JEXL.
It would be too dangerous/insecure to call setAccessible and/or use a very
liberal security policy (ReflectPermission. suppressAccessChecks).
> Inner type attributes cannot be resolved in expressions
> ---
>
> Key: JEXL-129
> URL: https://issues.apache.org/jira/browse/JEXL-129
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 2.1.1
> Environment: JDK 6
>Reporter: Antonio Agudo
>Assignee: Henri Biestro
> Fix For: 2.1.1
>
>
> When using inner types e.g. for unit tests, it is impossible to resolve bean
> attributes from beans that are otherwise available in the JexlContext. I
> don't know about the implications for real world systems, but in testing this
> can be a pain.
> Junit Example:
> package test;
> import org.apache.commons.jexl2.Expression;
> import org.apache.commons.jexl2.JexlContext;
> import org.apache.commons.jexl2.JexlEngine;
> import org.apache.commons.jexl2.MapContext;
> import org.junit.Test;
> import static junit.framework.Assert.assertEquals;
> public class TestJEXL {
> @Test
> public void test() {
> JexlEngine jexl = new JexlEngine();
> Expression exp = jexl.createExpression("b.i + b.i");
> FakeBean b = new FakeBean();
> JexlContext jc = new MapContext();
> jc.set("b", b);
> Object results = exp.evaluate(jc);
> System.out.println(results);
> assertEquals(20,results);
> }
> private static class FakeBean {
> private int i = 10;
> private String key = "myval";
> public int getI() {
> return i;
> }
> public void setI(int i) {
> this.i = i;
> }
> public String getKey() {
> return key;
> }
> public void setKey(String key) {
> this.key = key;
> }
> }
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
