[jira] [Updated] (COLLECTIONS-285) TreeBidiMap should implement Serializable
[ https://issues.apache.org/jira/browse/COLLECTIONS-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Gruenberg updated COLLECTIONS-285: Attachment: TreeBidiMap.patch Patch with the serialisation with writeObject and readObject-methods > TreeBidiMap should implement Serializable > - > > Key: COLLECTIONS-285 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-285 > Project: Commons Collections > Issue Type: Improvement > Components: BidiMap >Affects Versions: 3.2 >Reporter: Geert Pante > Fix For: 4.0 > > Attachments: COLLECTIONS_285.diff, COLLECTIONS-285.patch, > TreeBidiMap.patch > > > TreeBidiMap does not implement Serializable. DualTreeBidiMap does. > It's just a matter of checking which fields should be transient and done. > In fact, all Maps should be Serializable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COMPRESS-214) better support for unix symlinks
[
https://issues.apache.org/jira/browse/COMPRESS-214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13557988#comment-13557988
]
Stefan Bodewig commented on COMPRESS-214:
-
Sorry, I'm a bit late, but a few comments:
I guess the symlinks are likely written using the same encoding that is used
for filenames. ZipFile already has support for that, it might be better to
simply reuse that than default to UTF-8. In fact it might be better to move
the whole getUnixSymlink to ZipFile For the ZipInputStreamCase a combination
of ZipEncoding#decode and reading thwo full content of the entry should work as
well.
Anyway, nice addition, thanks.
> better support for unix symlinks
>
>
> Key: COMPRESS-214
> URL: https://issues.apache.org/jira/browse/COMPRESS-214
> Project: Commons Compress
> Issue Type: Improvement
> Components: Archivers
>Reporter: Julius Davies
>Assignee: Julius Davies
>Priority: Minor
> Fix For: 1.5
>
> Attachments: COMPRESS-214.patch, COMPRESS-214_unix_symlinks.zip
>
>
> The current API is a little awkward when dealing with symlinks (e.g., those
> created using Info-Zip's "zip -y").
> I propose the following three methods for ZipArchiveEntry:
> {noformat}
> public boolean isUnixSymlink()
> public String getUnixSymlink(ZipFile zf)
> public String getUnixSymlink(ZipFile zf, String pathCharset)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COMPRESS-215) ZipFile reads up to 64KiB in a sequence of one byte reads
[ https://issues.apache.org/jira/browse/COMPRESS-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13557990#comment-13557990 ] Stefan Bodewig commented on COMPRESS-215: - As long as the ZIP format doesn't change your solution should work and in fact speed up reading Zip32 archives, thanks! > ZipFile reads up to 64KiB in a sequence of one byte reads > - > > Key: COMPRESS-215 > URL: https://issues.apache.org/jira/browse/COMPRESS-215 > Project: Commons Compress > Issue Type: Improvement > Components: Archivers >Affects Versions: 1.4.1 > Environment: JDK 1.7 64-bit, Windows 7 >Reporter: Robin Power >Priority: Minor > Attachments: COMPRESS-215.patch > > > This relates to a performance improvement. > When ZipFile is parsing a file it searches for the ZIP64 End Of Central > Directory Locator as a first step to determining if the file is ZIP64 or > regular 32 bit. It searches in reverse for the ZIP64 EOCDL signature from the > end of the file reading one byte at a time, potentially up to about 64KiB. > This can be an expensive operation, especially if it is not a ZIP64 file, as > it will make over 64000 file reads to determine that the file is not ZIP64. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-930) SimplexSolver finds suboptimal solution or throws NoFeasibleSolutionException
[
https://issues.apache.org/jira/browse/MATH-930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart resolved MATH-930.
--
Resolution: Fixed
Fix Version/s: 3.2
I have added more elaborate information about convergence criteria to the class
javadoc of SimplexSolver and added an additional constructor to override the
epsilon value.
As your problem seems to work fine with an epsilon value of 1e-4, no further
changes are required imho.
After discussion on the mailinglist, the non-deterministic behavior, resulting
in different results / exceptions is actually good and should give the user a
hint that the current convergence criteria may be too strict.
Thanks for the report, your problem has been added as a unit test.
> SimplexSolver finds suboptimal solution or throws NoFeasibleSolutionException
> -
>
> Key: MATH-930
> URL: https://issues.apache.org/jira/browse/MATH-930
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.1.1
>Reporter: Konstantin
>Priority: Minor
> Fix For: 3.2
>
> Attachments: exception.txt, program.7z, test.m
>
>
> When I run this code sometimes I get NoFeasibleSolutionException, and
> sometimes the result is 0.37522987682323883.
> Octave gives result 0.70679 and a point = {1.59032, 1.0, 0.70679,
> 0.40399, 1.04004, 0.67396, 0.37868, 0.22823, 0.98909, 0.68793, 0.17021,
> 0.09192, 0.67501, 0.44573, 0.07829, 0.0, 0.81316, 0.63520, 0.55634
> 0.40399, 0.48504, 0.45944, 0.22823, 0.22823, 0.34873, 0.32313, 0.09192,
> 0.09192, 0.25681, 0.23122, 0.0, 0.0, 1.59032
> double[][] coefficients = new double[97][];
> double[] value = new double[97];
> Relationship[] relationship = new Relationship[97];
> int i = 0;
> double[] m0 = {1, -1, -1, 1, -1, 1, 1, -1, -1, 1, 1, -1, 1, -1, -1,
> 1, -1, 1, 1, -1, 1, -1, -1, 1, 1, -1, -1, 1, -1, 1, 1, -1, 0};
> coefficients[i] = m0;
> relationship[i] = Relationship.GEQ;
> value[i] = 0.0;
> i++;
> double[] m1 = {1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, -1};
> coefficients[i] = m1;
> relationship[i] = Relationship.GEQ;
> value[i] = 0.0;
> i++;
> double[] m2 = {1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, -1};
> coefficients[i] = m2;
> relationship[i] = Relationship.LEQ;
> value[i] = 0.0;
> i++;
> double[] m3 = {0, 1, 0, -1, 0, -1, 0, 1, 0, -1, 0, 1, 0, 1, 0, -1,
> 0, -1, 0, 1, 0, 1, 0, -1, 0, 1, 0, -1, 0, -1, 0, 1, 0};
> coefficients[i] = m3;
> relationship[i] = Relationship.GEQ;
> value[i] = 0.0;
> i++;
> double[] m4 = {0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, -0.628803};
> coefficients[i] = m4;
> relationship[i] = Relationship.GEQ;
> value[i] = 0.0;
> i++;
> double[] m5 = {0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, -0.676993};
> coefficients[i] = m5;
> relationship[i] = Relationship.LEQ;
> value[i] = 0.0;
> i++;
> double[] m6 = {0, 0, 1, -1, 0, 0, -1, 1, 0, 0, -1, 1, 0, 0, 1, -1,
> 0, 0, -1, 1, 0, 0, 1, -1, 0, 0, 1, -1, 0, 0, -1, 1, 0};
> coefficients[i] = m6;
> relationship[i] = Relationship.GEQ;
> value[i] = 0.0;
> i++;
> double[] m7 = {0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, -0.136677};
> coefficients[i] = m7;
> relationship[i] = Relationship.GEQ;
> value[i] = 0.0;
> i++;
> double[] m8 = {0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, -0.34};
> coefficients[i] = m8;
> relationship[i] = Relationship.LEQ;
> value[i] = 0.0;
> i++;
> double[] m9 = {0, 0, 0, 1, 0, 0, 0, -1, 0, 0, 0, -1, 0, 0, 0, 1, 0,
> 0, 0, -1, 0, 0, 0, 1, 0, 0, 0, 1, 0, 0, 0, -1, 0};
> coefficients[i] = m9;
> relationship[i] = Relationship.GEQ;
> value[i] = 0.0;
> i++;
> double[] m10 = {0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, -0.254028};
> coefficients[i] = m10;
> relationship[i] = Relationship.GEQ;
> value[i] = 0.0;
> i++;
> double[] m11 = {0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, -0.302218};
> coefficients[i] = m11;
> relationship[i] = Relation
[jira] [Resolved] (COMPRESS-215) ZipFile reads up to 64KiB in a sequence of one byte reads
[ https://issues.apache.org/jira/browse/COMPRESS-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig resolved COMPRESS-215. - Resolution: Fixed Fix Version/s: 1.5 svn revision 1435549 contains a change based on your patch. > ZipFile reads up to 64KiB in a sequence of one byte reads > - > > Key: COMPRESS-215 > URL: https://issues.apache.org/jira/browse/COMPRESS-215 > Project: Commons Compress > Issue Type: Improvement > Components: Archivers >Affects Versions: 1.4.1 > Environment: JDK 1.7 64-bit, Windows 7 >Reporter: Robin Power >Priority: Minor > Fix For: 1.5 > > Attachments: COMPRESS-215.patch > > > This relates to a performance improvement. > When ZipFile is parsing a file it searches for the ZIP64 End Of Central > Directory Locator as a first step to determining if the file is ZIP64 or > regular 32 bit. It searches in reverse for the ZIP64 EOCDL signature from the > end of the file reading one byte at a time, potentially up to about 64KiB. > This can be an expensive operation, especially if it is not a ZIP64 file, as > it will make over 64000 file reads to determine that the file is not ZIP64. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COMPRESS-54) Add 7zip or RAR archive support
[ https://issues.apache.org/jira/browse/COMPRESS-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13557999#comment-13557999 ] Stefan Bodewig commented on COMPRESS-54: I'm not aware of anybody working on it. "XZ for Java" http://tukaani.org/xz/java.html which we already use for XZ compression likely knows how to do LZMA, I haven't explicitly looked into it, though. > Add 7zip or RAR archive support > --- > > Key: COMPRESS-54 > URL: https://issues.apache.org/jira/browse/COMPRESS-54 > Project: Commons Compress > Issue Type: New Feature > Components: Archivers > Environment: N/A >Reporter: Tim Pinet >Priority: Minor > Original Estimate: 30h > Remaining Estimate: 30h > > Has anyone looked into adding support for 7zip and RAR file types? Using the > j7zip and junrar libraries I was able to get a rough protoype working with > commons-compress but only with extract support for RAR (due to licencing > issues). Also, my prototype performance is poor so I definately need to > improve it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-158) Add Codec, StringCodec, and BinaryCodec interfaces that extend both encoder and decoder
[
https://issues.apache.org/jira/browse/CODEC-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13558006#comment-13558006
]
Thomas Neidhart commented on CODEC-158:
---
I am in favor of integrating this change as it makes sense and is quite useful
as Mirko pointed out in his example.
Regarding the name, what do you think of the following:
* [Binary, String]Coder
* [Binary, String]Endec (see http://en.wikipedia.org/wiki/Endec)
> Add Codec, StringCodec, and BinaryCodec interfaces that extend both encoder
> and decoder
> ---
>
> Key: CODEC-158
> URL: https://issues.apache.org/jira/browse/CODEC-158
> Project: Commons Codec
> Issue Type: Improvement
>Affects Versions: 1.7
>Reporter: Mirko Raner
>Priority: Minor
> Attachments: CODEC-158.patch, CODEC-158.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Currently, there are no common interfaces that extend both the encoder and
> the decoder interfaces. This makes it hard to deal with a codec as a single
> entity and requires separate treatment of encoder and decoder parts.
> For example, let's say you want to develop a storage abstraction that uses an
> encoding. Right now, you would need to write
> class Storage
> {
> @Inject Encoder encoder;
> @Inject Decoder decoder;
> //...
> }
> In practice, encoder and decoder need to match, and most likely both encoder
> and decoder would be bound to the same implementation, like Base64 or
> URLCodec. Because of the lack of a common superinterface they need to be
> specified separately. There are some classes like BaseNCodec that can be used
> to unify some of the encoders and decoders, but they are too specific and
> restrictive.
> Ideally, I would like to write:
> class Storage
> {
> @Inject Codec codec;
> //...
> }
> Assuming that combined encoder/decoder classes like Base64 would implement
> that Codec interface, this could be directly bound to a combined
> encoder/decoder implementation.
> It would be nice if these interfaces were added and the existing codec
> classes (BaseNCodec, Hex, QCodec, QuotedPrintableCodec, URLCodec) could be
> modified to implement these new interfaces.
> I'm happy to contribute a patch if there is interest in this feature.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-907) org.apache.commons.math3.special.Gamma comments have bad characters
[ https://issues.apache.org/jira/browse/MATH-907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13558014#comment-13558014 ] Thomas Neidhart commented on MATH-907: -- It looks like that Konstantin was using the ant build.xml file to compile CM. Why is it there anyway, as nobody of the developers seems to use it anymore, and it may be out-of-date? > org.apache.commons.math3.special.Gamma comments have bad characters > > > Key: MATH-907 > URL: https://issues.apache.org/jira/browse/MATH-907 > Project: Commons Math > Issue Type: Bug > Environment: OS 10.8.2, Java 7 >Reporter: Konstantin Berlin > > [javac] > /math/src/main/java/org/apache/commons/math3/special/Gamma.java:708: warning: > unmappable character for encoding ASCII > [javac] * Returns the value of log ??(a + b) for 1 ??? a, b ??? 2. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COLLECTIONS-322) Adds a Collections wrapper around the w3c NodeList
[ https://issues.apache.org/jira/browse/COLLECTIONS-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13558035#comment-13558035 ] Thomas Vahrst commented on COLLECTIONS-322: --- proposal for an implementation for NodeListAsList, with Junit Tests. > Adds a Collections wrapper around the w3c NodeList > -- > > Key: COLLECTIONS-322 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-322 > Project: Commons Collections > Issue Type: Improvement > Components: List >Reporter: Hasan Diwan >Priority: Minor > Fix For: 4.0 > > Attachments: NodeListAsCollection.java, > TestNodeListAsCollection.java, vcs-diff2762905948687805364.patch > > > org.w3c.dom.NodeList is defined as an "abstract collection of Nodes" and > java.util.List is defined as "An ordered collection (also known as a > sequence). The user of this interface has precise control over where in the > list each element is inserted. The user can access elements by their integer > index (position in the list), and search for elements in the list.". It > seemed similar enough, so I did an implementation of the useful methods, > while throwing the appropriate exception when the method wouldn't make sense. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COLLECTIONS-322) Adds a Collections wrapper around the w3c NodeList
[ https://issues.apache.org/jira/browse/COLLECTIONS-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vahrst updated COLLECTIONS-322: -- Attachment: vcs-diff2762905948687805364.patch > Adds a Collections wrapper around the w3c NodeList > -- > > Key: COLLECTIONS-322 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-322 > Project: Commons Collections > Issue Type: Improvement > Components: List >Reporter: Hasan Diwan >Priority: Minor > Fix For: 4.0 > > Attachments: NodeListAsCollection.java, > TestNodeListAsCollection.java, vcs-diff2762905948687805364.patch > > > org.w3c.dom.NodeList is defined as an "abstract collection of Nodes" and > java.util.List is defined as "An ordered collection (also known as a > sequence). The user of this interface has precise control over where in the > list each element is inserted. The user can access elements by their integer > index (position in the list), and search for elements in the list.". It > seemed similar enough, so I did an implementation of the useful methods, > while throwing the appropriate exception when the method wouldn't make sense. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (COLLECTIONS-322) Adds a Collections wrapper around the w3c NodeList
[
https://issues.apache.org/jira/browse/COLLECTIONS-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13558035#comment-13558035
]
Thomas Vahrst edited comment on COLLECTIONS-322 at 1/19/13 3:50 PM:
proposal for an implementation for NodeListAsList, with Junit Tests.
NodeListAsList implements the Unmodifiable interface, because the
org.w3c.NodeList has not support for adding/removing items.
In most cases the org.w3c.NodeList is used to iterate over the children of a
parent node. So it may be a better idea to provide a NodeListUtils class with
methods like
{code}
Iterable NodeListUtils.asIterable(org.w3c.NodeList)
Iterable NodeListUtils.getChildNodesAsIterable(org.w3c.NodeList)
{code}
instead of NodeListAsList. NodeListAsList could then be made a private inner
class of NodeListUtils.
was (Author: t.vahrst):
proposal for an implementation for NodeListAsList, with Junit Tests.
> Adds a Collections wrapper around the w3c NodeList
> --
>
> Key: COLLECTIONS-322
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-322
> Project: Commons Collections
> Issue Type: Improvement
> Components: List
>Reporter: Hasan Diwan
>Priority: Minor
> Fix For: 4.0
>
> Attachments: NodeListAsCollection.java,
> TestNodeListAsCollection.java, vcs-diff2762905948687805364.patch
>
>
> org.w3c.dom.NodeList is defined as an "abstract collection of Nodes" and
> java.util.List is defined as "An ordered collection (also known as a
> sequence). The user of this interface has precise control over where in the
> list each element is inserted. The user can access elements by their integer
> index (position in the list), and search for elements in the list.". It
> seemed similar enough, so I did an implementation of the useful methods,
> while throwing the appropriate exception when the method wouldn't make sense.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (COLLECTIONS-322) Adds a Collections wrapper around the w3c NodeList
[
https://issues.apache.org/jira/browse/COLLECTIONS-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13558035#comment-13558035
]
Thomas Vahrst edited comment on COLLECTIONS-322 at 1/19/13 3:52 PM:
proposal for an implementation for NodeListAsList, with Junit Tests.
NodeListAsList implements the Unmodifiable interface, because the
org.w3c.NodeList has not support for adding/removing items.
In most cases the org.w3c.NodeList is used to iterate over the children of a
parent node. So it may be a better idea to provide a NodeListUtils class with
methods like
{code}
Iterable NodeListUtils.asIterable(org.w3c.NodeList)
Iterable NodeListUtils.getChildNodesAsIterable(org.w3c.NodeList)
{code}
instead of providing a 'crippled' List implementation (NodeListAsList).
NodeListAsList could then be made a private inner class of NodeListUtils.
was (Author: t.vahrst):
proposal for an implementation for NodeListAsList, with Junit Tests.
NodeListAsList implements the Unmodifiable interface, because the
org.w3c.NodeList has not support for adding/removing items.
In most cases the org.w3c.NodeList is used to iterate over the children of a
parent node. So it may be a better idea to provide a NodeListUtils class with
methods like
{code}
Iterable NodeListUtils.asIterable(org.w3c.NodeList)
Iterable NodeListUtils.getChildNodesAsIterable(org.w3c.NodeList)
{code}
instead of NodeListAsList. NodeListAsList could then be made a private inner
class of NodeListUtils.
> Adds a Collections wrapper around the w3c NodeList
> --
>
> Key: COLLECTIONS-322
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-322
> Project: Commons Collections
> Issue Type: Improvement
> Components: List
>Reporter: Hasan Diwan
>Priority: Minor
> Fix For: 4.0
>
> Attachments: NodeListAsCollection.java,
> TestNodeListAsCollection.java, vcs-diff2762905948687805364.patch
>
>
> org.w3c.dom.NodeList is defined as an "abstract collection of Nodes" and
> java.util.List is defined as "An ordered collection (also known as a
> sequence). The user of this interface has precise control over where in the
> list each element is inserted. The user can access elements by their integer
> index (position in the list), and search for elements in the list.". It
> seemed similar enough, so I did an implementation of the useful methods,
> while throwing the appropriate exception when the method wouldn't make sense.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COLLECTIONS-322) Adds a Collections wrapper around the w3c NodeList
[ https://issues.apache.org/jira/browse/COLLECTIONS-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vahrst updated COLLECTIONS-322: -- Attachment: (was: vcs-diff2762905948687805364.patch) > Adds a Collections wrapper around the w3c NodeList > -- > > Key: COLLECTIONS-322 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-322 > Project: Commons Collections > Issue Type: Improvement > Components: List >Reporter: Hasan Diwan >Priority: Minor > Fix For: 4.0 > > Attachments: NodeListAsCollection.java, patch.txt, > TestNodeListAsCollection.java > > > org.w3c.dom.NodeList is defined as an "abstract collection of Nodes" and > java.util.List is defined as "An ordered collection (also known as a > sequence). The user of this interface has precise control over where in the > list each element is inserted. The user can access elements by their integer > index (position in the list), and search for elements in the list.". It > seemed similar enough, so I did an implementation of the useful methods, > while throwing the appropriate exception when the method wouldn't make sense. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COLLECTIONS-322) Adds a Collections wrapper around the w3c NodeList
[ https://issues.apache.org/jira/browse/COLLECTIONS-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vahrst updated COLLECTIONS-322: -- Attachment: patch.txt > Adds a Collections wrapper around the w3c NodeList > -- > > Key: COLLECTIONS-322 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-322 > Project: Commons Collections > Issue Type: Improvement > Components: List >Reporter: Hasan Diwan >Priority: Minor > Fix For: 4.0 > > Attachments: NodeListAsCollection.java, patch.txt, > TestNodeListAsCollection.java > > > org.w3c.dom.NodeList is defined as an "abstract collection of Nodes" and > java.util.List is defined as "An ordered collection (also known as a > sequence). The user of this interface has precise control over where in the > list each element is inserted. The user can access elements by their integer > index (position in the list), and search for elements in the list.". It > seemed similar enough, so I did an implementation of the useful methods, > while throwing the appropriate exception when the method wouldn't make sense. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-907) org.apache.commons.math3.special.Gamma comments have bad characters
[ https://issues.apache.org/jira/browse/MATH-907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13558052#comment-13558052 ] Phil Steitz commented on MATH-907: -- The Ant build is there because not all users use maven. A working Ant build is a good thing to have and I am willing to do the (minimal) work to maintain it. If Konstantin or another user having experienced the same problem can confirm the fix, we can resolve this. I think what I committed in r1413060 should have fixed the problem. > org.apache.commons.math3.special.Gamma comments have bad characters > > > Key: MATH-907 > URL: https://issues.apache.org/jira/browse/MATH-907 > Project: Commons Math > Issue Type: Bug > Environment: OS 10.8.2, Java 7 >Reporter: Konstantin Berlin > > [javac] > /math/src/main/java/org/apache/commons/math3/special/Gamma.java:708: warning: > unmappable character for encoding ASCII > [javac] * Returns the value of log ??(a + b) for 1 ??? a, b ??? 2. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-158) Add Codec, StringCodec, and BinaryCodec interfaces that extend both encoder and decoder
[
https://issues.apache.org/jira/browse/CODEC-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13558101#comment-13558101
]
Gary Gregory commented on CODEC-158:
I am not in favor, please see my previous comments.
> Add Codec, StringCodec, and BinaryCodec interfaces that extend both encoder
> and decoder
> ---
>
> Key: CODEC-158
> URL: https://issues.apache.org/jira/browse/CODEC-158
> Project: Commons Codec
> Issue Type: Improvement
>Affects Versions: 1.7
>Reporter: Mirko Raner
>Priority: Minor
> Attachments: CODEC-158.patch, CODEC-158.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Currently, there are no common interfaces that extend both the encoder and
> the decoder interfaces. This makes it hard to deal with a codec as a single
> entity and requires separate treatment of encoder and decoder parts.
> For example, let's say you want to develop a storage abstraction that uses an
> encoding. Right now, you would need to write
> class Storage
> {
> @Inject Encoder encoder;
> @Inject Decoder decoder;
> //...
> }
> In practice, encoder and decoder need to match, and most likely both encoder
> and decoder would be bound to the same implementation, like Base64 or
> URLCodec. Because of the lack of a common superinterface they need to be
> specified separately. There are some classes like BaseNCodec that can be used
> to unify some of the encoders and decoders, but they are too specific and
> restrictive.
> Ideally, I would like to write:
> class Storage
> {
> @Inject Codec codec;
> //...
> }
> Assuming that combined encoder/decoder classes like Base64 would implement
> that Codec interface, this could be directly bound to a combined
> encoder/decoder implementation.
> It would be nice if these interfaces were added and the existing codec
> classes (BaseNCodec, Hex, QCodec, QuotedPrintableCodec, URLCodec) could be
> modified to implement these new interfaces.
> I'm happy to contribute a patch if there is interest in this feature.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-158) Add Codec, StringCodec, and BinaryCodec interfaces that extend both encoder and decoder
[
https://issues.apache.org/jira/browse/CODEC-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13558114#comment-13558114
]
Sebb commented on CODEC-158:
@Gary Please explain how the addition of these interfaces would make it harder
to add generics?
> Add Codec, StringCodec, and BinaryCodec interfaces that extend both encoder
> and decoder
> ---
>
> Key: CODEC-158
> URL: https://issues.apache.org/jira/browse/CODEC-158
> Project: Commons Codec
> Issue Type: Improvement
>Affects Versions: 1.7
>Reporter: Mirko Raner
>Priority: Minor
> Attachments: CODEC-158.patch, CODEC-158.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Currently, there are no common interfaces that extend both the encoder and
> the decoder interfaces. This makes it hard to deal with a codec as a single
> entity and requires separate treatment of encoder and decoder parts.
> For example, let's say you want to develop a storage abstraction that uses an
> encoding. Right now, you would need to write
> class Storage
> {
> @Inject Encoder encoder;
> @Inject Decoder decoder;
> //...
> }
> In practice, encoder and decoder need to match, and most likely both encoder
> and decoder would be bound to the same implementation, like Base64 or
> URLCodec. Because of the lack of a common superinterface they need to be
> specified separately. There are some classes like BaseNCodec that can be used
> to unify some of the encoders and decoders, but they are too specific and
> restrictive.
> Ideally, I would like to write:
> class Storage
> {
> @Inject Codec codec;
> //...
> }
> Assuming that combined encoder/decoder classes like Base64 would implement
> that Codec interface, this could be directly bound to a combined
> encoder/decoder implementation.
> It would be nice if these interfaces were added and the existing codec
> classes (BaseNCodec, Hex, QCodec, QuotedPrintableCodec, URLCodec) could be
> modified to implement these new interfaces.
> I'm happy to contribute a patch if there is interest in this feature.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (BCEL-170) Type.getArgumentTypes() throws ClassFormatException: Invalid method signature: >;)
Hendrik Brummermann created BCEL-170:
Summary: Type.getArgumentTypes() throws ClassFormatException:
Invalid method signature: >;)
Key: BCEL-170
URL: https://issues.apache.org/jira/browse/BCEL-170
Project: Commons BCEL
Issue Type: Bug
Components: Main
Affects Versions: 5.1, 5.2
Reporter: Hendrik Brummermann
for (Attribute attribute : method.getAttributes()) {
if (attribute instanceof Signature) {
Signature sig = (Signature) attribute;
System.out.println("Sig: " + sig.getSignature());
System.out.println("Ret: " + Type.getReturnType(sig.getSignature()));
System.out.println("Prm: " + Type.getArgumentTypes(sig.getSignature()));
}
}
Input: public SampleReturn
method
(SampleMethodParameter param1) {
...
}
Output:
Sig:
(Lnet/sf/sample/SampleMethodParameter;)Lnet/sf/sample/SampleReturn;
Ret: net.sf.sample.SampleReturn;)Lnet/sf/sample/SampleReturn;
at org.apache.bcel.classfile.Utility.typeOfSignature(Utility.java:978)
at org.apache.bcel.generic.Type.getType(Type.java:169)
at org.apache.bcel.generic.Type.getArgumentTypes(Type.java:230)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (BCEL-170) Type.getArgumentTypes() throws ClassFormatException: Invalid method signature: >;)
[
https://issues.apache.org/jira/browse/BCEL-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hendrik Brummermann updated BCEL-170:
-
Description:
{code:java}
for (Attribute attribute : method.getAttributes()) {
if (attribute instanceof Signature) {
Signature sig = (Signature) attribute;
System.out.println("Sig: " + sig.getSignature());
System.out.println("Ret: " + Type.getReturnType(sig.getSignature()));
System.out.println("Prm: " + Type.getArgumentTypes(sig.getSignature()));
}
}
{code}
{code}
Input: public SampleReturn
method
(SampleMethodParameter param1) {
...
}
{code}
Output:
{code}
Sig:
(Lnet/sf/sample/SampleMethodParameter;)Lnet/sf/sample/SampleReturn;
Ret: net.sf.sample.SampleReturn;)Lnet/sf/sample/SampleReturn;
at org.apache.bcel.classfile.Utility.typeOfSignature(Utility.java:978)
at org.apache.bcel.generic.Type.getType(Type.java:169)
at org.apache.bcel.generic.Type.getArgumentTypes(Type.java:230)
{code}
was:
for (Attribute attribute : method.getAttributes()) {
if (attribute instanceof Signature) {
Signature sig = (Signature) attribute;
System.out.println("Sig: " + sig.getSignature());
System.out.println("Ret: " + Type.getReturnType(sig.getSignature()));
System.out.println("Prm: " + Type.getArgumentTypes(sig.getSignature()));
}
}
Input: public SampleReturn
method
(SampleMethodParameter param1) {
...
}
Output:
Sig:
(Lnet/sf/sample/SampleMethodParameter;)Lnet/sf/sample/SampleReturn;
Ret: net.sf.sample.SampleReturn;)Lnet/sf/sample/SampleReturn;
at org.apache.bcel.classfile.Utility.typeOfSignature(Utility.java:978)
at org.apache.bcel.generic.Type.getType(Type.java:169)
at org.apache.bcel.generic.Type.getArgumentTypes(Type.java:230)
> Type.getArgumentTypes() throws ClassFormatException: Invalid method
> signature: >;)
> --
>
> Key: BCEL-170
> URL: https://issues.apache.org/jira/browse/BCEL-170
> Project: Commons BCEL
> Issue Type: Bug
> Components: Main
>Affects Versions: 5.1, 5.2
>Reporter: Hendrik Brummermann
>
> {code:java}
> for (Attribute attribute : method.getAttributes()) {
> if (attribute instanceof Signature) {
> Signature sig = (Signature) attribute;
> System.out.println("Sig: " + sig.getSignature());
> System.out.println("Ret: " + Type.getReturnType(sig.getSignature()));
> System.out.println("Prm: " +
> Type.getArgumentTypes(sig.getSignature()));
> }
> }
> {code}
> {code}
> Input: public SampleReturn
>method
> (SampleMethodParameter param1) {
> ...
>}
> {code}
> Output:
> {code}
> Sig:
> (Lnet/sf/sample/SampleMethodParameter;)Lnet/sf/sample/SampleReturn;
> Ret: net.sf.sample.SampleReturn org.apache.bcel.classfile.ClassFormatException: Invalid method signature:
> >;)Lnet/sf/sample/SampleReturn;
> at org.apache.bcel.classfile.Utility.typeOfSignature(Utility.java:978)
> at org.apache.bcel.generic.Type.getType(Type.java:169)
> at org.apache.bcel.generic.Type.getArgumentTypes(Type.java:230)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-907) org.apache.commons.math3.special.Gamma comments have bad characters
[ https://issues.apache.org/jira/browse/MATH-907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13558137#comment-13558137 ] Konstantin Berlin commented on MATH-907: I can confirm that it compiles without warnings and passes all the unit tests. > org.apache.commons.math3.special.Gamma comments have bad characters > > > Key: MATH-907 > URL: https://issues.apache.org/jira/browse/MATH-907 > Project: Commons Math > Issue Type: Bug > Environment: OS 10.8.2, Java 7 >Reporter: Konstantin Berlin > > [javac] > /math/src/main/java/org/apache/commons/math3/special/Gamma.java:708: warning: > unmappable character for encoding ASCII > [javac] * Returns the value of log ??(a + b) for 1 ??? a, b ??? 2. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-907) org.apache.commons.math3.special.Gamma comments have bad characters
[ https://issues.apache.org/jira/browse/MATH-907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz resolved MATH-907. -- Resolution: Fixed > org.apache.commons.math3.special.Gamma comments have bad characters > > > Key: MATH-907 > URL: https://issues.apache.org/jira/browse/MATH-907 > Project: Commons Math > Issue Type: Bug > Environment: OS 10.8.2, Java 7 >Reporter: Konstantin Berlin > > [javac] > /math/src/main/java/org/apache/commons/math3/special/Gamma.java:708: warning: > unmappable character for encoding ASCII > [javac] * Returns the value of log ??(a + b) for 1 ??? a, b ??? 2. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
