[jira] [Updated] (MATH-968) Pareto distribution is missing
[ https://issues.apache.org/jira/browse/MATH-968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart updated MATH-968: - Attachment: MATH-968.zip Please find attached a patch that add support for the Pareto distribution. The test values have been created with R (cran modules VGAM contains a pareto distribution), although there seems to be a small bug in the module as the density for x == scale/k is returned as 0. Looking at the wikipedia page or wolfram (http://reference.wolfram.com/mathematica/ref/ParetoDistribution.html) you can see that for this case the density should be 0. So I adapted the test values for this case. Pareto distribution is missing -- Key: MATH-968 URL: https://issues.apache.org/jira/browse/MATH-968 Project: Commons Math Issue Type: New Feature Affects Versions: 3.2 Reporter: Alex Gryzlov Priority: Minor Attachments: MATH-968.zip Seems that org.apache.commons.math3.distribution lacks a ParetoDistribution for some reason. This is a real common type of distribution, so providing it would be very nice! -- 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] (MATH-968) Pareto distribution is missing
[ https://issues.apache.org/jira/browse/MATH-968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13641496#comment-13641496 ] Thomas Neidhart edited comment on MATH-968 at 4/25/13 6:39 AM: --- Please find attached a patch that adds support for the Pareto distribution. The test values have been created with R (cran module VGAM contains a pareto distribution), although there seems to be a small bug in the module as the density for x == scale/k is returned as 0. Looking at the wikipedia page or wolfram (http://reference.wolfram.com/mathematica/ref/ParetoDistribution.html) you can see that for this case the density should be 0. So I adapted the test values for this case. was (Author: tn): Please find attached a patch that add support for the Pareto distribution. The test values have been created with R (cran modules VGAM contains a pareto distribution), although there seems to be a small bug in the module as the density for x == scale/k is returned as 0. Looking at the wikipedia page or wolfram (http://reference.wolfram.com/mathematica/ref/ParetoDistribution.html) you can see that for this case the density should be 0. So I adapted the test values for this case. Pareto distribution is missing -- Key: MATH-968 URL: https://issues.apache.org/jira/browse/MATH-968 Project: Commons Math Issue Type: New Feature Affects Versions: 3.2 Reporter: Alex Gryzlov Priority: Minor Attachments: MATH-968.zip Seems that org.apache.commons.math3.distribution lacks a ParetoDistribution for some reason. This is a real common type of distribution, so providing it would be very nice! -- 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] (LANG-890) Adding equalsIgnoreWhiteSpaces() method to StringUtils
[
https://issues.apache.org/jira/browse/LANG-890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thilak updated LANG-890:
Summary: Adding equalsIgnoreWhiteSpaces() method to StringUtils (was:
Adding {{equalsIgnoreWhiteSpaces()}} method to StringUtils)
Adding equalsIgnoreWhiteSpaces() method to StringUtils
--
Key: LANG-890
URL: https://issues.apache.org/jira/browse/LANG-890
Project: Commons Lang
Issue Type: New Feature
Components: lang.*
Affects Versions: 4.0
Environment: New Feature
Reporter: Thilak
Labels: StringUtil
Fix For: 4.0
Original Estimate: 0h
Remaining Estimate: 0h
Currently, no java uitility package offers a method to compare two strings
which differ only in format white spaces for equality. The common scenario
when we need such a method would be (a) when one needs to perform equality
check between two narrative fields in a SWIFT message or (b) to compare a
paragrapgh retreived from different files.
Please advise on how i can share the code for this new method. thank you
--
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] (LANG-890) Adding {{equalsIgnoreWhiteSpaces()}} method to StringUtils
Thilak created LANG-890:
---
Summary: Adding {{equalsIgnoreWhiteSpaces()}} method to StringUtils
Key: LANG-890
URL: https://issues.apache.org/jira/browse/LANG-890
Project: Commons Lang
Issue Type: New Feature
Components: lang.*
Affects Versions: 4.0
Environment: New Feature
Reporter: Thilak
Fix For: 4.0
Currently, no java uitility package offers a method to compare two strings
which differ only in format white spaces for equality. The common scenario
when we need such a method would be (a) when one needs to perform equality
check between two narrative fields in a SWIFT message or (b) to compare a
paragrapgh retreived from different files.
Please advise on how i can share the code for this new method. thank you
--
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-968) Pareto distribution is missing
[ https://issues.apache.org/jira/browse/MATH-968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13641619#comment-13641619 ] Gilles commented on MATH-968: - Raising the comments formatting issue, again. We agreed that UTF-8 characters can be used. Should we go further and further so as to use them in formulae that translitterates the code implemented? Since the Javadoc is mainly intended for Java programmers, I think that the comment does not need to be excessively beautified. An additional argument is that the (plain) Javadoc will never match the correct (LaTeX) layout, so that we are left with a hybrid: part Java statement syntax, part mathematical notation, part neither (like the caret ^ character when used to represent exponentiation). IMHO, in the class Javadoc, it is enough to use links (to reference sites). If necessary, beautified formulae could be added there (and in the user guide). In a method's Javadoc, I'd tend to stay close to the programming language syntax. Pareto distribution is missing -- Key: MATH-968 URL: https://issues.apache.org/jira/browse/MATH-968 Project: Commons Math Issue Type: New Feature Affects Versions: 3.2 Reporter: Alex Gryzlov Priority: Minor Attachments: MATH-968.zip Seems that org.apache.commons.math3.distribution lacks a ParetoDistribution for some reason. This is a real common type of distribution, so providing it would be very nice! -- 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] (LANG-890) Adding equalsIgnoreWhiteSpaces() method to StringUtils
[ https://issues.apache.org/jira/browse/LANG-890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13641632#comment-13641632 ] Sebb commented on LANG-890: --- bq. Please advise on how i can share the code for this new method. Not exactly sure what you mean by that, but patches (unified diff) are accepted as attachments. However, it might make more sense to provide a method to collapse all whitespace to a single space (should probably also trim leading/trailing whitespace). Do that to both strings and then compare them. I think that would be more generally useful than an equals method, as it would allow both case-sensitive and insensitive natching as well as potentially detecting the first difference etc. There could also be a method to remove all whitespace. That would ignore word-boundaries in comparisons, but would have other uses. Adding equalsIgnoreWhiteSpaces() method to StringUtils -- Key: LANG-890 URL: https://issues.apache.org/jira/browse/LANG-890 Project: Commons Lang Issue Type: New Feature Components: lang.* Affects Versions: 4.0 Environment: New Feature Reporter: Thilak Labels: StringUtil Fix For: 4.0 Original Estimate: 0h Remaining Estimate: 0h Currently, no java uitility package offers a method to compare two strings which differ only in format white spaces for equality. The common scenario when we need such a method would be (a) when one needs to perform equality check between two narrative fields in a SWIFT message or (b) to compare a paragrapgh retreived from different files. Please advise on how i can share the code for this new method. thank you -- 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] (LANG-890) Adding equalsIgnoreWhiteSpaces() method to StringUtils
[
https://issues.apache.org/jira/browse/LANG-890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13641662#comment-13641662
]
Joerg Schaible commented on LANG-890:
-
{quote}
However, it might make more sense to provide a method to collapse all
whitespace to a single space (should probably also trim leading/trailing
whitespace). Do that to both strings and then compare them.
I think that would be more generally useful than an equals method, as it would
allow both case-sensitive and insensitive natching as well as potentially
detecting the first difference etc.
There could also be a method to remove all whitespace.
That would ignore word-boundaries in comparisons, but would have other uses.
{quote}
We have this already:
StringUtils.normalizeSpace();
StringUtils.deleteWhitespace();
Adding equalsIgnoreWhiteSpaces() method to StringUtils
--
Key: LANG-890
URL: https://issues.apache.org/jira/browse/LANG-890
Project: Commons Lang
Issue Type: New Feature
Components: lang.*
Affects Versions: 4.0
Environment: New Feature
Reporter: Thilak
Labels: StringUtil
Fix For: 4.0
Original Estimate: 0h
Remaining Estimate: 0h
Currently, no java uitility package offers a method to compare two strings
which differ only in format white spaces for equality. The common scenario
when we need such a method would be (a) when one needs to perform equality
check between two narrative fields in a SWIFT message or (b) to compare a
paragrapgh retreived from different files.
Please advise on how i can share the code for this new method. thank you
--
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] (LANG-890) Adding equalsIgnoreWhiteSpaces() method to StringUtils
[ https://issues.apache.org/jira/browse/LANG-890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13641670#comment-13641670 ] Sebb commented on LANG-890: --- Oops! In that case, I think this issue should be closed as Won't Fix - I cannot see the point of adding a specific method. The class is already so large that it's easy to overlook methods! Adding equalsIgnoreWhiteSpaces() method to StringUtils -- Key: LANG-890 URL: https://issues.apache.org/jira/browse/LANG-890 Project: Commons Lang Issue Type: New Feature Components: lang.* Affects Versions: 4.0 Environment: New Feature Reporter: Thilak Labels: StringUtil Fix For: 4.0 Original Estimate: 0h Remaining Estimate: 0h Currently, no java uitility package offers a method to compare two strings which differ only in format white spaces for equality. The common scenario when we need such a method would be (a) when one needs to perform equality check between two narrative fields in a SWIFT message or (b) to compare a paragrapgh retreived from different files. Please advise on how i can share the code for this new method. thank you -- 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] (MATH-969) Wrong link on the site
Gilles created MATH-969: --- Summary: Wrong link on the site Key: MATH-969 URL: https://issues.apache.org/jira/browse/MATH-969 Project: Commons Math Issue Type: Task Affects Versions: 3.2 Reporter: Gilles Priority: Minor The link http://commons.apache.org/proper/commons-math/javadocs/api-3.2/index.html points to the 3.1.1 documentation. -- 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] (COMPRESS-223) NPE from TarBuffer.tryToConsumeSecondEOFRecord
[
https://issues.apache.org/jira/browse/COMPRESS-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig resolved COMPRESS-223.
-
Resolution: Fixed
Fix Version/s: 1.6
fixed with svn revision 1475758 - thanks!
I fixed a few Javadocs on the way as well an documented readRecord may return
null.
NPE from TarBuffer.tryToConsumeSecondEOFRecord
--
Key: COMPRESS-223
URL: https://issues.apache.org/jira/browse/COMPRESS-223
Project: Commons Compress
Issue Type: Bug
Components: Archivers
Affects Versions: 1.5
Reporter: Jeremy Gustie
Fix For: 1.6
Attachments: TarArchiveInputStream.java.patch, TarBuffer.java.patch
I get an NPE using {{Lister}} on the decompressed
[Xerces-J-bin.2.5.0.tar.gz|http://archive.apache.org/dist/xml/xerces-j/Xerces-J-bin.2.5.0.tar.gz]
archive.
Wrapping the {{for}} loop in {{TarBuffer.isEOFRecord}} with a {{null}} check
would fix the issue; it would also clean up the
{{TarArchiveInputStream.getRecord}} implementation a little.
--
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] (IO-279) Tailer erroneously considers file as new
[
https://issues.apache.org/jira/browse/IO-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herman Meerlo updated IO-279:
-
Attachment: fix-tailer.patch
Ok, I've tested the patch for a few days now. The problem has not reoccured
anymore whereas before it used to happen multiple times per day. I have
attached the patch.
Tailer erroneously considers file as new
Key: IO-279
URL: https://issues.apache.org/jira/browse/IO-279
Project: Commons IO
Issue Type: Bug
Affects Versions: 2.0.1, 2.4
Reporter: Sergio Bossa
Fix For: 2.4
Attachments: fix-tailer.patch, IO-279.patch, modify-test-fixed.patch,
modify-test.patch
Tailer sometimes erroneously considers the tailed file as new, forcing a
repositioning at the start of the file: I'm still unable to reproduce this in
a test case, because it only happens to me with huge log files during Apache
Tomcat startup.
This is the piece of code causing the problem:
{code}
// See if the file needs to be read again
if (length position) {
// The file has more content than it did last time
last = System.currentTimeMillis();
position = readLines(reader);
} else if (FileUtils.isFileNewer(file, last)) {
/* This can happen if the file is truncated or overwritten
* with the exact same length of information. In cases like
* this, the file position needs to be reset
*/
position = 0;
reader.seek(position); // cannot be null here
// Now we can read new lines
last = System.currentTimeMillis();
position = readLines(reader);
}
{code}
What probably happens is that the new file content is about to be written on
disk, the date is already updated but content is still not flushed, so actual
length is untouched and there you go.
In other words, I think there should be some better method to verify the
condition above, rather than relying only on dates: keeping and comparing the
hash code of the latest line may be a solution, but may hurt performances ...
other ideas?
--
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-968) Pareto distribution is missing
[ https://issues.apache.org/jira/browse/MATH-968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13641874#comment-13641874 ] Thomas Neidhart commented on MATH-968: -- What about this approach: http://zverovich.net/2012/01/14/beautiful-math-in-javadoc.html Write latex formulas which are anyway similar to the ones we already use, and these will be rendered nicely in HTML. Pareto distribution is missing -- Key: MATH-968 URL: https://issues.apache.org/jira/browse/MATH-968 Project: Commons Math Issue Type: New Feature Affects Versions: 3.2 Reporter: Alex Gryzlov Priority: Minor Attachments: MATH-968.zip Seems that org.apache.commons.math3.distribution lacks a ParetoDistribution for some reason. This is a real common type of distribution, so providing it would be very nice! -- 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-310) Modifications of a SetUniqueList.subList() invalidate the parent list
[
https://issues.apache.org/jira/browse/COLLECTIONS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13642120#comment-13642120
]
Thomas Neidhart commented on COLLECTIONS-310:
-
I did take another look at your provided test-cases and I do not agree with the
following behavior:
* adding an element in a subList that is contained in the backing list results
in moving the element to the new location
This is not what I would expect, and also the backing list does not do this,
e.g. when calling add(obj) where obj is already contained in the list will
result in no change at all. I think we should make it clear, that the returned
subList is *backed* by a SetUniqueList, thus adding elements that are in the
backing list but not in the subList should not be added at all, as they are
already present, just not visible in this view.
Modifications of a SetUniqueList.subList() invalidate the parent list
-
Key: COLLECTIONS-310
URL: https://issues.apache.org/jira/browse/COLLECTIONS-310
Project: Commons Collections
Issue Type: Bug
Components: List
Affects Versions: 3.2, Nightly Builds
Reporter: Christian Semrau
Priority: Minor
Fix For: 4.0
Attachments: SetUniqueList.java, SetUniqueList.patch,
SetUniqueListTest.java, SetUniqueListTest.java, SetUniqueList.v2.java
The List returned by SetUniqueList.subList() is again a SetUniqueList. The
contract for List.subList() says that the returned list supports all the
operations of the parent list, and it is backed by the parent list.
We have a SetUniqueList uniqueList equal to {Hello, World}. We get a
subList containing the last element. Now we add the element Hello,
contained in the uniqueList but not in the subList, to the subList.
What should happen?
Should the subList behave like a SetUniqueList and add the element - meaning
that it changes position in the uniqueList because at the old place it gets
removed, so now uniqueList equals {World, Hello} (which fails)?
Or should the element not be added, because it is already contained in the
parent list, thereby violating the SetUniqueList-ness of the subList (which
fails)?
I prefer the former behaviour, because modifications should only be made
through the subList and not through the parent list (as explained in
List.subList()).
What should happen if we replace (using set) the subList element World with
Hello instead of adding an element?
The subList should contain only Hello, and for the parent list, the old
element 0 (now a duplicate of the just set element 1) should be removed
(which fails).
And of course the parent list should know what happens to it (specifically,
its uniqueness Set) (which fails in the current snapshot).
public void testSubListAddNew() {
List uniqueList = SetUniqueList.decorate(new ArrayList());
uniqueList.add(Hello);
uniqueList.add(World);
List subList = uniqueList.subList(1, 2);
subList.add(Goodbye);
List expectedSubList = Arrays.asList(new Object[] { World,
Goodbye });
List expectedParentList = Arrays.asList(new Object[] { Hello,
World, Goodbye });
assertEquals(expectedSubList, subList);
assertEquals(expectedParentList, uniqueList);
assertTrue(uniqueList.contains(Goodbye)); // fails
}
public void testSubListAddDuplicate() {
List uniqueList = SetUniqueList.decorate(new ArrayList());
uniqueList.add(Hello);
uniqueList.add(World);
List subList = uniqueList.subList(1, 2);
subList.add(Hello);
List expectedSubList = Arrays.asList(new Object[] { World,
Hello });
List expectedParentList = Arrays.asList(new Object[] { World,
Hello });
assertEquals(expectedSubList, subList);
assertEquals(expectedParentList, uniqueList); // fails
}
public void testSubListSetDuplicate() {
List uniqueList = SetUniqueList.decorate(new ArrayList());
uniqueList.add(Hello);
uniqueList.add(World);
List subList = uniqueList.subList(1, 2);
subList.set(0, Hello);
List expectedSubList = Arrays.asList(new Object[] { Hello });
List expectedParentList = Arrays.asList(new Object[] { Hello
});
assertEquals(expectedSubList, subList);
assertEquals(expectedParentList, uniqueList); // fails
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA,
[jira] [Updated] (COLLECTIONS-148) [collections] Change to HashEntry inner class of AbstractHashedMap
[
https://issues.apache.org/jira/browse/COLLECTIONS-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart updated COLLECTIONS-148:
Fix Version/s: (was: 4.0)
4.x
[collections] Change to HashEntry inner class of AbstractHashedMap
--
Key: COLLECTIONS-148
URL: https://issues.apache.org/jira/browse/COLLECTIONS-148
Project: Commons Collections
Issue Type: Improvement
Environment: Operating System: other
Platform: All
Reporter: Henry Story
Priority: Minor
Fix For: 4.x
Attachments: ASF.LICENSE.NOT.GRANTED--collections-altered.jpg,
ASF.LICENSE.NOT.GRANTED--collections.jpg,
ASF.LICENSE.NOT.GRANTED--hashed.tar, ASF.LICENSE.NOT.GRANTED--patch.txt
The way the AbstractHashedMap class is currently written it is not as
extensible as it could be.
The HashEntry static inner class is abstract. By slightly refactoring it to
an inner interface one can get a
lot more mileage out of it.
This change has minimal impact on four other classes from the map package.
Two extra classes which I will submit as a seperate patch (should I do this
before this one is accepted?)
that use this inner interface are a HashedSet and a WeakHashedSet. Both of
these classes are adapters
of a subclass of the changed AbstractHashedMap.
The HashEntry interface essentially hides the representation of the key and
value objects. In a HashSet
the key is the value, so this avoids the duplication - not of objects, but of
references. More importantly
it also allows a HashEntry to extend a WeakReference Object, which cannot be
done as the code
presently stands.
Here is the new interface:
protected static interface HashEntry extends Map.Entry, KeyValue {
public HashEntry getNext();
public void setNext(HashEntry next);
public int getHashCode();
public void setHashCode(int hashCode);
/**
* @param key raw key (ie, no interpretation for special cases like
NULL
*/
public void setRawKey(Object key);
/**
*
* @return the raw key
*/
public Object getRawKey();
}
This allows the implementation to decide how they can refer to the key and
the values. Essentially we
remove all reference in the code to the variables 'key' and 'value' and
replace them with the (set/
get)rawkey (set/get)value methods. The raw key method is necessary as the
setKey method is often
overridden to do special null substition work.
I have also created a more interesting NULL object, that can better describe
itself. When debugging it is
often helpful to know that one is looking at a NULL object.
Finally I also - and debatably wrongly - changed the Iterator from static
inner classes to real inner
classes. This is how it is meant to work anyway. An inner class just has a
reference to its enclosing
class. But perhaps there is something here that I have not understood. My
other contributions don't
hang on this change. They just make the code a little simpler.
If the intention is to extract these classes to an external package, then the
current solution of having a
static inner class makes sense.
I will attach class diagrams and diffs to this request to clarify the changes.
--
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-148) [collections] Change to HashEntry inner class of AbstractHashedMap
[
https://issues.apache.org/jira/browse/COLLECTIONS-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13642126#comment-13642126
]
Thomas Neidhart commented on COLLECTIONS-148:
-
Postpone to a later version.
[collections] Change to HashEntry inner class of AbstractHashedMap
--
Key: COLLECTIONS-148
URL: https://issues.apache.org/jira/browse/COLLECTIONS-148
Project: Commons Collections
Issue Type: Improvement
Environment: Operating System: other
Platform: All
Reporter: Henry Story
Priority: Minor
Fix For: 4.x
Attachments: ASF.LICENSE.NOT.GRANTED--collections-altered.jpg,
ASF.LICENSE.NOT.GRANTED--collections.jpg,
ASF.LICENSE.NOT.GRANTED--hashed.tar, ASF.LICENSE.NOT.GRANTED--patch.txt
The way the AbstractHashedMap class is currently written it is not as
extensible as it could be.
The HashEntry static inner class is abstract. By slightly refactoring it to
an inner interface one can get a
lot more mileage out of it.
This change has minimal impact on four other classes from the map package.
Two extra classes which I will submit as a seperate patch (should I do this
before this one is accepted?)
that use this inner interface are a HashedSet and a WeakHashedSet. Both of
these classes are adapters
of a subclass of the changed AbstractHashedMap.
The HashEntry interface essentially hides the representation of the key and
value objects. In a HashSet
the key is the value, so this avoids the duplication - not of objects, but of
references. More importantly
it also allows a HashEntry to extend a WeakReference Object, which cannot be
done as the code
presently stands.
Here is the new interface:
protected static interface HashEntry extends Map.Entry, KeyValue {
public HashEntry getNext();
public void setNext(HashEntry next);
public int getHashCode();
public void setHashCode(int hashCode);
/**
* @param key raw key (ie, no interpretation for special cases like
NULL
*/
public void setRawKey(Object key);
/**
*
* @return the raw key
*/
public Object getRawKey();
}
This allows the implementation to decide how they can refer to the key and
the values. Essentially we
remove all reference in the code to the variables 'key' and 'value' and
replace them with the (set/
get)rawkey (set/get)value methods. The raw key method is necessary as the
setKey method is often
overridden to do special null substition work.
I have also created a more interesting NULL object, that can better describe
itself. When debugging it is
often helpful to know that one is looking at a NULL object.
Finally I also - and debatably wrongly - changed the Iterator from static
inner classes to real inner
classes. This is how it is meant to work anyway. An inner class just has a
reference to its enclosing
class. But perhaps there is something here that I have not understood. My
other contributions don't
hang on this change. They just make the code a little simpler.
If the intention is to extract these classes to an external package, then the
current solution of having a
static inner class makes sense.
I will attach class diagrams and diffs to this request to clarify the changes.
--
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] (EMAIL-126) DKIM Signing
Zhihong Zhang created EMAIL-126: --- Summary: DKIM Signing Key: EMAIL-126 URL: https://issues.apache.org/jira/browse/EMAIL-126 Project: Commons Email Issue Type: New Feature Affects Versions: 1.3.1 Reporter: Zhihong Zhang -- 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] (COLLECTIONS-450) Iterate over the all elements excluding the last/first one
[
https://issues.apache.org/jira/browse/COLLECTIONS-450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart resolved COLLECTIONS-450.
-
Resolution: Fixed
Added with minor changes in r1475937.
Thanks for the patch!
Iterate over the all elements excluding the last/first one
--
Key: COLLECTIONS-450
URL: https://issues.apache.org/jira/browse/COLLECTIONS-450
Project: Commons Collections
Issue Type: Wish
Components: Collection
Reporter: J. Moldawski
Priority: Minor
Fix For: 4.0
Attachments: patch_COLLECTIONS-450.txt
The Problem
In many applications you will extremly often find this sort of code:
int i=0;
for (element:elements)
{
i++;
if (i!=elemets.size)
{
processLastElement(element);
}else
{
// Just for last element
processLastElement(element);
}
}
It happens often, if not just all collections's elements themself must be
processed, but some actions must be performed on going from one element to
the next. Since the last element has no successor, this actions must be
skipped when processing the last element. A very famous example is, if your
are going the generate a comma-separated-vector from a CollectionString:
You will end up in a code like above.
Proposal
=
The method TCollectionUtils.forAllButLastDo(CollectionT, C)
should be introduced, which process all elements of a collection, but skips
the last one, which will be just returned. The above code can be then
re-written:
processLastElement(forAllButLastDo(elements,
new ClosureT{
execute(T element){
processAllButTheLast(element)
}
}
))
--
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] (EMAIL-126) DKIM Signing
[ https://issues.apache.org/jira/browse/EMAIL-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhihong Zhang updated EMAIL-126: Labels: dkim email (was: ) Description: Support DKIM signing natively in EMail library. Affects Version/s: 2.0 The code will be attached later once it passes legal review. DKIM Signing Key: EMAIL-126 URL: https://issues.apache.org/jira/browse/EMAIL-126 Project: Commons Email Issue Type: New Feature Affects Versions: 2.0, 1.3.1 Reporter: Zhihong Zhang Labels: dkim, email Support DKIM signing natively in EMail library. -- 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] (COLLECTIONS-263) Extend the MultiHashMap to create an object filter by value of given field
[ https://issues.apache.org/jira/browse/COLLECTIONS-263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved COLLECTIONS-263. - Resolution: Fixed Added overridden methods for MapUtils.populateMap(MultiMap, ...) in r1475949. Extend the MultiHashMap to create an object filter by value of given field -- Key: COLLECTIONS-263 URL: https://issues.apache.org/jira/browse/COLLECTIONS-263 Project: Commons Collections Issue Type: New Feature Components: KeyValue, Map Affects Versions: 3.1, 3.2 Reporter: John Hunsley Priority: Minor Fix For: 4.0 Attachments: CollectionFilter.java, CollectionFilterTest.java I purpose extending the MultiHashMap to create an object filter which will filter a given collection of objects by a given field value. For example: I have a collection of 5 objects of class X. X has an int field i as shown below: x1 i = 1 x2 i = 2 x3 i = 2 x4 i = 5 x5 i = 5 The extended MultiHashMap will filter those objects by the field i and store each sorted object into the map using the value of the field, i, as the key, such that the resulting MultiHashMap looks as follows: key | values 1 | x1 2 | x2, x3 5 | x4, x5 I have a class which does this and I find it invaluable in my day to day work. I don't Collections has a similar one. Kind regards, John. -- 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-968) Pareto distribution is missing
[ https://issues.apache.org/jira/browse/MATH-968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13642278#comment-13642278 ] Gilles commented on MATH-968: - I proposed to test something similar some time ago: http://users.informatik.uni-halle.de/~grau/LaTeXlet/ But there has been significant reluctance about licensing, dependencies, and plainly having LaTeX code inside the Javadoc. IMHO, there are two options: # LaTeX-based extension to create beautiful (when generated!) comments # Basic Javadoc, no fancy formulae (especially _not_ using plain HTML) Pareto distribution is missing -- Key: MATH-968 URL: https://issues.apache.org/jira/browse/MATH-968 Project: Commons Math Issue Type: New Feature Affects Versions: 3.2 Reporter: Alex Gryzlov Priority: Minor Attachments: MATH-968.zip Seems that org.apache.commons.math3.distribution lacks a ParetoDistribution for some reason. This is a real common type of distribution, so providing it would be very nice! -- 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
