[jira] [Commented] (LANG-909) Thread-safe wrapper for SimpleDateFormat
[
https://issues.apache.org/jira/browse/LANG-909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13801641#comment-13801641
]
Dmitry Katsubo commented on LANG-909:
-
Perhaps Java8 does not need this class (it will have better date/time
functionality support), but {{commons-lang}} is Java1.5-compatible, is it?
Thread-safe wrapper for SimpleDateFormat
Key: LANG-909
URL: https://issues.apache.org/jira/browse/LANG-909
Project: Commons Lang
Issue Type: New Feature
Components: lang.time.*
Affects Versions: 3.1
Reporter: Dmitry Katsubo
Priority: Minor
Fix For: Review Patch
Attachments: DateFormatAdapter.java, ThreadSafeSimpleDateFormat.java,
ThreadSafeSimpleDateFormatTest.java
{{SimpleDateFormat}} implementation in JDK is known to be [not
thread-safe|http://stackoverflow.com/questions/6840803/simpledateformat-thread-safety].
The attached helper class solves the problem by holding a separate instance
of {{SimpleDateFormat}} per thread.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (DAEMON-309) Documentation for start method in JVM mode is conflicting
Joachim Sauer created DAEMON-309:
Summary: Documentation for start method in JVM mode is conflicting
Key: DAEMON-309
URL: https://issues.apache.org/jira/browse/DAEMON-309
Project: Commons Daemon
Issue Type: Bug
Components: Procrun
Reporter: Joachim Sauer
Priority: Minor
The documentation for how the start method should act in JVM mode is
conflicting (http://commons.apache.org/proper/commons-daemon/procrun.html).
1. In the documentation of the StartMethod parameter there's this text:
{quote}
Note: in jvm mode, the start method should not return until the stop method has
been called.
{quote}
2. The second-to-last sentence in the section Using Procrun in jvm mode reads:
{quote}
Note that the method handling service start should create and start a separate
thread to carry out the processing, and then return.
{quote}
According to my reading those two sentences say pretty much the opposite of
each other and observation shows that #1 is the correct one (i.e. the service
is assumed to have stopped when the start method returns).
Generally speaking, JVM mode is pretty under-documented (in my opinion). That
can easily be verified by the fact that very popular documentation exists
outside the procrun/commons daemon project, as a blog post:
http://joerglenhard.wordpress.com/2012/05/29/build-windows-service-from-java-application-with-procrun/
A simple end-to-end example showing a similar setup as that blog post would be
good.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (MATH-1044) Clarify and fix javadoc of DecompositionSolver.getInverse() and implementations
Sean Owen created MATH-1044: --- Summary: Clarify and fix javadoc of DecompositionSolver.getInverse() and implementations Key: MATH-1044 URL: https://issues.apache.org/jira/browse/MATH-1044 Project: Commons Math Issue Type: Improvement Affects Versions: 3.2 Reporter: Sean Owen Priority: Minor As suggested by Phil on the mailing list, I'm providing a patch to the javadoc of DecompositionSolver.getInverse() to clarify what it does. It also correctly moves the @throws SingularMatrixException to implementations that do throw this exception; not all do. Tests already cover most of the behavior asserted by the documentation. I added one to show that the SVD does not reject singular matrices. There should be a test for EigenDecomposition here too, but in the course of adding it I found another apparent small bug in its behavior with singular matrices. So I will provide that separately (it actually involves no doc changes, and docs are the topic here.) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1044) Clarify and fix javadoc of DecompositionSolver.getInverse() and implementations
[ https://issues.apache.org/jira/browse/MATH-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1044: Attachment: MATH-1044.patch Clarify and fix javadoc of DecompositionSolver.getInverse() and implementations --- Key: MATH-1044 URL: https://issues.apache.org/jira/browse/MATH-1044 Project: Commons Math Issue Type: Improvement Affects Versions: 3.2 Reporter: Sean Owen Priority: Minor Labels: decomposition, inverse, singular, solver Attachments: MATH-1044.patch As suggested by Phil on the mailing list, I'm providing a patch to the javadoc of DecompositionSolver.getInverse() to clarify what it does. It also correctly moves the @throws SingularMatrixException to implementations that do throw this exception; not all do. Tests already cover most of the behavior asserted by the documentation. I added one to show that the SVD does not reject singular matrices. There should be a test for EigenDecomposition here too, but in the course of adding it I found another apparent small bug in its behavior with singular matrices. So I will provide that separately (it actually involves no doc changes, and docs are the topic here.) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (MATH-1045) EigenDecomposition.Solver should consider tiny values 0 for purposes of determining singularity
Sean Owen created MATH-1045: --- Summary: EigenDecomposition.Solver should consider tiny values 0 for purposes of determining singularity Key: MATH-1045 URL: https://issues.apache.org/jira/browse/MATH-1045 Project: Commons Math Issue Type: Bug Affects Versions: 3.2 Reporter: Sean Owen Priority: Minor Attachments: MATH-1045.patch EigenDecomposition.Solver tests for singularity by comparing eigenvalues to 0 for exact equality. Elsewhere in the class and in the code, of course, very small values are considered 0. This causes the solver to consider some singular matrices as non-singular. The patch here includes a test as well showing the behavior -- the matrix is clearly singular but isn't considered as such since one eigenvalue are ~1e-14 rather than exactly 0. (What I am not sure of is whether we should really be evaluating the *norm* of the imaginary eigenvalues rather than real/imag components separately. But the javadoc says the solver only supports real eigenvalues anyhow, so it's kind of moot since imag=0 for all eigenvalues.) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1045) EigenDecomposition.Solver should consider tiny values 0 for purposes of determining singularity
[ https://issues.apache.org/jira/browse/MATH-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1045: Attachment: MATH-1045.patch EigenDecomposition.Solver should consider tiny values 0 for purposes of determining singularity --- Key: MATH-1045 URL: https://issues.apache.org/jira/browse/MATH-1045 Project: Commons Math Issue Type: Bug Affects Versions: 3.2 Reporter: Sean Owen Priority: Minor Labels: eigenvalue, singular Attachments: MATH-1045.patch EigenDecomposition.Solver tests for singularity by comparing eigenvalues to 0 for exact equality. Elsewhere in the class and in the code, of course, very small values are considered 0. This causes the solver to consider some singular matrices as non-singular. The patch here includes a test as well showing the behavior -- the matrix is clearly singular but isn't considered as such since one eigenvalue are ~1e-14 rather than exactly 0. (What I am not sure of is whether we should really be evaluating the *norm* of the imaginary eigenvalues rather than real/imag components separately. But the javadoc says the solver only supports real eigenvalues anyhow, so it's kind of moot since imag=0 for all eigenvalues.) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1044) Clarify and fix javadoc of DecompositionSolver.getInverse() and implementations
[ https://issues.apache.org/jira/browse/MATH-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1044: Attachment: MATH-1045.patch Clarify and fix javadoc of DecompositionSolver.getInverse() and implementations --- Key: MATH-1044 URL: https://issues.apache.org/jira/browse/MATH-1044 Project: Commons Math Issue Type: Improvement Affects Versions: 3.2 Reporter: Sean Owen Priority: Minor Labels: decomposition, inverse, singular, solver Attachments: MATH-1044.patch As suggested by Phil on the mailing list, I'm providing a patch to the javadoc of DecompositionSolver.getInverse() to clarify what it does. It also correctly moves the @throws SingularMatrixException to implementations that do throw this exception; not all do. Tests already cover most of the behavior asserted by the documentation. I added one to show that the SVD does not reject singular matrices. There should be a test for EigenDecomposition here too, but in the course of adding it I found another apparent small bug in its behavior with singular matrices. So I will provide that separately (it actually involves no doc changes, and docs are the topic here.) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1044) Clarify and fix javadoc of DecompositionSolver.getInverse() and implementations
[ https://issues.apache.org/jira/browse/MATH-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1044: Attachment: (was: MATH-1045.patch) Clarify and fix javadoc of DecompositionSolver.getInverse() and implementations --- Key: MATH-1044 URL: https://issues.apache.org/jira/browse/MATH-1044 Project: Commons Math Issue Type: Improvement Affects Versions: 3.2 Reporter: Sean Owen Priority: Minor Labels: decomposition, inverse, singular, solver Attachments: MATH-1044.patch As suggested by Phil on the mailing list, I'm providing a patch to the javadoc of DecompositionSolver.getInverse() to clarify what it does. It also correctly moves the @throws SingularMatrixException to implementations that do throw this exception; not all do. Tests already cover most of the behavior asserted by the documentation. I added one to show that the SVD does not reject singular matrices. There should be a test for EigenDecomposition here too, but in the course of adding it I found another apparent small bug in its behavior with singular matrices. So I will provide that separately (it actually involves no doc changes, and docs are the topic here.) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MATH-1044) Clarify and fix javadoc of DecompositionSolver.getInverse() and implementations
[
https://issues.apache.org/jira/browse/MATH-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13801804#comment-13801804
]
Gilles commented on MATH-1044:
--
If you know (and like) LaTeX, it is now possible to write formulae with it
within the Javadoc (thanks to MathJax).
Interpretation is activated by having an inline formula enclosed between
{noformat}\({noformat} and {noformat}\){noformat} and a display formula
enclosed between {noformat}\[{noformat} and {noformat}\]{noformat}
See for example the doc of class
{{org.apache.commons.math3.fitting.HarmonicCurveFitter}}.
Clarify and fix javadoc of DecompositionSolver.getInverse() and
implementations
---
Key: MATH-1044
URL: https://issues.apache.org/jira/browse/MATH-1044
Project: Commons Math
Issue Type: Improvement
Affects Versions: 3.2
Reporter: Sean Owen
Priority: Minor
Labels: decomposition, inverse, singular, solver
Attachments: MATH-1044.patch
As suggested by Phil on the mailing list, I'm providing a patch to the
javadoc of DecompositionSolver.getInverse() to clarify what it does. It also
correctly moves the @throws SingularMatrixException to implementations that
do throw this exception; not all do.
Tests already cover most of the behavior asserted by the documentation. I
added one to show that the SVD does not reject singular matrices. There
should be a test for EigenDecomposition here too, but in the course of adding
it I found another apparent small bug in its behavior with singular matrices.
So I will provide that separately (it actually involves no doc changes, and
docs are the topic here.)
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (IMAGING-113) Cannot read multipage tiff
[
https://issues.apache.org/jira/browse/IMAGING-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13801830#comment-13801830
]
Adrian Costil commented on IMAGING-113:
---
the patch seems to work.
I was facing another issue with my test tiff image which has 14 images, each
3386 x 4397. The library uses a lot of memory for
Imaging.getAllBufferedImages(new File(imageLocation));
so I had to start the JVM with a lot of memory to process a single image file.
-Xms512m
-Xmx1024m
Is there a way to improve the memory usage ?
Also I was trying to write to a different file and it seems that it will write
only the last image. Is there a way to append the images to a tiff file ?
this is a sample code:
final ListBufferedImage images = Imaging.getAllBufferedImages(new
File(imageLocation));
final ImageFormat format =
ImageFormat.IMAGE_FORMAT_TIFF;
final MapString,Object params = new HashMapString,Object();
// set optional parameters if you like
params.put(ImagingConstants.PARAM_KEY_COMPRESSION, new Integer(
TiffConstants.TIFF_COMPRESSION_LZW));
int i= 0;
File outFile = new File(outLocation);
for (IteratorBufferedImage iterator = images.iterator();
iterator.hasNext(); i++) {
BufferedImage bufferedImage = iterator.next();
System.out.println(write image + i);
Imaging.writeImage(bufferedImage, outFile, format,
params);
}
Cannot read multipage tiff
--
Key: IMAGING-113
URL: https://issues.apache.org/jira/browse/IMAGING-113
Project: Commons Imaging
Issue Type: Bug
Affects Versions: 1.0
Reporter: Adrian Costil
Labels: multipage, tiff
Fix For: 1.0
I get the error below when I'm trying to read a multipage tiff file as a list
of images
final ListBufferedImage images =
Imaging.getAllBufferedImages(new File(imageLocation));
line 589 of TiffImageParser
Rectangle subImage = checkForSubImage(params); //if the params is
null it will crash
java.lang.NullPointerException
at
org.apache.commons.imaging.formats.tiff.TiffImageParser.getIntegerParameter(TiffImageParser.java:513)
at
org.apache.commons.imaging.formats.tiff.TiffImageParser.checkForSubImage(TiffImageParser.java:531)
at
org.apache.commons.imaging.formats.tiff.TiffImageParser.getBufferedImage(TiffImageParser.java:589)
at
org.apache.commons.imaging.formats.tiff.TiffDirectory.getTiffImage(TiffDirectory.java:163)
at
org.apache.commons.imaging.formats.tiff.TiffImageParser.getAllBufferedImages(TiffImageParser.java:499)
at
org.apache.commons.imaging.Imaging.getAllBufferedImages(Imaging.java:1210)
at
org.apache.commons.imaging.Imaging.getAllBufferedImages(Imaging.java:1202)
at TestWriteTiffImages.main(TestWriteTiffImages.java:30)
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (MATH-1044) Clarify and fix javadoc of DecompositionSolver.getInverse() and implementations
[ https://issues.apache.org/jira/browse/MATH-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1044: Attachment: (was: MATH-1044.patch) Clarify and fix javadoc of DecompositionSolver.getInverse() and implementations --- Key: MATH-1044 URL: https://issues.apache.org/jira/browse/MATH-1044 Project: Commons Math Issue Type: Improvement Affects Versions: 3.2 Reporter: Sean Owen Priority: Minor Labels: decomposition, inverse, singular, solver Attachments: MATH-1044.patch As suggested by Phil on the mailing list, I'm providing a patch to the javadoc of DecompositionSolver.getInverse() to clarify what it does. It also correctly moves the @throws SingularMatrixException to implementations that do throw this exception; not all do. Tests already cover most of the behavior asserted by the documentation. I added one to show that the SVD does not reject singular matrices. There should be a test for EigenDecomposition here too, but in the course of adding it I found another apparent small bug in its behavior with singular matrices. So I will provide that separately (it actually involves no doc changes, and docs are the topic here.) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1044) Clarify and fix javadoc of DecompositionSolver.getInverse() and implementations
[ https://issues.apache.org/jira/browse/MATH-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1044: Attachment: MATH-1044.patch Now with LaTeX Clarify and fix javadoc of DecompositionSolver.getInverse() and implementations --- Key: MATH-1044 URL: https://issues.apache.org/jira/browse/MATH-1044 Project: Commons Math Issue Type: Improvement Affects Versions: 3.2 Reporter: Sean Owen Priority: Minor Labels: decomposition, inverse, singular, solver Attachments: MATH-1044.patch As suggested by Phil on the mailing list, I'm providing a patch to the javadoc of DecompositionSolver.getInverse() to clarify what it does. It also correctly moves the @throws SingularMatrixException to implementations that do throw this exception; not all do. Tests already cover most of the behavior asserted by the documentation. I added one to show that the SVD does not reject singular matrices. There should be a test for EigenDecomposition here too, but in the course of adding it I found another apparent small bug in its behavior with singular matrices. So I will provide that separately (it actually involves no doc changes, and docs are the topic here.) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1045) EigenDecomposition.Solver should consider tiny values 0 for purposes of determining singularity
[ https://issues.apache.org/jira/browse/MATH-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1045: Attachment: MATH-1045.patch EigenDecomposition.Solver should consider tiny values 0 for purposes of determining singularity --- Key: MATH-1045 URL: https://issues.apache.org/jira/browse/MATH-1045 Project: Commons Math Issue Type: Bug Affects Versions: 3.2 Reporter: Sean Owen Priority: Minor Labels: eigenvalue, singular Attachments: MATH-1045.patch EigenDecomposition.Solver tests for singularity by comparing eigenvalues to 0 for exact equality. Elsewhere in the class and in the code, of course, very small values are considered 0. This causes the solver to consider some singular matrices as non-singular. The patch here includes a test as well showing the behavior -- the matrix is clearly singular but isn't considered as such since one eigenvalue are ~1e-14 rather than exactly 0. (What I am not sure of is whether we should really be evaluating the *norm* of the imaginary eigenvalues rather than real/imag components separately. But the javadoc says the solver only supports real eigenvalues anyhow, so it's kind of moot since imag=0 for all eigenvalues.) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1045) EigenDecomposition.Solver should consider tiny values 0 for purposes of determining singularity
[ https://issues.apache.org/jira/browse/MATH-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated MATH-1045: Attachment: (was: MATH-1045.patch) EigenDecomposition.Solver should consider tiny values 0 for purposes of determining singularity --- Key: MATH-1045 URL: https://issues.apache.org/jira/browse/MATH-1045 Project: Commons Math Issue Type: Bug Affects Versions: 3.2 Reporter: Sean Owen Priority: Minor Labels: eigenvalue, singular Attachments: MATH-1045.patch EigenDecomposition.Solver tests for singularity by comparing eigenvalues to 0 for exact equality. Elsewhere in the class and in the code, of course, very small values are considered 0. This causes the solver to consider some singular matrices as non-singular. The patch here includes a test as well showing the behavior -- the matrix is clearly singular but isn't considered as such since one eigenvalue are ~1e-14 rather than exactly 0. (What I am not sure of is whether we should really be evaluating the *norm* of the imaginary eigenvalues rather than real/imag components separately. But the javadoc says the solver only supports real eigenvalues anyhow, so it's kind of moot since imag=0 for all eigenvalues.) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MATH-1045) EigenDecomposition.Solver should consider tiny values 0 for purposes of determining singularity
[ https://issues.apache.org/jira/browse/MATH-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13801866#comment-13801866 ] Gilles commented on MATH-1045: -- Isn't the code in this class (and others similarly) supposed to work for a matrix with very small entries too? I mean that, if all eigenvalues are of the order of, say, EPSILON / 10, should the matrix be considered singular right away? EigenDecomposition.Solver should consider tiny values 0 for purposes of determining singularity --- Key: MATH-1045 URL: https://issues.apache.org/jira/browse/MATH-1045 Project: Commons Math Issue Type: Bug Affects Versions: 3.2 Reporter: Sean Owen Priority: Minor Labels: eigenvalue, singular Attachments: MATH-1045.patch EigenDecomposition.Solver tests for singularity by comparing eigenvalues to 0 for exact equality. Elsewhere in the class and in the code, of course, very small values are considered 0. This causes the solver to consider some singular matrices as non-singular. The patch here includes a test as well showing the behavior -- the matrix is clearly singular but isn't considered as such since one eigenvalue are ~1e-14 rather than exactly 0. (What I am not sure of is whether we should really be evaluating the *norm* of the imaginary eigenvalues rather than real/imag components separately. But the javadoc says the solver only supports real eigenvalues anyhow, so it's kind of moot since imag=0 for all eigenvalues.) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (IMAGING-117) SofnSegment.components - public mutable array
[ https://issues.apache.org/jira/browse/IMAGING-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13801905#comment-13801905 ] Matt Benson commented on IMAGING-117: - Because any code executing in the VM can come along and modify the contents of that array. SofnSegment.components - public mutable array - Key: IMAGING-117 URL: https://issues.apache.org/jira/browse/IMAGING-117 Project: Commons Imaging Issue Type: Bug Reporter: Sebb -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MATH-1045) EigenDecomposition.Solver should consider tiny values 0 for purposes of determining singularity
[ https://issues.apache.org/jira/browse/MATH-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13801910#comment-13801910 ] Sean Owen commented on MATH-1045: - That's a good point. If you make the example matrix non-singular, but then divide elements by 1e12, it will report it as singular. This seems wrong. On the other hand it seems a bit undesirable to return an 'inverse' in this case -- it's dominated by the inverse of that tiny eigenvalue, which is huge, and the result is pretty unreliable. I'm a bit out of my depth here but I wonder if it's more reasonable to examine the eigenvalues in sorted order and examine ratio of one to the next. When that ratio is below epsilon it makes more sense to declare it 0. I could also see this being a case of caller beware. That's the more conservative thing here. EigenDecomposition.Solver should consider tiny values 0 for purposes of determining singularity --- Key: MATH-1045 URL: https://issues.apache.org/jira/browse/MATH-1045 Project: Commons Math Issue Type: Bug Affects Versions: 3.2 Reporter: Sean Owen Priority: Minor Labels: eigenvalue, singular Attachments: MATH-1045.patch EigenDecomposition.Solver tests for singularity by comparing eigenvalues to 0 for exact equality. Elsewhere in the class and in the code, of course, very small values are considered 0. This causes the solver to consider some singular matrices as non-singular. The patch here includes a test as well showing the behavior -- the matrix is clearly singular but isn't considered as such since one eigenvalue are ~1e-14 rather than exactly 0. (What I am not sure of is whether we should really be evaluating the *norm* of the imaginary eigenvalues rather than real/imag components separately. But the javadoc says the solver only supports real eigenvalues anyhow, so it's kind of moot since imag=0 for all eigenvalues.) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (IMAGING-117) SofnSegment.components - public mutable array
[ https://issues.apache.org/jira/browse/IMAGING-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13801944#comment-13801944 ] Sebb commented on IMAGING-117: -- Also - because of the Java memory model - there is no way for the classes to ensure thread safety when the array is modified. Array entries written by one thread are not guaranteed to be made visible to other threads in the absence of synchronisation. SofnSegment.components - public mutable array - Key: IMAGING-117 URL: https://issues.apache.org/jira/browse/IMAGING-117 Project: Commons Imaging Issue Type: Bug Reporter: Sebb -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (LANG-909) Thread-safe wrapper for SimpleDateFormat
[
https://issues.apache.org/jira/browse/LANG-909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13801978#comment-13801978
]
Henri Yandell commented on LANG-909:
Agreed - the proposal for Lang 4.0 is to be Java 8 compatible. So my note is
meant to read as 'would we be removing this in Lang 4.0?'
Thread-safe wrapper for SimpleDateFormat
Key: LANG-909
URL: https://issues.apache.org/jira/browse/LANG-909
Project: Commons Lang
Issue Type: New Feature
Components: lang.time.*
Affects Versions: 3.1
Reporter: Dmitry Katsubo
Priority: Minor
Fix For: Review Patch
Attachments: DateFormatAdapter.java, ThreadSafeSimpleDateFormat.java,
ThreadSafeSimpleDateFormatTest.java
{{SimpleDateFormat}} implementation in JDK is known to be [not
thread-safe|http://stackoverflow.com/questions/6840803/simpledateformat-thread-safety].
The attached helper class solves the problem by holding a separate instance
of {{SimpleDateFormat}} per thread.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (LANG-456) HashCodeBuilder throws StackOverflowError in bidirectional navigable association
[ https://issues.apache.org/jira/browse/LANG-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Woonsan Ko updated LANG-456: Attachment: LANG-456-patch.txt Attaching my patch (LANG-456-patch.txt) to fix this issue. I moved the isRegistered()-register()-unregister() code from #reflectionAppend() to #append(). I think this should be more reasonable because #reflectionAppend() invokes #append() method anyway. Also, #append(Object) code has been improved to check registration status only when the object argument is neither primitive nor String type. Please take a review. Cheers, Woonsan HashCodeBuilder throws StackOverflowError in bidirectional navigable association Key: LANG-456 URL: https://issues.apache.org/jira/browse/LANG-456 Project: Commons Lang Issue Type: Bug Components: lang.builder.* Affects Versions: 2.4 Environment: Widows XP. Sun JDK 1.5 or 1.6. Reporter: Bob Fields Fix For: Patch Needed Attachments: HashCodeBuilderStackOverflow.zip, LANG-456-patch.txt, StackOverflowError.zip This is not the reflection methods, it is the regular HashCodeBuilder append methods. It causes EqualsBuilder, ToStringBuilder, CompareToBuilder to also throw the StackOverflowException, but those methods work when one of the HashCodeBuilder bidirectional association attributes .hashCode() is commented out. The problem is that all of the builders call registerObject() which creates a hashCode, but only the reflectionAppend method checks if an object is registered. Bi-directional associations are a very common pattern in Jaxb and Hibernate. In this case, I generate code from a model in order to avoid the reflection penalty - I already know what the attributes are at compile time, so I use .append instead of .reflectionAppend. See attached example + unit test. One side of the bidirectional association must be commented out in the hashCode method. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-456) HashCodeBuilder throws StackOverflowError in bidirectional navigable association
[ https://issues.apache.org/jira/browse/LANG-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-456: --- Fix Version/s: (was: Patch Needed) Review Patch HashCodeBuilder throws StackOverflowError in bidirectional navigable association Key: LANG-456 URL: https://issues.apache.org/jira/browse/LANG-456 Project: Commons Lang Issue Type: Bug Components: lang.builder.* Affects Versions: 2.4 Environment: Widows XP. Sun JDK 1.5 or 1.6. Reporter: Bob Fields Fix For: Review Patch Attachments: HashCodeBuilderStackOverflow.zip, LANG-456-patch.txt, StackOverflowError.zip This is not the reflection methods, it is the regular HashCodeBuilder append methods. It causes EqualsBuilder, ToStringBuilder, CompareToBuilder to also throw the StackOverflowException, but those methods work when one of the HashCodeBuilder bidirectional association attributes .hashCode() is commented out. The problem is that all of the builders call registerObject() which creates a hashCode, but only the reflectionAppend method checks if an object is registered. Bi-directional associations are a very common pattern in Jaxb and Hibernate. In this case, I generate code from a model in order to avoid the reflection penalty - I already know what the attributes are at compile time, so I use .append instead of .reflectionAppend. See attached example + unit test. One side of the bidirectional association must be commented out in the hashCode method. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (LANG-456) HashCodeBuilder throws StackOverflowError in bidirectional navigable association
[ https://issues.apache.org/jira/browse/LANG-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13801990#comment-13801990 ] Henri Yandell commented on LANG-456: Thanks Woonsan :) Moving to Review Patch. HashCodeBuilder throws StackOverflowError in bidirectional navigable association Key: LANG-456 URL: https://issues.apache.org/jira/browse/LANG-456 Project: Commons Lang Issue Type: Bug Components: lang.builder.* Affects Versions: 2.4 Environment: Widows XP. Sun JDK 1.5 or 1.6. Reporter: Bob Fields Fix For: Review Patch Attachments: HashCodeBuilderStackOverflow.zip, LANG-456-patch.txt, StackOverflowError.zip This is not the reflection methods, it is the regular HashCodeBuilder append methods. It causes EqualsBuilder, ToStringBuilder, CompareToBuilder to also throw the StackOverflowException, but those methods work when one of the HashCodeBuilder bidirectional association attributes .hashCode() is commented out. The problem is that all of the builders call registerObject() which creates a hashCode, but only the reflectionAppend method checks if an object is registered. Bi-directional associations are a very common pattern in Jaxb and Hibernate. In this case, I generate code from a model in order to avoid the reflection penalty - I already know what the attributes are at compile time, so I use .append instead of .reflectionAppend. See attached example + unit test. One side of the bidirectional association must be commented out in the hashCode method. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (LANG-910) Patch to extend StringUtils
[
https://issues.apache.org/jira/browse/LANG-910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13801994#comment-13801994
]
Matt Benson commented on LANG-910:
--
Followup: Your example suggested that a user looking for kins would
intuitively supply 2 as the final argument. Maybe so, but I think the
_correct_ behavior would really be:
Yes, support pulling in each matching subsequence, but rather than:
{code}
assertEquals(kins, StringUtils.substringMatching(two little pumpkins sitting
over there, Pattern.compile(() ), 2));
{code}
The correct assertion would be:
{code}
assertEquals(kins, StringUtils.substringsMatching(two little pumpkins
sitting over there, Pattern.compile(() ), 1)[1]);
{code}
Less intuitive perhaps, but IMO more defensible in terms of why did we do it
this way?. We provide the required functionality but the path from
{{Pattern}}/{{Matcher}} APIs is fairly evident.
Patch to extend StringUtils
---
Key: LANG-910
URL: https://issues.apache.org/jira/browse/LANG-910
Project: Commons Lang
Issue Type: Bug
Components: lang.*
Affects Versions: 3.1
Environment: Developed on Ubuntu 13.04 with openjdk 7u25
Reporter: Timur Yarosh
Labels: patch
Fix For: 3.2, Discussion
Attachments: LANG-910.patch,
substring-matches-and-white-space-normalize.patch
This patch extends StringUtils capabilities: added methods to find
substring(s) by Pattern. Also method
org.apache.commons.lang3.StringUtils#normalizeSpace now replaces ASCII #160
char to normal whitespace.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (LANG-910) Patch to extend StringUtils
[ https://issues.apache.org/jira/browse/LANG-910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13802010#comment-13802010 ] Henri Yandell commented on LANG-910: Gotya. Sounds reasonable. I agree with the [0] group being supported btw. I'm going to drop the 3.2 off this for the moment as the patch needs more work. I also wonder if it should go in a PatternUtils. Patch to extend StringUtils --- Key: LANG-910 URL: https://issues.apache.org/jira/browse/LANG-910 Project: Commons Lang Issue Type: Bug Components: lang.* Affects Versions: 3.1 Environment: Developed on Ubuntu 13.04 with openjdk 7u25 Reporter: Timur Yarosh Labels: patch Fix For: Discussion Attachments: LANG-910.patch, substring-matches-and-white-space-normalize.patch This patch extends StringUtils capabilities: added methods to find substring(s) by Pattern. Also method org.apache.commons.lang3.StringUtils#normalizeSpace now replaces ASCII #160 char to normal whitespace. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-910) Patch to extend StringUtils
[ https://issues.apache.org/jira/browse/LANG-910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-910: --- Fix Version/s: (was: 3.2) Patch to extend StringUtils --- Key: LANG-910 URL: https://issues.apache.org/jira/browse/LANG-910 Project: Commons Lang Issue Type: Bug Components: lang.* Affects Versions: 3.1 Environment: Developed on Ubuntu 13.04 with openjdk 7u25 Reporter: Timur Yarosh Labels: patch Fix For: Discussion Attachments: LANG-910.patch, substring-matches-and-white-space-normalize.patch This patch extends StringUtils capabilities: added methods to find substring(s) by Pattern. Also method org.apache.commons.lang3.StringUtils#normalizeSpace now replaces ASCII #160 char to normal whitespace. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (IMAGING-115) DhtSegment class contains mutable public arrays
[ https://issues.apache.org/jira/browse/IMAGING-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13802045#comment-13802045 ] Damjan Jovanovic commented on IMAGING-115: -- DhtSegment fields are accessed from the performance-critical JPEG decompression path, so making those arrays private and returning copies in getters is probably out of the question. DhtSegment class contains mutable public arrays --- Key: IMAGING-115 URL: https://issues.apache.org/jira/browse/IMAGING-115 Project: Commons Imaging Issue Type: Bug Reporter: Sebb Mutable public arrays are very bad for thread-safety and maintainability. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (IMAGING-115) DhtSegment class contains mutable public arrays
[ https://issues.apache.org/jira/browse/IMAGING-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13802051#comment-13802051 ] Matt Benson commented on IMAGING-115: - Maybe some alternate design should be explored whereby the arrays are maintained privately to classes whose methods use the arrays with parameters that have been passed in. DhtSegment class contains mutable public arrays --- Key: IMAGING-115 URL: https://issues.apache.org/jira/browse/IMAGING-115 Project: Commons Imaging Issue Type: Bug Reporter: Sebb Mutable public arrays are very bad for thread-safety and maintainability. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (IMAGING-115) DhtSegment class contains mutable public arrays
[ https://issues.apache.org/jira/browse/IMAGING-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13802056#comment-13802056 ] Sebb commented on IMAGING-115: -- In which case use a getter that does not copy. At least it would be possible to have more control over thread-safety, and it would be possible to add debug tracing to accesses etc. A public mutable field is bad. DhtSegment class contains mutable public arrays --- Key: IMAGING-115 URL: https://issues.apache.org/jira/browse/IMAGING-115 Project: Commons Imaging Issue Type: Bug Reporter: Sebb Mutable public arrays are very bad for thread-safety and maintainability. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (LANG-417) ClassUtils: method for turning FQN into resource path
[
https://issues.apache.org/jira/browse/LANG-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13802060#comment-13802060
]
Woonsan Ko commented on LANG-417:
-
I'd like to suggest the following:
{code}
public class ResourceUtils {
public static String toAbsoluteResourceName(Package context, name);
public static String toAbsoluteResourceName(Class context, name);
}
{code}
According to the original description above, he just wanted to replace a
resource name by an absolute resource name. e.g, [ com.example.Hello.class,
'HelloMessage.properties' ] - 'com/example/HelloMessage.properties'.
In this sense, URL doesn't seem to be proper. URL is likely to have something
like 'file:///...', which is different from the original request. I assume he
wanted to use something like ClassLoader#getResource() in the end.
Also, the suggested api, toResourcePath(String fqName), doesn't seem to be
necessary in this sense.
By the way, I think we'd better use 'AbsoluteResourceName' instead of
'ResourcePath' because the former one is similar to the javadoc explanation in
java.lang.Class#getResource(name) (quote: Before delegation, an *absolute
resource name* is constructed from the given resource name using this
algorithm), and 'path' may sound confusing because the return value doesn't
represent a full (file) path at all.
Just my two cents,
Woonsan
ClassUtils: method for turning FQN into resource path
-
Key: LANG-417
URL: https://issues.apache.org/jira/browse/LANG-417
Project: Commons Lang
Issue Type: New Feature
Components: lang.*
Reporter: Paul Benedict
Fix For: Patch Needed
I commonly need a FQ path to a resource within the same location as a class
file. I recommend the addition of this method:
public String getPackageResourcePath(Class clazz, String resourceName)
StringBuffer buf = new StringBuffer();
buf.append(ClassUtils.getPackageName(getClass()).replace('.', '/'));
buf.append(/);
buf.append(resourceName);
return buf.toString();
}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (MATH-1045) EigenDecomposition.Solver should consider tiny values 0 for purposes of determining singularity
[ https://issues.apache.org/jira/browse/MATH-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13802067#comment-13802067 ] Gilles commented on MATH-1045: -- bq. On the other hand it seems a bit undesirable to return an 'inverse' in this case – it's dominated by the inverse of that tiny eigenvalue, which is huge, and the result is pretty unreliable. This could be case-dependent and the code should perhaps be able to detect and accept input that can return a reliable result. In r1534709, I've committed an example that seems to work, even as the eigenvalues are quite small indeed. bq. it's more reasonable to examine the eigenvalues in sorted order and examine ratio That's an interesting idea. Could you try and see whether it would let the new test pass, while intercepting the singular matrix of your test? EigenDecomposition.Solver should consider tiny values 0 for purposes of determining singularity --- Key: MATH-1045 URL: https://issues.apache.org/jira/browse/MATH-1045 Project: Commons Math Issue Type: Bug Affects Versions: 3.2 Reporter: Sean Owen Priority: Minor Labels: eigenvalue, singular Attachments: MATH-1045.patch EigenDecomposition.Solver tests for singularity by comparing eigenvalues to 0 for exact equality. Elsewhere in the class and in the code, of course, very small values are considered 0. This causes the solver to consider some singular matrices as non-singular. The patch here includes a test as well showing the behavior -- the matrix is clearly singular but isn't considered as such since one eigenvalue are ~1e-14 rather than exactly 0. (What I am not sure of is whether we should really be evaluating the *norm* of the imaginary eigenvalues rather than real/imag components separately. But the javadoc says the solver only supports real eigenvalues anyhow, so it's kind of moot since imag=0 for all eigenvalues.) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (IMAGING-117) SofnSegment.components - public mutable array
[ https://issues.apache.org/jira/browse/IMAGING-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13802068#comment-13802068 ] Damjan Jovanovic commented on IMAGING-117: -- Public mutable List: TiffContents.directories and ColorGroup.color_counts are now Collections.unmodifiableList()s Protected mutable arrays: But protected fields can only be written from subclasses and from the same package, both of which presumably know not to write to them. SofnSegment.components - public mutable array - Key: IMAGING-117 URL: https://issues.apache.org/jira/browse/IMAGING-117 Project: Commons Imaging Issue Type: Bug Reporter: Sebb -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (COLLECTIONS-485) Collection copy-constructors should accept wildcarded input
[
https://issues.apache.org/jira/browse/COLLECTIONS-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13802154#comment-13802154
]
Thomas Neidhart commented on COLLECTIONS-485:
-
I do not know exactly why sorted collections have no wildcard type in
java.util.Collections, but I assume it has something to do with the Comparator
being used to sort the item.
One of the requirements is that for no pair of elements in the collection, the
comparator may throw a ClassCastException.
Now, when enabling wildcards for sorted collections one can do the following
(without a warning):
{noformat}
SortedBagB bagB = new TreeBagB(new ComparatorB() {
public int compare(B o1, B o2) {
return o1.hashCode() - o2.hashCode();
}
});
bagB.add(new B());
SortedBagA bagA =
UnmodifiableSortedBag.AunmodifiableSortedBag(bagB);
SortedBagA bagA2 = new TreeBagA(bagA.comparator());
bagA2.addAll(bagA);
bagA2.add(new C());
{noformat}
This will result in a ClassCastException when you try to add a C object to
bagA2. This is maybe a bit far-fetched, but perfectly valid when allowing
wildcard generics for a SortedBag.
Collection copy-constructors should accept wildcarded input
---
Key: COLLECTIONS-485
URL: https://issues.apache.org/jira/browse/COLLECTIONS-485
Project: Commons Collections
Issue Type: Improvement
Components: Bag, BidiMap, Collection, List, Map, Set
Affects Versions: 4.0-alpha1
Reporter: Hollis Waite
Attachments: wildcards.patch
Many Collection constructors copy input in order to self-populate. For
convenience (and consistency with standard Java collections library),
wildcarded parameters should be accepted where possible. Unmodifiable*
classes might also benefit from less restrictive generic signatures.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Comment Edited] (COLLECTIONS-485) Collection copy-constructors should accept wildcarded input
[
https://issues.apache.org/jira/browse/COLLECTIONS-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13802154#comment-13802154
]
Thomas Neidhart edited comment on COLLECTIONS-485 at 10/22/13 7:20 PM:
---
I do not know exactly why sorted collections have no wildcard type in
java.util.Collections, but I assume it has something to do with the Comparator
being used to sort the items.
One of the requirements is that for no pair of elements in the collection, the
comparator may throw a ClassCastException.
Now, when enabling wildcards for sorted collections one can do the following
(without a warning):
{noformat}
SortedBagB bagB = new TreeBagB(new ComparatorB() {
public int compare(B o1, B o2) {
return o1.hashCode() - o2.hashCode();
}
});
bagB.add(new B());
SortedBagA bagA =
UnmodifiableSortedBag.AunmodifiableSortedBag(bagB);
SortedBagA bagA2 = new TreeBagA(bagA.comparator());
bagA2.addAll(bagA);
bagA2.add(new C());
{noformat}
This will result in a ClassCastException when you try to add a C object to
bagA2. This is maybe a bit far-fetched, but perfectly valid when allowing
wildcard types for a SortedBag.
was (Author: tn):
I do not know exactly why sorted collections have no wildcard type in
java.util.Collections, but I assume it has something to do with the Comparator
being used to sort the item.
One of the requirements is that for no pair of elements in the collection, the
comparator may throw a ClassCastException.
Now, when enabling wildcards for sorted collections one can do the following
(without a warning):
{noformat}
SortedBagB bagB = new TreeBagB(new ComparatorB() {
public int compare(B o1, B o2) {
return o1.hashCode() - o2.hashCode();
}
});
bagB.add(new B());
SortedBagA bagA =
UnmodifiableSortedBag.AunmodifiableSortedBag(bagB);
SortedBagA bagA2 = new TreeBagA(bagA.comparator());
bagA2.addAll(bagA);
bagA2.add(new C());
{noformat}
This will result in a ClassCastException when you try to add a C object to
bagA2. This is maybe a bit far-fetched, but perfectly valid when allowing
wildcard generics for a SortedBag.
Collection copy-constructors should accept wildcarded input
---
Key: COLLECTIONS-485
URL: https://issues.apache.org/jira/browse/COLLECTIONS-485
Project: Commons Collections
Issue Type: Improvement
Components: Bag, BidiMap, Collection, List, Map, Set
Affects Versions: 4.0-alpha1
Reporter: Hollis Waite
Attachments: wildcards.patch
Many Collection constructors copy input in order to self-populate. For
convenience (and consistency with standard Java collections library),
wildcarded parameters should be accepted where possible. Unmodifiable*
classes might also benefit from less restrictive generic signatures.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (LANG-922) Add isOneTrue(booleans...) to BooleanUtils to preserve old behavior of BooleanUtils.xor(booleans...)
[ https://issues.apache.org/jira/browse/LANG-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13802161#comment-13802161 ] Benedikt Ritter commented on LANG-922: -- I have removed isExactlyOneTrue in [r1534738|http://svn.apache.org/r1534738]. Add isOneTrue(booleans...) to BooleanUtils to preserve old behavior of BooleanUtils.xor(booleans...) Key: LANG-922 URL: https://issues.apache.org/jira/browse/LANG-922 Project: Commons Lang Issue Type: Bug Components: lang.* Reporter: Benedikt Ritter Assignee: Benedikt Ritter Fix For: Discussion The old implementation (prior to r1532476) of BooleanUtils.xor(boolean...) checked if the provided array contained exactly one boolean with value true. This was changed because it is not the correct behavior for an XOR operation. To preserve the behavior we should add BooleanUtils.isOneTrue(boolean...) and BooleanUtils.isOneTrue(Boolean...) (and possibly the equivalents for isOneFalse). -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-922) Add isOneTrue(booleans...) to BooleanUtils to preserve old behavior of BooleanUtils.xor(booleans...)
[ https://issues.apache.org/jira/browse/LANG-922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated LANG-922: - Fix Version/s: (was: 3.2) Add isOneTrue(booleans...) to BooleanUtils to preserve old behavior of BooleanUtils.xor(booleans...) Key: LANG-922 URL: https://issues.apache.org/jira/browse/LANG-922 Project: Commons Lang Issue Type: Bug Components: lang.* Reporter: Benedikt Ritter Assignee: Benedikt Ritter Fix For: Discussion The old implementation (prior to r1532476) of BooleanUtils.xor(boolean...) checked if the provided array contained exactly one boolean with value true. This was changed because it is not the correct behavior for an XOR operation. To preserve the behavior we should add BooleanUtils.isOneTrue(boolean...) and BooleanUtils.isOneTrue(Boolean...) (and possibly the equivalents for isOneFalse). -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (LANG-925) Deprecate o.a.c.lang.time.* package
[ https://issues.apache.org/jira/browse/LANG-925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13802165#comment-13802165 ] Benedikt Ritter commented on LANG-925: -- Later than 3.2? This isn't super critical for 3.2. Deprecate o.a.c.lang.time.* package --- Key: LANG-925 URL: https://issues.apache.org/jira/browse/LANG-925 Project: Commons Lang Issue Type: Task Components: lang.time.* Affects Versions: 3.1 Reporter: Benedikt Ritter Fix For: 3.2, Discussion We have discussed [1] to deprecate the time package, because it will become obsolete in Java 8. [1] http://markmail.org/message/uw3lggwkt5ul5b7k -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (LANG-848) Improve StringUtils.is(Not)Blank with a CharSequence... version
[
https://issues.apache.org/jira/browse/LANG-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13802164#comment-13802164
]
Benedikt Ritter commented on LANG-848:
--
How about adding the initial contribution with the varargs and post pone the
iterable version to 3.x?
Improve StringUtils.is(Not)Blank with a CharSequence... version
---
Key: LANG-848
URL: https://issues.apache.org/jira/browse/LANG-848
Project: Commons Lang
Issue Type: Improvement
Components: lang.*
Affects Versions: 3.1
Reporter: Alexander Muthmann
Fix For: 3.2, Discussion
Currently it's only possible to compare a single CharSequence per
is(Not)Blank/is(Not)Empty call.
This should be changed to support multiple CharSequences in a single call.
{code}
if(StringUtils.isNotBlank(foo) StringUtils.isNotBlank(bar) ...)
{code}
could be changed to
{code}
if(StringUtils.isNotBlank(foo, bar, ...)
{code}
As there are two possible ways to combine the results (AND and OR), it'd be
necessary to create multiple methods.
{code}
isAnyBlank(CharSequence... cs)
isNoneBlank(CharSequence... cs)
isAnyEmpty(CharSequence... cs)
isNoneEmpty(CharSequence... cs)
{code}
I could implement those methods and contribute them via github if there is
any interest from project's side.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (COLLECTIONS-485) Collection copy-constructors should accept wildcarded input
[ https://issues.apache.org/jira/browse/COLLECTIONS-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13802300#comment-13802300 ] Hollis Waite commented on COLLECTIONS-485: -- I do not know exactly why sorted collections have no wildcard type in java.util.Collections See comments from 10/5. I figured that it's because of the head/tail/sub-methods (which don't exist for Bag implementations). No big deal either way. Collection copy-constructors should accept wildcarded input --- Key: COLLECTIONS-485 URL: https://issues.apache.org/jira/browse/COLLECTIONS-485 Project: Commons Collections Issue Type: Improvement Components: Bag, BidiMap, Collection, List, Map, Set Affects Versions: 4.0-alpha1 Reporter: Hollis Waite Attachments: wildcards.patch Many Collection constructors copy input in order to self-populate. For convenience (and consistency with standard Java collections library), wildcarded parameters should be accepted where possible. Unmodifiable* classes might also benefit from less restrictive generic signatures. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (FUNCTOR-25) Update site after new project structure
[ https://issues.apache.org/jira/browse/FUNCTOR-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita resolved FUNCTOR-25. --- Resolution: Not A Problem The site can be generated with mvn site:stage Update site after new project structure --- Key: FUNCTOR-25 URL: https://issues.apache.org/jira/browse/FUNCTOR-25 Project: Commons Functor Issue Type: Improvement Reporter: Bruno P. Kinoshita Assignee: Bruno P. Kinoshita The site needs to be updated following the new project structure, with functor-api, functor-core and other modules before the initial release. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (FUNCTOR-14) Enhancements on the Generator API
[ https://issues.apache.org/jira/browse/FUNCTOR-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita resolved FUNCTOR-14. --- Resolution: Fixed Enhancements on the Generator API - Key: FUNCTOR-14 URL: https://issues.apache.org/jira/browse/FUNCTOR-14 Project: Commons Functor Issue Type: Improvement Reporter: Bruno P. Kinoshita Assignee: Bruno P. Kinoshita Priority: Minor Apparently, the Generator API in [functor] was created based on Python generators. However, there is room for enhancements in the current implementation. The Generator interface contains methods to stop its execution. However not all generators are necessarily 'stoppable'. Maybe we could move this behavior to a separate interface. The parameters passed to a generator (from, to, step) are the same that, in Python, can be used to create a Range. Ranges are used in many examples of Generators in Python. We could include Ranges in [functor] and utilize them in Generators. It would be good if we could include/exclude the Range boundary values, i.e. we could create a Range 0..2, and define 0 or 2, as being either inclusive or exclusive. Among the current generators, there is one for Integer's, and another one for Long's. We could create generators for other types too (e.g.: Char, Date, Double, Float, ...). Another feature usually related to Generators in Python is the yield statement. There are some API's in Java that provide a yield implementation. This is not entirely necessary, but could be convenient to include it to [functor] too, combined with Generators. Maybe in [functor] we could create a YieldProcedure. This way, the Generator would yield its values to this procedure. Just food for thought. This issue is quite vague, so feel free to add comments, or criticize. This way we can achieve a common consensus on a new and awesome Generator API for [functor]. No hard feelings :-) Cheers -- This message was sent by Atlassian JIRA (v6.1#6144)
