[jira] [Commented] (CLI-244) Non-existing option is not reported as a failure when it follows an option that accepts multiple values
[
https://issues.apache.org/jira/browse/CLI-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14482671#comment-14482671
]
Duncan Jones commented on CLI-244:
--
Marking this as blocked by CLI-221. Until the correct behaviour is determined,
this issue cannot be examined.
Non-existing option is not reported as a failure when it follows an option
that accepts multiple values
---
Key: CLI-244
URL: https://issues.apache.org/jira/browse/CLI-244
Project: Commons CLI
Issue Type: Bug
Components: CLI-1.x
Affects Versions: 1.2
Environment: Java 7
Linux/Windows
Reporter: Ivan C
Priority: Critical
If I define the following options:
{code:java}
Option dest = OptionBuilder
.withArgName(-d)
.withDescription(Destination)
.hasArg()
.create(-d);
dest.setRequired(true);
Option filenames = OptionBuilder
.withArgName(-f)
.withDescription(Filenames; comma separated)
.hasArgs()
.withValueSeparator(',')
.create(-f);
{code}
when I parse the following arguments
{code}
-d c:\development\test -f abc.txt -qa hello
{code}
rather than getting a ParseException, the code thinks abc.txt, -qa, hello are
the values for the -f option.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-740) Add a Memoizer class
[
https://issues.apache.org/jira/browse/LANG-740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14482755#comment-14482755
]
James Sawle commented on LANG-740:
--
Are they any comments about the structure or the change to the behaviour
(caching failed calculations)?
If not will tidy up the code against the current master and write tests. Also
under which package do you think this fits best?
Add a Memoizer class
Key: LANG-740
URL: https://issues.apache.org/jira/browse/LANG-740
Project: Commons Lang
Issue Type: New Feature
Components: lang.concurrent.*
Reporter: Gary Gregory
Assignee: Gary Gregory
Fix For: Review Patch, 3.5
Attachments: LANG-740.patch
I am currently using a class like the Memoizer class [1] from Java
Concurrency in Practice [2], a great book.
It would fit perfectly in org.apache.commons.lang3.concurrent.
[1] http://jcip.net/listings/Memoizer.java
[2] http://jcip.net/
There is no licensing issue because the code is in the public domain:
{noformat}
-- Forwarded message --
From: Brian Goetz br...@briangoetz.com
Date: Tue, Aug 9, 2011 at 5:40 PM
Subject: Re: Apache Commons Lang and Memoizer
To: Gary Gregory ggreg...@apache.org, Tim Peierls t...@peierls.net
No license issues -- the code is in the public domain:
Written by Brian Goetz and Tim Peierls with assistance from members of
JCP JSR-166 Expert Group and released to the public domain, as explained at
http://creativecommons.org/licenses/publicdomain
Code for the samples can be downloaded from http://www.jcip.net/listings.html.
Cheers,
-Brian
On 8/9/2011 5:38 PM, Gary Gregory wrote:
Hi Brian,
I would like to include a Memoizer in the next release of Apache
Commons Lang [1].
Can we use the Memoizer pattern from Java Concurrency in Practice? I
think I would reuse the code from the class Memoizer and change names,
things like that.
We are talking about this on the Lang mailing list and are wondering
if there are any licensing issues.
[1] https://commons.apache.org/lang/
--
Thank you,
Gary
http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-740) Add a Memoizer class
[
https://issues.apache.org/jira/browse/LANG-740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14482745#comment-14482745
]
Benedikt Ritter commented on LANG-740:
--
I'm setting this to be included in the next release (3.5)
Add a Memoizer class
Key: LANG-740
URL: https://issues.apache.org/jira/browse/LANG-740
Project: Commons Lang
Issue Type: New Feature
Components: lang.concurrent.*
Reporter: Gary Gregory
Assignee: Gary Gregory
Fix For: Review Patch, 3.5
Attachments: LANG-740.patch
I am currently using a class like the Memoizer class [1] from Java
Concurrency in Practice [2], a great book.
It would fit perfectly in org.apache.commons.lang3.concurrent.
[1] http://jcip.net/listings/Memoizer.java
[2] http://jcip.net/
There is no licensing issue because the code is in the public domain:
{noformat}
-- Forwarded message --
From: Brian Goetz br...@briangoetz.com
Date: Tue, Aug 9, 2011 at 5:40 PM
Subject: Re: Apache Commons Lang and Memoizer
To: Gary Gregory ggreg...@apache.org, Tim Peierls t...@peierls.net
No license issues -- the code is in the public domain:
Written by Brian Goetz and Tim Peierls with assistance from members of
JCP JSR-166 Expert Group and released to the public domain, as explained at
http://creativecommons.org/licenses/publicdomain
Code for the samples can be downloaded from http://www.jcip.net/listings.html.
Cheers,
-Brian
On 8/9/2011 5:38 PM, Gary Gregory wrote:
Hi Brian,
I would like to include a Memoizer in the next release of Apache
Commons Lang [1].
Can we use the Memoizer pattern from Java Concurrency in Practice? I
think I would reuse the code from the class Memoizer and change names,
things like that.
We are talking about this on the Lang mailing list and are wondering
if there are any licensing issues.
[1] https://commons.apache.org/lang/
--
Thank you,
Gary
http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-701) StringUtils join with var args
[
https://issues.apache.org/jira/browse/LANG-701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14482781#comment-14482781
]
James Sawle commented on LANG-701:
--
Sorry took a new job in October and have been trying to get up to speed with
different technologies.
Whilst I totally understand that the messages are not public APIs as not
documented, as they are returned and visible to the end user, they are as good
as public APIs, and possibly worse as there is no documentation when they
change. I am not suggesting that we document them, nor that we never change
them. But if they are asserted over, then if they are changed, then the tests
will need to be changed; and this is more likely to be highlighted in a code
review and lead to stable exception messages. Cases where I think we should be
asserting even if we don't on general messages is where there is dynamic data
within the message.
I suppose my thought is, that for a library that prides itself on stability, it
seems a way of suring up hidden API that every library has. But I understand
this is outside of the scope, so will remove it from the pull request; update
the request to be up-to-date with master and bring this up in a separate issue
with references.
StringUtils join with var args
--
Key: LANG-701
URL: https://issues.apache.org/jira/browse/LANG-701
Project: Commons Lang
Issue Type: New Feature
Components: lang.*
Reporter: Gabriele Kahlout
Priority: Minor
Fix For: Review Patch
Attachments: VarArgJoinTest.java
{code:java}
final String apple = apple;
final String banana = banana;
final String orange = orange;
final String expected = apple + SPACE + banana + SPACE + orange;
final String actual = join(SPACE, apple, banana, orange);
final int expLength = expected.length();
final int actLength = actual.length();
assertEquals(expLength, actLength);
assertEquals(expected, actual);
{code}
I missed the functionality of joining strings with the space separator in one
line. BTW, why space ' ' not a constant field anywhere?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (BCEL-216) Allow creation of class object constants
Markus Uhr created BCEL-216: --- Summary: Allow creation of class object constants Key: BCEL-216 URL: https://issues.apache.org/jira/browse/BCEL-216 Project: Commons BCEL Issue Type: Bug Components: Main Affects Versions: unspecified Reporter: Markus Uhr Priority: Minor Accessing class objects (e.g. String.class) gets BCELified as new PUSH(_cp, new ObjectType(java.lang.String)) which works fine. Trying to create such a constant using Factory.createConstant throws a ClassGenException, however: _factory.createConstant(new ObjectType(java.lang.String)) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LANG-1050) Change nullToEmpty methods to generics
[ https://issues.apache.org/jira/browse/LANG-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14482807#comment-14482807 ] James Sawle commented on LANG-1050: --- Could some please review the changes Change nullToEmpty methods to generics -- Key: LANG-1050 URL: https://issues.apache.org/jira/browse/LANG-1050 Project: Commons Lang Issue Type: Improvement Components: lang.* Reporter: James Sawle Assignee: Duncan Jones Fix For: Review Patch Currently there are multiple Object based methods which could be replaced by a single generic method. - public static Long[] nullToEmpty(final Long[] array) - public static Integer[] nullToEmpty(final Integer[] array) - public static Short[] nullToEmpty(final Short[] array) - public static Character[] nullToEmpty(final Character[] array) - public static Byte[] nullToEmpty(final Byte[] array) - public static Double[] nullToEmpty(final Double[] array) - public static Float[] nullToEmpty(final Float[] array) - public static Boolean[] nullToEmpty(final Boolean[] array) Recommendation, replace all of these with a single method that would also allow a defensive programming style when not using wrapped primitives. - public static T T[] nullToEmpty(final T[] array) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (LANG-740) Add a Memoizer class
[
https://issues.apache.org/jira/browse/LANG-740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter updated LANG-740:
-
Fix Version/s: 3.5
Add a Memoizer class
Key: LANG-740
URL: https://issues.apache.org/jira/browse/LANG-740
Project: Commons Lang
Issue Type: New Feature
Components: lang.concurrent.*
Reporter: Gary Gregory
Assignee: Gary Gregory
Fix For: Review Patch, 3.5
Attachments: LANG-740.patch
I am currently using a class like the Memoizer class [1] from Java
Concurrency in Practice [2], a great book.
It would fit perfectly in org.apache.commons.lang3.concurrent.
[1] http://jcip.net/listings/Memoizer.java
[2] http://jcip.net/
There is no licensing issue because the code is in the public domain:
{noformat}
-- Forwarded message --
From: Brian Goetz br...@briangoetz.com
Date: Tue, Aug 9, 2011 at 5:40 PM
Subject: Re: Apache Commons Lang and Memoizer
To: Gary Gregory ggreg...@apache.org, Tim Peierls t...@peierls.net
No license issues -- the code is in the public domain:
Written by Brian Goetz and Tim Peierls with assistance from members of
JCP JSR-166 Expert Group and released to the public domain, as explained at
http://creativecommons.org/licenses/publicdomain
Code for the samples can be downloaded from http://www.jcip.net/listings.html.
Cheers,
-Brian
On 8/9/2011 5:38 PM, Gary Gregory wrote:
Hi Brian,
I would like to include a Memoizer in the next release of Apache
Commons Lang [1].
Can we use the Memoizer pattern from Java Concurrency in Practice? I
think I would reuse the code from the class Memoizer and change names,
things like that.
We are talking about this on the Lang mailing list and are wondering
if there are any licensing issues.
[1] https://commons.apache.org/lang/
--
Thank you,
Gary
http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLI-221) cli's with last option as list type values and have argument are not parsed correctly
[
https://issues.apache.org/jira/browse/CLI-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14482665#comment-14482665
]
Duncan Jones commented on CLI-221:
--
The Javadocs do not make this sound optional. From
{{OptionBuilder::withValueSeparator}}:
bq. The next Option created uses sep as a means to separate argument values
At the very least, the Javadocs should be updated to make it clear that
whitespace will always remain a valid separator. We may also consider a new
method that exclusively uses the supplied separator.
Personally I find the current behaviour non-intuitive and I'm struggling to
imagine a use for it.
cli's with last option as list type values and have argument are not parsed
correctly
-
Key: CLI-221
URL: https://issues.apache.org/jira/browse/CLI-221
Project: Commons CLI
Issue Type: Bug
Components: Parser
Affects Versions: 1.2
Reporter: Gagan Jain
I have set the value separator for an option to be comma (',').
Consider the following cli:
cli definition : cmd1 -o1 comma separated values a1
command name: 'cmd1'
options: 'o1' accpets list of values separated by ','
arguments: 'a1' single valued argument
{code}cmd1 -o1 o1v1,o1v2,o1v3 a1v1{code}
GnuParser parses this the cli with o1 having values {o1v1, o1v2, o1v3, a1v1}
instead of {o1v1,o1v2,o1v3}
Bug seems to be in org.apache.commons.cli.Parser's class processArgs method.
{code:java}
public void processArgs(Option opt, ListIterator iter) throws
ParseException
{
// loop until an option is found
while (iter.hasNext())
{
String str = (String) iter.next();
// found an Option, not an argument
if (getOptions().hasOption(str) str.startsWith(-))
{
iter.previous();
break;
}
// found a value
try
{
opt.addValueForProcessing(Util.stripLeadingAndTrailingQuotes(str));
}
catch (RuntimeException exp)
{
iter.previous();
break;
}
}
if (opt.getValues() == null !opt.hasOptionalArg())
{
throw new MissingArgumentException(opt);
}
}
{code}
In my opinion, if a value separator is defined for option, and is other than
space (' '), loop should break immediately after one iteration.
Correct me, if I am wrong in my understanding.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-740) Add a Memoizer class
[
https://issues.apache.org/jira/browse/LANG-740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14482725#comment-14482725
]
James Sawle commented on LANG-740:
--
sorry I have been quiet for a while, been a busy period at work. Any progress
on this?
Add a Memoizer class
Key: LANG-740
URL: https://issues.apache.org/jira/browse/LANG-740
Project: Commons Lang
Issue Type: New Feature
Components: lang.concurrent.*
Reporter: Gary Gregory
Assignee: Gary Gregory
Fix For: Review Patch
Attachments: LANG-740.patch
I am currently using a class like the Memoizer class [1] from Java
Concurrency in Practice [2], a great book.
It would fit perfectly in org.apache.commons.lang3.concurrent.
[1] http://jcip.net/listings/Memoizer.java
[2] http://jcip.net/
There is no licensing issue because the code is in the public domain:
{noformat}
-- Forwarded message --
From: Brian Goetz br...@briangoetz.com
Date: Tue, Aug 9, 2011 at 5:40 PM
Subject: Re: Apache Commons Lang and Memoizer
To: Gary Gregory ggreg...@apache.org, Tim Peierls t...@peierls.net
No license issues -- the code is in the public domain:
Written by Brian Goetz and Tim Peierls with assistance from members of
JCP JSR-166 Expert Group and released to the public domain, as explained at
http://creativecommons.org/licenses/publicdomain
Code for the samples can be downloaded from http://www.jcip.net/listings.html.
Cheers,
-Brian
On 8/9/2011 5:38 PM, Gary Gregory wrote:
Hi Brian,
I would like to include a Memoizer in the next release of Apache
Commons Lang [1].
Can we use the Memoizer pattern from Java Concurrency in Practice? I
think I would reuse the code from the class Memoizer and change names,
things like that.
We are talking about this on the Lang mailing list and are wondering
if there are any licensing issues.
[1] https://commons.apache.org/lang/
--
Thank you,
Gary
http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1065) Merge date and time together
[ https://issues.apache.org/jira/browse/LANG-1065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14482739#comment-14482739 ] James Sawle commented on LANG-1065: --- Hi, My answer to this is two fold: - yes I do enjoy submitting patches - however, this is something we have custom implemented in our code base and I have had to do in multiple code bases elsewhere. Whilst Java 8 and Joda Time are nice solutions to the problem, both would be to large a refactor (and my previous projects would not have been supported within the contract) I can not believe we are the only two users of the commons-lang framework who would find this useful, maybe just the only two on the Jira boards. This would aid a lot, as would split methods doing the inverse. Merge date and time together Key: LANG-1065 URL: https://issues.apache.org/jira/browse/LANG-1065 Project: Commons Lang Issue Type: New Feature Components: lang.time.* Reporter: Paul Benedict Priority: Minor Fix For: Review Patch Original Estimate: 1h Remaining Estimate: 1h I have 2 java.util.Date objects -- one with the correct date and one with the correct time. This enhancement will create a new method to apply the respective fragments to a new java.util.Date instance. Possible signature: public static Date merge(Date date, Date time); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (COLLECTIONS-557) LRUMap memory usage vs size
[ https://issues.apache.org/jira/browse/COLLECTIONS-557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart updated COLLECTIONS-557: Fix Version/s: 4.1 LRUMap memory usage vs size --- Key: COLLECTIONS-557 URL: https://issues.apache.org/jira/browse/COLLECTIONS-557 Project: Commons Collections Issue Type: Improvement Components: Map Affects Versions: 3.2.1 Reporter: Philippe Mouawad Labels: MEMORY Fix For: 3.2.2, 4.1 Hello, Currently LRUMap uses maxSize parameter to configure its maxSize. This is not great for its memory usage. For example I have a use case where I can't really guess the target maxSize of LRUMap so I have put a big number . In reality I end up having 380 elements but LRUMap uses 33 Mb of memory because it allocates (as capacity) LOAD_FACTORxsupposed max size. It would be nice to have the possibility to set maxSize apart making it unrelated to capacity. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IMAGING-168) IPTC parser should use CodedCharacterSet tag to determine encoding of the IPTC tag values
sudeep khemka created IMAGING-168: - Summary: IPTC parser should use CodedCharacterSet tag to determine encoding of the IPTC tag values Key: IMAGING-168 URL: https://issues.apache.org/jira/browse/IMAGING-168 Project: Commons Imaging Issue Type: Bug Components: Format: JPEG Reporter: sudeep khemka The IPTC CodedCharacterSet tag can be used to specify the encoding of the IPTC tag values. But the setting is currently ignored. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (COLLECTIONS-464) Add FluentIterator / FluentIterable implementation
[ https://issues.apache.org/jira/browse/COLLECTIONS-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart updated COLLECTIONS-464: Fix Version/s: (was: 4.1) 4.x Add FluentIterator / FluentIterable implementation -- Key: COLLECTIONS-464 URL: https://issues.apache.org/jira/browse/COLLECTIONS-464 Project: Commons Collections Issue Type: Sub-task Components: Iterator Reporter: Thomas Neidhart Fix For: 4.x Add an iterator implementation supporting a fluent API, similar to the Iter class in jena. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (COLLECTIONS-553) TransformedMultiValuedMap.equals() fails when comparing the value with itself
[
https://issues.apache.org/jira/browse/COLLECTIONS-553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart resolved COLLECTIONS-553.
-
Resolution: Fixed
Fix Version/s: 4.1
Problem solved after fixing COLLECTIONS-543.
TransformedMultiValuedMap.equals() fails when comparing the value with itself
-
Key: COLLECTIONS-553
URL: https://issues.apache.org/jira/browse/COLLECTIONS-553
Project: Commons Collections
Issue Type: Bug
Components: Map
Affects Versions: 4.0
Reporter: M Kim
Fix For: 4.1
TransformedMultiValuedMap.equals() does not return true when comparing a
value of a Collection key with itself. Is it allowed to put Collection as a
key in TransformedMultiValuedMap at all? If not, I think it should be
specified in the document. Or, equals() should be fixed accordingly.
Reproduce step
{code:title=Test.java|borderStyle=solid}
public void test()
{
TransformedMultiValuedMap map =
TransformedMultiValuedMap.transformingMap((MultiValuedMap)new
MultiValuedHashMap(),TransformerUtils.stringValueTransformer(),
TransformerUtils.stringValueTransformer());
MultiValuedHashMap helperMap = new MultiValuedHashMap();
helperMap.put(KEY, Value);
Collection key = helperMap.keySet();
map.put(key, Hi);
Collection value = map.get(key);
assertTrue(Contract failed: value.equals(value), value.equals(value));
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (COLLECTIONS-395) Request for UnBoundedLRUMap implementation with extra get method
[ https://issues.apache.org/jira/browse/COLLECTIONS-395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved COLLECTIONS-395. - Resolution: Fixed Fix Version/s: (was: 4.x) 4.1 Added in r1671832 together with some javadoc fixes. Thanks for the report! Request for UnBoundedLRUMap implementation with extra get method Key: COLLECTIONS-395 URL: https://issues.apache.org/jira/browse/COLLECTIONS-395 Project: Commons Collections Issue Type: Wish Components: Map Affects Versions: Nightly Builds Reporter: David Hawthorne Priority: Minor Fix For: 4.1 I've created an UnBoundedLRUMap implementation (based off of BoundedLRUMap) using the svn tree at version 3.3, and this has come in so handy that it makes sense to suggest it to the masters in charge of the collections framework. One tweak I made to the copy we're using is an extra get method that takes two arguments: key and boolean. The boolean determines whether or not the MRU item is updated, so we can make requests into the map that do *not* affect order. This is sometimes necessary in real world environments where you do not want a data structure with LRU-only accesses. This implementation would solve the main problem we have with using the jdk's LinkedHashMap LRU implementation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (COLLECTIONS-554) NullPointerException in CollectionUtils.partition
[
https://issues.apache.org/jira/browse/COLLECTIONS-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart resolved COLLECTIONS-554.
-
Resolution: Invalid
Providing a factory that returns null objects does not make sense, and throwing
a NPE in this case is reasonable imho.
The second comment: a MultiValuedHashMap is *not* a java.util.Collection, thus
can not be used for the partition method.
NullPointerException in CollectionUtils.partition
-
Key: COLLECTIONS-554
URL: https://issues.apache.org/jira/browse/COLLECTIONS-554
Project: Commons Collections
Issue Type: Bug
Components: Collection
Affects Versions: 4.1
Reporter: M Kim
Priority: Minor
NullPointerException (NPE) is not suitably handled in
CollectionUtils.partition. With a nullFactory,
partitions.get(numberOfPredicates) can be null at line
partitions.get(numberOfPredicates).add(element);.
Stack trace:
{code}
test(Test)java.lang.NullPointerException
at
org.apache.commons.collections4.CollectionUtils.partition(CollectionUtils.java:1187)
at Test.test(Test.java:18)
{code}
Test case:
{code}
public void test() {
Collection input = CollectionUtils.permutations((java.util.Collection)new
CircularFifoQueue(10));
Factory factory = FactoryUtils.nullFactory();
NullIsFalsePredicate p = new
NullIsFalsePredicate(NullPredicate.nullPredicate());
Predicate[] predicates = p.getPredicates();
CollectionUtils.java.lang.Object,java.util.Collectionpartition((java.lang.Iterable)input,
factory, predicates);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (COLLECTIONS-342) Add ExpiringMap
[
https://issues.apache.org/jira/browse/COLLECTIONS-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart resolved COLLECTIONS-342.
-
Resolution: Later
Fix Version/s: (was: 4.x)
The PassiveExpiringMap has been added and there have been no requests to add a
variant which uses active expiration, thus I close this for now.
Add ExpiringMap
---
Key: COLLECTIONS-342
URL: https://issues.apache.org/jira/browse/COLLECTIONS-342
Project: Commons Collections
Issue Type: New Feature
Components: Map
Reporter: Marc Rohlfs
Assignee: Brent Worden
Priority: Minor
The project {{mina-core}} contains a very useful map implementation:
{{org.apache.mina.util.ExpiringMap}}. I'd suggest to adopt it for the
{{commons-collections}} project.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CLI-248) dead links on doc page
[ https://issues.apache.org/jira/browse/CLI-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duncan Jones resolved CLI-248. -- Resolution: Fixed Fix Version/s: 1.3 Assignee: Duncan Jones Thanks for spotting that. Assuming the Javadocs end up where they were before, this will fix it. Author: djones Date: Tue Apr 7 13:54:37 2015 New Revision: 1671849 URL: http://svn.apache.org/r1671849 Log: Fixed links to Javadoc (closes CLI-248). Modified: commons/proper/cli/trunk/src/changes/changes.xml commons/proper/cli/trunk/src/site/xdoc/introduction.xml dead links on doc page -- Key: CLI-248 URL: https://issues.apache.org/jira/browse/CLI-248 Project: Commons CLI Issue Type: Bug Components: Documentation Reporter: Gerard Weatherby Assignee: Duncan Jones Priority: Minor Labels: web-site Fix For: 1.3 Original Estimate: 24h Remaining Estimate: 24h http://commons.apache.org/proper/commons-cli/introduction.html Links to Option, Options, Command Line et. al. are dead (e.g. http://commons.apache.org/proper/commons-cli/api-release/org/apache/commons/cli/Options.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IO-294) Adding FileUtils.byteCountToDisplaySize(long size, boolean useSiUnits)
[
https://issues.apache.org/jira/browse/IO-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14483620#comment-14483620
]
Paul Benedict commented on IO-294:
--
Some thoughts:
* I would prefer an Enum over a boolean parameter.
* Regarding what package to put this in, I think FileUtils is still fine (it's
remains here even in 2.4) and an enhancement to use SI units seems like the
logical thing to do.
* Regarding the patch, the list of String[] abbreviations should be static --
no need to construct them on each method invocation.
* According to Wikipedia, the trend to use SI units is increasing
(http://en.wikipedia.org/wiki/Timeline_of_binary_prefixes).
Adding FileUtils.byteCountToDisplaySize(long size, boolean useSiUnits)
--
Key: IO-294
URL: https://issues.apache.org/jira/browse/IO-294
Project: Commons IO
Issue Type: New Feature
Components: Utilities
Affects Versions: 2.1
Reporter: Jean-Noel Rouvignac
Attachments: FileUtils.java, FileUtilsTest.java,
IO-294_FileSizeUnit.patch
I have written a little Utility method that might benefit Commons IO:
{code}
public class FileUtils {
/**
* Returns a human-readable version of the file size (original is in
bytes). The implementation has the following features:
* ul
* liSupports the SI or IEC units./li
* liSupports I18n/li
* liDisplay a one digit remainder (rounded down if less than 5,
rounded up otherwise)/li
* liOnce the main unit is = 100, drops the remainder which would be
over precision./li
* /ul
*
* @param size The number of bytes.
* @param useSiUnits if false, uses the IEC (International
Electrotechnical Commission) units (powers of 2), else uses SI (International
System of Units)
*units (powers of 10).
* @return A human-readable display value (includes units).
*/
public static String byteCountToDisplaySize(long size, boolean
useSiUnits) {
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1074) Add a method to ArrayUtils for removing all occurrences of a given element
[
https://issues.apache.org/jira/browse/LANG-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14483709#comment-14483709
]
Duncan Jones commented on LANG-1074:
Not to worry, I've patched this on the command line. Reviewing now...
Add a method to ArrayUtils for removing all occurrences of a given element
--
Key: LANG-1074
URL: https://issues.apache.org/jira/browse/LANG-1074
Project: Commons Lang
Issue Type: Improvement
Components: lang.*
Affects Versions: 3.3.2
Reporter: haiyang li
Priority: Minor
Fix For: Review Patch
Attachments: LANG-1074.patch.txt, LANG-1074_20150320.patch
Could we add the method: removeElementAll to remove all the occurrences of
the specified element from the specified
(boolean/char/byte/short/int/long/float/double/Object) array:
{code:title=org.apache.commons.lang3.ArrayUtils.java|borderStyle=solid}
public static T T[] removeElementAll(final T[] array, final Object
element) {
int index = indexOf(array, element);
if (index == INDEX_NOT_FOUND) {
return clone(array);
}
int[] indices = new int[array.length - index];
int count = 0;
indices[count++] = index;
for (;;) {
index = indexOf(array, element, ++index);
if (index == INDEX_NOT_FOUND) {
break;
} else {
indices[count++] = index;
}
}
return (T[]) removeAll((Object) array, Arrays.copyOfRange(indices, 0,
count));
}
{code}
or maybe better:
{code:title=org.apache.commons.lang3.ArrayUtils.java|borderStyle=solid}
public static T T[] removeElement(final T[] a, final Object element,
boolean removeAll) {
int index = indexOf(a, element);
if (index == INDEX_NOT_FOUND) {
return clone(a);
} else if (!removeAll || index = a.length - 1) {
return remove(a, index);
} else {
int[] indices = new int[a.length - index];
int count = 0;
indices[count++] = index++;
for (int len = a.length; index len; index++) {
if ((a[index] == null) ? element == null : (element == null ?
false : a[index].equals(element))) {
indices[count++] = index;
}
}
return (T[]) removeAll((Object) a, Arrays.copyOfRange(indices, 0,
count));
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IO-475) FilenameUtils#normalizeNoEndSeparator returns null for UNC prefix without trailing backslash
Scott Hoof created IO-475:
-
Summary: FilenameUtils#normalizeNoEndSeparator returns null for
UNC prefix without trailing backslash
Key: IO-475
URL: https://issues.apache.org/jira/browse/IO-475
Project: Commons IO
Issue Type: Bug
Affects Versions: 2.4, 2.3, 2.2, 2.1, 2.0.1, 2.0, 1.4
Reporter: Scott Hoof
Priority: Minor
FilenameUtils#normalizeNoEndSeparator returns null for UNC prefix without
trailing backslash.
The observed behavior is that normalizeNoEndSeparator returns a non-null value
for the following unc-path-prefix:
\\{serverName-or-IP}\
but returns null for the following unc-path-prefix:
\\{serverName-or-IP}
There is nothing in the Microsoft API documentation which would suggest that
the second unc-path-prefix would be invalid.
Therefore the expectation is that they should be treated as equivalent by
FilenameUtils#normalizeNoEndSeparator.
The handling of unc-path-prefix is inconsistent with how
FilenameUtils#normalizeNoEndSeparator handles drive relative and drive absolute
path prefixes, where each notation is accepted and returns a non-null -- ( C:
and C:\ ).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IO-475) FilenameUtils#normalizeNoEndSeparator returns null for UNC prefix without trailing backslash
[
https://issues.apache.org/jira/browse/IO-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Hoof updated IO-475:
--
Description:
FilenameUtils#normalizeNoEndSeparator returns null for UNC prefix without
trailing backslash.
The observed behavior is that normalizeNoEndSeparator returns a non-null value
for the following unc-path-prefix:
{serverName-or-IP}\
but returns null for the following unc-path-prefix:
{serverName-or-IP}
There is nothing in the Microsoft API documentation which would suggest that
the second unc-path-prefix would be invalid.
Therefore the expectation is that they should be treated as equivalent by
FilenameUtils#normalizeNoEndSeparator.
The handling of unc-path-prefix is inconsistent with how
FilenameUtils#normalizeNoEndSeparator handles drive relative and drive absolute
path prefixes, where each notation is accepted and returns a non-null -- ( C:
and C:\ ).
was:
FilenameUtils#normalizeNoEndSeparator returns null for UNC prefix without
trailing backslash.
The observed behavior is that normalizeNoEndSeparator returns a non-null value
for the following unc-path-prefix:
\\{serverName-or-IP}\
but returns null for the following unc-path-prefix:
\\{serverName-or-IP}
There is nothing in the Microsoft API documentation which would suggest that
the second unc-path-prefix would be invalid.
Therefore the expectation is that they should be treated as equivalent by
FilenameUtils#normalizeNoEndSeparator.
The handling of unc-path-prefix is inconsistent with how
FilenameUtils#normalizeNoEndSeparator handles drive relative and drive absolute
path prefixes, where each notation is accepted and returns a non-null -- ( C:
and C:\ ).
FilenameUtils#normalizeNoEndSeparator returns null for UNC prefix without
trailing backslash
Key: IO-475
URL: https://issues.apache.org/jira/browse/IO-475
Project: Commons IO
Issue Type: Bug
Affects Versions: 1.4, 2.0, 2.0.1, 2.1, 2.2, 2.3, 2.4
Reporter: Scott Hoof
Priority: Minor
FilenameUtils#normalizeNoEndSeparator returns null for UNC prefix without
trailing backslash.
The observed behavior is that normalizeNoEndSeparator returns a non-null
value for the following unc-path-prefix:
{serverName-or-IP}\
but returns null for the following unc-path-prefix:
{serverName-or-IP}
There is nothing in the Microsoft API documentation which would suggest that
the second unc-path-prefix would be invalid.
Therefore the expectation is that they should be treated as equivalent by
FilenameUtils#normalizeNoEndSeparator.
The handling of unc-path-prefix is inconsistent with how
FilenameUtils#normalizeNoEndSeparator handles drive relative and drive
absolute path prefixes, where each notation is accepted and returns a
non-null -- ( C: and C:\ ).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IO-475) FilenameUtils#normalizeNoEndSeparator returns null for UNC prefix without trailing backslash
[
https://issues.apache.org/jira/browse/IO-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Hoof updated IO-475:
--
Description:
FilenameUtils#normalizeNoEndSeparator returns null for UNC prefix without
trailing backslash.
The observed behavior is that normalizeNoEndSeparator returns a non-null value
for the following unc-path-prefix:
\\{serverName-or-IP}\
but returns null for the following unc-path-prefix:
\\{serverName-or-IP}
There is nothing in the Microsoft API documentation which would suggest that
the second unc-path-prefix would be invalid.
Therefore the expectation is that they should be treated as equivalent by
FilenameUtils#normalizeNoEndSeparator.
The handling of unc-path-prefix is inconsistent with how
FilenameUtils#normalizeNoEndSeparator handles drive relative and drive absolute
path prefixes, where each notation is accepted and returns a non-null -- ( C:
and C:\ ).
was:
FilenameUtils#normalizeNoEndSeparator returns null for UNC prefix without
trailing backslash.
The observed behavior is that normalizeNoEndSeparator returns a non-null value
for the following unc-path-prefix:
\\\{serverName-or-IP}\
but returns null for the following unc-path-prefix:
\\\{serverName-or-IP}
There is nothing in the Microsoft API documentation which would suggest that
the second unc-path-prefix would be invalid.
Therefore the expectation is that they should be treated as equivalent by
FilenameUtils#normalizeNoEndSeparator.
The handling of unc-path-prefix is inconsistent with how
FilenameUtils#normalizeNoEndSeparator handles drive relative and drive absolute
path prefixes, where each notation is accepted and returns a non-null -- ( C:
and C:\ ).
FilenameUtils#normalizeNoEndSeparator returns null for UNC prefix without
trailing backslash
Key: IO-475
URL: https://issues.apache.org/jira/browse/IO-475
Project: Commons IO
Issue Type: Bug
Affects Versions: 1.4, 2.0, 2.0.1, 2.1, 2.2, 2.3, 2.4
Reporter: Scott Hoof
Priority: Minor
FilenameUtils#normalizeNoEndSeparator returns null for UNC prefix without
trailing backslash.
The observed behavior is that normalizeNoEndSeparator returns a non-null
value for the following unc-path-prefix:
\\{serverName-or-IP}\
but returns null for the following unc-path-prefix:
\\{serverName-or-IP}
There is nothing in the Microsoft API documentation which would suggest that
the second unc-path-prefix would be invalid.
Therefore the expectation is that they should be treated as equivalent by
FilenameUtils#normalizeNoEndSeparator.
The handling of unc-path-prefix is inconsistent with how
FilenameUtils#normalizeNoEndSeparator handles drive relative and drive
absolute path prefixes, where each notation is accepted and returns a
non-null -- ( C: and C:\ ).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IO-475) FilenameUtils#normalizeNoEndSeparator returns null for UNC prefix without trailing backslash
[
https://issues.apache.org/jira/browse/IO-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Hoof updated IO-475:
--
Description:
FilenameUtils#normalizeNoEndSeparator returns null for UNC prefix without
trailing backslash.
The observed behavior is that normalizeNoEndSeparator returns a non-null value
for the following unc-path-prefix:
\\\{serverName-or-IP}\
but returns null for the following unc-path-prefix:
\\\{serverName-or-IP}
There is nothing in the Microsoft API documentation which would suggest that
the second unc-path-prefix would be invalid.
Therefore the expectation is that they should be treated as equivalent by
FilenameUtils#normalizeNoEndSeparator.
The handling of unc-path-prefix is inconsistent with how
FilenameUtils#normalizeNoEndSeparator handles drive relative and drive absolute
path prefixes, where each notation is accepted and returns a non-null -- ( C:
and C:\ ).
was:
FilenameUtils#normalizeNoEndSeparator returns null for UNC prefix without
trailing backslash.
The observed behavior is that normalizeNoEndSeparator returns a non-null value
for the following unc-path-prefix:
\\{serverName-or-IP}\
but returns null for the following unc-path-prefix:
\\{serverName-or-IP}
There is nothing in the Microsoft API documentation which would suggest that
the second unc-path-prefix would be invalid.
Therefore the expectation is that they should be treated as equivalent by
FilenameUtils#normalizeNoEndSeparator.
The handling of unc-path-prefix is inconsistent with how
FilenameUtils#normalizeNoEndSeparator handles drive relative and drive absolute
path prefixes, where each notation is accepted and returns a non-null -- ( C:
and C:\ ).
FilenameUtils#normalizeNoEndSeparator returns null for UNC prefix without
trailing backslash
Key: IO-475
URL: https://issues.apache.org/jira/browse/IO-475
Project: Commons IO
Issue Type: Bug
Affects Versions: 1.4, 2.0, 2.0.1, 2.1, 2.2, 2.3, 2.4
Reporter: Scott Hoof
Priority: Minor
FilenameUtils#normalizeNoEndSeparator returns null for UNC prefix without
trailing backslash.
The observed behavior is that normalizeNoEndSeparator returns a non-null
value for the following unc-path-prefix:
\\\{serverName-or-IP}\
but returns null for the following unc-path-prefix:
\\\{serverName-or-IP}
There is nothing in the Microsoft API documentation which would suggest that
the second unc-path-prefix would be invalid.
Therefore the expectation is that they should be treated as equivalent by
FilenameUtils#normalizeNoEndSeparator.
The handling of unc-path-prefix is inconsistent with how
FilenameUtils#normalizeNoEndSeparator handles drive relative and drive
absolute path prefixes, where each notation is accepted and returns a
non-null -- ( C: and C:\ ).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IO-475) FilenameUtils#normalizeNoEndSeparator returns null for UNC prefix without trailing backslash
[
https://issues.apache.org/jira/browse/IO-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Hoof updated IO-475:
--
Description:
FilenameUtils#normalizeNoEndSeparator returns null for UNC prefix without
trailing backslash.
The observed behavior is that normalizeNoEndSeparator returns a non-null value
for the following unc-path-prefix:
\\{serverName-or-IP}\
{backSlash}{backSlash}{serverName-or-IP}{backSlash}
but returns null for the following unc-path-prefix:
\\{serverName-or-IP}
{backSlash}{backSlash}{serverName-or-IP}
The markdown seems to eat my backslashes prepended to the serverName-or-IP.
There is nothing in the Microsoft API documentation which would suggest that
the second unc-path-prefix would be invalid.
Therefore the expectation is that they should be treated as equivalent by
FilenameUtils#normalizeNoEndSeparator.
The handling of unc-path-prefix is inconsistent with how
FilenameUtils#normalizeNoEndSeparator handles drive relative and drive absolute
path prefixes, where each notation is accepted and returns a non-null -- ( C:
and C:\ ).
was:
FilenameUtils#normalizeNoEndSeparator returns null for UNC prefix without
trailing backslash.
The observed behavior is that normalizeNoEndSeparator returns a non-null value
for the following unc-path-prefix:
\\{serverName-or-IP}\
{backSlash}{backSlash}{serverName-or-IP}{backSlash}
but returns null for the following unc-path-prefix:
\\{serverName-or-IP}
{backSlash}{backSlash}{serverName-or-IP}
The markdown seems to eat my backslashes prepended to the serverName-or-IP.
There is nothing in the Microsoft API documentation which would suggest that
the second unc-path-prefix would be invalid.
Therefore the expectation is that they should be treated as equivalent by
FilenameUtils#normalizeNoEndSeparator.
The handling of unc-path-prefix is inconsistent with how
FilenameUtils#normalizeNoEndSeparator handles drive relative and drive absolute
path prefixes, where each notation is accepted and returns a non-null -- ( C:
and C:\ ).
FilenameUtils#normalizeNoEndSeparator returns null for UNC prefix without
trailing backslash
Key: IO-475
URL: https://issues.apache.org/jira/browse/IO-475
Project: Commons IO
Issue Type: Bug
Affects Versions: 1.4, 2.0, 2.0.1, 2.1, 2.2, 2.3, 2.4
Reporter: Scott Hoof
Priority: Minor
FilenameUtils#normalizeNoEndSeparator returns null for UNC prefix without
trailing backslash.
The observed behavior is that normalizeNoEndSeparator returns a non-null
value for the following unc-path-prefix:
\\{serverName-or-IP}\
{backSlash}{backSlash}{serverName-or-IP}{backSlash}
but returns null for the following unc-path-prefix:
\\{serverName-or-IP}
{backSlash}{backSlash}{serverName-or-IP}
The markdown seems to eat my backslashes prepended to the serverName-or-IP.
There is nothing in the Microsoft API documentation which would suggest that
the second unc-path-prefix would be invalid.
Therefore the expectation is that they should be treated as equivalent by
FilenameUtils#normalizeNoEndSeparator.
The handling of unc-path-prefix is inconsistent with how
FilenameUtils#normalizeNoEndSeparator handles drive relative and drive
absolute path prefixes, where each notation is accepted and returns a
non-null -- ( C: and C:\ ).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IO-475) FilenameUtils#normalizeNoEndSeparator returns null for UNC prefix without trailing backslash
[
https://issues.apache.org/jira/browse/IO-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Hoof updated IO-475:
--
Description:
FilenameUtils#normalizeNoEndSeparator returns null for UNC prefix without
trailing backslash.
The observed behavior is that normalizeNoEndSeparator returns a non-null value
for the following unc-path-prefix:
\\{serverName-or-IP}\
{backSlash}{backSlash}{serverName-or-IP}{backSlash}
but returns null for the following unc-path-prefix:
\\{serverName-or-IP}
{backSlash}{backSlash}{serverName-or-IP}
The markdown seems to eat my backslashes prepended to the serverName-or-IP.
There is nothing in the Microsoft API documentation which would suggest that
the second unc-path-prefix would be invalid.
Therefore the expectation is that they should be treated as equivalent by
FilenameUtils#normalizeNoEndSeparator.
The handling of unc-path-prefix is inconsistent with how
FilenameUtils#normalizeNoEndSeparator handles drive relative and drive absolute
path prefixes, where each notation is accepted and returns a non-null -- ( C:
and C:\ ).
was:
FilenameUtils#normalizeNoEndSeparator returns null for UNC prefix without
trailing backslash.
The observed behavior is that normalizeNoEndSeparator returns a non-null value
for the following unc-path-prefix:
\\{serverName-or-IP}\
{backSlash}{backSlash}{serverName-or-IP}{backSlash}
but returns null for the following unc-path-prefix:
\\{serverName-or-IP}
{backSlash}{backSlash}{serverName-or-IP}
The markdown seems to eat my backslashes prepended to the serverName-or-IP.
There is nothing in the Microsoft API documentation which would suggest that
the second unc-path-prefix would be invalid.
Therefore the expectation is that they should be treated as equivalent by
FilenameUtils#normalizeNoEndSeparator.
The handling of unc-path-prefix is inconsistent with how
FilenameUtils#normalizeNoEndSeparator handles drive relative and drive absolute
path prefixes, where each notation is accepted and returns a non-null -- ( C:
and C:\ ).
FilenameUtils#normalizeNoEndSeparator returns null for UNC prefix without
trailing backslash
Key: IO-475
URL: https://issues.apache.org/jira/browse/IO-475
Project: Commons IO
Issue Type: Bug
Affects Versions: 1.4, 2.0, 2.0.1, 2.1, 2.2, 2.3, 2.4
Reporter: Scott Hoof
Priority: Minor
FilenameUtils#normalizeNoEndSeparator returns null for UNC prefix without
trailing backslash.
The observed behavior is that normalizeNoEndSeparator returns a non-null
value for the following unc-path-prefix:
\\{serverName-or-IP}\
{backSlash}{backSlash}{serverName-or-IP}{backSlash}
but returns null for the following unc-path-prefix:
\\{serverName-or-IP}
{backSlash}{backSlash}{serverName-or-IP}
The markdown seems to eat my backslashes prepended to the serverName-or-IP.
There is nothing in the Microsoft API documentation which would suggest that
the second unc-path-prefix would be invalid.
Therefore the expectation is that they should be treated as equivalent by
FilenameUtils#normalizeNoEndSeparator.
The handling of unc-path-prefix is inconsistent with how
FilenameUtils#normalizeNoEndSeparator handles drive relative and drive
absolute path prefixes, where each notation is accepted and returns a
non-null -- ( C: and C:\ ).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IO-475) FilenameUtils#normalizeNoEndSeparator returns null for UNC prefix without trailing backslash
[
https://issues.apache.org/jira/browse/IO-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Hoof updated IO-475:
--
Description:
FilenameUtils#normalizeNoEndSeparator returns null for UNC prefix without
trailing backslash.
The observed behavior is that normalizeNoEndSeparator returns a non-null value
for the following unc-path-prefix:
\\{serverName-or-IP}\
{backSlash}{backSlash}{serverName-or-IP}{backSlash}
but returns null for the following unc-path-prefix:
\\{serverName-or-IP}
{backSlash}{backSlash}{serverName-or-IP}
The markdown seems to eat my backslashes prepended to the serverName-or-IP.
There is nothing in the Microsoft API documentation which would suggest that
the second unc-path-prefix would be invalid.
Therefore the expectation is that they should be treated as equivalent by
FilenameUtils#normalizeNoEndSeparator.
The handling of unc-path-prefix is inconsistent with how
FilenameUtils#normalizeNoEndSeparator handles drive relative and drive absolute
path prefixes, where each notation is accepted and returns a non-null -- ( C:
and C:\ ).
was:
FilenameUtils#normalizeNoEndSeparator returns null for UNC prefix without
trailing backslash.
The observed behavior is that normalizeNoEndSeparator returns a non-null value
for the following unc-path-prefix:
\\{serverName-or-IP}\
{backSlash}{backSlash}{serverName-or-IP}{backSlash}
but returns null for the following unc-path-prefix:
\\{serverName-or-IP}
{backSlash}{backSlash}{serverName-or-IP}
The markdown seems to eat my backslashes prepended to the serverName-or-IP.
There is nothing in the Microsoft API documentation which would suggest that
the second unc-path-prefix would be invalid.
Therefore the expectation is that they should be treated as equivalent by
FilenameUtils#normalizeNoEndSeparator.
The handling of unc-path-prefix is inconsistent with how
FilenameUtils#normalizeNoEndSeparator handles drive relative and drive absolute
path prefixes, where each notation is accepted and returns a non-null -- ( C:
and C:\ ).
FilenameUtils#normalizeNoEndSeparator returns null for UNC prefix without
trailing backslash
Key: IO-475
URL: https://issues.apache.org/jira/browse/IO-475
Project: Commons IO
Issue Type: Bug
Affects Versions: 1.4, 2.0, 2.0.1, 2.1, 2.2, 2.3, 2.4
Reporter: Scott Hoof
Priority: Minor
FilenameUtils#normalizeNoEndSeparator returns null for UNC prefix without
trailing backslash.
The observed behavior is that normalizeNoEndSeparator returns a non-null
value for the following unc-path-prefix:
\\{serverName-or-IP}\
{backSlash}{backSlash}{serverName-or-IP}{backSlash}
but returns null for the following unc-path-prefix:
\\{serverName-or-IP}
{backSlash}{backSlash}{serverName-or-IP}
The markdown seems to eat my backslashes prepended to the serverName-or-IP.
There is nothing in the Microsoft API documentation which would suggest that
the second unc-path-prefix would be invalid.
Therefore the expectation is that they should be treated as equivalent by
FilenameUtils#normalizeNoEndSeparator.
The handling of unc-path-prefix is inconsistent with how
FilenameUtils#normalizeNoEndSeparator handles drive relative and drive
absolute path prefixes, where each notation is accepted and returns a
non-null -- ( C: and C:\ ).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IO-475) FilenameUtils#normalizeNoEndSeparator returns null for UNC prefix without trailing backslash
[
https://issues.apache.org/jira/browse/IO-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Hoof updated IO-475:
--
Description:
FilenameUtils#normalizeNoEndSeparator returns null for UNC prefix without
trailing backslash.
The observed behavior is that normalizeNoEndSeparator returns a non-null value
for the following unc-path-prefix:
\\{serverName-or-IP}\
{backSlash}{backSlash}{serverName-or-IP}{backSlash}
but returns null for the following unc-path-prefix:
\\{serverName-or-IP}
{backSlash}{backSlash}{serverName-or-IP}
The markdown seems to eat my backslashes prepended to the serverName-or-IP.
There is nothing in the Microsoft API documentation which would suggest that
the second unc-path-prefix would be invalid.
Therefore the expectation is that they should be treated as equivalent by
FilenameUtils#normalizeNoEndSeparator.
The handling of unc-path-prefix is inconsistent with how
FilenameUtils#normalizeNoEndSeparator handles drive relative and drive absolute
path prefixes, where each notation is accepted and returns a non-null -- ( C:
and C:\ ).
was:
FilenameUtils#normalizeNoEndSeparator returns null for UNC prefix without
trailing backslash.
The observed behavior is that normalizeNoEndSeparator returns a non-null value
for the following unc-path-prefix:
\\{serverName-or-IP}\
but returns null for the following unc-path-prefix:
\\{serverName-or-IP}
There is nothing in the Microsoft API documentation which would suggest that
the second unc-path-prefix would be invalid.
Therefore the expectation is that they should be treated as equivalent by
FilenameUtils#normalizeNoEndSeparator.
The handling of unc-path-prefix is inconsistent with how
FilenameUtils#normalizeNoEndSeparator handles drive relative and drive absolute
path prefixes, where each notation is accepted and returns a non-null -- ( C:
and C:\ ).
FilenameUtils#normalizeNoEndSeparator returns null for UNC prefix without
trailing backslash
Key: IO-475
URL: https://issues.apache.org/jira/browse/IO-475
Project: Commons IO
Issue Type: Bug
Affects Versions: 1.4, 2.0, 2.0.1, 2.1, 2.2, 2.3, 2.4
Reporter: Scott Hoof
Priority: Minor
FilenameUtils#normalizeNoEndSeparator returns null for UNC prefix without
trailing backslash.
The observed behavior is that normalizeNoEndSeparator returns a non-null
value for the following unc-path-prefix:
\\{serverName-or-IP}\
{backSlash}{backSlash}{serverName-or-IP}{backSlash}
but returns null for the following unc-path-prefix:
\\{serverName-or-IP}
{backSlash}{backSlash}{serverName-or-IP}
The markdown seems to eat my backslashes prepended to the serverName-or-IP.
There is nothing in the Microsoft API documentation which would suggest that
the second unc-path-prefix would be invalid.
Therefore the expectation is that they should be treated as equivalent by
FilenameUtils#normalizeNoEndSeparator.
The handling of unc-path-prefix is inconsistent with how
FilenameUtils#normalizeNoEndSeparator handles drive relative and drive
absolute path prefixes, where each notation is accepted and returns a
non-null -- ( C: and C:\ ).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MATH-1211) PolyhedronsSet.firstIntersection(Vector3D point, Line line) sometimes reports intersections on wrong end of line
Mike Zimmerman created MATH-1211: Summary: PolyhedronsSet.firstIntersection(Vector3D point, Line line) sometimes reports intersections on wrong end of line Key: MATH-1211 URL: https://issues.apache.org/jira/browse/MATH-1211 Project: Commons Math Issue Type: Bug Reporter: Mike Zimmerman I constructed a PolyhedronsSet from a list of triangular faces representing an icosphere (using the instructions found at https://mail-archives.apache.org/mod_mbox/commons-user/201208.mbox/5039fe35.2090...@free.fr). This seems to produce correct INSIDE/OUTSIDE results for randomly chosen points. I think my mesh triangles are defined appropriately. However, using PolyhedronsSet.firstIntersection(Vector3D point, Line line) to shoot randomly oriented rays from the origin sometimes gives a wrong mesh intersection point behind the origin. The intersection algorithm is sometimes picking up faces of the sphere-shaped mesh on the wrong semi-infinite portion of the line, i.e. meshIntersectionPoint.subtract(point).dotProduct(line.getDirection())0 where point is the Vector3D at center of the sphere and line extends outward through the mesh. I think the dot product above should always be positive. If multiple intersections exist along a whole line then the first one in front of the line's origin should be returned. This makes ray tracing with a PolyhedronsSet possible. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (LANG-1107) Fix parsing edge cases in FastDateParser
[ https://issues.apache.org/jira/browse/LANG-1107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charles Honton resolved LANG-1107. -- Resolution: Fixed Fix Version/s: (was: Patch Needed) 3.5 r1671992 Fix parsing edge cases in FastDateParser Key: LANG-1107 URL: https://issues.apache.org/jira/browse/LANG-1107 Project: Commons Lang Issue Type: Improvement Components: lang.time.* Reporter: Benedikt Ritter Assignee: Charles Honton Fix For: 3.5 There are two commented out tests in FastDateParserSDFTest: * testLowerCase * testLowerCasePP When activating these tests, the build fails with 6 failures. This indicates, that there are edge cases in date parsing, where FastDateFormat behave different vom SimpleDateFormat. This this be fixed so that the parsing result is the same for FastDateParser and SimpleDateParser. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LANG-916) CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations
[
https://issues.apache.org/jira/browse/LANG-916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14484761#comment-14484761
]
Christian P. MOMON commented on LANG-916:
-
Here are the results of my investigations.
A) Thomas Neidhart patch is really good.
I confirm that the patch from Thomas Neidhart is the good way.
It is easy to verify:
FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(Asia/Kolkata)).format(cal)
1- FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(Asia/Kolkata))
2-- .format(cal)
3--- return printer.format(calendar)
4 return format(calendar, new
StringBuffer(this.mMaxLengthEstimate)).toString()
5- return applyRules(calendar, buf);
Step 1: store the TimeZone parameter in a FastDateFormat instance and build
rules from the pattern to display.
Step 5: apply previously build rules to the parameter 'calendar'. So, there is
no use of the TimeZone parameter stored in step 1 = **BUG**
In his patch, Thomas Neidhart calls the newCalendar(); method which build a new
calendar using the TimeZone parameter stored in step 1. Then, this new calendar
is used to apply rules.
It is exactly what it is done in other methods called format too but with a
different parameter type (Date, long...). For each, there is a comment // hard
code GregorianCalendar.
The method format must build a new calendar with the timezone previously
stored.
B) Test errors come from bad test.
Almost all test errors come from a flawed test. In
FastDatePrinterTimeZonesTest.testCalendarTimezoneRespected, we can see:
final String actualValue = FastDateFormat.getInstance(PATTERN).format(cal);
As the TimeZone is not setted, then the TimeZone.getDefault() is set and so it
is different than the original timezone. So the displayed result is not the
same.
Fix: final String actualValue = FastDateFormat.getInstance(PATTERN,
this.timeZone).format(cal);
It must also be true of other tests.
So, definitively, the patch from Thomas Neidhart is the good way.
I will try to provide patches for tests.
CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in
certain situations
Key: LANG-916
URL: https://issues.apache.org/jira/browse/LANG-916
Project: Commons Lang
Issue Type: Bug
Components: lang.time.*
Affects Versions: 3.1
Environment: Sun JDK 1.6.0_45 and 1.7.0_21 on Fedora 17 (Linux
3.9.10-100.fc17.i686.PAE).
Reporter: Christian P. MOMON
Labels: patch, time
Fix For: Review Patch
Attachments: LANG-916.patch
In LANG-538 issue, there is an unit test:
{noformat}
public void testFormat_CalendarIsoMsZulu() {
final String dateTime = 2009-10-16T16:42:16.000Z;
GregorianCalendar cal = new
GregorianCalendar(TimeZone.getTimeZone(GMT-8));
cal.clear();
cal.set(2009, 9, 16, 8, 42, 16);
cal.getTime();
FastDateFormat format =
FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(GMT));
assertEquals(dateTime, dateTime, format.format(cal));
}
{noformat}
This test passes successfully in lang-2.6 but failed in lang3-3.1:
{noformat}
org.junit.ComparisonFailure: dateTime expected:2009-10-16T[16]:42:16.000Z
but was:2009-10-16T[08]:42:16.000Z
{noformat}
Reproduced whit Sun Java version: 1.6.0_45 and 1.7.0_21 on Fedora 17 (Linux
3.9.10-100.fc17.i686.PAE).
Moreover, I wrote another unit test showing that the timeZone parameter seems
to be ignored :
{noformat}
public void test() {
Calendar cal =
Calendar.getInstance(TimeZone.getTimeZone(Europe/Paris));
cal.set(2009, 9, 16, 8, 42, 16);
//
System.out.println(DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.format(cal));
System.out.println(long);
System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getDefault()));
System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getTimeZone(Asia/Kolkata)));
System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getTimeZone(Europe/London)));
System.out.println(calendar);
System.out.println(DateFormatUtils.format(cal,
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getDefault()));
System.out.println(DateFormatUtils.format(cal,
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getTimeZone(Asia/Kolkata)));
System.out.println(DateFormatUtils.format(cal,
[jira] [Comment Edited] (LANG-916) CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations
[
https://issues.apache.org/jira/browse/LANG-916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14484761#comment-14484761
]
Christian P. MOMON edited comment on LANG-916 at 4/8/15 5:49 AM:
-
Here are the results of my investigations.
A) Thomas Neidhart patch is really good.
I confirm that the patch from Thomas Neidhart is the good way.
It is easy to verify:
FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(Asia/Kolkata)).format(cal)
1- FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(Asia/Kolkata))
2-- .format(cal)
3--- return printer.format(calendar)
4 return format(calendar, new
StringBuffer(this.mMaxLengthEstimate)).toString()
5- return applyRules(calendar, buf);
Step 1: store the TimeZone parameter in a FastDateFormat instance and build
rules from the pattern to display.
Step 5: apply previously build rules to the parameter 'calendar'. So, there is
no use of the TimeZone parameter stored in step 1 = **BUG**
In his patch, Thomas Neidhart calls the newCalendar(); method which build a new
calendar using the TimeZone parameter stored in step 1. Then, this new calendar
is used to apply rules.
It is exactly what it is done in other methods called format too but with a
different parameter type (Date, long...). For each, there is a comment // hard
code GregorianCalendar.
The method format must build a hard code GregorianCalendar.
B) Test errors come from bad test.
Almost all test errors come from a flawed test. In
FastDatePrinterTimeZonesTest.testCalendarTimezoneRespected, we can see:
final String actualValue = FastDateFormat.getInstance(PATTERN).format(cal);
As the TimeZone is not setted, then the TimeZone.getDefault() is set and so it
is different than the original timezone. So the displayed result is not the
same.
Fix: final String actualValue = FastDateFormat.getInstance(PATTERN,
this.timeZone).format(cal);
It must also be true of other tests.
So, definitively, the patch from Thomas Neidhart is the good way.
I will try to provide patches for tests.
was (Author: cpm):
Here are the results of my investigations.
A) Thomas Neidhart patch is really good.
I confirm that the patch from Thomas Neidhart is the good way.
It is easy to verify:
FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(Asia/Kolkata)).format(cal)
1- FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(Asia/Kolkata))
2-- .format(cal)
3--- return printer.format(calendar)
4 return format(calendar, new
StringBuffer(this.mMaxLengthEstimate)).toString()
5- return applyRules(calendar, buf);
Step 1: store the TimeZone parameter in a FastDateFormat instance and build
rules from the pattern to display.
Step 5: apply previously build rules to the parameter 'calendar'. So, there is
no use of the TimeZone parameter stored in step 1 = **BUG**
In his patch, Thomas Neidhart calls the newCalendar(); method which build a new
calendar using the TimeZone parameter stored in step 1. Then, this new calendar
is used to apply rules.
It is exactly what it is done in other methods called format too but with a
different parameter type (Date, long...). For each, there is a comment // hard
code GregorianCalendar.
The method format must build a new calendar with the timezone previously
stored.
B) Test errors come from bad test.
Almost all test errors come from a flawed test. In
FastDatePrinterTimeZonesTest.testCalendarTimezoneRespected, we can see:
final String actualValue = FastDateFormat.getInstance(PATTERN).format(cal);
As the TimeZone is not setted, then the TimeZone.getDefault() is set and so it
is different than the original timezone. So the displayed result is not the
same.
Fix: final String actualValue = FastDateFormat.getInstance(PATTERN,
this.timeZone).format(cal);
It must also be true of other tests.
So, definitively, the patch from Thomas Neidhart is the good way.
I will try to provide patches for tests.
CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in
certain situations
Key: LANG-916
URL: https://issues.apache.org/jira/browse/LANG-916
Project: Commons Lang
Issue Type: Bug
Components: lang.time.*
Affects Versions: 3.1
Environment: Sun JDK 1.6.0_45 and 1.7.0_21 on Fedora 17 (Linux
3.9.10-100.fc17.i686.PAE).
Reporter: Christian P. MOMON
Labels: patch, time
Fix For: Review Patch
Attachments: LANG-916.patch
In LANG-538 issue, there is an unit test:
{noformat}
public void testFormat_CalendarIsoMsZulu() {
final String dateTime = 2009-10-16T16:42:16.000Z;
GregorianCalendar cal = new
[jira] [Resolved] (LANG-1111) Fix FindBugs warnings in DurationFormatUtils
[ https://issues.apache.org/jira/browse/LANG-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charles Honton resolved LANG-. -- Resolution: Fixed Fix Version/s: (was: Patch Needed) 1671994 Fix FindBugs warnings in DurationFormatUtils Key: LANG- URL: https://issues.apache.org/jira/browse/LANG- Project: Commons Lang Issue Type: Improvement Reporter: Benedikt Ritter Assignee: Charles Honton Fix For: 3.5 There are some FindBugs warnings in DurationFormatUtils: bq. Comparison of String objects using == or != in org.apache.commons.lang3.time.DurationFormatUtils.format(DurationFormatUtils$Token[], long, long, long, long, long, long, long, boolean) We should either fix them or define a FindBugs exclude rule. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1211) PolyhedronsSet.firstIntersection(Vector3D point, Line line) sometimes reports intersections on wrong end of line
[
https://issues.apache.org/jira/browse/MATH-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14484606#comment-14484606
]
Mike Zimmerman commented on MATH-1211:
--
It might be enough to incorporate a direction check just after line 365 in the
recurseFirstIntersection method of PolyhedronsSet, something like:
final Vector3D hit3D = plane.intersection(line);
if (hit3D != null hit3D.subtract(point).dotProduct(line.getDirection()0) {
...
}
The problem is that the Plane.intersection method does not check for
directionality of the line, thus the PolyhedronsSet.firstIntersection method
simply returns the first face that intersects the whole line rather than the
first face intersecting the semi-infinite front of the line.
PolyhedronsSet.firstIntersection(Vector3D point, Line line) sometimes reports
intersections on wrong end of line
Key: MATH-1211
URL: https://issues.apache.org/jira/browse/MATH-1211
Project: Commons Math
Issue Type: Bug
Reporter: Mike Zimmerman
I constructed a PolyhedronsSet from a list of triangular faces representing
an icosphere (using the instructions found at
https://mail-archives.apache.org/mod_mbox/commons-user/201208.mbox/5039fe35.2090...@free.fr).
This seems to produce correct INSIDE/OUTSIDE results for randomly chosen
points. I think my mesh triangles are defined appropriately.
However, using PolyhedronsSet.firstIntersection(Vector3D point, Line line) to
shoot randomly oriented rays from the origin sometimes gives a wrong mesh
intersection point behind the origin. The intersection algorithm is
sometimes picking up faces of the sphere-shaped mesh on the wrong
semi-infinite portion of the line, i.e.
meshIntersectionPoint.subtract(point).dotProduct(line.getDirection())0 where
point is the Vector3D at center of the sphere and line extends outward
through the mesh.
I think the dot product above should always be positive. If multiple
intersections exist along a whole line then the first one in front of the
line's origin should be returned. This makes ray tracing with a
PolyhedronsSet possible.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
