[jira] [Updated] (MATH-724) RandomDataImpl.nextInt does not distribute uniformly for negative lower bound
[ https://issues.apache.org/jira/browse/MATH-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Hendriks updated MATH-724: - Attachment: math-724.patch math-724.patch: it first scales the [0..1) interval to [0..length), then discretizes it, and finally shifts it to [lower, upper]. It may be a good idea to also add some tests for cases such as [0,3], [3,5], [-3,5], [-5, -3], and see if the distribution of sampled values is uniform. It seems RandomDataTest.testNextInt does this using chiSquare, but since I'm not familiar with that, I'm not sure how to add more tests for the other lower/upper bound pairs... RandomDataImpl.nextInt does not distribute uniformly for negative lower bound - Key: MATH-724 URL: https://issues.apache.org/jira/browse/MATH-724 Project: Commons Math Issue Type: Bug Affects Versions: Nightly Builds Reporter: Dennis Hendriks Attachments: NextIntUniformTest.java, math-724.patch When using the RandomDataImpl.nextInt function to get a uniform sample in a [lower, upper] interval, when the lower value is less than zero, the output is not uniformly distributed, as the lowest value is practically never returned. See the attached NextIntUniformTest.java file. It uses a [-3, 5] interval. For several values between 0 and 1, testNextIntUniform1 prints the return value of RandomDataImpl.nextInt (as double and as int). We see that -2 through 5 are returned several times. The -3 value however, is only returned for 0.0, and is thus under-respresented in the integer samples. The output of test method testNextIntUniform2 also clearly shows that value -3 is never sampled. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-724) RandomDataImpl.nextInt does not distribute uniformly for negative lower bound
[
https://issues.apache.org/jira/browse/MATH-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13168225#comment-13168225
]
Dennis Hendriks commented on MATH-724:
--
I just ran the unit tests with my patch applied, an the following test, in
RandomDataTest:
{code:java}
@Test
public void testNextIntExtremeValues() {
int x = randomData.nextInt(Integer.MIN_VALUE, Integer.MAX_VALUE);
int y = randomData.nextInt(Integer.MIN_VALUE, Integer.MAX_VALUE);
Assert.assertFalse(x == y);
}
{code}
fails, as does testNextLongExtremeValues. Both x and y become equal to
Integer.MIN_VALUE, making x == y to become true, causing the assertion to
fail...
RandomDataImpl.nextInt does not distribute uniformly for negative lower bound
-
Key: MATH-724
URL: https://issues.apache.org/jira/browse/MATH-724
Project: Commons Math
Issue Type: Bug
Affects Versions: Nightly Builds
Reporter: Dennis Hendriks
Attachments: NextIntUniformTest.java, math-724.patch
When using the RandomDataImpl.nextInt function to get a uniform sample in a
[lower, upper] interval, when the lower value is less than zero, the output
is not uniformly distributed, as the lowest value is practically never
returned.
See the attached NextIntUniformTest.java file. It uses a [-3, 5] interval.
For several values between 0 and 1, testNextIntUniform1 prints the return
value of RandomDataImpl.nextInt (as double and as int). We see that -2
through 5 are returned several times. The -3 value however, is only returned
for 0.0, and is thus under-respresented in the integer samples. The output of
test method testNextIntUniform2 also clearly shows that value -3 is never
sampled.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-724) RandomDataImpl.nextInt does not distribute uniformly for negative lower bound
[ https://issues.apache.org/jira/browse/MATH-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13168249#comment-13168249 ] Dennis Hendriks commented on MATH-724: -- Also note that RandomDataImpl.nextUniform uses a similar scale/shift method to transform the range. It may thus suffer from the same failure in case of extreme values... RandomDataImpl.nextInt does not distribute uniformly for negative lower bound - Key: MATH-724 URL: https://issues.apache.org/jira/browse/MATH-724 Project: Commons Math Issue Type: Bug Affects Versions: Nightly Builds Reporter: Dennis Hendriks Attachments: NextIntUniformTest.java, math-724.patch When using the RandomDataImpl.nextInt function to get a uniform sample in a [lower, upper] interval, when the lower value is less than zero, the output is not uniformly distributed, as the lowest value is practically never returned. See the attached NextIntUniformTest.java file. It uses a [-3, 5] interval. For several values between 0 and 1, testNextIntUniform1 prints the return value of RandomDataImpl.nextInt (as double and as int). We see that -2 through 5 are returned several times. The -3 value however, is only returned for 0.0, and is thus under-respresented in the integer samples. The output of test method testNextIntUniform2 also clearly shows that value -3 is never sampled. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (LANG-781) Null-Check to variable Object parameters - ObjectUtils.isAnyNull
Null-Check to variable Object parameters - ObjectUtils.isAnyNull Key: LANG-781 URL: https://issues.apache.org/jira/browse/LANG-781 Project: Commons Lang Issue Type: New Feature Components: lang.* Affects Versions: 3.1 Reporter: Sandro Lehmann Priority: Minor Sometimes it would be very comfortable, to test a few objects to null. Instead of writing if(obj1==null || obj2==null || ...), if there is a method like isAnyNull(obj1, obj2, ...). It is much more readable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-781) Null-Check to variable Object parameters - ObjectUtils.isAnyNull
[ https://issues.apache.org/jira/browse/LANG-781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sandro Lehmann updated LANG-781: Attachment: ObjectUtils.java.patch Null-Check to variable Object parameters - ObjectUtils.isAnyNull Key: LANG-781 URL: https://issues.apache.org/jira/browse/LANG-781 Project: Commons Lang Issue Type: New Feature Components: lang.* Affects Versions: 3.1 Reporter: Sandro Lehmann Priority: Minor Labels: patch Attachments: ObjectUtils.java.patch Sometimes it would be very comfortable, to test a few objects to null. Instead of writing if(obj1==null || obj2==null || ...), if there is a method like isAnyNull(obj1, obj2, ...). It is much more readable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-781) Null-Check to variable Object parameters - ObjectUtils.isAnyNull
[ https://issues.apache.org/jira/browse/LANG-781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sandro Lehmann updated LANG-781: Attachment: ObjectUtilsTest.java.patch Null-Check to variable Object parameters - ObjectUtils.isAnyNull Key: LANG-781 URL: https://issues.apache.org/jira/browse/LANG-781 Project: Commons Lang Issue Type: New Feature Components: lang.* Affects Versions: 3.1 Reporter: Sandro Lehmann Priority: Minor Labels: patch Attachments: ObjectUtils.java.patch, ObjectUtilsTest.java.patch Sometimes it would be very comfortable, to test a few objects to null. Instead of writing if(obj1==null || obj2==null || ...), if there is a method like isAnyNull(obj1, obj2, ...). It is much more readable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (POOL-197) PooledObject: risky init of lastBorrowTime lastReturnTime
[ https://issues.apache.org/jira/browse/POOL-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved POOL-197. -- Resolution: Fixed Fix Version/s: 2.0 PooledObject: risky init of lastBorrowTime lastReturnTime --- Key: POOL-197 URL: https://issues.apache.org/jira/browse/POOL-197 Project: Commons Pool Issue Type: Bug Reporter: Sebb Fix For: 2.0 PooledObject inits lastBorrowTime lastReturnTime (and createTime) using System.currentTimeMillis(). As well as being wasteful to call the System method 3 times, it's possible that the clock will change between invocations. This could result in getActiveTimeMillis() returning non-zero active time even though the object has never been used. Should probably init lastBorrowTime lastReturnTime from createTime. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (POOL-198) LinkedBlockingDeque has some non-private fields, and a package-protected internal method
[ https://issues.apache.org/jira/browse/POOL-198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved POOL-198. -- Resolution: Fixed Fix Version/s: 2.0 Those issues are all side-effects of copying the class from Harmony and only changing things that had to be changed to simplify any future merging of fixes. Given that Harmony is in / heading for the attic then there is scope to make more changes. That said, I'd prefer to minimise those changes as much as possible. I have changed everything that was package package-private to private. I'm not at all convinced that the change was necessary. Users should not be creating classes under any part of the org.apache namespace. However, making the changes doesn't do any harm and takes less time trying to argue the position that the change was pointless. LinkedBlockingDeque has some non-private fields, and a package-protected internal method Key: POOL-198 URL: https://issues.apache.org/jira/browse/POOL-198 Project: Commons Pool Issue Type: Bug Reporter: Sebb Fix For: 2.0 LinkedBlockingDeque has non-private mutable fields first, last and lock - these should be private. Also the method void unlink(NodeE x) is package-protected; it should be private unless there's a very good reason to allow it to be accessed/overridden externally - in which case it the locking conditions need to be documented. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (POOL-196) PooledObject.getActiveTimeMillis() does not synch. access to lastReturnTime and lastBorrowTime
[ https://issues.apache.org/jira/browse/POOL-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved POOL-196. -- Resolution: Fixed Fix Version/s: 2.0 PooledObject.getActiveTimeMillis() does not synch. access to lastReturnTime and lastBorrowTime -- Key: POOL-196 URL: https://issues.apache.org/jira/browse/POOL-196 Project: Commons Pool Issue Type: Bug Reporter: Sebb Fix For: 2.0 The method PooledObject.getActiveTimeMillis() compares lastReturnTime and lastBorrowTime, but is not synchronised; nor are the variables volatile. There are two possible thread issues here: safe publication of the variables, and possible window error when comparing the values. The method needs to be synch. and the fields need to be volatile (or the getters need to be synch.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (POOL-195) Generic[Keyed]ObjectPool.startEvictor() is overrideable yet is called from the ctor
[ https://issues.apache.org/jira/browse/POOL-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved POOL-195. -- Resolution: Fixed Fix Version/s: 2.0 I went with the final option. Generic[Keyed]ObjectPool.startEvictor() is overrideable yet is called from the ctor --- Key: POOL-195 URL: https://issues.apache.org/jira/browse/POOL-195 Project: Commons Pool Issue Type: Bug Reporter: Sebb Fix For: 2.0 The method Generic[Keyed]ObjectPool.startEvictor() is overrideable yet is called from the ctor - this can cause problems with subclasses, as the class may be only partially constructed when the method is invoked. Either the method should be final, or private, or the code could be extracted into a private method called by the ctor. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (POOL-193) It is safer to make org.apache.commons.pool2.impl.GenericObjectPool.evictor volatile
[
https://issues.apache.org/jira/browse/POOL-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Thomas resolved POOL-193.
--
Resolution: Fixed
Fix Version/s: 2.0
I made the method synchronized to align it with GKOP.
It is safer to make org.apache.commons.pool2.impl.GenericObjectPool.evictor
volatile
Key: POOL-193
URL: https://issues.apache.org/jira/browse/POOL-193
Project: Commons Pool
Issue Type: Bug
Affects Versions: Nightly Builds
Environment: Platform: All
Reporter: Samira Tasharofi
Labels: concurrency
Fix For: 2.0
A field of
[org.apache.commons.pool2.impl.GenericObjectPoolT|http://svn.apache.org/repos/asf/!svn/bc/1206499/commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericObjectPool.java]
might need to be synchronized. Field
{{org.apache.commons.pool2.impl.GenericObjectPool.evictor}} is read and
written in method
{{org.apache.commons.pool2.impl.GenericObjectPool.startEvictor(long)}}, which
might be called by multiple threads concurrently. Is there a possibility that
{{org.apache.commons.pool2.impl.GenericObjectPool.startEvictor(long)}} gets
invoked concurrently? Would it be safer to make
{{org.apache.commons.pool2.impl.GenericObjectPool.evictor}} {{volatile}}?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (POOL-190) Add API BaseObjectPool.isOpen()
[ https://issues.apache.org/jira/browse/POOL-190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved POOL-190. -- Resolution: Fixed BOP is still present in 2.0. There is an isClosed() method that can be used. Add API BaseObjectPool.isOpen() --- Key: POOL-190 URL: https://issues.apache.org/jira/browse/POOL-190 Project: Commons Pool Issue Type: New Feature Affects Versions: 1.5.6 Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) Maven home: C:\Java\apache-maven-3.0.3\bin\.. Java version: 1.6.0_24, vendor: Sun Microsystems Inc. Java home: C:\Program Files\Java\jdk1.6.0_24\jre Default locale: en_US, platform encoding: Cp1252 OS name: windows 7, version: 6.1, arch: amd64, family: windows Reporter: Gary D. Gregory Fix For: 2.0 Attachments: isOpen.diff Add API BaseObjectPool.isOpen() -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (POOL-193) It is safer to make org.apache.commons.pool2.impl.GenericObjectPool.evictor volatile
[
https://issues.apache.org/jira/browse/POOL-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13168489#comment-13168489
]
Samira Tasharofi commented on POOL-193:
---
This bug was detected using [Keshmesh | http://keshmesh.cs.illinois.edu] which
is a static tool for finding concurrency bug pattern.
[Keshmesh|http://keshmesh.cs.illinois.edu/] reported the accesses to
{{org.apache.commons.pool2.impl.GenericObjectPool.evictor}} as instances of a
generalized form of the
[VNA00-J|https://www.securecoding.cert.org/confluence/display/java/VNA00-J.+Ensure+visibility+when+accessing+shared+primitive+variables]
bug pattern. We used
{{org.apache.commons.pool2.impl.GenericObjectPool.startEvictor(long)}} as entry
point.
It is safer to make org.apache.commons.pool2.impl.GenericObjectPool.evictor
volatile
Key: POOL-193
URL: https://issues.apache.org/jira/browse/POOL-193
Project: Commons Pool
Issue Type: Bug
Affects Versions: Nightly Builds
Environment: Platform: All
Reporter: Samira Tasharofi
Labels: concurrency
Fix For: 2.0
A field of
[org.apache.commons.pool2.impl.GenericObjectPoolT|http://svn.apache.org/repos/asf/!svn/bc/1206499/commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericObjectPool.java]
might need to be synchronized. Field
{{org.apache.commons.pool2.impl.GenericObjectPool.evictor}} is read and
written in method
{{org.apache.commons.pool2.impl.GenericObjectPool.startEvictor(long)}}, which
might be called by multiple threads concurrently. Is there a possibility that
{{org.apache.commons.pool2.impl.GenericObjectPool.startEvictor(long)}} gets
invoked concurrently? Would it be safer to make
{{org.apache.commons.pool2.impl.GenericObjectPool.evictor}} {{volatile}}?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (POOL-182) Issues with org.apache.commons.pool2.performance. PerformanceTest
[ https://issues.apache.org/jira/browse/POOL-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved POOL-182. -- Resolution: Fixed I merged the proposed match manually. Functional changes were kept. Cosmetic ones were not. Issues with org.apache.commons.pool2.performance. PerformanceTest - Key: POOL-182 URL: https://issues.apache.org/jira/browse/POOL-182 Project: Commons Pool Issue Type: Bug Affects Versions: 2.0 Reporter: Zoltan Farkas Priority: Trivial Fix For: 2.0 Attachments: PerformanceTest.patch Original Estimate: 4h Remaining Estimate: 4h the use volatiles : waiting,complete,totalBorrowTime, totalReturnTime, nrSamples is not correct. for ex the following totalBorrowTime += borrowTime is not atomic resulting in a race condition. one way to fix this is using the java.util.concurent Atomic variants or even better, make these variables members of MyThread and aggregate them at the end of the test, this way there will be no need to use Atomic and thus increasing efficiency, and accuracy of the test of the test. also: private boolean start; needs to be volatile, due to visibility issue. (when updating start other threads might not pick up the value) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (POOL-164) GenericKeyedObjectPoolFactory should be able to load itself from a properties file
[ https://issues.apache.org/jira/browse/POOL-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved POOL-164. -- Resolution: Won't Fix There appears to be little demand for this so I suggest that you implement a helper class to do this for you. If there is sufficient interest and the property names can be agreed then the helper class could be added to the pool distribution. GenericKeyedObjectPoolFactory should be able to load itself from a properties file -- Key: POOL-164 URL: https://issues.apache.org/jira/browse/POOL-164 Project: Commons Pool Issue Type: New Feature Reporter: Mircea Markus Fix For: 2.0 This would be quite handy. Generally pooling configs are not hardcoded, but specified in a config and then passed to the GenericKeyedObjectPoolFactory/GenericObjectPoolFactory. It would be handy to allow a user to load all these configuration from a property file. a new constructor would be needed: GenericKeyedObjectPoolFactory(property) or even better GenericKeyedObjectPoolFactory(URL) Glad to contribute this myself if you find it useful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (POOL-199) GOP/GKOP evict() method is not synchronised and is not thread-safe
GOP/GKOP evict() method is not synchronised and is not thread-safe -- Key: POOL-199 URL: https://issues.apache.org/jira/browse/POOL-199 Project: Commons Pool Issue Type: Bug Affects Versions: 2.0 Reporter: Sebb The evict() method in Pool2 GOP/GKOP classes is not synchronised, yet it relies on accessing and updating the field evictionIterator without any synchronisation. Adding volatile to the field would help with safe publication across threads, but won't address the problem of two evictions running in parallel. AFAICT, two threads running evict() in parallel could operate on the same objects, which will almost certainly cause problems. The evict() method should probably be synchronised, which would also solve the safe publication problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (POOL-200) GOP/GKOP don't consistently use getters to access fields
GOP/GKOP don't consistently use getters to access fields Key: POOL-200 URL: https://issues.apache.org/jira/browse/POOL-200 Project: Commons Pool Issue Type: Bug Affects Versions: 2.0 Reporter: Sebb Priority: Minor The GOP/GKOP classes generally always use getters to read the values of local fields, e.g. maxIdle. However, some fields are accessed directly. The code should be consistent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DIGESTER-158) Use the APT to process Digester Annotations and generate RulesModule instances at compile-time
[
https://issues.apache.org/jira/browse/DIGESTER-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi updated DIGESTER-158:
Fix Version/s: (was: 3.2)
3.3
Use the APT to process Digester Annotations and generate RulesModule
instances at compile-time
--
Key: DIGESTER-158
URL: https://issues.apache.org/jira/browse/DIGESTER-158
Project: Commons Digester
Issue Type: New Feature
Affects Versions: 3.2
Reporter: Simone Tripodi
Assignee: Simone Tripodi
Fix For: 3.3
Using the [APT
Tool|http://download.oracle.com/javase/1,5.0/docs/guide/apt/GettingStarted.html]
it would be possible to process Digester annotations rules and generate
{{RulesModule}} instances at compile time.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-294) Adding FileUtils.byteCountToDisplaySize(long size, boolean useSiUnits)
[
https://issues.apache.org/jira/browse/IO-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13168845#comment-13168845
]
Jean-Noel Rouvignac commented on IO-294:
@Sebb: FileUtils already has this other byteCountToDisplaySize() method, so I
thought it was the right place to add it.
Do you have a class you can suggest for adding this in Commons Lang?
Cheers.
Adding FileUtils.byteCountToDisplaySize(long size, boolean useSiUnits)
--
Key: IO-294
URL: https://issues.apache.org/jira/browse/IO-294
Project: Commons IO
Issue Type: New Feature
Components: Utilities
Affects Versions: 2.1
Reporter: Jean-Noel Rouvignac
Fix For: 2.2
Attachments: FileUtils.java, FileUtilsTest.java
I have written a little Utility method that might benefit Commons IO:
{code}
public class FileUtils {
/**
* Returns a human-readable version of the file size (original is in
bytes). The implementation has the following features:
* ul
* liSupports the SI or IEC units./li
* liSupports I18n/li
* liDisplay a one digit remainder (rounded down if less than 5,
rounded up otherwise)/li
* liOnce the main unit is = 100, drops the remainder which would be
over precision./li
* /ul
*
* @param size The number of bytes.
* @param useSiUnits if false, uses the IEC (International
Electrotechnical Commission) units (powers of 2), else uses SI (International
System of Units)
*units (powers of 10).
* @return A human-readable display value (includes units).
*/
public static String byteCountToDisplaySize(long size, boolean
useSiUnits) {
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-725) use initialized static final arrays, instead of initializing it in constructors
use initialized static final arrays, instead of initializing it in constructors
---
Key: MATH-725
URL: https://issues.apache.org/jira/browse/MATH-725
Project: Commons Math
Issue Type: Improvement
Affects Versions: 2.2
Reporter: Eldar Agalarov
Priority: Minor
The Well PRNG's implementations have arrays iRm1, iRm2, iRm3, i1, i2, i3. All
these arrays are unmodifiable, so we can replace this arrays initialization
block
final int w = 32;
final int r = (k + w - 1) / w;
this.v = new int[r];
this.index = 0;
// precompute indirection index tables. These tables are used for
optimizing access
// they allow saving computations like (j + r - 2) % r with costly
modulo operations
iRm1 = new int[r];
iRm2 = new int[r];
i1 = new int[r];
i2 = new int[r];
i3 = new int[r];
for (int j = 0; j r; ++j) {
iRm1[j] = (j + r - 1) % r;
iRm2[j] = (j + r - 2) % r;
i1[j] = (j + m1) % r;
i2[j] = (j + m2) % r;
i3[j] = (j + m3) % r;
}
with inline initialized static final arrays.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-725) use initialized static final arrays, instead of initializing it in constructors
[
https://issues.apache.org/jira/browse/MATH-725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eldar Agalarov updated MATH-725:
Description:
The Well PRNG's implementations have arrays iRm1, iRm2, iRm3, i1, i2, i3. All
these arrays are unmodifiable, so we can replace this arrays initialization
block
final int w = 32;
final int r = (k + w - 1) / w;
this.v = new int[r];
this.index = 0;
// precompute indirection index tables. These tables are used for
optimizing access
// they allow saving computations like (j + r - 2) % r with costly
modulo operations
iRm1 = new int[r];
iRm2 = new int[r];
i1 = new int[r];
i2 = new int[r];
i3 = new int[r];
for (int j = 0; j r; ++j) {
iRm1[j] = (j + r - 1) % r;
iRm2[j] = (j + r - 2) % r;
i1[j] = (j + m1) % r;
i2[j] = (j + m2) % r;
i3[j] = (j + m3) % r;
}
with inline initialized static final arrays.
This is much faster implementation, freed from unnecessary costly calculations
(such as %).
was:
The Well PRNG's implementations have arrays iRm1, iRm2, iRm3, i1, i2, i3. All
these arrays are unmodifiable, so we can replace this arrays initialization
block
final int w = 32;
final int r = (k + w - 1) / w;
this.v = new int[r];
this.index = 0;
// precompute indirection index tables. These tables are used for
optimizing access
// they allow saving computations like (j + r - 2) % r with costly
modulo operations
iRm1 = new int[r];
iRm2 = new int[r];
i1 = new int[r];
i2 = new int[r];
i3 = new int[r];
for (int j = 0; j r; ++j) {
iRm1[j] = (j + r - 1) % r;
iRm2[j] = (j + r - 2) % r;
i1[j] = (j + m1) % r;
i2[j] = (j + m2) % r;
i3[j] = (j + m3) % r;
}
with inline initialized static final arrays.
use initialized static final arrays, instead of initializing it in
constructors
---
Key: MATH-725
URL: https://issues.apache.org/jira/browse/MATH-725
Project: Commons Math
Issue Type: Improvement
Affects Versions: 2.2
Reporter: Eldar Agalarov
Priority: Minor
Original Estimate: 1h
Remaining Estimate: 1h
The Well PRNG's implementations have arrays iRm1, iRm2, iRm3, i1, i2, i3. All
these arrays are unmodifiable, so we can replace this arrays initialization
block
final int w = 32;
final int r = (k + w - 1) / w;
this.v = new int[r];
this.index = 0;
// precompute indirection index tables. These tables are used for
optimizing access
// they allow saving computations like (j + r - 2) % r with costly
modulo operations
iRm1 = new int[r];
iRm2 = new int[r];
i1 = new int[r];
i2 = new int[r];
i3 = new int[r];
for (int j = 0; j r; ++j) {
iRm1[j] = (j + r - 1) % r;
iRm2[j] = (j + r - 2) % r;
i1[j] = (j + m1) % r;
i2[j] = (j + m2) % r;
i3[j] = (j + m3) % r;
}
with inline initialized static final arrays.
This is much faster implementation, freed from unnecessary costly
calculations (such as %).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-725) use initialized static final arrays, instead of initializing it in constructors
[
https://issues.apache.org/jira/browse/MATH-725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eldar Agalarov updated MATH-725:
Description:
The Well PRNG's implementations have arrays iRm1, iRm2, iRm3, i1, i2, i3. All
these arrays are unmodifiable, so we can replace this arrays initialization
block
final int w = 32;
final int r = (k + w - 1) / w;
this.v = new int[r];
this.index = 0;
// precompute indirection index tables. These tables are used for
optimizing access
// they allow saving computations like (j + r - 2) % r with costly
modulo operations
iRm1 = new int[r];
iRm2 = new int[r];
i1 = new int[r];
i2 = new int[r];
i3 = new int[r];
for (int j = 0; j r; ++j) {
iRm1[j] = (j + r - 1) % r;
iRm2[j] = (j + r - 2) % r;
i1[j] = (j + m1) % r;
i2[j] = (j + m2) % r;
i3[j] = (j + m3) % r;
}
with inline initialized static final arrays.
This is much better and faster implementation, freed from unnecessary costly
calculations (such as %).
was:
The Well PRNG's implementations have arrays iRm1, iRm2, iRm3, i1, i2, i3. All
these arrays are unmodifiable, so we can replace this arrays initialization
block
final int w = 32;
final int r = (k + w - 1) / w;
this.v = new int[r];
this.index = 0;
// precompute indirection index tables. These tables are used for
optimizing access
// they allow saving computations like (j + r - 2) % r with costly
modulo operations
iRm1 = new int[r];
iRm2 = new int[r];
i1 = new int[r];
i2 = new int[r];
i3 = new int[r];
for (int j = 0; j r; ++j) {
iRm1[j] = (j + r - 1) % r;
iRm2[j] = (j + r - 2) % r;
i1[j] = (j + m1) % r;
i2[j] = (j + m2) % r;
i3[j] = (j + m3) % r;
}
with inline initialized static final arrays.
This is much faster implementation, freed from unnecessary costly calculations
(such as %).
use initialized static final arrays, instead of initializing it in
constructors
---
Key: MATH-725
URL: https://issues.apache.org/jira/browse/MATH-725
Project: Commons Math
Issue Type: Improvement
Affects Versions: 2.2
Reporter: Eldar Agalarov
Priority: Minor
Original Estimate: 1h
Remaining Estimate: 1h
The Well PRNG's implementations have arrays iRm1, iRm2, iRm3, i1, i2, i3. All
these arrays are unmodifiable, so we can replace this arrays initialization
block
final int w = 32;
final int r = (k + w - 1) / w;
this.v = new int[r];
this.index = 0;
// precompute indirection index tables. These tables are used for
optimizing access
// they allow saving computations like (j + r - 2) % r with costly
modulo operations
iRm1 = new int[r];
iRm2 = new int[r];
i1 = new int[r];
i2 = new int[r];
i3 = new int[r];
for (int j = 0; j r; ++j) {
iRm1[j] = (j + r - 1) % r;
iRm2[j] = (j + r - 2) % r;
i1[j] = (j + m1) % r;
i2[j] = (j + m2) % r;
i3[j] = (j + m3) % r;
}
with inline initialized static final arrays.
This is much better and faster implementation, freed from unnecessary costly
calculations (such as %).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-725) use initialized static final arrays, instead of initializing it in constructors
[
https://issues.apache.org/jira/browse/MATH-725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eldar Agalarov updated MATH-725:
Description:
The Well PRNG's implementations have arrays iRm1, iRm2, iRm3, i1, i2, i3. All
these arrays are unmodifiable, so we can replace this arrays initialization
block
final int w = 32;
final int r = (k + w - 1) / w;
this.v = new int[r];
this.index = 0;
// precompute indirection index tables. These tables are used for
optimizing access
// they allow saving computations like (j + r - 2) % r with costly
modulo operations
iRm1 = new int[r];
iRm2 = new int[r];
i1 = new int[r];
i2 = new int[r];
i3 = new int[r];
for (int j = 0; j r; ++j) {
iRm1[j] = (j + r - 1) % r;
iRm2[j] = (j + r - 2) % r;
i1[j] = (j + m1) % r;
i2[j] = (j + m2) % r;
i3[j] = (j + m3) % r;
}
with inline initialized static final arrays.
This is much better and faster implementation, freed from unnecessary costly
calculations (such as %).
If you agreed with my proposal, i can make a patch for this issue.
was:
The Well PRNG's implementations have arrays iRm1, iRm2, iRm3, i1, i2, i3. All
these arrays are unmodifiable, so we can replace this arrays initialization
block
final int w = 32;
final int r = (k + w - 1) / w;
this.v = new int[r];
this.index = 0;
// precompute indirection index tables. These tables are used for
optimizing access
// they allow saving computations like (j + r - 2) % r with costly
modulo operations
iRm1 = new int[r];
iRm2 = new int[r];
i1 = new int[r];
i2 = new int[r];
i3 = new int[r];
for (int j = 0; j r; ++j) {
iRm1[j] = (j + r - 1) % r;
iRm2[j] = (j + r - 2) % r;
i1[j] = (j + m1) % r;
i2[j] = (j + m2) % r;
i3[j] = (j + m3) % r;
}
with inline initialized static final arrays.
This is much better and faster implementation, freed from unnecessary costly
calculations (such as %).
use initialized static final arrays, instead of initializing it in
constructors
---
Key: MATH-725
URL: https://issues.apache.org/jira/browse/MATH-725
Project: Commons Math
Issue Type: Improvement
Affects Versions: 2.2
Reporter: Eldar Agalarov
Priority: Minor
Original Estimate: 1h
Remaining Estimate: 1h
The Well PRNG's implementations have arrays iRm1, iRm2, iRm3, i1, i2, i3. All
these arrays are unmodifiable, so we can replace this arrays initialization
block
final int w = 32;
final int r = (k + w - 1) / w;
this.v = new int[r];
this.index = 0;
// precompute indirection index tables. These tables are used for
optimizing access
// they allow saving computations like (j + r - 2) % r with costly
modulo operations
iRm1 = new int[r];
iRm2 = new int[r];
i1 = new int[r];
i2 = new int[r];
i3 = new int[r];
for (int j = 0; j r; ++j) {
iRm1[j] = (j + r - 1) % r;
iRm2[j] = (j + r - 2) % r;
i1[j] = (j + m1) % r;
i2[j] = (j + m2) % r;
i3[j] = (j + m3) % r;
}
with inline initialized static final arrays.
This is much better and faster implementation, freed from unnecessary costly
calculations (such as %).
If you agreed with my proposal, i can make a patch for this issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-725) use initialized static final arrays, instead of initializing it in constructors
[
https://issues.apache.org/jira/browse/MATH-725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eldar Agalarov updated MATH-725:
Description:
The Well PRNG's implementations have arrays iRm1, iRm2, iRm3, i1, i2, i3. All
these arrays are unmodifiable, so we can replace this arrays initialization
block
final int w = 32;
final int r = (k + w - 1) / w;
this.v = new int[r];
this.index = 0;
// precompute indirection index tables. These tables are used for
optimizing access
// they allow saving computations like (j + r - 2) % r with costly
modulo operations
iRm1 = new int[r];
iRm2 = new int[r];
i1 = new int[r];
i2 = new int[r];
i3 = new int[r];
for (int j = 0; j r; ++j) {
iRm1[j] = (j + r - 1) % r;
iRm2[j] = (j + r - 2) % r;
i1[j] = (j + m1) % r;
i2[j] = (j + m2) % r;
i3[j] = (j + m3) % r;
}
with inline initialized static final arrays.
This is much better and faster implementation, freed from unnecessary costly
calculations (such as %).
Another solution: leave as is, but make all these arrays static.
was:
The Well PRNG's implementations have arrays iRm1, iRm2, iRm3, i1, i2, i3. All
these arrays are unmodifiable, so we can replace this arrays initialization
block
final int w = 32;
final int r = (k + w - 1) / w;
this.v = new int[r];
this.index = 0;
// precompute indirection index tables. These tables are used for
optimizing access
// they allow saving computations like (j + r - 2) % r with costly
modulo operations
iRm1 = new int[r];
iRm2 = new int[r];
i1 = new int[r];
i2 = new int[r];
i3 = new int[r];
for (int j = 0; j r; ++j) {
iRm1[j] = (j + r - 1) % r;
iRm2[j] = (j + r - 2) % r;
i1[j] = (j + m1) % r;
i2[j] = (j + m2) % r;
i3[j] = (j + m3) % r;
}
with inline initialized static final arrays.
This is much better and faster implementation, freed from unnecessary costly
calculations (such as %).
If you agreed with my proposal, i can make a patch for this issue.
use initialized static final arrays, instead of initializing it in
constructors
---
Key: MATH-725
URL: https://issues.apache.org/jira/browse/MATH-725
Project: Commons Math
Issue Type: Improvement
Affects Versions: 2.2
Reporter: Eldar Agalarov
Priority: Minor
Original Estimate: 1h
Remaining Estimate: 1h
The Well PRNG's implementations have arrays iRm1, iRm2, iRm3, i1, i2, i3. All
these arrays are unmodifiable, so we can replace this arrays initialization
block
final int w = 32;
final int r = (k + w - 1) / w;
this.v = new int[r];
this.index = 0;
// precompute indirection index tables. These tables are used for
optimizing access
// they allow saving computations like (j + r - 2) % r with costly
modulo operations
iRm1 = new int[r];
iRm2 = new int[r];
i1 = new int[r];
i2 = new int[r];
i3 = new int[r];
for (int j = 0; j r; ++j) {
iRm1[j] = (j + r - 1) % r;
iRm2[j] = (j + r - 2) % r;
i1[j] = (j + m1) % r;
i2[j] = (j + m2) % r;
i3[j] = (j + m3) % r;
}
with inline initialized static final arrays.
This is much better and faster implementation, freed from unnecessary costly
calculations (such as %).
Another solution: leave as is, but make all these arrays static.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DIGESTER-158) Use the APT to process Digester Annotations and generate RulesModule instances at compile-time
[
https://issues.apache.org/jira/browse/DIGESTER-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13168917#comment-13168917
]
Paul Benedict commented on DIGESTER-158:
APT is being removed from Oracle's JDK 8. Does that matter?
Use the APT to process Digester Annotations and generate RulesModule
instances at compile-time
--
Key: DIGESTER-158
URL: https://issues.apache.org/jira/browse/DIGESTER-158
Project: Commons Digester
Issue Type: New Feature
Affects Versions: 3.2
Reporter: Simone Tripodi
Assignee: Simone Tripodi
Fix For: 3.3
Using the [APT
Tool|http://download.oracle.com/javase/1,5.0/docs/guide/apt/GettingStarted.html]
it would be possible to process Digester annotations rules and generate
{{RulesModule}} instances at compile time.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-780) add public org.apache.commons.lang.builder.HashCodeBuilder append(Enum value) to HashCodeBuilder
[
https://issues.apache.org/jira/browse/LANG-780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13168966#comment-13168966
]
Alex Pokotilo commented on LANG-780:
Using Enum#name() means that the same hashCode will be used for different Enum
instances that happen to have the same name.
That seems like quite a disadvantage to me.(c)
Proposed method is just an example and to avoid your concent we can use
something like following
private static int hashCodeForEnum(Enum enumItem)
{ return (enumItem.getClass().getName()+enumItem.name()).hashCode(); }
But again this is just proposal. I think initial point is valid. I want to see
the same hashCode for enum using HashCodeBuilder. This would be great.
add public org.apache.commons.lang.builder.HashCodeBuilder append(Enum
value) to HashCodeBuilder
--
Key: LANG-780
URL: https://issues.apache.org/jira/browse/LANG-780
Project: Commons Lang
Issue Type: New Feature
Components: lang.builder.*
Affects Versions: 2.5
Reporter: Alex Pokotilo
Original Estimate: 2h
Remaining Estimate: 2h
Since Enum's hashCode return different values between calls this can cause
different values if enum appended to HashCodeBuilder
IMHO adding append for enum would be enough to solve this entirely
public org.apache.commons.lang.builder.HashCodeBuilder append(Enum value)
{
append(value.name().hashCode());
return this;
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-717) A varied class of Array2DRowRealMatrix is needed to contain float type instead of double.
[ https://issues.apache.org/jira/browse/MATH-717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13169041#comment-13169041 ] Dusan Ku commented on MATH-717: --- Hi Sébastien, I also agree with you on the downside of float - ugly precision and its workaround. Just like your case, my huge matrices can be generated procedurally, which means no need to store the matrix. I just felt the diversity (or flexibility) of the choice between the matrix dimension and the type size might benefit us (the developers who are using the library). In this way, for some small problems, small enough to test against the full matrices with float type but not possible with double type, we can test the fully generated matrices with float type. double type sometimes does not allow me to test these matrices because the maximum java heap size I could specify under 32-bit OS is somewhere between 1.3G and 1.4G and any attempt over this memory limit throws an OutOfMemory exception. When that happens, my current solution is to make the same classes with float type as the basis. What conclusions can we draw on this issue? Well, for now, let's just assume that there were some opinions like mine regarding the fact that the basic type is fixed to double type. A varied class of Array2DRowRealMatrix is needed to contain float type instead of double. - Key: MATH-717 URL: https://issues.apache.org/jira/browse/MATH-717 Project: Commons Math Issue Type: Improvement Affects Versions: 2.2 Environment: All Reporter: Dusan Ku Labels: features The current implementation of Array2DRowRealMatrix takes only double type as its base element value in the matrix. However, the memory size of double is bigger than float, the downside of which makes the matrix dimension quite limited, compared to float type as its base element type. For small sized problem, this does not make such a big difference, but for large problems, this limits the usability of this library quite severely. In my case, I easily hit an error even after I increase the memory option to 1G. This could have been much more enhanced just by using 'float[][]' instead of the current Array2DRowRealMatrix. Therefore, the solution I may suggest is to add another class similar to Array2DRowRealMatrix containing float type for its matrix variable instead of double. Of course, a better way is welcome as long as the needs can be fulfilled. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-717) A varied class of Array2DRowRealMatrix is needed to contain float type instead of double.
[ https://issues.apache.org/jira/browse/MATH-717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13169059#comment-13169059 ] Sébastien Brisard commented on MATH-717: Hi Dusan, I still think that your proposal deserve that we think about it, let's see what the others say. Implementation of the class you're asking for would be fairly easy. Best regards, Sébastien A varied class of Array2DRowRealMatrix is needed to contain float type instead of double. - Key: MATH-717 URL: https://issues.apache.org/jira/browse/MATH-717 Project: Commons Math Issue Type: Improvement Affects Versions: 2.2 Environment: All Reporter: Dusan Ku Labels: features The current implementation of Array2DRowRealMatrix takes only double type as its base element value in the matrix. However, the memory size of double is bigger than float, the downside of which makes the matrix dimension quite limited, compared to float type as its base element type. For small sized problem, this does not make such a big difference, but for large problems, this limits the usability of this library quite severely. In my case, I easily hit an error even after I increase the memory option to 1G. This could have been much more enhanced just by using 'float[][]' instead of the current Array2DRowRealMatrix. Therefore, the solution I may suggest is to add another class similar to Array2DRowRealMatrix containing float type for its matrix variable instead of double. Of course, a better way is welcome as long as the needs can be fulfilled. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DIGESTER-158) Use the APT to process Digester Annotations and generate RulesModule instances at compile-time
[
https://issues.apache.org/jira/browse/DIGESTER-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13169154#comment-13169154
]
Simone Tripodi commented on DIGESTER-158:
-
AFAIK JDK 8 is not on production systems yet, I would postpone the problem and
provide a temporary solution for today's technology.
that makes me smile anyway - please don't get me wrong! - because in the dev@
ML people are still worried about maintaining JDK3... :)
Use the APT to process Digester Annotations and generate RulesModule
instances at compile-time
--
Key: DIGESTER-158
URL: https://issues.apache.org/jira/browse/DIGESTER-158
Project: Commons Digester
Issue Type: New Feature
Affects Versions: 3.2
Reporter: Simone Tripodi
Assignee: Simone Tripodi
Fix For: 3.3
Using the [APT
Tool|http://download.oracle.com/javase/1,5.0/docs/guide/apt/GettingStarted.html]
it would be possible to process Digester annotations rules and generate
{{RulesModule}} instances at compile time.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
