Re: [ANNOUNCE] Welcome Duncan Jones, committer
On 01/24/2014 04:20 PM, Gary Gregory wrote: Hi All, Please give a warm welcome to Duncan Jones, our latest committer. Welcome aboard Duncan! Well, you have been around for some time, but welcome as committer ;-) Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1561228 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/time/FastDateParser.java
Hello Charles, please don't forget to add the tickets you fix to changes.xml. This is needed to generate release notes. I've added LANG-958 in r1561276 for you. Benedikt 2014/1/25 c...@apache.org Author: chas Date: Fri Jan 24 23:29:17 2014 New Revision: 1561228 URL: http://svn.apache.org/r1561228 Log: FastDateParser javadoc incorrectly states that SimpleDateFormat is used internally Modified: commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/time/FastDateParser.java Modified: commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/time/FastDateParser.java URL: http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/time/FastDateParser.java?rev=1561228r1=1561227r2=1561228view=diff == --- commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/time/FastDateParser.java (original) +++ commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/time/FastDateParser.java Fri Jan 24 23:29:17 2014 @@ -44,7 +44,7 @@ import java.util.regex.Pattern; * codeSimpleDateFormat/code in most parsing situations. * This class is especially useful in multi-threaded server environments. * codeSimpleDateFormat/code is not thread-safe in any JDK version, - * nor will it be as Sun have closed the + * nor will it be as Sun has closed the * a href=http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4228335 bug/a/RFE. * /p * @@ -54,14 +54,6 @@ import java.util.regex.Pattern; * pTiming tests indicate this class is as about as fast as SimpleDateFormat * in single thread applications and about 25% faster in multi-thread applications./p * - * pNote that the code only handles Gregorian calendars. The following non-Gregorian - * calendars use SimpleDateFormat internally, and so will be slower: - * ul - * lija_JP_TH - Japanese Imperial/li - * lith_TH (any variant) - Thai Buddhist/li - * /ul - * /p - * * @version $Id$ * @since 3.2 */ -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
Re: [compress] 2.0: require Java7?
2014/1/25 Damjan Jovanovic dam...@apache.org On Fri, Jan 24, 2014 at 6:06 PM, Stefan Bodewig bode...@apache.org wrote: On 2013-12-30, Stefan Bodewig wrote: Compress 1.x is at Java5, personally I don't think Java6 would give us any benefits. I don't know about the other improvements in NIO2 but the java.nio.file package looks useful for compress. In the meantime it has been pointed out to me that Android doesn't support NIO2. I can imagine Android apps using Compress so this looks like a good reason to hold back requiring Java7. Stefan It's already possible to use most Java 7 language level features and compile to Android (https://github.com/yareally/Java7-on-Android). It would also possible to reimplement the needed classes (which is only SeekableByteChannel?) in nio2 using some kind of wrapper on top of Android's java.nio. We could still use Java 7 / nio2 and then make a plan for Android releases. +1 Damjan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
Re: [compress] 2.0: require Java7?
And the old 1.x releases are not going magically away with a 2.x release ;) +1 for not having Android influence the decision On Sat, Jan 25, 2014 at 9:58 AM, Benedikt Ritter brit...@apache.org wrote: 2014/1/25 Damjan Jovanovic dam...@apache.org On Fri, Jan 24, 2014 at 6:06 PM, Stefan Bodewig bode...@apache.org wrote: On 2013-12-30, Stefan Bodewig wrote: Compress 1.x is at Java5, personally I don't think Java6 would give us any benefits. I don't know about the other improvements in NIO2 but the java.nio.file package looks useful for compress. In the meantime it has been pointed out to me that Android doesn't support NIO2. I can imagine Android apps using Compress so this looks like a good reason to hold back requiring Java7. Stefan It's already possible to use most Java 7 language level features and compile to Android (https://github.com/yareally/Java7-on-Android). It would also possible to reimplement the needed classes (which is only SeekableByteChannel?) in nio2 using some kind of wrapper on top of Android's java.nio. We could still use Java 7 / nio2 and then make a plan for Android releases. +1 Damjan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ANNOUNCE] Welcome Duncan Jones, committer
On 25 January 2014 08:51, Thomas Neidhart thomas.neidh...@gmail.com wrote: On 01/24/2014 04:20 PM, Gary Gregory wrote: Hi All, Please give a warm welcome to Duncan Jones, our latest committer. Welcome aboard Duncan! Well, you have been around for some time, but welcome as committer ;-) Thomas I'm delighted to join as a committer, thank you everyone. Duncan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1560382 - /commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVPrinter.java
+1. Makes svn blame useless by creating a date in time when everything was touched. On Thu, Jan 23, 2014 at 10:07 AM, sebb seb...@gmail.com wrote: I think there is a big difference between creating a class with sorted methods, and retrospectively sorting methods in an existing class. That may improve the readibility of the class, or it may make the class much harder to read. For example with getters/setters: if these are kept together in pairs, then it is immediately obvious if one half is missing (deliberately or not). Not so easy to spot if one has to compare two long lists which are at nearly opposing ends of the alphabet. Unless the class is seriously messy, I would say leave well alone. It's very difficult to review the commit mails to be sure nothing was accidentally changed. It makes subsequent comparisons between versions much harder to do. It won't please everyone. On 23 January 2014 17:25, Paul Benedict pbened...@apache.org wrote: Yes, and Gary's argument is a very high priority driver behind my alphabetizing. I don't want to maintain groupings. I have concluded a long time ago that my time is wasted doing that stuff in code. On Thu, Jan 23, 2014 at 11:18 AM, Gary Gregory garydgreg...@gmail.com wrote: Adopting a guideline like this is still a subjective arrangement. It's also takes time to maintain, not something I'm found of doing. To reach his own I suppose. G Original message From: sebb seb...@gmail.com Date:01/23/2014 09:15 (GMT-05:00) To: Commons Developers List dev@commons.apache.org Subject: Re: svn commit: r1560382 - /commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVPrinter.java On 23 January 2014 07:34, Emmanuel Bourg ebo...@apache.org wrote: Le 23/01/2014 08:03, Benedikt Ritter a écrit : I personally don't like alphabetically sorted classes. For example if a public method calls a private method, I like to have the private method beneath the public method that uses it. This way I can read through a claa top to bottom without out to much jumping back and forth. But that's just a matter of taste, I guess. What do others think? +1 As far as methods are concerned, usually I find it helpful to group them into the following general sections: group + protected package private Within a group, alphaorder is not always the most appropriate - for example getter/setter pairs more naturally belong together. Also getter/setters are not generally the most interesting methods, so can be relegated further down the file. I prefer to see related methods together (which may involve mixing private/public in the same section) I don't see the point of sorting the methods just for the sake of it. If the methods are logically grouped it can make the code much easier to follow. As far as data items are concerned, I do find it easier if they are organised in sections. Even here, there may be private fields that relate directly to a public field, in which case they should be together. Within a data section, generally the fields should be sorted, but only within functional groups. I favour logical ordering rather than strict lexicographical ordering. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Cheers, Paul - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1560762 - /commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/StringUtilsTest.java
In case you didn't get an answer here:
http://stackoverflow.com/questions/304383/how-do-i-edit-a-log-message-that-i-already-committed-in-subversion
$svn propedit -r N --revprop svn:log URL
$svn propset -r N --revprop svn:log new log message URL
On Thu, Jan 23, 2014 at 9:17 AM, Benedikt Ritter brit...@apache.org wrote:
Sorry, I messed that one up. I wanted to call mvn clean test but instead
committed with the some message as one before. Should be Use annotation
based testing for failure cases. Is there any way to modify the commit
log?
Benedikt
2014/1/23 brit...@apache.org
Author: britter
Date: Thu Jan 23 17:15:48 2014
New Revision: 1560762
URL: http://svn.apache.org/r1560762
Log:
Keep tests for Levenshtein Distance together
Modified:
commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/StringUtilsTest.java
Modified:
commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/StringUtilsTest.java
URL:
http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/StringUtilsTest.java?rev=1560762r1=1560761r2=1560762view=diff
==
---
commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/StringUtilsTest.java
(original)
+++
commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/StringUtilsTest.java
Thu Jan 23 17:15:48 2014
@@ -1901,20 +1901,18 @@ public class StringUtilsTest {
assertEquals(8, StringUtils.getLevenshteinDistance(hippo,
) );
assertEquals(8, StringUtils.getLevenshteinDistance(,
hippo) );
assertEquals(1, StringUtils.getLevenshteinDistance(hello,
hallo) );
-try {
-StringUtils.getLevenshteinDistance(a, null);
-fail(expecting IllegalArgumentException);
-} catch (final IllegalArgumentException ex) {
-// empty
-}
-try {
-StringUtils.getLevenshteinDistance(null, a);
-fail(expecting IllegalArgumentException);
-} catch (final IllegalArgumentException ex) {
-// empty
-}
}
-
+
+@Test(expected = IllegalArgumentException.class)
+public void testGetLevenshteinDistance_NullString() throws
Exception {
+StringUtils.getLevenshteinDistance(a, null);
+}
+
+@Test(expected = IllegalArgumentException.class)
+public void testGetLevenshteinDistance_StringNull() throws
Exception {
+StringUtils.getLevenshteinDistance(null, a);
+}
+
@Test
public void testGetLevenshteinDistance_StringStringInt() {
// empty strings
@@ -1976,33 +1974,26 @@ public class StringUtilsTest {
assertEquals(7, StringUtils.getLevenshteinDistance(hippo,
elephant, Integer.MAX_VALUE) );
assertEquals(8, StringUtils.getLevenshteinDistance(hippo,
, Integer.MAX_VALUE) );
assertEquals(8, StringUtils.getLevenshteinDistance(,
hippo, Integer.MAX_VALUE) );
-assertEquals(1, StringUtils.getLevenshteinDistance(hello,
hallo, Integer.MAX_VALUE) );
+assertEquals(1, StringUtils.getLevenshteinDistance(hello,
hallo, Integer.MAX_VALUE));
+}
-// exceptions
-try {
-StringUtils.getLevenshteinDistance(a, null, 0);
-fail(expecting IllegalArgumentException);
-} catch (final IllegalArgumentException ex) {
-// empty
-}
-try {
+@Test(expected = IllegalArgumentException.class)
+public void testGetLevenshteinDistance_NullStringInt() throws
Exception {
StringUtils.getLevenshteinDistance(null, a, 0);
-fail(expecting IllegalArgumentException);
-} catch (final IllegalArgumentException ex) {
-// empty
-}
+}
-try {
+@Test(expected = IllegalArgumentException.class)
+public void testGetLevenshteinDistance_StringNullInt() throws
Exception {
+StringUtils.getLevenshteinDistance(a, null, 0);
+}
+
+@Test(expected = IllegalArgumentException.class)
+public void testGetLevenshteinDistance_StringStringNegativeInt()
throws Exception {
StringUtils.getLevenshteinDistance(a, a, -1);
-fail(expecting IllegalArgumentException);
-} catch (final IllegalArgumentException ex) {
-// empty
-}
}
@Test
public void testGetJaroWinklerDistance_StringString() {
-
assertEquals(0.93d, StringUtils.getJaroWinklerDistance(frog,
fog), 0.0d);
assertEquals(0.0d, StringUtils.getJaroWinklerDistance(fly,
ant), 0.0d);
assertEquals(0.44d,
StringUtils.getJaroWinklerDistance(elephant, hippo), 0.0d);
@@ -2010,26 +2001,21 @@ public class StringUtilsTest {
assertEquals(0.93d,
Re: svn commit: r1560762 - /commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/StringUtilsTest.java
Figured, it out myself.
Thanks :)
Send from my mobile device
Am 25.01.2014 um 18:26 schrieb Henri Yandell flame...@gmail.com:
In case you didn't get an answer here:
http://stackoverflow.com/questions/304383/how-do-i-edit-a-log-message-that-i-already-committed-in-subversion
$svn propedit -r N --revprop svn:log URL
$svn propset -r N --revprop svn:log new log message URL
On Thu, Jan 23, 2014 at 9:17 AM, Benedikt Ritter brit...@apache.org wrote:
Sorry, I messed that one up. I wanted to call mvn clean test but instead
committed with the some message as one before. Should be Use annotation
based testing for failure cases. Is there any way to modify the commit
log?
Benedikt
2014/1/23 brit...@apache.org
Author: britter
Date: Thu Jan 23 17:15:48 2014
New Revision: 1560762
URL: http://svn.apache.org/r1560762
Log:
Keep tests for Levenshtein Distance together
Modified:
commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/StringUtilsTest.java
Modified:
commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/StringUtilsTest.java
URL:
http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/StringUtilsTest.java?rev=1560762r1=1560761r2=1560762view=diff
==
---
commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/StringUtilsTest.java
(original)
+++
commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/StringUtilsTest.java
Thu Jan 23 17:15:48 2014
@@ -1901,20 +1901,18 @@ public class StringUtilsTest {
assertEquals(8, StringUtils.getLevenshteinDistance(hippo,
) );
assertEquals(8, StringUtils.getLevenshteinDistance(,
hippo) );
assertEquals(1, StringUtils.getLevenshteinDistance(hello,
hallo) );
-try {
-StringUtils.getLevenshteinDistance(a, null);
-fail(expecting IllegalArgumentException);
-} catch (final IllegalArgumentException ex) {
-// empty
-}
-try {
-StringUtils.getLevenshteinDistance(null, a);
-fail(expecting IllegalArgumentException);
-} catch (final IllegalArgumentException ex) {
-// empty
-}
}
-
+
+@Test(expected = IllegalArgumentException.class)
+public void testGetLevenshteinDistance_NullString() throws
Exception {
+StringUtils.getLevenshteinDistance(a, null);
+}
+
+@Test(expected = IllegalArgumentException.class)
+public void testGetLevenshteinDistance_StringNull() throws
Exception {
+StringUtils.getLevenshteinDistance(null, a);
+}
+
@Test
public void testGetLevenshteinDistance_StringStringInt() {
// empty strings
@@ -1976,33 +1974,26 @@ public class StringUtilsTest {
assertEquals(7, StringUtils.getLevenshteinDistance(hippo,
elephant, Integer.MAX_VALUE) );
assertEquals(8, StringUtils.getLevenshteinDistance(hippo,
, Integer.MAX_VALUE) );
assertEquals(8, StringUtils.getLevenshteinDistance(,
hippo, Integer.MAX_VALUE) );
-assertEquals(1, StringUtils.getLevenshteinDistance(hello,
hallo, Integer.MAX_VALUE) );
+assertEquals(1, StringUtils.getLevenshteinDistance(hello,
hallo, Integer.MAX_VALUE));
+}
-// exceptions
-try {
-StringUtils.getLevenshteinDistance(a, null, 0);
-fail(expecting IllegalArgumentException);
-} catch (final IllegalArgumentException ex) {
-// empty
-}
-try {
+@Test(expected = IllegalArgumentException.class)
+public void testGetLevenshteinDistance_NullStringInt() throws
Exception {
StringUtils.getLevenshteinDistance(null, a, 0);
-fail(expecting IllegalArgumentException);
-} catch (final IllegalArgumentException ex) {
-// empty
-}
+}
-try {
+@Test(expected = IllegalArgumentException.class)
+public void testGetLevenshteinDistance_StringNullInt() throws
Exception {
+StringUtils.getLevenshteinDistance(a, null, 0);
+}
+
+@Test(expected = IllegalArgumentException.class)
+public void testGetLevenshteinDistance_StringStringNegativeInt()
throws Exception {
StringUtils.getLevenshteinDistance(a, a, -1);
-fail(expecting IllegalArgumentException);
-} catch (final IllegalArgumentException ex) {
-// empty
-}
}
@Test
public void testGetJaroWinklerDistance_StringString() {
-
assertEquals(0.93d, StringUtils.getJaroWinklerDistance(frog,
fog), 0.0d);
assertEquals(0.0d, StringUtils.getJaroWinklerDistance(fly,
ant), 0.0d);
assertEquals(0.44d,
StringUtils.getJaroWinklerDistance(elephant, hippo), 0.0d);
@@ -2010,26 +2001,21 @@ public class StringUtilsTest {
Re: [compress] 2.0: require Java7?
On 2014-01-25, Damjan Jovanovic wrote: On Fri, Jan 24, 2014 at 6:06 PM, Stefan Bodewig bode...@apache.org wrote: On 2013-12-30, Stefan Bodewig wrote: Compress 1.x is at Java5, personally I don't think Java6 would give us any benefits. I don't know about the other improvements in NIO2 but the java.nio.file package looks useful for compress. In the meantime it has been pointed out to me that Android doesn't support NIO2. I can imagine Android apps using Compress so this looks like a good reason to hold back requiring Java7. It's already possible to use most Java 7 language level features and compile to Android (https://github.com/yareally/Java7-on-Android). It would also possible to reimplement the needed classes (which is only SeekableByteChannel?) in nio2 using some kind of wrapper on top of Android's java.nio. It would also be a part java.nio.file.attribute, but we can re-invent that as well, if needed. What you suggest could work as long as we are careful and never assume FileChannel implements SeekableByteChannel but use some custom File = SeekableByteChannel code using Java7 if available - I'm just afraid we'll forget to be careful. We could still use Java 7 / nio2 and then make a plan for Android releases. Thanks for volunteering ;-) Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
