[jira] [Work logged] (IMAGING-228) Remove private method PhotometricInterpreterLogLuv#cube by Math.pow
[ https://issues.apache.org/jira/browse/IMAGING-228?focusedWorklogId=253565&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-253565 ] ASF GitHub Bot logged work on IMAGING-228: -- Author: ASF GitHub Bot Created on: 04/Jun/19 06:25 Start Date: 04/Jun/19 06:25 Worklog Time Spent: 10m Work Description: kinow commented on issue #44: [IMAGING-228] Drop cube method and add unit tests for PhotometricInterpretationLogLuv URL: https://github.com/apache/commons-imaging/pull/44#issuecomment-498538508 Addressed feedback on using double instead of integer on `Math.pow`. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 253565) Time Spent: 20m (was: 10m) > Remove private method PhotometricInterpreterLogLuv#cube by Math.pow > --- > > Key: IMAGING-228 > URL: https://issues.apache.org/jira/browse/IMAGING-228 > Project: Commons Imaging > Issue Type: Improvement >Reporter: Bruno P. Kinoshita >Assignee: Bruno P. Kinoshita >Priority: Minor > Fix For: 1.0-alpha2 > > Time Spent: 20m > Remaining Estimate: 0h > > We have a private method in PhotometricInterpreterLogLuv, that calculates the > cube of a number N doing N * N * N. That can be replaced by Math.pow(N, 3). > Will add unit tests and some javadocs around photometric interpreters, > logluv, cei, lab, color spaces, ceixyz-ceilab, etc, as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-imaging] kinow commented on issue #44: [IMAGING-228] Drop cube method and add unit tests for PhotometricInterpretationLogLuv
kinow commented on issue #44: [IMAGING-228] Drop cube method and add unit tests for PhotometricInterpretationLogLuv URL: https://github.com/apache/commons-imaging/pull/44#issuecomment-498538508 Addressed feedback on using double instead of integer on `Math.pow`. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (IMAGING-228) Remove private method PhotometricInterpreterLogLuv#cube by Math.pow
[ https://issues.apache.org/jira/browse/IMAGING-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16855360#comment-16855360 ] Bruno P. Kinoshita commented on IMAGING-228: >I just wanted to point out that the Math method takes 2 {{double}} as >arguments. Oh, good spot! And good to know about the current status of FastMath. Will bring performance improvements up in the mailing list after 1.0 is out - and I have had the chance to use it more to get a good idea of how well it performs. Thanks Gilles! > Remove private method PhotometricInterpreterLogLuv#cube by Math.pow > --- > > Key: IMAGING-228 > URL: https://issues.apache.org/jira/browse/IMAGING-228 > Project: Commons Imaging > Issue Type: Improvement >Reporter: Bruno P. Kinoshita >Assignee: Bruno P. Kinoshita >Priority: Minor > Fix For: 1.0-alpha2 > > Time Spent: 10m > Remaining Estimate: 0h > > We have a private method in PhotometricInterpreterLogLuv, that calculates the > cube of a number N doing N * N * N. That can be replaced by Math.pow(N, 3). > Will add unit tests and some javadocs around photometric interpreters, > logluv, cei, lab, color spaces, ceixyz-ceilab, etc, as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-daemon] wzssyqa opened a new pull request #10: apsupport.m4: improve mips detect
wzssyqa opened a new pull request #10: apsupport.m4: improve mips detect URL: https://github.com/apache/commons-daemon/pull/10 For mips, we add some new CPU types: mipsisa64r6{,el}, mipsisa32r6{,el}. To add support of them and don't make the list too long, we detect mips*el and then mips*. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[ https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16855285#comment-16855285 ] Matt Juntunen commented on GEOMETRY-32: --- Update: Still working on this. I'm currently almost done with the Euclidean 2D classes. I've created the new types {{LineSegment}}, {{LineSegmentPath}}, {{LineSegmentConnector}} (and subclasses), {{SubLine}}, and {{RegionBSPTree2D}}. I'm currently working on finishing up the geometric property calculations for {{RegionBSPTree2D}} and handling several edge cases. I still have yet to do the Euclidean 3D classes as well as Spherical 1D and 2D before I can remove the old BSP tree classes. If someone wants to follow the pattern I've done for Euclidean 1D and 2D and apply it to the spherical packages, that would be a big help. > BSPTree Updates > --- > > Key: GEOMETRY-32 > URL: https://issues.apache.org/jira/browse/GEOMETRY-32 > Project: Apache Commons Geometry > Issue Type: Improvement > Components: core >Reporter: Matt Juntunen >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > The following updates should be made to the BSPTree class: > - add an {{isLeaf()}} method to replace all of the {{node.getCut() == null}} > expressions > - add unit tests > _Edit [2019-02-17]:_ > Additional goals: > - Refactor the API to split the idea of a general BSPTree and a BSPTree used > for defining in/out regions. This could result in a BSPTree interface and a > RegionBSPTree interface. The goal here is to allow end-users to create their > own extensions of these classes and specialize them for their own > applications (for example, to implement spatial sorting or other algorithms). > This will be one of the only planned extension points in the library. > - Make the API easier to use and extend and reduce the necessity of casting > (especially unchecked casting) as much as possible. > - Add the idea of convex subhyperplanes to allow for more efficient tree > construction. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (NUMBERS-104) Speed up trial division
[ https://issues.apache.org/jira/browse/NUMBERS-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16855187#comment-16855187 ] Heinrich Bohne edited comment on NUMBERS-104 at 6/4/19 2:06 AM: OK, done. The last {{if (n != 1)}} condition is still not fully covered, but this is because {{n != 1}} will only evaluate to false here if, all other conditions the method's contract imposes being fulfilled, the method is called with an unnecessarily high value for the parameter {{maxFactor}}, or, more specifically, if the parameter {{maxFactor}} is greater than or equal to the parameter {{n}}, which is an indication of a design flaw of the method itself rather than the unit tests, and this design flaw is outside the scope of this ticket. was (Author: schamschi): OK, done. The last {{if (n != 1)}} condition is still not fully covered, but this is because {{n != 1}} will only evaluate to false here if, all other conditions the method's contract imposes being fulfilled, the method is called with an unnecessarily high value for the parameter {{maxFactor}}, or, more specifically, if the parameters {{maxFactor}} and {{n}} are identical, which is an indication of a design flaw of the method itself rather than the unit tests, and this design flaw is outside the scope of this ticket. > Speed up trial division > --- > > Key: NUMBERS-104 > URL: https://issues.apache.org/jira/browse/NUMBERS-104 > Project: Commons Numbers > Issue Type: Improvement > Components: primes >Reporter: Heinrich Bohne >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > Currently, the method {{SmallPrimes.boundedTrialDivision(int, int, > List)}} skips multiples of 2 and 3, thereby reducing the amount of > integers to be tried to 1/3 of all integers. This can be improved at the cost > of extra memory by extending the set of prime factors to be skipped in the > trial division, for example, to 2, 3, 5, 7, and 11. > However, instead of code duplication, which is the way the code currently > achieves this, a way to implement this could be: > * First, precompute and store all integers between 0 (inclusive) and > 2⋅3⋅5⋅7⋅11=2310 (exclusive) that are not divisible by any of those 5 prime > numbers (480 numbers in total, according to my experiments). > * Then, when performing the trial division, one only needs to try out numbers > of the form 2310⋅k + c, where k is a non-negative integer and c is one of the > 480 numbers described in the previous step. > That way, the amount of integers to be tried will be 480/2310 ≈ 20.78%, > instead of 1/3 ≈ 33.33%, which is a speedup of about 60.42% compared to the > current algorithm. Of course, with more prime factors eliminated, less > numbers will have to be tried, but it seems that the returns are quickly > diminishing compared to the required memory. For example, when also > eliminating the prime factors 13, 17 and 19, the memory required increases to > 1658880 integers, whereas the percentage of integers to be tried only drops > to about 17.10%. > Since the class {{SmallPrimes}} already stores an array containing the first > 512 prime numbers, a 480-element {{int}} array seems like a reasonable size > and a small price to pay for a 60.42% speedup. > I'm just not entirely sure whether this should go here or on the developer > mailing list. Since this is actually not a new idea, but just an enhancement > of an already existing idea, I'm putting it here, but on the other hand, it > requires some re-writing and some new code, so maybe I'm wrong. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (NUMBERS-112) Port "BrentSolver" from "Commons Math"
Gilles created NUMBERS-112: -- Summary: Port "BrentSolver" from "Commons Math" Key: NUMBERS-112 URL: https://issues.apache.org/jira/browse/NUMBERS-112 Project: Commons Numbers Issue Type: Task Reporter: Gilles Assignee: Gilles Fix For: 1.0 Efficient algorithm for finding the root of a function (it is used within "Commons Statistics"). See proposal on the ["dev" ML|https://markmail.org/message/44w75iq5vyfiwmle]. The relatively deep hierarchy of the "Commons Math" design will not be ported. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NUMBERS-104) Speed up trial division
[ https://issues.apache.org/jira/browse/NUMBERS-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16855187#comment-16855187 ] Heinrich Bohne commented on NUMBERS-104: OK, done. The last {{if (n != 1)}} condition is still not fully covered, but this is because {{n != 1}} will only evaluate to false here if, all other conditions the method's contract imposes being fulfilled, the method is called with an unnecessarily high value for the parameter {{maxFactor}}, or, more specifically, if the parameters {{maxFactor}} and {{n}} are identical, which is an indication of a design flaw of the method itself rather than the unit tests, and this design flaw is outside the scope of this ticket. > Speed up trial division > --- > > Key: NUMBERS-104 > URL: https://issues.apache.org/jira/browse/NUMBERS-104 > Project: Commons Numbers > Issue Type: Improvement > Components: primes >Reporter: Heinrich Bohne >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > Currently, the method {{SmallPrimes.boundedTrialDivision(int, int, > List)}} skips multiples of 2 and 3, thereby reducing the amount of > integers to be tried to 1/3 of all integers. This can be improved at the cost > of extra memory by extending the set of prime factors to be skipped in the > trial division, for example, to 2, 3, 5, 7, and 11. > However, instead of code duplication, which is the way the code currently > achieves this, a way to implement this could be: > * First, precompute and store all integers between 0 (inclusive) and > 2⋅3⋅5⋅7⋅11=2310 (exclusive) that are not divisible by any of those 5 prime > numbers (480 numbers in total, according to my experiments). > * Then, when performing the trial division, one only needs to try out numbers > of the form 2310⋅k + c, where k is a non-negative integer and c is one of the > 480 numbers described in the previous step. > That way, the amount of integers to be tried will be 480/2310 ≈ 20.78%, > instead of 1/3 ≈ 33.33%, which is a speedup of about 60.42% compared to the > current algorithm. Of course, with more prime factors eliminated, less > numbers will have to be tried, but it seems that the returns are quickly > diminishing compared to the required memory. For example, when also > eliminating the prime factors 13, 17 and 19, the memory required increases to > 1658880 integers, whereas the percentage of integers to be tried only drops > to about 17.10%. > Since the class {{SmallPrimes}} already stores an array containing the first > 512 prime numbers, a 480-element {{int}} array seems like a reasonable size > and a small price to pay for a 60.42% speedup. > I'm just not entirely sure whether this should go here or on the developer > mailing list. Since this is actually not a new idea, but just an enhancement > of an already existing idea, I'm putting it here, but on the other hand, it > requires some re-writing and some new code, so maybe I'm wrong. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (NUMBERS-104) Speed up trial division
[ https://issues.apache.org/jira/browse/NUMBERS-104?focusedWorklogId=253478&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-253478 ] ASF GitHub Bot logged work on NUMBERS-104: -- Author: ASF GitHub Bot Created on: 04/Jun/19 00:58 Start Date: 04/Jun/19 00:58 Worklog Time Spent: 10m Work Description: coveralls commented on issue #46: NUMBERS-104: Speed up trial division URL: https://github.com/apache/commons-numbers/pull/46#issuecomment-497873456 [![Coverage Status](https://coveralls.io/builds/23771969/badge)](https://coveralls.io/builds/23771969) Coverage increased (+0.2%) to 93.642% when pulling **7b15fad6c3eeece124f635b7a5c2fd72443f2017 on Schamschi:NUMBERS-104** into **daac9ac15f6161b32fa4c1374c2d6b563c90af87 on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 253478) Time Spent: 0.5h (was: 20m) > Speed up trial division > --- > > Key: NUMBERS-104 > URL: https://issues.apache.org/jira/browse/NUMBERS-104 > Project: Commons Numbers > Issue Type: Improvement > Components: primes >Reporter: Heinrich Bohne >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > Currently, the method {{SmallPrimes.boundedTrialDivision(int, int, > List)}} skips multiples of 2 and 3, thereby reducing the amount of > integers to be tried to 1/3 of all integers. This can be improved at the cost > of extra memory by extending the set of prime factors to be skipped in the > trial division, for example, to 2, 3, 5, 7, and 11. > However, instead of code duplication, which is the way the code currently > achieves this, a way to implement this could be: > * First, precompute and store all integers between 0 (inclusive) and > 2⋅3⋅5⋅7⋅11=2310 (exclusive) that are not divisible by any of those 5 prime > numbers (480 numbers in total, according to my experiments). > * Then, when performing the trial division, one only needs to try out numbers > of the form 2310⋅k + c, where k is a non-negative integer and c is one of the > 480 numbers described in the previous step. > That way, the amount of integers to be tried will be 480/2310 ≈ 20.78%, > instead of 1/3 ≈ 33.33%, which is a speedup of about 60.42% compared to the > current algorithm. Of course, with more prime factors eliminated, less > numbers will have to be tried, but it seems that the returns are quickly > diminishing compared to the required memory. For example, when also > eliminating the prime factors 13, 17 and 19, the memory required increases to > 1658880 integers, whereas the percentage of integers to be tried only drops > to about 17.10%. > Since the class {{SmallPrimes}} already stores an array containing the first > 512 prime numbers, a 480-element {{int}} array seems like a reasonable size > and a small price to pay for a 60.42% speedup. > I'm just not entirely sure whether this should go here or on the developer > mailing list. Since this is actually not a new idea, but just an enhancement > of an already existing idea, I'm putting it here, but on the other hand, it > requires some re-writing and some new code, so maybe I'm wrong. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-numbers] coveralls edited a comment on issue #46: NUMBERS-104: Speed up trial division
coveralls edited a comment on issue #46: NUMBERS-104: Speed up trial division URL: https://github.com/apache/commons-numbers/pull/46#issuecomment-497873456 [![Coverage Status](https://coveralls.io/builds/23771969/badge)](https://coveralls.io/builds/23771969) Coverage increased (+0.2%) to 93.642% when pulling **7b15fad6c3eeece124f635b7a5c2fd72443f2017 on Schamschi:NUMBERS-104** into **daac9ac15f6161b32fa4c1374c2d6b563c90af87 on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (IMAGING-228) Remove private method PhotometricInterpreterLogLuv#cube by Math.pow
[ https://issues.apache.org/jira/browse/IMAGING-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16855177#comment-16855177 ] Gilles commented on IMAGING-228: {quote}For maintainability - for now. {quote} I just wanted to point out that the Math method takes 2 {{double}} as arguments. IMO, it is easier to keep track of the specific needs with private methods like "cube" and "square". But I won't dispute more how you want to manage the improvement of that codebase. {quote}commons-math had some sort of optimized math methods {quote} Yes. Some of the methods in {{FastMath}} were faster than their counterpart in the JDK, but some were slower. There is an old JIRA about this. Also, several Java releases have happened since then, and I'd be surprised if the JVM hadn't caught up (this could be checked with JMH). The main advantage of {{FastMath}} was the improved accuracy (but, again, this advantage may have dwindled in more recent JVMs). Unless there is some follow-up on the findings reported in the JIRA issue, I wouldn't recommend coding against {{FastMath}} (it's the reason it is not part on the new math-related components). > Remove private method PhotometricInterpreterLogLuv#cube by Math.pow > --- > > Key: IMAGING-228 > URL: https://issues.apache.org/jira/browse/IMAGING-228 > Project: Commons Imaging > Issue Type: Improvement >Reporter: Bruno P. Kinoshita >Assignee: Bruno P. Kinoshita >Priority: Minor > Fix For: 1.0-alpha2 > > Time Spent: 10m > Remaining Estimate: 0h > > We have a private method in PhotometricInterpreterLogLuv, that calculates the > cube of a number N doing N * N * N. That can be replaced by Math.pow(N, 3). > Will add unit tests and some javadocs around photometric interpreters, > logluv, cei, lab, color spaces, ceixyz-ceilab, etc, as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IMAGING-228) Remove private method PhotometricInterpreterLogLuv#cube by Math.pow
[ https://issues.apache.org/jira/browse/IMAGING-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16855122#comment-16855122 ] Bruno P. Kinoshita edited comment on IMAGING-228 at 6/3/19 10:44 PM: - Hi [~erans] Glad I created a PR and this issue instead of committing directly, some review & feedback is always appreciated. >Why would you do that? For maintainability - for now. >Just saw the commit on GitHub: The original code is how I would have done it. >;) Intuitively, I'd bet that the call to {{Math.pow}} is slower... Agree, even if a few ms or ns, this is probably some performance users would appreciate, as parsing images is not always the fastest operation. But at the moment the old code base needs some polishing, and IMO it could do with simplification list this, even at cost of performance. This `#cube` method, for example, is not the only one in Imaging. There's another one in [ColorConversion|[https://github.com/apache/commons-imaging/blob/eb98398bd111cdc35b2c9a5fc8022a28d7c99035/src/main/java/org/apache/commons/imaging/color/ColorConversions.java#L536].] ColorConversion has also a `#square` method. And even though it has a `#cube` method, there is a `Math(var_Y, 3)` there too. We could create some sort of utility class to accommodate these methods. But I would prefer doing this later, in the whole project, and considering whether this should be maintained here or if there are libraries out there that could help us (e.g. I remember commons-math had some sort of optimized math methods, that could outperform the ones from JDK?). What do you think? was (Author: kinow): Hi [~erans] Glad I created a PR and this issue instead of committing directly, some review & feedback is always appreciated. >Why would you do that? For maintainability - for now. >Just saw the commit on GitHub: The original code is how I would have done it. >;) Intuitively, I'd bet that the call to {{Math.pow}} is slower... Agree, even if a few ms or ns, this is probably some performance users would appreciate, as parsing images is not always the fastest operation. But at the moment the old code base needs some polishing, and IMO it could do with simplification list this, even at cost of performance. This `#cube` method, for example, is not the only one in Imaging. There's another one in [ColorConversion|[https://github.com/apache/commons-imaging/blob/eb98398bd111cdc35b2c9a5fc8022a28d7c99035/src/main/java/org/apache/commons/imaging/color/ColorConversions.java#L536].] ColorConversion has also a `#square` method. We would either have to maintain both, or start creating some sort of utility class to accommodate these methods. And I would prefer doing this later, in the whole project, and considering whether this should be maintained here or if there are libraries out there that could help us (e.g. I remember commons-math had some sort of optimized math methods, that could outperform the ones from JDK?). So my plan is to use Math methods for now, then revisit performance later in another ticket, and try to do it right across the whole project. What do you think? > Remove private method PhotometricInterpreterLogLuv#cube by Math.pow > --- > > Key: IMAGING-228 > URL: https://issues.apache.org/jira/browse/IMAGING-228 > Project: Commons Imaging > Issue Type: Improvement >Reporter: Bruno P. Kinoshita >Assignee: Bruno P. Kinoshita >Priority: Minor > Fix For: 1.0-alpha2 > > Time Spent: 10m > Remaining Estimate: 0h > > We have a private method in PhotometricInterpreterLogLuv, that calculates the > cube of a number N doing N * N * N. That can be replaced by Math.pow(N, 3). > Will add unit tests and some javadocs around photometric interpreters, > logluv, cei, lab, color spaces, ceixyz-ceilab, etc, as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IMAGING-228) Remove private method PhotometricInterpreterLogLuv#cube by Math.pow
[ https://issues.apache.org/jira/browse/IMAGING-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16855122#comment-16855122 ] Bruno P. Kinoshita edited comment on IMAGING-228 at 6/3/19 10:43 PM: - Hi [~erans] Glad I created a PR and this issue instead of committing directly, some review & feedback is always appreciated. >Why would you do that? For maintainability - for now. >Just saw the commit on GitHub: The original code is how I would have done it. >;) Intuitively, I'd bet that the call to {{Math.pow}} is slower... Agree, even if a few ms or ns, this is probably some performance users would appreciate, as parsing images is not always the fastest operation. But at the moment the old code base needs some polishing, and IMO it could do with simplification list this, even at cost of performance. This `#cube` method, for example, is not the only one in Imaging. There's another one in [ColorConversion|[https://github.com/apache/commons-imaging/blob/eb98398bd111cdc35b2c9a5fc8022a28d7c99035/src/main/java/org/apache/commons/imaging/color/ColorConversions.java#L536].] ColorConversion has also a `#square` method. We would either have to maintain both, or start creating some sort of utility class to accommodate these methods. And I would prefer doing this later, in the whole project, and considering whether this should be maintained here or if there are libraries out there that could help us (e.g. I remember commons-math had some sort of optimized math methods, that could outperform the ones from JDK?). So my plan is to use Math methods for now, then revisit performance later in another ticket, and try to do it right across the whole project. What do you think? was (Author: kinow): Hi [~erans] Glad I created a PR and this issue instead of committing directly, some review & feedback is always appreciated. >Why would you do that? For maintainability - for now. >Just saw the commit on GitHub: The original code is how I would have done it. >;) Intuitively, I'd bet that the call to {{Math.pow}} is slower... Agree, even if a few ms or ns, this is probably some performance users would appreciate, as parsing images is not always the fastest operation. But at the moment the old code base needs some polishing, and IMO it could do with simplification list this, even at cost of performance. This `#cube` method, for example, is not the only one in Imaging. There's another one in [ColorConversion|[https://github.com/apache/commons-imaging/blob/eb98398bd111cdc35b2c9a5fc8022a28d7c99035/src/main/java/org/apache/commons/imaging/color/ColorConversions.java#L536].] ColorConversion has also a `#square` method. But if you look at ColorConversion, even though it has a `#cube` method, it also uses Math.pow(N, 3). We would either have to maintain both, or start creating some sort of utility class to accommodate these methods. And I would prefer doing this later, in the whole project, and considering whether this should be maintained here or if there are libraries out there that could help us (e.g. I remember commons-math had some sort of optimized math methods, that could outperform the ones from JDK?). So my plan is to use Math methods for now, then revisit performance later in another ticket, and try to do it right across the whole project. What do you think? > Remove private method PhotometricInterpreterLogLuv#cube by Math.pow > --- > > Key: IMAGING-228 > URL: https://issues.apache.org/jira/browse/IMAGING-228 > Project: Commons Imaging > Issue Type: Improvement >Reporter: Bruno P. Kinoshita >Assignee: Bruno P. Kinoshita >Priority: Minor > Fix For: 1.0-alpha2 > > Time Spent: 10m > Remaining Estimate: 0h > > We have a private method in PhotometricInterpreterLogLuv, that calculates the > cube of a number N doing N * N * N. That can be replaced by Math.pow(N, 3). > Will add unit tests and some javadocs around photometric interpreters, > logluv, cei, lab, color spaces, ceixyz-ceilab, etc, as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IMAGING-228) Remove private method PhotometricInterpreterLogLuv#cube by Math.pow
[ https://issues.apache.org/jira/browse/IMAGING-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16855122#comment-16855122 ] Bruno P. Kinoshita edited comment on IMAGING-228 at 6/3/19 10:42 PM: - Hi [~erans] Glad I created a PR and this issue instead of committing directly, some review & feedback is always appreciated. >Why would you do that? For maintainability - for now. >Just saw the commit on GitHub: The original code is how I would have done it. >;) Intuitively, I'd bet that the call to {{Math.pow}} is slower... Agree, even if a few ms or ns, this is probably some performance users would appreciate, as parsing images is not always the fastest operation. But at the moment the old code base needs some polishing, and IMO it could do with simplification list this, even at cost of performance. This `#cube` method, for example, is not the only one in Imaging. There's another one in [ColorConversion|[https://github.com/apache/commons-imaging/blob/eb98398bd111cdc35b2c9a5fc8022a28d7c99035/src/main/java/org/apache/commons/imaging/color/ColorConversions.java#L536].] ColorConversion has also a `#square` method. But if you look at ColorConversion, even though it has a `#cube` method, it also uses Math.pow(N, 3). We would either have to maintain both, or start creating some sort of utility class to accommodate these methods. And I would prefer doing this later, in the whole project, and considering whether this should be maintained here or if there are libraries out there that could help us (e.g. I remember commons-math had some sort of optimized math methods, that could outperform the ones from JDK?). So my plan is to use Math methods for now, then revisit performance later in another ticket, and try to do it right across the whole project. What do you think? was (Author: kinow): Hi [~erans] Glad I created a PR and this issue instead of committing directly, some review & feedback is always appreciated. >Why would you do that? For maintainability - for now. >Just saw the commit on GitHub: The original code is how I would have done it. >;) Intuitively, I'd bet that the call to {{Math.pow}} is slower... Agree, even if a few ms or ns, this is probably some performance users would appreciate, as parsing images is not always the fastest operation. But at the moment the old code base needs some polishing, and IMO it could do with simplification list this, even at cost of performance. This `#cube` method, for example, is not the only one in Imaging. There's another one in [ColorConversion|[https://github.com/apache/commons-imaging/blob/eb98398bd111cdc35b2c9a5fc8022a28d7c99035/src/main/java/org/apache/commons/imaging/color/ColorConversions.java#L536].] ColorConversion has also a `#square` method. But if you look at ColorConversion, even though it has a `#cube` method, it also uses Math.pow(N, 3). And even though it has `#cube` it also uses Math.sqrt. We would either have to maintain both, or start creating some sort of utility class to accommodate these methods. And I would prefer doing this later, in the whole project, and considering whether this should be maintained here or if there are libraries out there that could help us (e.g. I remember commons-math had some sort of optimized math methods, that could outperform the ones from JDK?). So my plan is to use Math methods for now, then revisit performance later in another ticket, and try to do it right across the whole project. What do you think? > Remove private method PhotometricInterpreterLogLuv#cube by Math.pow > --- > > Key: IMAGING-228 > URL: https://issues.apache.org/jira/browse/IMAGING-228 > Project: Commons Imaging > Issue Type: Improvement >Reporter: Bruno P. Kinoshita >Assignee: Bruno P. Kinoshita >Priority: Minor > Fix For: 1.0-alpha2 > > Time Spent: 10m > Remaining Estimate: 0h > > We have a private method in PhotometricInterpreterLogLuv, that calculates the > cube of a number N doing N * N * N. That can be replaced by Math.pow(N, 3). > Will add unit tests and some javadocs around photometric interpreters, > logluv, cei, lab, color spaces, ceixyz-ceilab, etc, as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IMAGING-228) Remove private method PhotometricInterpreterLogLuv#cube by Math.pow
[ https://issues.apache.org/jira/browse/IMAGING-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16855122#comment-16855122 ] Bruno P. Kinoshita commented on IMAGING-228: Hi [~erans] Glad I created a PR and this issue instead of committing directly, some review & feedback is always appreciated. >Why would you do that? For maintainability - for now. >Just saw the commit on GitHub: The original code is how I would have done it. >;) Intuitively, I'd bet that the call to {{Math.pow}} is slower... Agree, even if a few ms or ns, this is probably some performance users would appreciate, as parsing images is not always the fastest operation. But at the moment the old code base needs some polishing, and IMO it could do with simplification list this, even at cost of performance. This `#cube` method, for example, is not the only one in Imaging. There's another one in [ColorConversion|[https://github.com/apache/commons-imaging/blob/eb98398bd111cdc35b2c9a5fc8022a28d7c99035/src/main/java/org/apache/commons/imaging/color/ColorConversions.java#L536].] ColorConversion has also a `#square` method. But if you look at ColorConversion, even though it has a `#cube` method, it also uses Math.pow(N, 3). And even though it has `#cube` it also uses Math.sqrt. We would either have to maintain both, or start creating some sort of utility class to accommodate these methods. And I would prefer doing this later, in the whole project, and considering whether this should be maintained here or if there are libraries out there that could help us (e.g. I remember commons-math had some sort of optimized math methods, that could outperform the ones from JDK?). So my plan is to use Math methods for now, then revisit performance later in another ticket, and try to do it right across the whole project. What do you think? > Remove private method PhotometricInterpreterLogLuv#cube by Math.pow > --- > > Key: IMAGING-228 > URL: https://issues.apache.org/jira/browse/IMAGING-228 > Project: Commons Imaging > Issue Type: Improvement >Reporter: Bruno P. Kinoshita >Assignee: Bruno P. Kinoshita >Priority: Minor > Fix For: 1.0-alpha2 > > Time Spent: 10m > Remaining Estimate: 0h > > We have a private method in PhotometricInterpreterLogLuv, that calculates the > cube of a number N doing N * N * N. That can be replaced by Math.pow(N, 3). > Will add unit tests and some javadocs around photometric interpreters, > logluv, cei, lab, color spaces, ceixyz-ceilab, etc, as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (RNG-75) Improve the speed of the RandomSource create method.
[ https://issues.apache.org/jira/browse/RNG-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16855087#comment-16855087 ] Alex D Herbert commented on RNG-75: --- Here is the data comparing the construction through the factory with construction using the *new* keyword. *With a pre-build seed*: |RNG|createNativeSeed|new + NativeSeed|Relative|Seed size|Seed type| |SPLIT_MIX_64|10.555|2.725|3.874|1|long| |XO_RO_SHI_RO_64_SS|11.410|2.772|4.116|2|int| |XO_RO_SHI_RO_64_S|11.430|2.778|4.114|2|int| |XO_SHI_RO_128_SS|12.175|3.759|3.239|4|int| |XO_RO_SHI_RO_128_SS|12.216|3.939|3.101|2|long| |XO_RO_SHI_RO_128_PLUS|12.347|4.069|3.034|2|long| |XO_SHI_RO_128_PLUS|12.147|4.796|2.533|4|int| |XO_SHI_RO_256_PLUS|13.326|5.815|2.292|4|long| |XO_SHI_RO_256_SS|13.363|5.946|2.247|4|long| |KISS|23.082|9.233|2.500|4|int| |XO_SHI_RO_512_PLUS|18.215|10.172|1.791|8|long| |XO_SHI_RO_512_SS|18.595|10.731|1.733|8|long| |JDK|24.610|12.654|1.945|1|long| |WELL_512_A|26.347|13.353|1.973|16|int| |WELL_1024_A|34.587|20.974|1.649|32|int| |XOR_SHIFT_1024_S_PHI|36.171|21.823|1.657|16|long| |XOR_SHIFT_1024_S|36.644|21.901|1.673|16|long| |WELL_19937_A|335.859|310.806|1.081|624|int| |WELL_19937_C|332.835|313.929|1.060|624|int| |MWC_256|322.355|325.020|0.992|257|int| |WELL_44497_A|638.771|618.200|1.033|1391|int| |WELL_44497_B|645.603|629.002|1.026|1391|int| |ISAAC|1835.391|1838.906|0.998|256|int| |MT_64|5179.458|5160.515|1.004|312|long| |MT|8644.216|8729.320|0.990|624|int| |TWO_CMRES|149571.119|100527.616|1.488|1|int| The TWO_CMRES data is an anomaly. The time to build the RNG is very large. The time for the constructor invocation should not matter. This should be investigated as using *new* here is the biggest benefit in the table. However the units are ns so this is a difference of .5 milliseconds in practice. For the rest of the generators the cost of the factory method is progressively swamped by the rest of the work to make the generator as the seed gets larger. Using the *new* keyword is only relatively noticeable for very small seeds when the RNG has no extra work in the constructor. In practice this will not be noticed since it would require creating thousands of short lifetime generators with simple pre-built seeds. *With seed built using the SeedFactory*. I only include those with small seeds as I do not have data for seeds larger than 128: |RNG|createNullSeed|new + SeedFactory|Relative|Seed size|Seed type| |SPLIT_MIX_64|85.635|58.978|1.452|1|long| |XO_RO_SHI_RO_64_SS|81.631|64.035|1.275|2|int| |XO_RO_SHI_RO_64_S|85.723|64.042|1.339|2|int| |JDK|95.676|68.908|1.388|1|long| |XO_SHI_RO_128_SS|104.708|82.973|1.262|4|int| |XO_SHI_RO_128_PLUS|103.972|84.010|1.238|4|int| |XO_RO_SHI_RO_128_SS|117.396|85.957|1.366|2|long| |XO_RO_SHI_RO_128_PLUS|110.042|86.088|1.278|2|long| |KISS|112.247|88.447|1.269|4|int| |XO_SHI_RO_256_PLUS|150.657|109.504|1.376|4|long| |XO_SHI_RO_256_SS|141.544|115.450|1.226|4|long| |WELL_512_A|254.421|179.110|1.420|16|int| |XO_SHI_RO_512_PLUS|217.515|186.256|1.168|8|long| |XO_SHI_RO_512_SS|217.241|186.816|1.163|8|long| |XOR_SHIFT_1024_S_PHI|372.309|330.121|1.128|16|long| |XOR_SHIFT_1024_S|368.234|330.200|1.115|16|long| |WELL_1024_A|596.979|352.489|1.694|32|int| |TWO_CMRES|149183.341|100574.526|1.483|1|int| WELL_1024_A is an outlier. The rest of the generators all are built in comparable time to using the *new* keyword. Comparison of the tables show that generating the seed takes the majority of time for construction of a generator. For the normal use case of a long-lived generator then construction cost is not a factor on run-time. If a use case is for a generator that is very short lived (<100 deviates) and then discarded where speed is a priority then the recommendation is to create using the *new* keyword a small state generator and build the state using a fast thread-safe method to create a seed. A separate Jira ticket will discuss options for adding such a method to the SeedFactory. The fastest generator to create is the SplitMix. There is a Jira ticket to add a primitive constructor to this generator RNG-76 which shows that auto-boxing is a significant part of construction. The other generators with small state have array seeds or constructors with primitive arguments so auto-boxing is not a factor. Alternatively ThreadLocalRandom from JDK 1.7 would fit this use case ideally as it is designed for this purpose. It does not implement UniformRandomProvider so would have to be wrapped to be used with anything requiring that interface. > Improve the speed of the RandomSource create method. > > > Key: RNG-75 > URL: https://issues.apache.org/jira/browse/RNG-75 > Project: Commons RNG > Issue Type: Improvement > Components: simple >Affects Versions: 1.3 >Reporter: Alex D Herbert
[jira] [Commented] (CSV-240) Links for JavaDoc broken on web site
[ https://issues.apache.org/jira/browse/CSV-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16855046#comment-16855046 ] Gary Gregory commented on CSV-240: -- This will be fixed in the upcoming release; for a preview please see https://dist.apache.org/repos/dist/dev/commons/csv/1.7-RC1/site/index.html > Links for JavaDoc broken on web site > > > Key: CSV-240 > URL: https://issues.apache.org/jira/browse/CSV-240 > Project: Commons CSV > Issue Type: Bug > Components: Documentation >Affects Versions: 1.6 >Reporter: Basil >Priority: Minor > > The sidebar on the left of this page: > [https://commons.apache.org/proper/commons-csv/] > …has items for `Javadoc 1.6`, `Javadoc 1.5`, and so on. The main body of the > page has the same. All of these links for the numbered versions of `Javadoc` > are broken, resulting in a `Not Found` error page. > For example, one such broken link: > [https://commons.apache.org/proper/commons-csv/archives/1.6/apidocs/index.html] > The only Javadoc link that works is `Javadoc Trunk`, but that is for the > forthcoming release, not the current release. > https://commons.apache.org/proper/commons-csv/apidocs/index.html > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CSV-240) Links for JavaDoc broken on web site
Basil created CSV-240: - Summary: Links for JavaDoc broken on web site Key: CSV-240 URL: https://issues.apache.org/jira/browse/CSV-240 Project: Commons CSV Issue Type: Bug Components: Documentation Affects Versions: 1.6 Reporter: Basil The sidebar on the left of this page: [https://commons.apache.org/proper/commons-csv/] …has items for `Javadoc 1.6`, `Javadoc 1.5`, and so on. The main body of the page has the same. All of these links for the numbered versions of `Javadoc` are broken, resulting in a `Not Found` error page. For example, one such broken link: [https://commons.apache.org/proper/commons-csv/archives/1.6/apidocs/index.html] The only Javadoc link that works is `Javadoc Trunk`, but that is for the forthcoming release, not the current release. https://commons.apache.org/proper/commons-csv/apidocs/index.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-rng] coveralls edited a comment on issue #46: Update ProviderBuilder factory methods
coveralls edited a comment on issue #46: Update ProviderBuilder factory methods URL: https://github.com/apache/commons-rng/pull/46#issuecomment-498219127 [![Coverage Status](https://coveralls.io/builds/23764252/badge)](https://coveralls.io/builds/23764252) Coverage increased (+0.06%) to 98.811% when pulling **45d73f54086c15d391938ae171d31b4c371194cc on aherbert:improvement-RNG-75** into **0bda14cc5fc04155f8d1d2c4eeb8d1e1dd6160a3 on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-lang] XenoAmess opened a new pull request #429: ArrayUtils: merge 8 isSameLength, isEmpty, isNotEmpty into one function each.
XenoAmess opened a new pull request #429: ArrayUtils: merge 8 isSameLength,isEmpty,isNotEmpty into one function each. URL: https://github.com/apache/commons-lang/pull/429 There are 8 isSameLength,8 isEmpty,8 isNotEmpty in ArrayUtils, but only one getLength function. That is somehow weird, and breaks compatibility. And also, if we make such change, we can apply isSameLength upon different kind of arrays. Otherwise, we shall make functions like getLength be 8 functions to keep compatibility in my opinion. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (BCEL-317) Pluggable cache for ConstantUtf8
[ https://issues.apache.org/jira/browse/BCEL-317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomo Suzuki updated BCEL-317: - Description: Follow-up of BCEL-186. This enhancement is to provide an option to cache ConstantUtf8 instances that have the same value. Email thread: [bcel] Idea to share ConstantUtf8 of same value among JavaClass instances We use BCEL library to inspect Java class. Thank you for the great library. When our tool checks classes in ~200 jar files, it creates more than 2 million BCEL ConstantUtf8 instances. I suspect many of them share the same values such as "java.lang.String". Without cache, my tool created 2,6 million ConstantUtf8 instances (before failing OutOfMemoryError: GC overhead limit exceeded) to check ~200 jar files. !2644k_constantutf8_without_getCachedInstance.png! With the cache, my tool created just 0.6 million ConstantUtf8 instances. It didn't throw the OutOfMemoryError. !621k_constantutf8_with_getCachedInstance.png! Old commit that made ConstantUtf8.getInstance [https://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/Constant.java?r1=1481383&r2=1481382&pathrev=1481383] The ConstantUtf8.getInstance has been unused in BCEL since BCEL-186 [http://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/ConstantUtf8.java?r1=1652541&r2=1652540&pathrev=1652541] h1. How our project uses BCEL - Our tool (Linkage Checker) creates BCEL's ClassPathRepository with around 200 JAR files as its input class path in ClassDumper.createClassRepository([source code URL|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L83]) {code:java} private static Repository createClassRepository(List paths) { ClassPath classPath = new LinkageCheckClassPath(paths); return new ClassPathRepository(classPath); # This is BCEL API }{code} - reads JavaClasses one by one in ClassDumper.listClassesInJar ([source code URL|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L360]) through the ClassPathRepository. {code:java} private ImmutableSet listClassesInJar(Path jar) throws IOException { ImmutableSet.Builder javaClasses = ImmutableSet.builder(); for (String className : listClassNamesInJar(jar)) { try { JavaClass javaClass = classRepository.loadClass(className); # This is BCEL API. ConstantUtf8 is not cached. javaClasses.add(javaClass); ...(omit) return javaClasses.build(); }{code} Stacktrace from the ClassDumper.listClassesInJar to BCEL's ConstantUtf8.getInstance would look like this: {code:java} ConstantUtf8.getInstance Constant.readConstant ConstantPool. ClassParser.readConstantPool ClassParser.parse ClassPathRepository.loadClass ClassPathRepository.loadClass ClassDumper.listClassesInJar {code} - Use the JavaClass instances to check if any symbol references (entries in constant pool [Java Virtual Machine Specification 4.4. The Constant Pool|https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.4]: CONSTANT_Class, CONSTANT_Fieldref, CONSTANT_Methodref, and CONSTANT_InterfaceMethodref) has invalid referent in the class path. was: Follow-up of BCEL-186. This enhancement is to provide an option to cache ConstantUtf8 instances that have the same value. Email thread: [bcel] Idea to share ConstantUtf8 of same value among JavaClass instances We use BCEL library to inspect Java class. Thank you for the great library. When our tool checks classes in ~200 jar files, it creates more than 2 million BCEL ConstantUtf8 instances. I suspect many of them share the same values such as "java.lang.String". Without cache, my tool created 2,6 million ConstantUtf8 instances (before failing OutOfMemoryError: GC overhead limit exceeded) to check ~200 jar files. !2644k_constantutf8_without_getCachedInstance.png! With the cache, my tool created just 0.6 million ConstantUtf8 instances. It didn't throw the OutOfMemoryError. !621k_constantutf8_with_getCachedInstance.png! Old commit that made ConstantUtf8.getInstance [https://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/Constant.java?r1=1481383&r2=1481382&pathrev=1481383] The ConstantUtf8.getInstance has been unused in BCEL since BCEL-186 [http://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/ConstantUtf8.java?r1=1652541&r2=1652540&pathrev=1652541] h1. How our project uses BCEL - Our tool (Linkage Checker) creates BCEL's ClassPathRepository with around 200 JAR files as its
[jira] [Closed] (LANG-1461) Add null-safe StringUtils APIs to wrap String#getBytes([Charset|String])
[ https://issues.apache.org/jira/browse/LANG-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed LANG-1461. -- Resolution: Fixed In git master. > Add null-safe StringUtils APIs to wrap String#getBytes([Charset|String]) > > > Key: LANG-1461 > URL: https://issues.apache.org/jira/browse/LANG-1461 > Project: Commons Lang > Issue Type: New Feature >Reporter: Gary Gregory >Assignee: Gary Gregory >Priority: Major > Fix For: 3.10 > > > Add null-safe versions to wrap {{getBytes(String, [Charset|String])}}: > * {{StringUtills#getBytes(String, Charset)}} > * {{StringUtills#getBytes(String, String)}} > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-rng] coveralls edited a comment on issue #46: Update ProviderBuilder factory methods
coveralls edited a comment on issue #46: Update ProviderBuilder factory methods URL: https://github.com/apache/commons-rng/pull/46#issuecomment-498219127 [![Coverage Status](https://coveralls.io/builds/23761654/badge)](https://coveralls.io/builds/23761654) Coverage increased (+0.06%) to 98.811% when pulling **a9d507c0335adc8d7cb3549cbc551214eb414334 on aherbert:improvement-RNG-75** into **0bda14cc5fc04155f8d1d2c4eeb8d1e1dd6160a3 on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (LANG-1461) Add null-safe StringUtils APIs to wrap String#getBytes([Charset|String])
[ https://issues.apache.org/jira/browse/LANG-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated LANG-1461: --- Description: Add null-safe versions to wrap {{getBytes(String, [Charset|String])}}: * {{StringUtills#getBytes(String, Charset)}} * {{StringUtills#getBytes(String, String)}} was: Add null-safe versions to wrap {{getBytes(String, [Charset|String])}}: * {{StringUtills#getBytes(String, Charset)}} * {{StringUtills#getBytes(String, String)}} Also adds the following used by the above: * {{CharSetUtils.defaultCharset(Charset)}} * {{CharSetUtils.defaultCharset(String)}} > Add null-safe StringUtils APIs to wrap String#getBytes([Charset|String]) > > > Key: LANG-1461 > URL: https://issues.apache.org/jira/browse/LANG-1461 > Project: Commons Lang > Issue Type: New Feature >Reporter: Gary Gregory >Assignee: Gary Gregory >Priority: Major > Fix For: 3.10 > > > Add null-safe versions to wrap {{getBytes(String, [Charset|String])}}: > * {{StringUtills#getBytes(String, Charset)}} > * {{StringUtills#getBytes(String, String)}} > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (BCEL-317) Pluggable cache for ConstantUtf8
[ https://issues.apache.org/jira/browse/BCEL-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16854715#comment-16854715 ] Tomo Suzuki commented on BCEL-317: -- Hi [~ggregory], I've enriched the "How our project uses BCEL" section in this ticket. I hope it answers your question but I'm happy to answer more detail. I also created another PR to reflect your feedback: PR [27|https://github.com/apache/commons-bcel/pull/27]: Constant to switch ConstantUtf8.getInstance or getCachedInstance. > Pluggable cache for ConstantUtf8 > > > Key: BCEL-317 > URL: https://issues.apache.org/jira/browse/BCEL-317 > Project: Commons BCEL > Issue Type: Improvement > Components: Main >Affects Versions: 6.3.1 >Reporter: Tomo Suzuki >Priority: Minor > Attachments: 2644k_constantutf8_without_getCachedInstance.png, > 621k_constantutf8_with_getCachedInstance.png > > Time Spent: 20m > Remaining Estimate: 0h > > Follow-up of BCEL-186. This enhancement is to provide an option to cache > ConstantUtf8 instances that have the same value. > > Email thread: [bcel] Idea to share ConstantUtf8 of same value among JavaClass > instances > > We use BCEL library to inspect Java class. Thank you for the great library. > > When our tool checks classes in ~200 jar files, it creates more than 2 > million BCEL ConstantUtf8 instances. I suspect many of them share the same > values such as "java.lang.String". > > Without cache, my tool created 2,6 million ConstantUtf8 instances (before > failing OutOfMemoryError: GC overhead limit exceeded) to check ~200 jar files. > !2644k_constantutf8_without_getCachedInstance.png! > > With the cache, my tool created just 0.6 million ConstantUtf8 instances. It > didn't throw the OutOfMemoryError. > !621k_constantutf8_with_getCachedInstance.png! > > Old commit that made ConstantUtf8.getInstance > [https://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/Constant.java?r1=1481383&r2=1481382&pathrev=1481383] > The ConstantUtf8.getInstance has been unused in BCEL since BCEL-186 > [http://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/ConstantUtf8.java?r1=1652541&r2=1652540&pathrev=1652541] > > h1. How our project uses BCEL > - Our tool (Linkage Checker) creates BCEL's ClassPathRepository with around > 200 JAR files as its input class path in > ClassDumper.createClassRepository([source code > URL|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L83]) > {code:java} > private static Repository createClassRepository(List paths) { > ClassPath classPath = new LinkageCheckClassPath(paths); > return new ClassPathRepository(classPath); # This is BCEL API > } > {code} > - reads JavaClasses one by one in ClassDumper.listClassesInJar ([source code > URL|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L360]) > through the ClassPathRepository. > {code:java} > private ImmutableSet listClassesInJar(Path jar) throws > IOException { > ImmutableSet.Builder javaClasses = ImmutableSet.builder(); > for (String className : listClassNamesInJar(jar)) { > try { > JavaClass javaClass = classRepository.loadClass(className); # This is > BCEL API. ConstantUtf8 is not cached. > javaClasses.add(javaClass); > ...(omit) > return javaClasses.build(); > } > {code} > - Use the JavaClass instances to check if any symbol references (entries in > constant pool [Java Virtual Machine Specification 4.4. The Constant > Pool|https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.4]: > CONSTANT_Class, CONSTANT_Fieldref, CONSTANT_Methodref, and > CONSTANT_InterfaceMethodref) has invalid referent in the class path. > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (BCEL-317) Pluggable cache for ConstantUtf8
[ https://issues.apache.org/jira/browse/BCEL-317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomo Suzuki updated BCEL-317: - Description: Follow-up of BCEL-186. This enhancement is to provide an option to cache ConstantUtf8 instances that have the same value. Email thread: [bcel] Idea to share ConstantUtf8 of same value among JavaClass instances We use BCEL library to inspect Java class. Thank you for the great library. When our tool checks classes in ~200 jar files, it creates more than 2 million BCEL ConstantUtf8 instances. I suspect many of them share the same values such as "java.lang.String". Without cache, my tool created 2,6 million ConstantUtf8 instances (before failing OutOfMemoryError: GC overhead limit exceeded) to check ~200 jar files. !2644k_constantutf8_without_getCachedInstance.png! With the cache, my tool created just 0.6 million ConstantUtf8 instances. It didn't throw the OutOfMemoryError. !621k_constantutf8_with_getCachedInstance.png! Old commit that made ConstantUtf8.getInstance [https://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/Constant.java?r1=1481383&r2=1481382&pathrev=1481383] The ConstantUtf8.getInstance has been unused in BCEL since BCEL-186 [http://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/ConstantUtf8.java?r1=1652541&r2=1652540&pathrev=1652541] h1. How our project uses BCEL - Our tool (Linkage Checker) creates BCEL's ClassPathRepository with around 200 JAR files as its input class path in ClassDumper.createClassRepository([source code URL|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L83]) {code:java} private static Repository createClassRepository(List paths) { ClassPath classPath = new LinkageCheckClassPath(paths); return new ClassPathRepository(classPath); # This is BCEL API } {code} - reads JavaClasses one by one in ClassDumper.listClassesInJar ([source code URL|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L360]) through the ClassPathRepository. {code:java} private ImmutableSet listClassesInJar(Path jar) throws IOException { ImmutableSet.Builder javaClasses = ImmutableSet.builder(); for (String className : listClassNamesInJar(jar)) { try { JavaClass javaClass = classRepository.loadClass(className); # This is BCEL API. ConstantUtf8 is not cached. javaClasses.add(javaClass); ...(omit) return javaClasses.build(); } {code} - Use the JavaClass instances to check if any symbol references (entries in constant pool [Java Virtual Machine Specification 4.4. The Constant Pool|https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.4]: CONSTANT_Class, CONSTANT_Fieldref, CONSTANT_Methodref, and CONSTANT_InterfaceMethodref) has invalid referent in the class path. was: Follow-up of BCEL-186. This enhancement is to provide an option to cache ConstantUtf8 instances that have the same value. Email thread: [bcel] Idea to share ConstantUtf8 of same value among JavaClass instances We use BCEL library to inspect Java class. Thank you for the great library. When our tool checks classes in ~200 jar files, it creates more than 2 million BCEL ConstantUtf8 instances. I suspect many of them share the same values such as "java.lang.String". Without cache, my tool created 2,6 million ConstantUtf8 instances (before failing OutOfMemoryError: GC overhead limit exceeded) to check ~200 jar files. !2644k_constantutf8_without_getCachedInstance.png! With the cache, my tool created just 0.6 million ConstantUtf8 instances. It didn't throw the OutOfMemoryError. !621k_constantutf8_with_getCachedInstance.png! Old commit that made ConstantUtf8.getInstance [https://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/Constant.java?r1=1481383&r2=1481382&pathrev=1481383] The ConstantUtf8.getInstance has been unused in BCEL since BCEL-186 [http://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/ConstantUtf8.java?r1=1652541&r2=1652540&pathrev=1652541] h1. How our project uses BCEL - Our tool (Linkage Checker) creates BCEL's ClassPathRepository with around 200 JAR files as its input class path in ClassDumper.createClassRepository([source code URL|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L83]) {code:java} private static Repository create
[jira] [Updated] (BCEL-317) Pluggable cache for ConstantUtf8
[ https://issues.apache.org/jira/browse/BCEL-317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomo Suzuki updated BCEL-317: - Description: Follow-up of BCEL-186. This enhancement is to provide an option to cache ConstantUtf8 instances that have the same value. Email thread: [bcel] Idea to share ConstantUtf8 of same value among JavaClass instances We use BCEL library to inspect Java class. Thank you for the great library. When our tool checks classes in ~200 jar files, it creates more than 2 million BCEL ConstantUtf8 instances. I suspect many of them share the same values such as "java.lang.String". Without cache, my tool created 2,6 million ConstantUtf8 instances (before failing OutOfMemoryError: GC overhead limit exceeded) to check ~200 jar files. !2644k_constantutf8_without_getCachedInstance.png! With the cache, my tool created just 0.6 million ConstantUtf8 instances. It didn't throw the OutOfMemoryError. !621k_constantutf8_with_getCachedInstance.png! Old commit that made ConstantUtf8.getInstance [https://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/Constant.java?r1=1481383&r2=1481382&pathrev=1481383] The ConstantUtf8.getInstance has been unused in BCEL since BCEL-186 [http://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/ConstantUtf8.java?r1=1652541&r2=1652540&pathrev=1652541] h1. How our project uses BCEL - Our tool (Linkage Checker) creates BCEL's ClassPathRepository with around 200 JAR files as its input class path in ClassDumper.createClassRepository([source code URL|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L83]) {code:java} private static Repository createClassRepository(List paths) { ClassPath classPath = new LinkageCheckClassPath(paths); return new ClassPathRepository(classPath); } {code} - reads JavaClasses one by one in ClassDumper.listClassesInJar ([source code URL|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L360]) through the ClassPathRepository. {code:java} private ImmutableSet listClassesInJar(Path jar) throws IOException { ImmutableSet.Builder javaClasses = ImmutableSet.builder(); for (String className : listClassNamesInJar(jar)) { try { JavaClass javaClass = classRepository.loadClass(className); javaClasses.add(javaClass); ...(omit) return javaClasses.build(); } {code} - Use the JavaClass instances to check if any symbol references (entries in constant pool [Java Virtual Machine Specification 4.4. The Constant Pool|https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.4]: CONSTANT_Class, CONSTANT_Fieldref, CONSTANT_Methodref, and CONSTANT_InterfaceMethodref) has invalid referent in the class path. was: Follow-up of BCEL-186. This enhancement is to provide an option to cache ConstantUtf8 instances that have the same value. Email thread: [bcel] Idea to share ConstantUtf8 of same value among JavaClass instances We use BCEL library to inspect Java class. Thank you for the great library. When our tool checks classes in ~200 jar files, it creates more than 2 million BCEL ConstantUtf8 instances. I suspect many of them share the same values such as "java.lang.String". Without cache, my tool created 2,6 million ConstantUtf8 instances (before failing OutOfMemoryError: GC overhead limit exceeded) to check ~200 jar files. !2644k_constantutf8_without_getCachedInstance.png! With the cache, my tool created just 0.6 million ConstantUtf8 instances. It didn't throw the OutOfMemoryError. !621k_constantutf8_with_getCachedInstance.png! Old commit that made ConstantUtf8.getInstance [https://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/Constant.java?r1=1481383&r2=1481382&pathrev=1481383] The ConstantUtf8.getInstance has been unused in BCEL since BCEL-186 [http://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/ConstantUtf8.java?r1=1652541&r2=1652540&pathrev=1652541] h1. How our project uses BCEL - Our tool (Linkage Checker) creates BCEL's ClassPathRepository with around 200 JAR files as its input class path in ClassDumper.createClassRepository([source code URL|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L83]) - reads JavaClass one by one in ClassDumper.listClassesInJar ([source code URL|https://github.com/GoogleCloudPlatf
[jira] [Updated] (LANG-1461) Add null-safe StringUtils APIs to wrap String#getBytes([Charset|String])
[ https://issues.apache.org/jira/browse/LANG-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated LANG-1461: --- Description: Add null-safe versions to wrap {{getBytes(String, [Charset|String])}}: * {{StringUtills#getBytes(String, Charset)}} * {{StringUtills#getBytes(String, String)}} Also adds the following used by the above: * {{CharSetUtils.defaultCharset(Charset)}} * {{CharSetUtils.defaultCharset(String)}} was: Add null-safe versions to wrap {{getBytes(String, [Charset|String])}}: * {{StringUtills#getBytes(String, Charset)}} * {{StringUtills#getBytes(String, String)}} > Add null-safe StringUtils APIs to wrap String#getBytes([Charset|String]) > > > Key: LANG-1461 > URL: https://issues.apache.org/jira/browse/LANG-1461 > Project: Commons Lang > Issue Type: New Feature >Reporter: Gary Gregory >Assignee: Gary Gregory >Priority: Major > Fix For: 3.10 > > > Add null-safe versions to wrap {{getBytes(String, [Charset|String])}}: > * {{StringUtills#getBytes(String, Charset)}} > * {{StringUtills#getBytes(String, String)}} > Also adds the following used by the above: > * {{CharSetUtils.defaultCharset(Charset)}} > * {{CharSetUtils.defaultCharset(String)}} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (BCEL-317) Pluggable cache for ConstantUtf8
[ https://issues.apache.org/jira/browse/BCEL-317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomo Suzuki updated BCEL-317: - Description: Follow-up of BCEL-186. This enhancement is to provide an option to cache ConstantUtf8 instances that have the same value. Email thread: [bcel] Idea to share ConstantUtf8 of same value among JavaClass instances We use BCEL library to inspect Java class. Thank you for the great library. When our tool checks classes in ~200 jar files, it creates more than 2 million BCEL ConstantUtf8 instances. I suspect many of them share the same values such as "java.lang.String". Without cache, my tool created 2,6 million ConstantUtf8 instances (before failing OutOfMemoryError: GC overhead limit exceeded) to check ~200 jar files. !2644k_constantutf8_without_getCachedInstance.png! With the cache, my tool created just 0.6 million ConstantUtf8 instances. It didn't throw the OutOfMemoryError. !621k_constantutf8_with_getCachedInstance.png! Old commit that made ConstantUtf8.getInstance [https://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/Constant.java?r1=1481383&r2=1481382&pathrev=1481383] The ConstantUtf8.getInstance has been unused in BCEL since BCEL-186 [http://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/ConstantUtf8.java?r1=1652541&r2=1652540&pathrev=1652541] h1. How our project uses BCEL - Our tool (Linkage Checker) creates BCEL's ClassPathRepository with around 200 JAR files as its input class path in ClassDumper.createClassRepository([source code URL|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L83]) - reads JavaClass one by one in ClassDumper.listClassesInJar ([source code URL|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L360]) through the ClassPathRepository. was: Follow-up of BCEL-186. This enhancement is to provide an option to cache ConstantUtf8 instances that have the same value. Email thread: [bcel] Idea to share ConstantUtf8 of same value among JavaClass instances We use BCEL library to inspect Java class. Thank you for the great library. When our tool checks classes in ~200 jar files, it creates more than 2 million BCEL ConstantUtf8 instances. I suspect many of them share the same values such as "java.lang.String". Without cache, my tool created 2,6 million ConstantUtf8 instances (before failing OutOfMemoryError: GC overhead limit exceeded) to check ~200 jar files. !2644k_constantutf8_without_getCachedInstance.png! With the cache, my tool created just 0.6 million ConstantUtf8 instances. It didn't throw the OutOfMemoryError. !621k_constantutf8_with_getCachedInstance.png! Old commit that made ConstantUtf8.getInstance [https://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/Constant.java?r1=1481383&r2=1481382&pathrev=1481383] The ConstantUtf8.getInstance has been unused in BCEL since BCEL-186 [http://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/ConstantUtf8.java?r1=1652541&r2=1652540&pathrev=1652541] h1. How our project uses BCEL Our tool (Linkage Checker) creates BCEL's ClassPathRepository with around 200 JAR files as its input class path ([ClassDumper.createClassRepository|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L83]) and reads JavaClass one by one ([ClassDumper.listClassesInJar|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L360]) through the ClassPathRepository. > Pluggable cache for ConstantUtf8 > > > Key: BCEL-317 > URL: https://issues.apache.org/jira/browse/BCEL-317 > Project: Commons BCEL > Issue Type: Improvement > Components: Main >Affects Versions: 6.3.1 >Reporter: Tomo Suzuki >Priority: Minor > Attachments: 2644k_constantutf8_without_getCachedInstance.png, > 621k_constantutf8_with_getCachedInstance.png > > Time Spent: 20m > Remaining Estimate: 0h > > Follow-up of BCEL-186. This enhancement is to provide an option to cache > ConstantUtf8 instances that have the same value. > > Email thread: [bcel] Idea to share ConstantUtf8 of same value among JavaClass >
[jira] [Updated] (LANG-1461) Add null-safe StringUtils APIs to wrap String#getBytes([Charset|String])
[ https://issues.apache.org/jira/browse/LANG-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated LANG-1461: --- Summary: Add null-safe StringUtils APIs to wrap String#getBytes([Charset|String]) (was: Add null-safe StringUtils APIs to wrap getBytes(String, [Charset|String])) > Add null-safe StringUtils APIs to wrap String#getBytes([Charset|String]) > > > Key: LANG-1461 > URL: https://issues.apache.org/jira/browse/LANG-1461 > Project: Commons Lang > Issue Type: New Feature >Reporter: Gary Gregory >Assignee: Gary Gregory >Priority: Major > Fix For: 3.10 > > > Add null-safe versions to wrap {{getBytes(String, [Charset|String])}}: > * {{StringUtills#getBytes(String, Charset)}} > * {{StringUtills#getBytes(String, String)}} > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (LANG-1461) Add null-safe StringUtils APIs to wrap getBytes(String, [Charset|String])
[ https://issues.apache.org/jira/browse/LANG-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated LANG-1461: --- Summary: Add null-safe StringUtils APIs to wrap getBytes(String, [Charset|String]) (was: Add null-safe versions to wrap getBytes(String, [Charset|String])) > Add null-safe StringUtils APIs to wrap getBytes(String, [Charset|String]) > - > > Key: LANG-1461 > URL: https://issues.apache.org/jira/browse/LANG-1461 > Project: Commons Lang > Issue Type: New Feature >Reporter: Gary Gregory >Assignee: Gary Gregory >Priority: Major > Fix For: 3.10 > > > Add null-safe versions to wrap {{getBytes(String, [Charset|String])}}: > * {{StringUtills#getBytes(String, Charset)}} > * {{StringUtills#getBytes(String, String)}} > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CODEC-253) Upgrade to Java 8
[ https://issues.apache.org/jira/browse/CODEC-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16854678#comment-16854678 ] Michael Osipov commented on CODEC-253: -- [~ggregory], pretty professional by opening another ticket for this issue and commit right away w/o concluding the discussion here. You can also get Zulu 7 for free and test your stuff. You pretty gained nothing by changing the byte code version. > Upgrade to Java 8 > - > > Key: CODEC-253 > URL: https://issues.apache.org/jira/browse/CODEC-253 > Project: Commons Codec > Issue Type: Improvement >Reporter: Rob Tompkins >Assignee: Rob Tompkins >Priority: Major > Fix For: 1.13 > > > Upgrade to java 8 as the target of of the build. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (LANG-1461) Add null-safe versions to wrap getBytes(String, [Charset|String])
Gary Gregory created LANG-1461: -- Summary: Add null-safe versions to wrap getBytes(String, [Charset|String]) Key: LANG-1461 URL: https://issues.apache.org/jira/browse/LANG-1461 Project: Commons Lang Issue Type: New Feature Reporter: Gary Gregory Assignee: Gary Gregory Fix For: 3.10 Add null-safe versions to wrap {{getBytes(String, [Charset|String])}}: * {{StringUtills#getBytes(String, Charset)}} * {{StringUtills#getBytes(String, String)}} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (RNG-75) Improve the speed of the RandomSource create method.
[ https://issues.apache.org/jira/browse/RNG-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16854632#comment-16854632 ] Alex D Herbert commented on RNG-75: --- {quote}Performance is a non-goal for this class. {quote} That was the impression I was working under. It was not clear from my post that I was pointing out that the main cost of constructing a SplitMix generator is the SeedFactory creating a new long. I agree that the output from the SeedFactory is good. I am currently running a Well44497b generator xor'd with the output of System getIdentityHashCode through the stress test application. A quick checks shows it passes SmallCrush (there was 1 fail from 5 runs for a plain Well44497b) and is about 33% slower to run the test. This shows that the Java-to-C bridge is the main bottle neck in the stress test application. Anyway it should be done by tomorrow and I expect the output to pass. I do not suggest altering the SeedFactory. The performance test was to gauge how to add new *create...Fast* methods to the SeedFactory. I have another table that shows the relative performance of using the RandomSource.create method against using the *new* keyword to create the generator, with a seed dynamically created by the SeedFactory and with a pre-built seed. The pre-built seed case shows that reflection is a lot slower when the seeding routine is simple. However I would assign the later as a minority case. Building a generator in the majority case would require building a new seed. I'll post this table later (as I do not have it on my current workstation). > Improve the speed of the RandomSource create method. > > > Key: RNG-75 > URL: https://issues.apache.org/jira/browse/RNG-75 > Project: Commons RNG > Issue Type: Improvement > Components: simple >Affects Versions: 1.3 >Reporter: Alex D Herbert >Assignee: Alex D Herbert >Priority: Minor > Fix For: 1.3 > > Attachments: large.jpg, long.jpg, small.jpg > > > Update the {{o.a.c.rng.simple.internal}} package to improve the construction > speed of random generators. > Areas identified by the construction benchmark > [RNG-72|https://issues.apache.org/jira/projects/RNG/issues/RNG-72] include: > * Update the {{RandomSourceInternal}} to know the desired size for the native > seed > * Update the {{SeedFactory}} for faster {{byte[]}} conversions > * Remove the use of reflection for fast seeding generators > It is intended that all changes made are non-destructive to the quality of > any generated seed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (BCEL-317) Pluggable cache for ConstantUtf8
[ https://issues.apache.org/jira/browse/BCEL-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16854631#comment-16854631 ] Gary Gregory commented on BCEL-317: --- May you please show how you use the BCEL API? That will help me see if I can provide a minimal change set for you to test... > Pluggable cache for ConstantUtf8 > > > Key: BCEL-317 > URL: https://issues.apache.org/jira/browse/BCEL-317 > Project: Commons BCEL > Issue Type: Improvement > Components: Main >Affects Versions: 6.3.1 >Reporter: Tomo Suzuki >Priority: Minor > Attachments: 2644k_constantutf8_without_getCachedInstance.png, > 621k_constantutf8_with_getCachedInstance.png > > Time Spent: 20m > Remaining Estimate: 0h > > Follow-up of BCEL-186. This enhancement is to provide an option to cache > ConstantUtf8 instances that have the same value. > > Email thread: [bcel] Idea to share ConstantUtf8 of same value among JavaClass > instances > > We use BCEL library to inspect Java class. Thank you for the great library. > > When our tool checks classes in ~200 jar files, it creates more than 2 > million BCEL ConstantUtf8 instances. I suspect many of them share the same > values such as "java.lang.String". > > Without cache, my tool created 2,6 million ConstantUtf8 instances (before > failing OutOfMemoryError: GC overhead limit exceeded) to check ~200 jar files. > !2644k_constantutf8_without_getCachedInstance.png! > > With the cache, my tool created just 0.6 million ConstantUtf8 instances. It > didn't throw the OutOfMemoryError. > !621k_constantutf8_with_getCachedInstance.png! > > Old commit that made ConstantUtf8.getInstance > [https://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/Constant.java?r1=1481383&r2=1481382&pathrev=1481383] > The ConstantUtf8.getInstance has been unused in BCEL since BCEL-186 > [http://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/ConstantUtf8.java?r1=1652541&r2=1652540&pathrev=1652541] > > h1. How our project uses BCEL > Our tool (Linkage Checker) creates BCEL's ClassPathRepository with around 200 > JAR files as its input class path > ([ClassDumper.createClassRepository|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L83]) > and reads JavaClass one by one > ([ClassDumper.listClassesInJar|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L360]) > through the ClassPathRepository. > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (RNG-75) Improve the speed of the RandomSource create method.
[ https://issues.apache.org/jira/browse/RNG-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16854589#comment-16854589 ] Gilles commented on RNG-75: --- bq. performance of the {{SeedFactory}} Performance is a non-goal for this class. Primary goal was to provide the largest possible seed space. To achieve it, the whole seed should be generated from the RNG with longest period. For "intermediate" requirement, a single long is generated from that longest period RNG in order to seed a fast RNG, and the rest of the seed array is produced by that RNG. IIRC we discussed of {{SeedFactory}} providing new {{create...Fast}} methods to that end. For "special" ("odd" ;)) requirement (throw-away RNG (?)), where even a single long from a slow RNG is unbearable (?), I would not assume that {{SeedFactory}} should be used (e.g. the user can instantiate and keep a reference to a fast RNG that would serve as his own seed factory). > Improve the speed of the RandomSource create method. > > > Key: RNG-75 > URL: https://issues.apache.org/jira/browse/RNG-75 > Project: Commons RNG > Issue Type: Improvement > Components: simple >Affects Versions: 1.3 >Reporter: Alex D Herbert >Assignee: Alex D Herbert >Priority: Minor > Fix For: 1.3 > > Attachments: large.jpg, long.jpg, small.jpg > > > Update the {{o.a.c.rng.simple.internal}} package to improve the construction > speed of random generators. > Areas identified by the construction benchmark > [RNG-72|https://issues.apache.org/jira/projects/RNG/issues/RNG-72] include: > * Update the {{RandomSourceInternal}} to know the desired size for the native > seed > * Update the {{SeedFactory}} for faster {{byte[]}} conversions > * Remove the use of reflection for fast seeding generators > It is intended that all changes made are non-destructive to the quality of > any generated seed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (BCEL-317) Pluggable cache for ConstantUtf8
[ https://issues.apache.org/jira/browse/BCEL-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16854577#comment-16854577 ] Tomo Suzuki commented on BCEL-317: -- My ClassDumper is irrelevant to the one in the examples. They happen to have the same name. > Pluggable cache for ConstantUtf8 > > > Key: BCEL-317 > URL: https://issues.apache.org/jira/browse/BCEL-317 > Project: Commons BCEL > Issue Type: Improvement > Components: Main >Affects Versions: 6.3.1 >Reporter: Tomo Suzuki >Priority: Minor > Attachments: 2644k_constantutf8_without_getCachedInstance.png, > 621k_constantutf8_with_getCachedInstance.png > > Time Spent: 20m > Remaining Estimate: 0h > > Follow-up of BCEL-186. This enhancement is to provide an option to cache > ConstantUtf8 instances that have the same value. > > Email thread: [bcel] Idea to share ConstantUtf8 of same value among JavaClass > instances > > We use BCEL library to inspect Java class. Thank you for the great library. > > When our tool checks classes in ~200 jar files, it creates more than 2 > million BCEL ConstantUtf8 instances. I suspect many of them share the same > values such as "java.lang.String". > > Without cache, my tool created 2,6 million ConstantUtf8 instances (before > failing OutOfMemoryError: GC overhead limit exceeded) to check ~200 jar files. > !2644k_constantutf8_without_getCachedInstance.png! > > With the cache, my tool created just 0.6 million ConstantUtf8 instances. It > didn't throw the OutOfMemoryError. > !621k_constantutf8_with_getCachedInstance.png! > > Old commit that made ConstantUtf8.getInstance > [https://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/Constant.java?r1=1481383&r2=1481382&pathrev=1481383] > The ConstantUtf8.getInstance has been unused in BCEL since BCEL-186 > [http://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/ConstantUtf8.java?r1=1652541&r2=1652540&pathrev=1652541] > > h1. How our project uses BCEL > Our tool (Linkage Checker) creates BCEL's ClassPathRepository with around 200 > JAR files as its input class path > ([ClassDumper.createClassRepository|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L83]) > and reads JavaClass one by one > ([ClassDumper.listClassesInJar|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L360]) > through the ClassPathRepository. > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JEXL-302) JexlScript.getVariables returns strange values for array access
[ https://issues.apache.org/jira/browse/JEXL-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16854569#comment-16854569 ] Dmitri Blinov commented on JEXL-302: I have got your point, but for the sake of argument, as of now - {{a.b}} is not equivalent to {{a["b"]}}. First because of ant-ish variables. One can only address anti-sh variable as {{a.b}}, not as {{a["b"]}}. And second - because we can have {{propertyGet()/propertySet()}} and {{arrayGet()/arraySet()}} to be overloaded separately. I understand that what {{a.b}} is resolved into (whether this a variable {{a.b}} or only {{a}} is a variable, and {{b}} is property name) is decided during runtime, so this can not be defined from syntax representation tree - a tough task for {{JexlScript.getVariables()}}. Still, the example of issue {code:java} a[b]['c']{code} does not follow the pattern in question. From your explanation, and from what I get from the {{JexlScript.getVariables(),}} the code {{a[b]['c']}} is equivalent to {{a[b.c]}}, which in fact should be equivalent to {{a[b["c"]]}}. Something is wrong here... > JexlScript.getVariables returns strange values for array access > --- > > Key: JEXL-302 > URL: https://issues.apache.org/jira/browse/JEXL-302 > Project: Commons JEXL > Issue Type: Bug >Affects Versions: 3.1 >Reporter: Dmitri Blinov >Assignee: Henri Biestro >Priority: Minor > Fix For: 3.2 > > > I can not understand the logic behind the current implementation of > {{JexlScript.getVariables()}} method. From the documentation we know that the > result should be the set of script variables. For the code > {code:java} > a[b][c]{code} > it gives three variables {{a}}, {{b}}, {{c}}. So far so good. But for the code > {code:java} > a[b]['c']{code} > it returns {{a}} and {{b c}}, where second variable has two fragments {{b}} > and {{c}}. The documentation states that variables with multiple fragments > are ant-ish variables, but I don't have any of ant-ish variables in the > example, and {{'c'}} is not a variable, but a constant. I expect to get {{a}} > and {{b}} as a result. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (RNG-75) Improve the speed of the RandomSource create method.
[ https://issues.apache.org/jira/browse/RNG-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16854542#comment-16854542 ] Alex D Herbert commented on RNG-75: --- I have created a PR that rearranges the internals of the ProviderBuilder. The goal was to allow: * Construction of array seeds of the correct length * Customisation of seed creation on a per generator basis, e.g. to prevent creation of seeds containing only zero bytes The code change does the following: * Moves the creation methods for creating a seed and a new generator into RandomSourceInternal * Adds a new interface for seed conversions to specify output array size * Adds a property to each RandomSourceInternal containing the size of the seed * Uses a custom enum supporting all the seed types to perform conversions * Caches the constructor (it is always the same) to avoid repeat lookups using reflection Note: The new code still creates a maximum array length of 128 when using a null seed. This is to minimise the work done in the SeedFactory to create arrays using a single synchronized RNG. This could be changed by has been left to have the same support as the old code. To support sized conversions a new interface has been added where the output array size is specified. This is only applicable when the input seed is either an int or long and is converted to an array using a SplitMix generator. So to avoid supporting this interface for all seed converters a new internal enum was created that performs seed conversions. This uses the seed converters directly and uses the array size when appropriate. I have JMH construction timing data for all the generators. For reference here are the methods: * Create using the native constructor with the {{new}} keyword * Create using a cached {{Constructor}} with newInstance * Create using a cached {{Class}}, lookup the {{Constructor}} and use newInstance * Create using {{RandomSource}} with the native seed * Create using {{RandomSource}} with a {{null}} seed * Create using {{RandomSource}} with a truncated native seed forcing self seeding * Create using {{RandomSource}} with a {{byte[]}} of the appropriate length To avoid a large table I've computed the relative time between the old code and the new. I've split the generators into groups with: * Long seeding routines * Large array seeds (above the supported max length of 128) * Small seeds (below length 128) Here are some charts of the relative construction time: *Long seeding routines* !long.jpg! In this case the changes have not made the construction faster. I do not understand the slower time for TWO_CMRES. Construction with the same seed using the *new* keyword is the same. But the new factory methods are slower. The seed is a single integer so this timing difference is strange. This generator is very slow to self-seed so I would expect no difference for the construction since instantiation time is minimal compared to the self-seeding time. The other generators are the same speed. The slower time for createLongSeed for the Mersenne Twisters is explained by the fact that the old method computed a seed of length 128. The MT requires a seed of 624 and MT_64 a seed of 312. So the new method which creates the correct seed length is doing more work. *Large array seeds* !large.jpg! For the generators with big seeds most methods are the same speed. The MWC result for *createNullSeed* is an outlier. It requires repeating on a different machine to verify. For the other generators they are slower on *createLongSeed* since the new method is array size aware and creates a full length seed rather than the old method creating length 128. *Small seeds* !small.jpg! For *createLongSeed* construction is faster as the correct seed length is created rather than a seed of length 128. For other cases the construction is faster as the method now caches the constructor that is used to create the generator. This adds a noticeable improvement when the seed is pre-built. Note that *createNullSeed* is not much faster for JDK or SplitMix as they have a single long seed. The time is mainly consumed by the SeedFactory creating the seed. A table comparing the speed of construction a single seed created by a synchronised method is shown below for a single thread or 4 threads running in JMH. |Method|1 Thread|4 Threads| |AtomicInt_getAndIncrement|4.88|66.20| |AtomicLong_getAndIncrement|4.85|62.57| |SeedFactory_createInt|54.75|791.25| |SeedFactory_createLong|63.92|842.57| |SyncSplitMix_nextInt|6.66|78.77| |SyncSplitMix_nextLong|6.63|75.18| |System_currentTimeMillis|570.87|2,217.24| |System_identityHashCode|36.43|41.42| |System_nanoTime|575.76|2,224.95| |ThreadLocalRandom_nextInt|1.44|1.65| |ThreadLocalRandom_nextLong|1.63|1.66| |volatileInt_increment|4.94|145.98| |volatileLong_increment|4.87|154.59| |Well44497b_nextInt|18.95|572.74| |Wel
[jira] [Commented] (CODEC-95) Base64: optionally allow strict parsing of base64 strings
[ https://issues.apache.org/jira/browse/CODEC-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16854540#comment-16854540 ] Melloware commented on CODEC-95: I think this is now fixed by https://issues.apache.org/jira/browse/CODEC-134 which no longer allows invalid Base64? > Base64: optionally allow strict parsing of base64 strings > - > > Key: CODEC-95 > URL: https://issues.apache.org/jira/browse/CODEC-95 > Project: Commons Codec > Issue Type: Improvement >Affects Versions: 1.4 >Reporter: Adam Rabung >Priority: Minor > Fix For: 1.x > > Attachments: strictMode.zip > > > Currently, Codec skips base64 characters that are outside of the encode > table. I realize this is perfectly to spec, but I wonder if other users > might appreciate a "strict" mode that throws an exception when one of these > illegal characters are encountered. For example, I would love an exception > to be thrown here: > new Base64().decode("!@#$ iHaveIllegalCharsAtBeginningAndEnd %^&")); -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (BCEL-317) Pluggable cache for ConstantUtf8
[ https://issues.apache.org/jira/browse/BCEL-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16854538#comment-16854538 ] Gary Gregory commented on BCEL-317: --- Hi [~suztomo], I do not see such methods in {{src/examples/ClassDumper.java}}. Do you have a customized version of the example? Gary > Pluggable cache for ConstantUtf8 > > > Key: BCEL-317 > URL: https://issues.apache.org/jira/browse/BCEL-317 > Project: Commons BCEL > Issue Type: Improvement > Components: Main >Affects Versions: 6.3.1 >Reporter: Tomo Suzuki >Priority: Minor > Attachments: 2644k_constantutf8_without_getCachedInstance.png, > 621k_constantutf8_with_getCachedInstance.png > > Time Spent: 20m > Remaining Estimate: 0h > > Follow-up of BCEL-186. This enhancement is to provide an option to cache > ConstantUtf8 instances that have the same value. > > Email thread: [bcel] Idea to share ConstantUtf8 of same value among JavaClass > instances > > We use BCEL library to inspect Java class. Thank you for the great library. > > When our tool checks classes in ~200 jar files, it creates more than 2 > million BCEL ConstantUtf8 instances. I suspect many of them share the same > values such as "java.lang.String". > > Without cache, my tool created 2,6 million ConstantUtf8 instances (before > failing OutOfMemoryError: GC overhead limit exceeded) to check ~200 jar files. > !2644k_constantutf8_without_getCachedInstance.png! > > With the cache, my tool created just 0.6 million ConstantUtf8 instances. It > didn't throw the OutOfMemoryError. > !621k_constantutf8_with_getCachedInstance.png! > > Old commit that made ConstantUtf8.getInstance > [https://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/Constant.java?r1=1481383&r2=1481382&pathrev=1481383] > The ConstantUtf8.getInstance has been unused in BCEL since BCEL-186 > [http://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/ConstantUtf8.java?r1=1652541&r2=1652540&pathrev=1652541] > > h1. How our project uses BCEL > Our tool (Linkage Checker) creates BCEL's ClassPathRepository with around 200 > JAR files as its input class path > ([ClassDumper.createClassRepository|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L83]) > and reads JavaClass one by one > ([ClassDumper.listClassesInJar|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L360]) > through the ClassPathRepository. > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IMAGING-228) Remove private method PhotometricInterpreterLogLuv#cube by Math.pow
[ https://issues.apache.org/jira/browse/IMAGING-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16854516#comment-16854516 ] Gilles commented on IMAGING-228: Just saw the commit on GitHub: The original code is how I would have done it. ;) Intuitively, I'd bet that the call to {{Math.pow}} is slower... > Remove private method PhotometricInterpreterLogLuv#cube by Math.pow > --- > > Key: IMAGING-228 > URL: https://issues.apache.org/jira/browse/IMAGING-228 > Project: Commons Imaging > Issue Type: Improvement >Reporter: Bruno P. Kinoshita >Assignee: Bruno P. Kinoshita >Priority: Minor > Fix For: 1.0-alpha2 > > Time Spent: 10m > Remaining Estimate: 0h > > We have a private method in PhotometricInterpreterLogLuv, that calculates the > cube of a number N doing N * N * N. That can be replaced by Math.pow(N, 3). > Will add unit tests and some javadocs around photometric interpreters, > logluv, cei, lab, color spaces, ceixyz-ceilab, etc, as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IMAGING-228) Remove private method PhotometricInterpreterLogLuv#cube by Math.pow
[ https://issues.apache.org/jira/browse/IMAGING-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16854512#comment-16854512 ] Gilles commented on IMAGING-228: bq. N * N * N \[...\] can be replaced by Math.pow(N, 3). Why would you do that? > Remove private method PhotometricInterpreterLogLuv#cube by Math.pow > --- > > Key: IMAGING-228 > URL: https://issues.apache.org/jira/browse/IMAGING-228 > Project: Commons Imaging > Issue Type: Improvement >Reporter: Bruno P. Kinoshita >Assignee: Bruno P. Kinoshita >Priority: Minor > Fix For: 1.0-alpha2 > > Time Spent: 10m > Remaining Estimate: 0h > > We have a private method in PhotometricInterpreterLogLuv, that calculates the > cube of a number N doing N * N * N. That can be replaced by Math.pow(N, 3). > Will add unit tests and some javadocs around photometric interpreters, > logluv, cei, lab, color spaces, ceixyz-ceilab, etc, as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (BCEL-319) DumpClass.main(String[]) leaks FileImageInputStream
Gary Gregory created BCEL-319: - Summary: DumpClass.main(String[]) leaks FileImageInputStream Key: BCEL-319 URL: https://issues.apache.org/jira/browse/BCEL-319 Project: Commons BCEL Issue Type: New Feature Reporter: Gary Gregory Assignee: Gary Gregory The method {{DumpClass.main(String[])}} leaks {{FileImageInputStream}} instances by never closing them. This only matters if invoked via an API call instead of from an OS shell. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Deleted] (BCEL-319) DumpClass.main(String[]) leaks FileImageInputStream
[ https://issues.apache.org/jira/browse/BCEL-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory deleted BCEL-319: -- > DumpClass.main(String[]) leaks FileImageInputStream > --- > > Key: BCEL-319 > URL: https://issues.apache.org/jira/browse/BCEL-319 > Project: Commons BCEL > Issue Type: New Feature >Reporter: Gary Gregory >Assignee: Gary Gregory >Priority: Major > > The method {{DumpClass.main(String[])}} leaks {{FileImageInputStream}} > instances by never closing them. > This only matters if invoked via an API call instead of from an OS shell. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (RNG-75) Improve the speed of the RandomSource create method.
[ https://issues.apache.org/jira/browse/RNG-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex D Herbert updated RNG-75: -- Attachment: small.jpg large.jpg > Improve the speed of the RandomSource create method. > > > Key: RNG-75 > URL: https://issues.apache.org/jira/browse/RNG-75 > Project: Commons RNG > Issue Type: Improvement > Components: simple >Affects Versions: 1.3 >Reporter: Alex D Herbert >Assignee: Alex D Herbert >Priority: Minor > Fix For: 1.3 > > Attachments: large.jpg, long.jpg, small.jpg > > > Update the {{o.a.c.rng.simple.internal}} package to improve the construction > speed of random generators. > Areas identified by the construction benchmark > [RNG-72|https://issues.apache.org/jira/projects/RNG/issues/RNG-72] include: > * Update the {{RandomSourceInternal}} to know the desired size for the native > seed > * Update the {{SeedFactory}} for faster {{byte[]}} conversions > * Remove the use of reflection for fast seeding generators > It is intended that all changes made are non-destructive to the quality of > any generated seed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (RNG-75) Improve the speed of the RandomSource create method.
[ https://issues.apache.org/jira/browse/RNG-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex D Herbert updated RNG-75: -- Attachment: (was: small.jpg) > Improve the speed of the RandomSource create method. > > > Key: RNG-75 > URL: https://issues.apache.org/jira/browse/RNG-75 > Project: Commons RNG > Issue Type: Improvement > Components: simple >Affects Versions: 1.3 >Reporter: Alex D Herbert >Assignee: Alex D Herbert >Priority: Minor > Fix For: 1.3 > > Attachments: long.jpg > > > Update the {{o.a.c.rng.simple.internal}} package to improve the construction > speed of random generators. > Areas identified by the construction benchmark > [RNG-72|https://issues.apache.org/jira/projects/RNG/issues/RNG-72] include: > * Update the {{RandomSourceInternal}} to know the desired size for the native > seed > * Update the {{SeedFactory}} for faster {{byte[]}} conversions > * Remove the use of reflection for fast seeding generators > It is intended that all changes made are non-destructive to the quality of > any generated seed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (RNG-75) Improve the speed of the RandomSource create method.
[ https://issues.apache.org/jira/browse/RNG-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex D Herbert updated RNG-75: -- Attachment: (was: large.jpg) > Improve the speed of the RandomSource create method. > > > Key: RNG-75 > URL: https://issues.apache.org/jira/browse/RNG-75 > Project: Commons RNG > Issue Type: Improvement > Components: simple >Affects Versions: 1.3 >Reporter: Alex D Herbert >Assignee: Alex D Herbert >Priority: Minor > Fix For: 1.3 > > Attachments: long.jpg > > > Update the {{o.a.c.rng.simple.internal}} package to improve the construction > speed of random generators. > Areas identified by the construction benchmark > [RNG-72|https://issues.apache.org/jira/projects/RNG/issues/RNG-72] include: > * Update the {{RandomSourceInternal}} to know the desired size for the native > seed > * Update the {{SeedFactory}} for faster {{byte[]}} conversions > * Remove the use of reflection for fast seeding generators > It is intended that all changes made are non-destructive to the quality of > any generated seed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (BCEL-318) Add org.apache.bcel.classfile.ConstantUtf8.clearCache().
Gary Gregory created BCEL-318: - Summary: Add org.apache.bcel.classfile.ConstantUtf8.clearCache(). Key: BCEL-318 URL: https://issues.apache.org/jira/browse/BCEL-318 Project: Commons BCEL Issue Type: New Feature Reporter: Gary Gregory Assignee: Gary Gregory Add {{org.apache.bcel.classfile.ConstantUtf8.clearCache()}}. There was previously no way to clear the cache. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (RNG-75) Improve the speed of the RandomSource create method.
[ https://issues.apache.org/jira/browse/RNG-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex D Herbert updated RNG-75: -- Attachment: small.jpg long.jpg large.jpg > Improve the speed of the RandomSource create method. > > > Key: RNG-75 > URL: https://issues.apache.org/jira/browse/RNG-75 > Project: Commons RNG > Issue Type: Improvement > Components: simple >Affects Versions: 1.3 >Reporter: Alex D Herbert >Assignee: Alex D Herbert >Priority: Minor > Fix For: 1.3 > > Attachments: large.jpg, long.jpg, small.jpg > > > Update the {{o.a.c.rng.simple.internal}} package to improve the construction > speed of random generators. > Areas identified by the construction benchmark > [RNG-72|https://issues.apache.org/jira/projects/RNG/issues/RNG-72] include: > * Update the {{RandomSourceInternal}} to know the desired size for the native > seed > * Update the {{SeedFactory}} for faster {{byte[]}} conversions > * Remove the use of reflection for fast seeding generators > It is intended that all changes made are non-destructive to the quality of > any generated seed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CODEC-253) Upgrade to Java 8
[ https://issues.apache.org/jira/browse/CODEC-253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory resolved CODEC-253. Resolution: Fixed > Upgrade to Java 8 > - > > Key: CODEC-253 > URL: https://issues.apache.org/jira/browse/CODEC-253 > Project: Commons Codec > Issue Type: Improvement >Reporter: Rob Tompkins >Assignee: Rob Tompkins >Priority: Major > Fix For: 1.13 > > > Upgrade to java 8 as the target of of the build. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CODEC-253) Upgrade to Java 8
[ https://issues.apache.org/jira/browse/CODEC-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16854488#comment-16854488 ] Gary Gregory commented on CODEC-253: [~melloware]: Yes, IMO, we can close this; YMMV. [~michael-o]: The comment https://issues.apache.org/jira/browse/CODEC-253?focusedCommentId=16761022&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16761022: {quote}Java 7 still receives updates, many commercial vendors will provide updates too. {quote} is to me a reason _against_ staying on Java 7. We cannot get these updates, only companies that pay for Java 7 commercial support (from Oracle) get them. So we have to way to know if newer "private" versions of Java 7 work or break for us. Granted this is an unlikely case, but I do see why, as a FOSS organization we should support Java 7 when support is only offered to paid customers. > Upgrade to Java 8 > - > > Key: CODEC-253 > URL: https://issues.apache.org/jira/browse/CODEC-253 > Project: Commons Codec > Issue Type: Improvement >Reporter: Rob Tompkins >Assignee: Rob Tompkins >Priority: Major > Fix For: 1.13 > > > Upgrade to java 8 as the target of of the build. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-rng] coveralls commented on issue #46: Update ProviderBuilder factory methods
coveralls commented on issue #46: Update ProviderBuilder factory methods URL: https://github.com/apache/commons-rng/pull/46#issuecomment-498219127 [![Coverage Status](https://coveralls.io/builds/23755787/badge)](https://coveralls.io/builds/23755787) Coverage increased (+0.07%) to 98.821% when pulling **730b217ab8ccb86032d46d9eba4bb087c2fd3f6e on aherbert:improvement-RNG-75** into **0bda14cc5fc04155f8d1d2c4eeb8d1e1dd6160a3 on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-rng] coveralls commented on issue #46: Update ProviderBuilder factory methods
coveralls commented on issue #46: Update ProviderBuilder factory methods URL: https://github.com/apache/commons-rng/pull/46#issuecomment-498219122 [![Coverage Status](https://coveralls.io/builds/23755787/badge)](https://coveralls.io/builds/23755787) Coverage increased (+0.07%) to 98.821% when pulling **730b217ab8ccb86032d46d9eba4bb087c2fd3f6e on aherbert:improvement-RNG-75** into **0bda14cc5fc04155f8d1d2c4eeb8d1e1dd6160a3 on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-rng] aherbert opened a new pull request #46: Update ProviderBuilder factory methods
aherbert opened a new pull request #46: Update ProviderBuilder factory methods URL: https://github.com/apache/commons-rng/pull/46 This rearranges the internals of the ProviderBuilder. This achieves the following goals: - Allow each RandomSource to know it's own array seed length - Allow each RandomSource to be able to override the default seed creation path The second point is to support generators with specific seeding requirements, e.g. do not allow all zero bytes. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Work logged] (IMAGING-228) Remove private method PhotometricInterpreterLogLuv#cube by Math.pow
[ https://issues.apache.org/jira/browse/IMAGING-228?focusedWorklogId=253029&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-253029 ] ASF GitHub Bot logged work on IMAGING-228: -- Author: ASF GitHub Bot Created on: 03/Jun/19 10:03 Start Date: 03/Jun/19 10:03 Worklog Time Spent: 10m Work Description: kinow commented on issue #44: [IMAGING-228] Drop cube method and add unit tests for PhotometricInterpretationLogLuv URL: https://github.com/apache/commons-imaging/pull/44#issuecomment-498194530 `oraclejdk8` is failing, but looks to be related to https://travis-ci.community/t/the-travis-ci-build-could-not-be-completed-due-to-an-error/1345 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 253029) Time Spent: 10m Remaining Estimate: 0h > Remove private method PhotometricInterpreterLogLuv#cube by Math.pow > --- > > Key: IMAGING-228 > URL: https://issues.apache.org/jira/browse/IMAGING-228 > Project: Commons Imaging > Issue Type: Improvement >Reporter: Bruno P. Kinoshita >Assignee: Bruno P. Kinoshita >Priority: Minor > Fix For: 1.0-alpha2 > > Time Spent: 10m > Remaining Estimate: 0h > > We have a private method in PhotometricInterpreterLogLuv, that calculates the > cube of a number N doing N * N * N. That can be replaced by Math.pow(N, 3). > Will add unit tests and some javadocs around photometric interpreters, > logluv, cei, lab, color spaces, ceixyz-ceilab, etc, as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-imaging] kinow commented on issue #44: [IMAGING-228] Drop cube method and add unit tests for PhotometricInterpretationLogLuv
kinow commented on issue #44: [IMAGING-228] Drop cube method and add unit tests for PhotometricInterpretationLogLuv URL: https://github.com/apache/commons-imaging/pull/44#issuecomment-498194530 `oraclejdk8` is failing, but looks to be related to https://travis-ci.community/t/the-travis-ci-build-could-not-be-completed-due-to-an-error/1345 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (IMAGING-221) updateExifMetadataLossless restructures meta data (and problems with Maker Notes)
[ https://issues.apache.org/jira/browse/IMAGING-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16854429#comment-16854429 ] Bruno P. Kinoshita commented on IMAGING-221: >The input to producing the file "mine-gps.jpg" is, perhaps, the file >"mine-original.jpg" which does not contain description and UserComment fields? Hi [~joakimk]! Unfortunately I don't have the workspace anymore (preparing laptop for overseas trip). But I don't remember having issues with the GPS coordinates. It all seemed to have worked fine for me. I may have added some comment with confusing wording, or attached the wrong file. > updateExifMetadataLossless restructures meta data (and problems with Maker > Notes) > - > > Key: IMAGING-221 > URL: https://issues.apache.org/jira/browse/IMAGING-221 > Project: Commons Imaging > Issue Type: Bug >Reporter: Joakim Knudsen >Assignee: Bruno P. Kinoshita >Priority: Major > Fix For: 1.0-alpha2 > > Attachments: mine-gps.JPG, mine-metadata.JPG, mine-original.JPG, > mine.JPG, mine.JPG.html, original.JPG, original.html, tagsmissing.png, > test.JPG, test.html > > > ExifRewriter's *updateExifMetadataLossless* method causes the meta data of > the JPEG to be completely reordered after writing. This, in itself, might not > be a big concern, but it's a bit unexpected when the method is named > "lossless". More worryingly, I also find problems are introduced wrt. the > Maker Notes tag (odd offset). > I've produced an example of the problem in the attached JPEG file, using > ExifTool to validate/analyze the images before and after. The image is taken > by a Sony Xperia Z5 phone, and the "original.JPG" validates OK. After > modifying the contents of the UserComments tag (value: "Test") the modified > image produces a warning: > Verifying the attached photo using ExifTool gives the following output: > $ ./exiftool\(-k\).exe -validate -warning -a ../test.JPG > -- press RETURN -- > > Validate : 1 Warning (all minor) > Warning : [minor] Possibly incorrect maker notes > offsets (fix by -628?) > > Using ExifTool's -htmldump option, it is easy to see how the meta data has > been affected. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IMAGING-228) Remove private method PhotometricInterpreterLogLuv#cube by Math.pow
Bruno P. Kinoshita created IMAGING-228: -- Summary: Remove private method PhotometricInterpreterLogLuv#cube by Math.pow Key: IMAGING-228 URL: https://issues.apache.org/jira/browse/IMAGING-228 Project: Commons Imaging Issue Type: Improvement Reporter: Bruno P. Kinoshita Assignee: Bruno P. Kinoshita Fix For: 1.0-alpha2 We have a private method in PhotometricInterpreterLogLuv, that calculates the cube of a number N doing N * N * N. That can be replaced by Math.pow(N, 3). Will add unit tests and some javadocs around photometric interpreters, logluv, cei, lab, color spaces, ceixyz-ceilab, etc, as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-imaging] kinow opened a new pull request #44: Drop cube function add tests
kinow opened a new pull request #44: Drop cube function add tests URL: https://github.com/apache/commons-imaging/pull/44 Noticed that the `PhotometricInterpretaterLogLuv` had no coverage, so decided to write some simple unit tests. Then found a `cube` method that can be replaced by `Math.pow(N, 3)`, and also that there is no javadocs about what is XYZ, why LAB, what is CIE, or even what is Photometric Interpretation. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-imaging] kinow commented on issue #44: Drop cube function add tests
kinow commented on issue #44: Drop cube function add tests URL: https://github.com/apache/commons-imaging/pull/44#issuecomment-498155651 Just need to finish the unit tests to promote to PR. Draft for now. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services