[jira] Updated: (DBCP-286) DBCP does not rollback
[ https://issues.apache.org/jira/browse/DBCP-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Schaible updated DBCP-286: Summary: DBCP does not rollback (was: MAJOR, MAJOR, MAJOR dbcp does not rollback) > DBCP does not rollback > -- > > Key: DBCP-286 > URL: https://issues.apache.org/jira/browse/DBCP-286 > Project: Commons Dbcp > Issue Type: Bug >Affects Versions: 1.2.2 > Environment: maven, gentoo linux, any java version >Reporter: Trenton D. Adams >Priority: Blocker > Original Estimate: 1h > Remaining Estimate: 1h > > DBCP 1.2.2 does not do connection rollbacks. Or, at least the one in maven 2 > repositories does not. I switched back to 1.2.1, and it works great. > I asked about this back in 2005, and it was stated that it did. And, it > does, up until 1.2.2 > http://mail-archives.apache.org/mod_mbox/commons-user/200504.mbox/<425cb254.1020...@pandora.be> -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COMPRESS-67) ZipArchiveInputStream fails to call setSize() when reading archives created by ZipArchiveOutputStream
ZipArchiveInputStream fails to call setSize() when reading archives created by
ZipArchiveOutputStream
-
Key: COMPRESS-67
URL: https://issues.apache.org/jira/browse/COMPRESS-67
Project: Commons Compress
Issue Type: Bug
Reporter: Sebb
ZipArchiveInputStream fails to call setSize() when reading archives created by
ZipArchiveOutputStream
I'm not exactly sure where the problem is - looks to be something to do with:
{code}
getNextZipEntry(){
...
if (!hasDataDescriptor) {
// calls setSize()
} else {
// does not call setSize()
}
{code}
Maybe the DataDescriptor is not being processed, or maybe there is no
descriptor and the flag is set wrongly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (COMPRESS-66) Document null return value of ArchiveInputStream.getNextEntry
[
https://issues.apache.org/jira/browse/COMPRESS-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting resolved COMPRESS-66.
---
Resolution: Fixed
Fix Version/s: 1.0
Assignee: Jukka Zitting
I took the liberty of committing this javadoc fix in revision 760170.
> Document null return value of ArchiveInputStream.getNextEntry
> -
>
> Key: COMPRESS-66
> URL: https://issues.apache.org/jira/browse/COMPRESS-66
> Project: Commons Compress
> Issue Type: Improvement
>Reporter: Jukka Zitting
>Assignee: Jukka Zitting
>Priority: Trivial
> Fix For: 1.0
>
>
> The ArchiveInputStream.getNextEntry method should mention that the return
> value will be null when there are no more entries in the archive stream.
> {noformat}
> Index:
> src/main/java/org/apache/commons/compress/archivers/ArchiveInputStream.java
> ===
> ---
> src/main/java/org/apache/commons/compress/archivers/ArchiveInputStream.java
> (revision 760154)
> +++
> src/main/java/org/apache/commons/compress/archivers/ArchiveInputStream.java
> (working copy)
> @@ -43,8 +43,10 @@
> private static final int BYTE_MASK = 0xFF;
> /**
> - * Returns the next Archive Entry in this Stream.
> - * @return the next entry
> + * Returns the next Archive Entry in this Stream.
> + *
> + * @return the next entry,
> + * or null if there are no more entries
> * @throws IOException if the next entry could not be read
> */
> public abstract ArchiveEntry getNextEntry() throws IOException;
> {noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (COMPRESS-66) Document null return value of ArchiveInputStream.getNextEntry
Document null return value of ArchiveInputStream.getNextEntry
-
Key: COMPRESS-66
URL: https://issues.apache.org/jira/browse/COMPRESS-66
Project: Commons Compress
Issue Type: Improvement
Reporter: Jukka Zitting
Priority: Trivial
The ArchiveInputStream.getNextEntry method should mention that the return value
will be null when there are no more entries in the archive stream.
{noformat}
Index:
src/main/java/org/apache/commons/compress/archivers/ArchiveInputStream.java
===
--- src/main/java/org/apache/commons/compress/archivers/ArchiveInputStream.java
(revision 760154)
+++ src/main/java/org/apache/commons/compress/archivers/ArchiveInputStream.java
(working copy)
@@ -43,8 +43,10 @@
private static final int BYTE_MASK = 0xFF;
/**
- * Returns the next Archive Entry in this Stream.
- * @return the next entry
+ * Returns the next Archive Entry in this Stream.
+ *
+ * @return the next entry,
+ * or null if there are no more entries
* @throws IOException if the next entry could not be read
*/
public abstract ArchiveEntry getNextEntry() throws IOException;
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CONFIGURATION-314) Allow custom separator characters when writing out PropertiesConfiguration
[
https://issues.apache.org/jira/browse/CONFIGURATION-314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger resolved CONFIGURATION-314.
Resolution: Fixed
The fix for CONFIGURATION-371 also fixes the major part of this issue.
{{PropertiesConfigurationLayout}} now also provides a method for setting the
line separator. (Per default the platform-specific line separator is used.)
> Allow custom separator characters when writing out PropertiesConfiguration
> --
>
> Key: CONFIGURATION-314
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-314
> Project: Commons Configuration
> Issue Type: Improvement
> Components: Format
>Affects Versions: 1.5
>Reporter: Kenny MacLeod
>Assignee: Oliver Heger
> Fix For: 1.7
>
>
> While PropertiesConfiguration is tolerant of several different key/value
> separator characters when reading a properties stream, it is hard-wired to
> use an "=" character when writing them out again.
> Can we please have a way to customise this? Seems like a perfect use for the
> PropertiesConfigurationLayout.
> Sadly, because of the way that PropertiesWriter has been implemented, it's
> impossible to extend and override this behaviour without copying large chunks
> of code.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CONFIGURATION-371) Add option to PropertiesConfiguration.PropertiesWriter to enable/disable using whitespace around = separator
[
https://issues.apache.org/jira/browse/CONFIGURATION-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger resolved CONFIGURATION-371.
Resolution: Fixed
Fix Version/s: 1.7
{{PropertiesConfigurationLayout}} now provides methods for setting single
property separators and a global property separator. If the default settings
are used, the original separators are restored.
The user's guide was updated to cover the new features of
{{PropertiesConfigurationLayout}}.
> Add option to PropertiesConfiguration.PropertiesWriter to enable/disable
> using whitespace around = separator
>
>
> Key: CONFIGURATION-371
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-371
> Project: Commons Configuration
> Issue Type: New Feature
> Components: Format
>Affects Versions: 1.6
>Reporter: Mark Anderson
>Assignee: Oliver Heger
> Fix For: 1.7
>
>
> PropertiesConfiguration can read property files where there is no whitespace
> around the property separator (name=value). However, when the same
> configuration is written back to disk whitespace is always used (name =
> value).
> Can an option be added to enable or disable using whitespace when writing
> property files so that the original properties file can be reproduced.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (MATH-251) Improve the Fraction class to avoid overflow problems and increase features
[
https://issues.apache.org/jira/browse/MATH-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Croizet closed MATH-251.
-
> Improve the Fraction class to avoid overflow problems and increase features
> ---
>
> Key: MATH-251
> URL: https://issues.apache.org/jira/browse/MATH-251
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 1.2
> Environment: java version "1.6.0_12"
> Java(TM) SE Runtime Environment (build 1.6.0_12-b04)
> Java HotSpot(TM) Client VM (build 11.2-b01, mixed mode, sharing)
> Windows XP
> Eclipse Ganymede 3.4.1
>Reporter: Benjamin Croizet
>Assignee: Luc Maisonobe
>Priority: Minor
> Fix For: 2.0
>
> Attachments: NewFraction.zip
>
>
> Hello everybody,
> I've improved and extended the _*Fraction*_ class for my personal needs, but
> it could be nice to incorporate it within the _commons-math_ library., either
> by modifying the current _*Fraction*_ class, or by creating a new class which
> could be called _*AdvancedFraction*_ or something like that. I've tried to
> keep all features from the original _*Fraction*_ class.
> {color:green}New features :{color}
> * I needed to avoid overflow problem. As a result, I've changed numerator and
> denominator to _*BigInteger*_ and all associated methods / constructors.
> * I've also added other methods and static fields such as :
> {code:java}
> public String toString()
> public Fraction add(int i)
> public Fraction subtract(int i)
> public Fraction multiply(int i)
> public Fraction divide(int i)
> public Fraction pow(int exponent)
> public double pow(Fraction exponent)
> public BigDecimal bigDecimalValue()
> public Fraction clone()
> public double percentageValue()
> public static Fraction ONE_HALF = new Fraction(1, 2)
> public static Fraction ONE_QUARTER = new Fraction(1, 4){code}
> * I've made sure that the original Junit test within the _*FractionTest*_
> class are all right (I've just commented the overflow tests)
> * I've made sure that checkstyle is all right without any tabs
> {color:red}Obviously, some things need to be reworked or improved :{color}
> * Some methods are still naively implemented, such as
> {code:java}
> public Fraction add(Fraction fraction)
> public Fraction subtract(Fraction fraction)
> {code} because I don't have converted the original _*private Fraction
> addSub(Fraction fraction, boolean isAdd)*_ method.
> * The original _*private Fraction(double value, double epsilon, int
> maxDenominator, int maxIterations)*_ constructor may use _*BigDecimal*_
> instead of _*double*_. I'm not sure it is relevant.
> * Junit tests have to be written with news methods (such as _*pow*_)
> * Some minor adaptations have to be done in the _*FractionFormat*_ class
> (change _*getDenominator()*_ by _*getDenominatorAsInt()*_ for instance)
> You'll find my work in the attached zip file :
> - The _*Fraction*_ and _*FractionTest*_ classes
> - The javadoc generated with public and private fields and methods (to show
> you a complete overview)
> Thank you.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (DBCP-286) MAJOR, MAJOR, MAJOR dbcp does not rollback
[ https://issues.apache.org/jira/browse/DBCP-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12693838#action_12693838 ] Trenton D. Adams edited comment on DBCP-286 at 3/30/09 9:55 AM: We turn autocommit off usually. In this case, it is turned off, which is why I noticed this. I was trying to retrieve a record that had just been inserted, but it wasn't showing up. So, a co-worker mentioned that I might be in a transaction, which would prevent me from seeing the latest records. So, I knew that there was no way that "I" was in the middle of a transaction. So, I decided to do a rollback just after getting the connection, and it then worked. Then i tried 1.2.1, to see if it worked, without my own rollback, and it did. connectionPool.setTestOnBorrow(true); connectionPool.setTestOnReturn(true); test is SELECT 'ping' FROM dual Oh, and autocommit is on by default, but turned off in each classes that gets a connection. -rw-r--r-- 1 trenta trenta 559366 Jul 17 2008 commons-collections-3.1.jar -rw-r--r-- 1 trenta trenta 121757 Mar 27 15:43 commons-dbcp-1.2.2.jar -rw-r--r-- 1 trenta trenta 42492 Jul 17 2008 commons-pool-1.2.jar Java 1.4.2-03, which I assume is JDBC2 > I assume that what you are seeing is when a connection is returned with > readonly=false, automcommit=false, no rollback is > happening in 1.2.2. Correct? Yes, that is what I am seeing. was (Author: trent): We turn autocommit off usually. In this case, it is turned off, which is why I noticed this. I was trying to retrieve a record that had just been inserted, but it wasn't showing up. So, a co-worker mentioned that I might be in a transaction, which would prevent me from seeing the latest records. So, I knew that there was no way that "I" was in the middle of a transaction. So, I decided to do a rollback just after getting the connection, and it then worked. Then i tried 1.2.1, to see if it worked, without my own rollback, and it did. connectionPool.setTestOnBorrow(true); connectionPool.setTestOnReturn(true); Oh, and autocommit is on by default, but turned off in each classes that gets a connection. -rw-r--r-- 1 trenta trenta 559366 Jul 17 2008 commons-collections-3.1.jar -rw-r--r-- 1 trenta trenta 121757 Mar 27 15:43 commons-dbcp-1.2.2.jar -rw-r--r-- 1 trenta trenta 42492 Jul 17 2008 commons-pool-1.2.jar Java 1.4.2-03, which I assume is JDBC2 SELECT 'ping' FROM dual > I assume that what you are seeing is when a connection is returned with > readonly=false, automcommit=false, no rollback is > happening in 1.2.2. Correct? Yes, that is what I am seeing. > MAJOR, MAJOR, MAJOR dbcp does not rollback > -- > > Key: DBCP-286 > URL: https://issues.apache.org/jira/browse/DBCP-286 > Project: Commons Dbcp > Issue Type: Bug >Affects Versions: 1.2.2 > Environment: maven, gentoo linux, any java version >Reporter: Trenton D. Adams >Priority: Blocker > Original Estimate: 1h > Remaining Estimate: 1h > > DBCP 1.2.2 does not do connection rollbacks. Or, at least the one in maven 2 > repositories does not. I switched back to 1.2.1, and it works great. > I asked about this back in 2005, and it was stated that it did. And, it > does, up until 1.2.2 > http://mail-archives.apache.org/mod_mbox/commons-user/200504.mbox/<425cb254.1020...@pandora.be> -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (DBCP-286) MAJOR, MAJOR, MAJOR dbcp does not rollback
[ https://issues.apache.org/jira/browse/DBCP-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12693838#action_12693838 ] Trenton D. Adams edited comment on DBCP-286 at 3/30/09 9:54 AM: We turn autocommit off usually. In this case, it is turned off, which is why I noticed this. I was trying to retrieve a record that had just been inserted, but it wasn't showing up. So, a co-worker mentioned that I might be in a transaction, which would prevent me from seeing the latest records. So, I knew that there was no way that "I" was in the middle of a transaction. So, I decided to do a rollback just after getting the connection, and it then worked. Then i tried 1.2.1, to see if it worked, without my own rollback, and it did. connectionPool.setTestOnBorrow(true); connectionPool.setTestOnReturn(true); Oh, and autocommit is on by default, but turned off in each classes that gets a connection. -rw-r--r-- 1 trenta trenta 559366 Jul 17 2008 commons-collections-3.1.jar -rw-r--r-- 1 trenta trenta 121757 Mar 27 15:43 commons-dbcp-1.2.2.jar -rw-r--r-- 1 trenta trenta 42492 Jul 17 2008 commons-pool-1.2.jar Java 1.4.2-03, which I assume is JDBC2 SELECT 'ping' FROM dual > I assume that what you are seeing is when a connection is returned with > readonly=false, automcommit=false, no rollback is > happening in 1.2.2. Correct? Yes, that is what I am seeing. was (Author: trent): We turn autocommit off usually. In this case, it is turned off, which is why I noticed this. I was trying to retrieve a record that had just been inserted, but it wasn't showing up. So, a co-worker mentioned that I might be in a transaction, which would prevent me from seeing the latest records. So, I knew that there was no way that "I" was in the middle of a transaction. So, I decided to do a rollback just after getting the connection, and it then worked. Then i tried 1.2.1, to see if it worked, without my own rollback, and it did. connectionPool.setTestOnBorrow(true); connectionPool.setTestOnReturn(true); -rw-r--r-- 1 trenta trenta 559366 Jul 17 2008 commons-collections-3.1.jar -rw-r--r-- 1 trenta trenta 121757 Mar 27 15:43 commons-dbcp-1.2.2.jar -rw-r--r-- 1 trenta trenta 42492 Jul 17 2008 commons-pool-1.2.jar Java 1.4.2-03, which I assume is JDBC2 > I assume that what you are seeing is when a connection is returned with > readonly=false, automcommit=false, no rollback is > happening in 1.2.2. Correct? Yes, that is what I am seeing. > MAJOR, MAJOR, MAJOR dbcp does not rollback > -- > > Key: DBCP-286 > URL: https://issues.apache.org/jira/browse/DBCP-286 > Project: Commons Dbcp > Issue Type: Bug >Affects Versions: 1.2.2 > Environment: maven, gentoo linux, any java version >Reporter: Trenton D. Adams >Priority: Blocker > Original Estimate: 1h > Remaining Estimate: 1h > > DBCP 1.2.2 does not do connection rollbacks. Or, at least the one in maven 2 > repositories does not. I switched back to 1.2.1, and it works great. > I asked about this back in 2005, and it was stated that it did. And, it > does, up until 1.2.2 > http://mail-archives.apache.org/mod_mbox/commons-user/200504.mbox/<425cb254.1020...@pandora.be> -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DBCP-286) MAJOR, MAJOR, MAJOR dbcp does not rollback
[ https://issues.apache.org/jira/browse/DBCP-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12693838#action_12693838 ] Trenton D. Adams commented on DBCP-286: --- We turn autocommit off usually. In this case, it is turned off, which is why I noticed this. I was trying to retrieve a record that had just been inserted, but it wasn't showing up. So, a co-worker mentioned that I might be in a transaction, which would prevent me from seeing the latest records. So, I knew that there was no way that "I" was in the middle of a transaction. So, I decided to do a rollback just after getting the connection, and it then worked. Then i tried 1.2.1, to see if it worked, without my own rollback, and it did. connectionPool.setTestOnBorrow(true); connectionPool.setTestOnReturn(true); -rw-r--r-- 1 trenta trenta 559366 Jul 17 2008 commons-collections-3.1.jar -rw-r--r-- 1 trenta trenta 121757 Mar 27 15:43 commons-dbcp-1.2.2.jar -rw-r--r-- 1 trenta trenta 42492 Jul 17 2008 commons-pool-1.2.jar Java 1.4.2-03, which I assume is JDBC2 > I assume that what you are seeing is when a connection is returned with > readonly=false, automcommit=false, no rollback is > happening in 1.2.2. Correct? Yes, that is what I am seeing. > MAJOR, MAJOR, MAJOR dbcp does not rollback > -- > > Key: DBCP-286 > URL: https://issues.apache.org/jira/browse/DBCP-286 > Project: Commons Dbcp > Issue Type: Bug >Affects Versions: 1.2.2 > Environment: maven, gentoo linux, any java version >Reporter: Trenton D. Adams >Priority: Blocker > Original Estimate: 1h > Remaining Estimate: 1h > > DBCP 1.2.2 does not do connection rollbacks. Or, at least the one in maven 2 > repositories does not. I switched back to 1.2.1, and it works great. > I asked about this back in 2005, and it was stated that it did. And, it > does, up until 1.2.2 > http://mail-archives.apache.org/mod_mbox/commons-user/200504.mbox/<425cb254.1020...@pandora.be> -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (COMPRESS-11) Ar doesn't delete correct
[ https://issues.apache.org/jira/browse/COMPRESS-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig resolved COMPRESS-11. Resolution: Fixed svn revision #760032 > Ar doesn't delete correct > - > > Key: COMPRESS-11 > URL: https://issues.apache.org/jira/browse/COMPRESS-11 > Project: Commons Compress > Issue Type: Bug >Reporter: Christian Grobmeier >Assignee: Stefan Bodewig > Fix For: 1.0 > > Attachments: patch-ar-improvement.txt > > > When working on the Testcases i figured out that a deletion from an Ar > Archive is not as successful as it look at first glance. > For example: my bla.ar file contains test1.xml and test2.xml. I delete > test2.xml > The "getNextEntry" Method just delivers test1.xml. Looks correct. > But checking the result file at commandline brings the following: > $> ar -t /tmp/dir26673/bla.ar > test1.xml > test2.xml > vi shows me that there is still the test2.xml entry in the archive, > even when getNextEntry returns null. > Deleting test2.xml and adding test.txt afterward brings the following: > $> ar -t /tmp/dir24825/bla.ar > test.txt > ar: /tmp/dir24825/bla.ar: Inappropriate file type or format -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MATH-251) Improve the Fraction class to avoid overflow problems and increase features
[
https://issues.apache.org/jira/browse/MATH-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luc Maisonobe resolved MATH-251.
Resolution: Fixed
the modifications discussed previously have been included.
Instead of adding methods to the existing FractionFormat class, a dedicated
BigFractionFormat class has been added, since we need different classes to
parse a string and create either a Fraction or a BigFraction depending on the
parser used.
The pow methods have been completely rewritten for efficiency (using an
algorithm in O(ln(n)) instead of O(n) where n is the exponent value). The
underlying integral pow methods have been added to MathUtils as they may be
useful elsewhere.
> Improve the Fraction class to avoid overflow problems and increase features
> ---
>
> Key: MATH-251
> URL: https://issues.apache.org/jira/browse/MATH-251
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 1.2
> Environment: java version "1.6.0_12"
> Java(TM) SE Runtime Environment (build 1.6.0_12-b04)
> Java HotSpot(TM) Client VM (build 11.2-b01, mixed mode, sharing)
> Windows XP
> Eclipse Ganymede 3.4.1
>Reporter: Benjamin Croizet
>Assignee: Luc Maisonobe
>Priority: Minor
> Fix For: 2.0
>
> Attachments: NewFraction.zip
>
>
> Hello everybody,
> I've improved and extended the _*Fraction*_ class for my personal needs, but
> it could be nice to incorporate it within the _commons-math_ library., either
> by modifying the current _*Fraction*_ class, or by creating a new class which
> could be called _*AdvancedFraction*_ or something like that. I've tried to
> keep all features from the original _*Fraction*_ class.
> {color:green}New features :{color}
> * I needed to avoid overflow problem. As a result, I've changed numerator and
> denominator to _*BigInteger*_ and all associated methods / constructors.
> * I've also added other methods and static fields such as :
> {code:java}
> public String toString()
> public Fraction add(int i)
> public Fraction subtract(int i)
> public Fraction multiply(int i)
> public Fraction divide(int i)
> public Fraction pow(int exponent)
> public double pow(Fraction exponent)
> public BigDecimal bigDecimalValue()
> public Fraction clone()
> public double percentageValue()
> public static Fraction ONE_HALF = new Fraction(1, 2)
> public static Fraction ONE_QUARTER = new Fraction(1, 4){code}
> * I've made sure that the original Junit test within the _*FractionTest*_
> class are all right (I've just commented the overflow tests)
> * I've made sure that checkstyle is all right without any tabs
> {color:red}Obviously, some things need to be reworked or improved :{color}
> * Some methods are still naively implemented, such as
> {code:java}
> public Fraction add(Fraction fraction)
> public Fraction subtract(Fraction fraction)
> {code} because I don't have converted the original _*private Fraction
> addSub(Fraction fraction, boolean isAdd)*_ method.
> * The original _*private Fraction(double value, double epsilon, int
> maxDenominator, int maxIterations)*_ constructor may use _*BigDecimal*_
> instead of _*double*_. I'm not sure it is relevant.
> * Junit tests have to be written with news methods (such as _*pow*_)
> * Some minor adaptations have to be done in the _*FractionFormat*_ class
> (change _*getDenominator()*_ by _*getDenominatorAsInt()*_ for instance)
> You'll find my work in the attached zip file :
> - The _*Fraction*_ and _*FractionTest*_ classes
> - The javadoc generated with public and private fields and methods (to show
> you a complete overview)
> Thank you.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
