[jira] Resolved: (MATH-154) MathUtils addAndCheck and subAndCheck for long values
[
https://issues.apache.org/jira/browse/MATH-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brent Worden resolved MATH-154.
---
Resolution: Fixed
Added addAndCheck, mulAndCheck, and subAndCheck MathUtils methods for long
integer arguments.
> MathUtils addAndCheck and subAndCheck for long values
> -
>
> Key: MATH-154
> URL: https://issues.apache.org/jira/browse/MATH-154
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 1.1, Nightly Builds
>Reporter: Remi Arntzen
> Fix For: 1.2
>
> Attachments: MathUtils.diff, MathUtils.diff
>
>
> public static long addAndCheck(long x, long y) {
> BigInteger s = BigInteger.valueOf(x).add(BigInteger.valueOf(y);
> if (s.bitLength() + 1 > Long.SIZE) {
> throw new ArithmeticException("overflow: add");
> }
> return s.longValue();
> }
> public static long subAndCheck(long x, long y) {
> BigInteger s = BigInteger.valueOf(x).subtract(BigInteger.valueOf(y));
> if (s.bitLength() + 1 > Long.SIZE) {
> throw new ArithmeticException("overflow: add");
> }
> return s.longValue();
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MATH-170) Create threadsafe versions of DescriptiveStatisticsImpl and DescriptiveStatistics
[ https://issues.apache.org/jira/browse/MATH-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brent Worden resolved MATH-170. --- Resolution: Fixed Fix Version/s: 1.2 Added the SynchronizedDescriptiveStatistics class. > Create threadsafe versions of DescriptiveStatisticsImpl and > DescriptiveStatistics > - > > Key: MATH-170 > URL: https://issues.apache.org/jira/browse/MATH-170 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 1.1 > Environment: N/A >Reporter: David J. M. Karlsen > Fix For: 1.2 > > > It would be very nice to have threadsafe versions (or make the current > implementations) threadsafe for > DescriptiveStatisticsImpl/DescriptiveStatistics. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (VALIDATOR-232) Add script attribute to control script generation
[ https://issues.apache.org/jira/browse/VALIDATOR-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben Speakmon resolved VALIDATOR-232. Resolution: Fixed Assignee: Ben Speakmon Committed per Paul's request. $ svn ci Sendingsrc/main/java/org/apache/commons/validator/Field.java Sending src/main/resources/org/apache/commons/validator/resources/validator_1_4_0.dtd Transmitting file data .. Committed revision 590558. > Add script attribute to control script generation > - > > Key: VALIDATOR-232 > URL: https://issues.apache.org/jira/browse/VALIDATOR-232 > Project: Commons Validator > Issue Type: New Feature > Components: Framework >Reporter: Paul Benedict >Assignee: Ben Speakmon >Priority: Minor > Fix For: 1.4 > > Attachments: VALIDATOR-232.dtd.patch, VALIDATOR-232.patch > > > Add a script="true|false" attribute to to control whether JavaScript > should be generated. > Also see: https://issues.apache.org/struts/browse/STR-1888 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-367) FastDateFormat thread safety
[ https://issues.apache.org/jira/browse/LANG-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12538986 ] Paul Benedict commented on LANG-367: Based on this link: http://www.ibm.com/developerworks/java/library/j-jtp09263.html "In any case, it's better to be clear in the documentation about how a class behaves when an instance is shared across threads. As an example of this pitfall, the class java.text.SimpleDateFormat is not thread-safe, but it wasn't until the 1.4 JDK that this was documented in the Javadoc. How many developers mistakenly created a static instance of SimpleDateFormat and used it from multiple threads, unaware that their programs were not going to behave correctly under heavy load? Don't do this to your customers or colleagues!" > FastDateFormat thread safety > > > Key: LANG-367 > URL: https://issues.apache.org/jira/browse/LANG-367 > Project: Commons Lang > Issue Type: Bug >Reporter: Sebb > Fix For: 2.4 > > Attachments: FastDateFormat.patch > > > FastDateFormat has several static HashMaps. These are currently not final, so > there is no guarantee that they will be visible to all threads. > Patch to follow. > Also, as far as I can make out, the class shares SimpleDateFormat instances > between threads. > It does not document why this is OK. > I'm guessing that it assumes that instances of the SimpleDateFormat class are > thread-safe provided that they have the same attributes, but this is not > documented. If this is the case, it's not clear that it is a valid assumption. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-367) FastDateFormat thread safety
[ https://issues.apache.org/jira/browse/LANG-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-367: --- Fix Version/s: 2.4 > FastDateFormat thread safety > > > Key: LANG-367 > URL: https://issues.apache.org/jira/browse/LANG-367 > Project: Commons Lang > Issue Type: Bug >Reporter: Sebb > Fix For: 2.4 > > Attachments: FastDateFormat.patch > > > FastDateFormat has several static HashMaps. These are currently not final, so > there is no guarantee that they will be visible to all threads. > Patch to follow. > Also, as far as I can make out, the class shares SimpleDateFormat instances > between threads. > It does not document why this is OK. > I'm guessing that it assumes that instances of the SimpleDateFormat class are > thread-safe provided that they have the same attributes, but this is not > documented. If this is the case, it's not clear that it is a valid assumption. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-367) FastDateFormat thread safety
[ https://issues.apache.org/jira/browse/LANG-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12538981 ] Henri Yandell commented on LANG-367: Patch applied (r590552). Keeping open until the SimpleDateFormat question is answered. > FastDateFormat thread safety > > > Key: LANG-367 > URL: https://issues.apache.org/jira/browse/LANG-367 > Project: Commons Lang > Issue Type: Bug >Reporter: Sebb > Fix For: 2.4 > > Attachments: FastDateFormat.patch > > > FastDateFormat has several static HashMaps. These are currently not final, so > there is no guarantee that they will be visible to all threads. > Patch to follow. > Also, as far as I can make out, the class shares SimpleDateFormat instances > between threads. > It does not document why this is OK. > I'm guessing that it assumes that instances of the SimpleDateFormat class are > thread-safe provided that they have the same attributes, but this is not > documented. If this is the case, it's not clear that it is a valid assumption. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (LANG-368) FastDateFormat getDateInstance() and getDateTimeInstance() assume Locale.getDefault() won't change
[ https://issues.apache.org/jira/browse/LANG-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell reopened LANG-368: > FastDateFormat getDateInstance() and getDateTimeInstance() assume > Locale.getDefault() won't change > -- > > Key: LANG-368 > URL: https://issues.apache.org/jira/browse/LANG-368 > Project: Commons Lang > Issue Type: Bug >Reporter: Sebb > Fix For: 2.4 > > Attachments: FastDateFormat.patch, FastDateFormatTest.patch > > > The FastDateFormat getDateInstance() and getDateTimeInstance() methods > create the HashMap key from various items including the locale. > If the locale is null, then it is not made part of the key, but the stored > object is created using the current default locale. > If the Locale is changed subsequently, then the wrong locale is applied. > Patch for test case to follow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (LANG-368) FastDateFormat getDateInstance() and getDateTimeInstance() assume Locale.getDefault() won't change
[ https://issues.apache.org/jira/browse/LANG-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed LANG-368. -- Resolution: Fixed Thanks Sebb, applied. svn ci -m "Applying Sebb's test and fix from LANG-368 - fixing it so that FastDateFormat getDateInstance and getDateTimeInstance continue to work if Locale.getDefault() changes" src/test/org/apache/commons/lang/time/FastDateFormatTest.java src/java/org/apache/commons/lang/time/FastDateFormat.java Sendingsrc/java/org/apache/commons/lang/time/FastDateFormat.java Sendingsrc/test/org/apache/commons/lang/time/FastDateFormatTest.java Transmitting file data .. Committed revision 590551. > FastDateFormat getDateInstance() and getDateTimeInstance() assume > Locale.getDefault() won't change > -- > > Key: LANG-368 > URL: https://issues.apache.org/jira/browse/LANG-368 > Project: Commons Lang > Issue Type: Bug >Reporter: Sebb > Attachments: FastDateFormat.patch, FastDateFormatTest.patch > > > The FastDateFormat getDateInstance() and getDateTimeInstance() methods > create the HashMap key from various items including the locale. > If the locale is null, then it is not made part of the key, but the stored > object is created using the current default locale. > If the Locale is changed subsequently, then the wrong locale is applied. > Patch for test case to follow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (LANG-368) FastDateFormat getDateInstance() and getDateTimeInstance() assume Locale.getDefault() won't change
[ https://issues.apache.org/jira/browse/LANG-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed LANG-368. -- Resolution: Fixed Fix Version/s: 2.4 > FastDateFormat getDateInstance() and getDateTimeInstance() assume > Locale.getDefault() won't change > -- > > Key: LANG-368 > URL: https://issues.apache.org/jira/browse/LANG-368 > Project: Commons Lang > Issue Type: Bug >Reporter: Sebb > Fix For: 2.4 > > Attachments: FastDateFormat.patch, FastDateFormatTest.patch > > > The FastDateFormat getDateInstance() and getDateTimeInstance() methods > create the HashMap key from various items including the locale. > If the locale is null, then it is not made part of the key, but the stored > object is created using the current default locale. > If the Locale is changed subsequently, then the wrong locale is applied. > Patch for test case to follow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COLLECTIONS-251) Replace getInstance() and decorate() methods with get{ClassName}()
[
https://issues.apache.org/jira/browse/COLLECTIONS-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Kestle updated COLLECTIONS-251:
---
Description:
Commons Collections uses the singleton "getInstance()" pattern and extends it
to allow parameters etc to be passed in. decorate() serves a similar purpose.
I propose replacing both of these with getClassName() for the following reasons:
1. Static imports would mean that TruePredicate.getInstance() would be replaced
with getTruePredicate(). getInstance() cannot be statically imported, because
it is reduced to one class' getInstance(), where we are likely using many.
2. It gives subclasses a way to avoid compiler issues - COLLECTIONS-243 compile
problems are generally because the compiler can't choose between Collection
and Set. Doing this change completely avoids this issue - even if there is
a workaround, this makes life a lot easier (different compilers - eclipse -
will allow things that the Sun one won't).
2.1 Overridden and overloaded static methods are a really bad idea
2.2 No confusion about what class is being instantiated
2.3 As our methods become more useful in the generic sense, the compiler issues
increase until you hit something that just won't work
3. Simple migration path - those using TruePredicate.getInstance() can switch
to PredicateUtils.truePredicate() before updating to this version.
4. Allows a more consistent user environment. Following the current pattern
means that most people will have MyTransformer.getInstance(), while using
TransformerUtils.nopTransformer().
Our work will be made a lot easier if we make this change.
was:
Commons Collections uses the singleton "getInstance()" pattern and extends it
to allow parameters etc to be passed in. decorate() serves a similar purpose.
I propose replacing both of these with getClassName() for the following reasons:
# Static imports would mean that TruePredicate.getInstance() would be replaced
with getTruePredicate(). getInstance() cannot be statically imported, because
it is reduced to one class' getInstance(), where we are likely using many.
# It gives subclasses a way to avoid compiler issues - COLLECTIONS-243 compile
problems are generally because the compiler can't choose between Collection
and Set. Doing this change completely avoids this issue - even if there is
a workaround, this makes life a lot easier (different compilers - eclipse -
will allow things that the Sun one won't).
## Overridden and overloaded static methods are a really bad idea
## No confusion about what class is being instantiated
## As our methods become more useful in the generic sense, the compiler issues
increase until you hit something that just won't work
# Simple migration path - those using TruePredicate.getInstance() can switch to
PredicateUtils.truePredicate() before updating to this version.
# Allows a more consistent user environment. Following the current pattern
means that most people will have MyTransformer.getInstance(), while using
TransformerUtils.nopTransformer().
Our work will be made a lot easier if we make this change.
> Replace getInstance() and decorate() methods with get{ClassName}()
> --
>
> Key: COLLECTIONS-251
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-251
> Project: Commons Collections
> Issue Type: Improvement
> Components: Bag, BidiMap, Buffer, Collection, Comparator, Core,
> Functor, Iterator, KeyValue, List, Map, Set
>Affects Versions: Generics
>Reporter: Stephen Kestle
> Fix For: Generics
>
>
> Commons Collections uses the singleton "getInstance()" pattern and extends it
> to allow parameters etc to be passed in. decorate() serves a similar purpose.
> I propose replacing both of these with getClassName() for the following
> reasons:
> 1. Static imports would mean that TruePredicate.getInstance() would be
> replaced with getTruePredicate(). getInstance() cannot be statically
> imported, because it is reduced to one class' getInstance(), where we are
> likely using many.
> 2. It gives subclasses a way to avoid compiler issues - COLLECTIONS-243
> compile problems are generally because the compiler can't choose between
> Collection and Set. Doing this change completely avoids this issue -
> even if there is a workaround, this makes life a lot easier (different
> compilers - eclipse - will allow things that the Sun one won't).
> 2.1 Overridden and overloaded static methods are a really bad idea
> 2.2 No confusion about what class is being instantiated
> 2.3 As our methods become more useful in the generic sense, the compiler
> issues increase until you hit something that just won't work
> 3. Simple migration path - those using TruePredicate.getInstance() can switch
> to PredicateUtils.trueP
[jira] Commented: (COLLECTIONS-251) Replace getInstance() and decorate() methods with get{ClassName}()
[
https://issues.apache.org/jira/browse/COLLECTIONS-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12538959
]
Stephen Kestle commented on COLLECTIONS-251:
I don't think so :)
BTW, this ticket was raised as a replacement for the current *Utils way of
doing it for the reasons above, not because they dont exist.
1. We promote a better static constructor pattern to the community.
2. Functors is likely to be split from collections
3. It makes more sense to find a class and use it rather than a compilation
4. These should not be in a *Utils class, but rather *s e.g. Predicates rather
than PredicateUtils
5. Java cannot attach new functions to an existing class (and extension is
difficult).
6. Do *Utils have (classes x no of instantiators) number of methods for this?
7. If so, maintenance is more difficult, and inconsistencies arise
8. These inconsistencies are made more difficult with generics, as
modifications are likely.
9. See points 2-end of the ticket.
The generics collection is meant to be a rewrite and re-evaluation.
Superfluous code that increases coding time and maintenance, in the face of a
(IMHO) more elegant solution should be eliminated in this release (the
final-clean-non deprecated version).
> Replace getInstance() and decorate() methods with get{ClassName}()
> --
>
> Key: COLLECTIONS-251
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-251
> Project: Commons Collections
> Issue Type: Improvement
> Components: Bag, BidiMap, Buffer, Collection, Comparator, Core,
> Functor, Iterator, KeyValue, List, Map, Set
>Affects Versions: Generics
>Reporter: Stephen Kestle
> Fix For: Generics
>
>
> Commons Collections uses the singleton "getInstance()" pattern and extends it
> to allow parameters etc to be passed in. decorate() serves a similar purpose.
> I propose replacing both of these with getClassName() for the following
> reasons:
> # Static imports would mean that TruePredicate.getInstance() would be
> replaced with getTruePredicate(). getInstance() cannot be statically
> imported, because it is reduced to one class' getInstance(), where we are
> likely using many.
> # It gives subclasses a way to avoid compiler issues - COLLECTIONS-243
> compile problems are generally because the compiler can't choose between
> Collection and Set. Doing this change completely avoids this issue -
> even if there is a workaround, this makes life a lot easier (different
> compilers - eclipse - will allow things that the Sun one won't).
> ## Overridden and overloaded static methods are a really bad idea
> ## No confusion about what class is being instantiated
> ## As our methods become more useful in the generic sense, the compiler
> issues increase until you hit something that just won't work
> # Simple migration path - those using TruePredicate.getInstance() can switch
> to PredicateUtils.truePredicate() before updating to this version.
> # Allows a more consistent user environment. Following the current pattern
> means that most people will have MyTransformer.getInstance(), while using
> TransformerUtils.nopTransformer().
> Our work will be made a lot easier if we make this change.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CONFIGURATION-261) Add support for date objects in PropertyListConfiguration
[ https://issues.apache.org/jira/browse/CONFIGURATION-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-261. Resolution: Fixed Parsing and formatting date values is now done manually and works on JDK 1.3, too. > Add support for date objects in PropertyListConfiguration > - > > Key: CONFIGURATION-261 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-261 > Project: Commons Configuration > Issue Type: Improvement >Reporter: Emmanuel Bourg >Assignee: Oliver Heger > Fix For: 1.5 > > > PropertyListConfiguration could implement the GNUStep extension for the > property list format to support date objects. A date is formatted like this : > <*D2002-03-22 11:30:00 +0100> > See > http://www.gnustep.org/resources/documentation/Developer/Base/Reference/NSPropertyList.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-350) New RandomDateUtils class in the lang.time package
[ https://issues.apache.org/jira/browse/LANG-350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Silberman updated LANG-350: -- Attachment: RandomDateUtilsTest.java RandomDateUtils.java Attaching proposed code > New RandomDateUtils class in the lang.time package > -- > > Key: LANG-350 > URL: https://issues.apache.org/jira/browse/LANG-350 > Project: Commons Lang > Issue Type: New Feature >Affects Versions: 2.3 >Reporter: Nathan Silberman >Priority: Minor > Fix For: 3.0 > > Attachments: RandomDateUtils.java, RandomDateUtilsTest.java > > > A new RandomDateUtils class that would provide methods for returning random > datetimes and random simple dates. Its functionality would include but not > limited to the following: > /* > * Random datetime after Janurary 1st, 1970 > */ > public static Date randomDate(); > /* > * A Random datetime after the given date > */ > public static Date randomDateAfter( Date date ); > /* > * A Random datetime before the given date > */ > public static Date randomDateBefore( Date date ); > /* > * Random datetime after this instant > */ > public static Date randomFutureDate(); > /* > * Random datetime before this instant > */ > public static Date randomPastDate(); > /* > * Random date (zeroed out time) after Janurary 1st, 1970 > */ > public static Date randomSimpleDate(); > /* > * A Random date (zeroed out time) after the given date > */ > public static Date randomSimpleDateAfter( Date date ); > /* > * A Random date (zeroed out time) before the given date > */ > public static Date randomSimpleDateBefore( Date date ); > /* > * Random date (zeroed out time) after this instant > */ > public static Date randomSimpleFutureDate(); > /* > * Random date (zeroed out time) before this instant > */ > public static Date randomSimplePastDate(); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COLLECTIONS-273) Generify functors
[ https://issues.apache.org/jira/browse/COLLECTIONS-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Egge updated COLLECTIONS-273: --- Attachment: functors.patch > Generify functors > - > > Key: COLLECTIONS-273 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-273 > Project: Commons Collections > Issue Type: Improvement >Affects Versions: Generics >Reporter: Brian Egge >Priority: Minor > Attachments: functors.patch > > > I generified most of the functors. I didn't touch the transformer classes, > as I need to think about those a bit more. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COLLECTIONS-273) Generify functors
[ https://issues.apache.org/jira/browse/COLLECTIONS-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Egge updated COLLECTIONS-273: --- Attachment: (was: functors.patch) > Generify functors > - > > Key: COLLECTIONS-273 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-273 > Project: Commons Collections > Issue Type: Improvement >Affects Versions: Generics >Reporter: Brian Egge >Priority: Minor > Attachments: functors.patch > > > I generified most of the functors. I didn't touch the transformer classes, > as I need to think about those a bit more. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (LANG-371) ToStringStyle javadoc should show examples of styles
ToStringStyle javadoc should show examples of styles Key: LANG-371 URL: https://issues.apache.org/jira/browse/LANG-371 Project: Commons Lang Issue Type: Improvement Reporter: Paul Benedict Priority: Trivial Fix For: 2.4 It is impossible to know what the style types actually render without seeing an example. I recommend first showing the code of a simple object, then give each constant an output example. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (COLLECTIONS-273) Generify functors
Wow - Brian - getting a move on! Patches are always welcome. What I am doing is basically making a project for every patch I get, and then merging them in as I make changes (to see if there's anything left of interest). Hmm. Looks like I really need to get CollectionUtils in sooner rather than later. Generics is troublesome enough that we need to be really vigilant about edge test cases. e.g. in the functors.patch, TransformedCollection.decorate(new ArrayList(), NOOP_TRANSFORMER) returns a Collection - it should also be able to return a Collection. Trust me, it's useful. And all these should be tested. We really need to ensure that our tests show something as broken, and then fix them. The strange thing about "testing" generics is that it's at compile time, so merely having the code in the test case is sufficient. JavaDoc is also really important for patches. I'm using generic method declarations as markers of completeness, so I'm not committing unless documentation is up to standard. This also slows committing down. Unfortunately, I don't know when ASAP is... Brian Egge (JIRA) wrote: Generify functors - Key: COLLECTIONS-273 URL: https://issues.apache.org/jira/browse/COLLECTIONS-273 Project: Commons Collections Issue Type: Improvement Affects Versions: Generics Reporter: Brian Egge Priority: Minor Attachments: functors.patch I generified most of the functors. I didn't touch the transformer classes, as I need to think about those a bit more.
[jira] Created: (LANG-370) Document thread safety of classes
Document thread safety of classes - Key: LANG-370 URL: https://issues.apache.org/jira/browse/LANG-370 Project: Commons Lang Issue Type: Wish Reporter: Sebb Few if any of the LANG classes state whether they are intended to be thread-safe or not. As a library, such documentation is essential IMO. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (LANG-369) ExceptionUtils not thread-safe
ExceptionUtils not thread-safe -- Key: LANG-369 URL: https://issues.apache.org/jira/browse/LANG-369 Project: Commons Lang Issue Type: Bug Reporter: Sebb The ExceptionUtils class does not appear to be thread-safe: - CAUSE_METHOD_NAMES is not final, so may not be visible to all threads - addCauseMethodName() and removeCauseMethodName() can update CAUSE_METHOD_NAMES but are not synch. - all accesses to CAUSE_METHOD_NAMES probably need to be synchronised The documentation does not state whether or not the class is thread-safe, but given that it only has static methods it does not make any sense unless it is thread-safe. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-360) Why does appendIdentityToString return null?
[ https://issues.apache.org/jira/browse/LANG-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12538854 ] Ben Speakmon commented on LANG-360: --- I like Henri's second suggestion better. Between that and deprecating the old method, I think everybody's happy :) > Why does appendIdentityToString return null? > > > Key: LANG-360 > URL: https://issues.apache.org/jira/browse/LANG-360 > Project: Commons Lang > Issue Type: Bug >Reporter: Jörg Gottschling > Fix For: 2.4 > > > ObjectUtils is designed to handle null imputs gracefully. But > ObjectUtils.appendIdentityToString does not. It returns null unnessecary if > you pass null als second parameter (the object to get the identity from). For > example appendIdentityToString(new StringBuffer(), null) will return null! > Which is an uncommen behaviour. Think about code like this: > ObjectUtils.appendIdentityToString(buffer, param1) > .appendIdentityToString(buffer, param2) > .appendIdentityToString(buffer, param3); > This will cause an NPE if param1 or param2 ist null. There may be other code > where a NPE will not happen, but the code is used for debugging and there > will be an unexpected or wrong output. > So you shoul return the StringBuffer which is passed in or a new one if null. > The harder question is what to do with the object. I think we should append > "null" to the StringBuffer, because this is what I would expect and what the > passed reference is. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-360) Why does appendIdentityToString return null?
[ https://issues.apache.org/jira/browse/LANG-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12538844 ] Jörg Gottschling commented on LANG-360: --- >> Perhaps we can call it simply "appendIdentity" ? Funny that the current >> method is "ToString" when it really appends to a StringBuffer, not a String >> ;-) << :-) +1 on that! > Why does appendIdentityToString return null? > > > Key: LANG-360 > URL: https://issues.apache.org/jira/browse/LANG-360 > Project: Commons Lang > Issue Type: Bug >Reporter: Jörg Gottschling > Fix For: 2.4 > > > ObjectUtils is designed to handle null imputs gracefully. But > ObjectUtils.appendIdentityToString does not. It returns null unnessecary if > you pass null als second parameter (the object to get the identity from). For > example appendIdentityToString(new StringBuffer(), null) will return null! > Which is an uncommen behaviour. Think about code like this: > ObjectUtils.appendIdentityToString(buffer, param1) > .appendIdentityToString(buffer, param2) > .appendIdentityToString(buffer, param3); > This will cause an NPE if param1 or param2 ist null. There may be other code > where a NPE will not happen, but the code is used for debugging and there > will be an unexpected or wrong output. > So you shoul return the StringBuffer which is passed in or a new one if null. > The harder question is what to do with the object. I think we should append > "null" to the StringBuffer, because this is what I would expect and what the > passed reference is. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-360) Why does appendIdentityToString return null?
[ https://issues.apache.org/jira/browse/LANG-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12538796 ] Henri Yandell commented on LANG-360: +1 on 'appendIdentity'. I also don't like the first parameter being nullable. There should be a version without that. appendIdentity(Object obj);StringBuffer appendIdentity(Object obj, StringBuffer buffer);StringBuffer The downside is that that means making it the second parameter. It's a clash between the API rules that 'the target should come first' and 'optional parameters should be on the end'. An optional target is just odd :) Maybe: appendIdentityToNewBuffer(Object obj);StringBuffer appendIdentity(StringBuffer buffer, Object obj);StringBuffer > Why does appendIdentityToString return null? > > > Key: LANG-360 > URL: https://issues.apache.org/jira/browse/LANG-360 > Project: Commons Lang > Issue Type: Bug >Reporter: Jörg Gottschling > Fix For: 2.4 > > > ObjectUtils is designed to handle null imputs gracefully. But > ObjectUtils.appendIdentityToString does not. It returns null unnessecary if > you pass null als second parameter (the object to get the identity from). For > example appendIdentityToString(new StringBuffer(), null) will return null! > Which is an uncommen behaviour. Think about code like this: > ObjectUtils.appendIdentityToString(buffer, param1) > .appendIdentityToString(buffer, param2) > .appendIdentityToString(buffer, param3); > This will cause an NPE if param1 or param2 ist null. There may be other code > where a NPE will not happen, but the code is used for debugging and there > will be an unexpected or wrong output. > So you shoul return the StringBuffer which is passed in or a new one if null. > The harder question is what to do with the object. I think we should append > "null" to the StringBuffer, because this is what I would expect and what the > passed reference is. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (LANG-362) Add ExtendedMessageFormat to org.apache.commons.lang.text
[ https://issues.apache.org/jira/browse/LANG-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson resolved LANG-362. -- Resolution: Fixed Since I think I've addressed Henri's concerns and noone else voiced any, I have committed this stuff. What went in differs from the latest patch here only in that some javadoc has been further modified/cleaned up to attempt to make the intents of the new classes clearer. > Add ExtendedMessageFormat to org.apache.commons.lang.text > - > > Key: LANG-362 > URL: https://issues.apache.org/jira/browse/LANG-362 > Project: Commons Lang > Issue Type: New Feature >Reporter: Matt Benson >Assignee: Matt Benson >Priority: Minor > Fix For: 2.4 > > Attachments: extendedMessageFormat.patch.txt, > extendedMessageFormat.patch.txt > > > Discussed on dev@ ( > http://mail-archives.apache.org/mod_mbox/commons-dev/200710.mbox/[EMAIL > PROTECTED] ); adding here for tracking purposes and in case anyone has any > serious objections to my implementation. Patch forthcoming... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-360) Why does appendIdentityToString return null?
[ https://issues.apache.org/jira/browse/LANG-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12538790 ] Paul Benedict commented on LANG-360: After some further ruminations, I favor deprecating the current method (Ben's comment) but also coming up with a new name that corrects the behavior. Throwing in a third parameter is quite ugly and not necessary. Perhaps we can call it simply "appendIdentity" ? Funny that the current method is "ToString" when it really appends to a StringBuffer, not a String ;-) > Why does appendIdentityToString return null? > > > Key: LANG-360 > URL: https://issues.apache.org/jira/browse/LANG-360 > Project: Commons Lang > Issue Type: Bug >Reporter: Jörg Gottschling > Fix For: 2.4 > > > ObjectUtils is designed to handle null imputs gracefully. But > ObjectUtils.appendIdentityToString does not. It returns null unnessecary if > you pass null als second parameter (the object to get the identity from). For > example appendIdentityToString(new StringBuffer(), null) will return null! > Which is an uncommen behaviour. Think about code like this: > ObjectUtils.appendIdentityToString(buffer, param1) > .appendIdentityToString(buffer, param2) > .appendIdentityToString(buffer, param3); > This will cause an NPE if param1 or param2 ist null. There may be other code > where a NPE will not happen, but the code is used for debugging and there > will be an unexpected or wrong output. > So you shoul return the StringBuffer which is passed in or a new one if null. > The harder question is what to do with the object. I think we should append > "null" to the StringBuffer, because this is what I would expect and what the > passed reference is. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (DBCP-246) Logging For DBCP
On 10/30/07, Antonio Trujillo <[EMAIL PROTECTED]> wrote: > Hi, how can I unsuscribe from this list? > http://commons.apache.org/mail-lists.html Scroll down for issues list, send email to unsubscribe address listed. -Rahul > thanx > > > > > Date: Mon, 29 Oct 2007 19:08:50 -0700 > > From: [EMAIL PROTECTED] > > To: issues@commons.apache.org > > Subject: [jira] Created: (DBCP-246) Logging For DBCP > > > > Logging For DBCP > > > > > > Key: DBCP-246 > > URL: https://issues.apache.org/jira/browse/DBCP-246 > > Project: Commons Dbcp > > Issue Type: Improvement > > Affects Versions: 1.2.2 > > Environment: Java DBCP > > Reporter: Madhusudan Pagadala > > > > > > Hi, > > > > I work in Operations, I feel that adding debug and info statements for this > > commons-dbcp is very much helpful to debug the database connection problems > > in production environment to the applications, its very useful for tuning > > the connectioon pool parameters also, I got surprised how the logging is > > missing to DBCP packages. Can I expect this to add in near releases. > > > > > > Thanks, > > Madhu. > > > > -- > > This message is automatically generated by JIRA. > > - > > You can reply to this email to add a comment to the issue online. > >
RE: [jira] Created: (DBCP-246) Logging For DBCP
Hi, how can I unsuscribe from this list? thanx > Date: Mon, 29 Oct 2007 19:08:50 -0700 > From: [EMAIL PROTECTED] > To: issues@commons.apache.org > Subject: [jira] Created: (DBCP-246) Logging For DBCP > > Logging For DBCP > > > Key: DBCP-246 > URL: https://issues.apache.org/jira/browse/DBCP-246 > Project: Commons Dbcp > Issue Type: Improvement > Affects Versions: 1.2.2 > Environment: Java DBCP > Reporter: Madhusudan Pagadala > > > Hi, > > I work in Operations, I feel that adding debug and info statements for this > commons-dbcp is very much helpful to debug the database connection problems > in production environment to the applications, its very useful for tuning the > connectioon pool parameters also, I got surprised how the logging is missing > to DBCP packages. Can I expect this to add in near releases. > > > Thanks, > Madhu. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
[jira] Updated: (LANG-368) FastDateFormat getDateInstance() and getDateTimeInstance() assume Locale.getDefault() won't change
[ https://issues.apache.org/jira/browse/LANG-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated LANG-368: -- Attachment: FastDateFormat.patch Fixes problem by using current locale as part of the key > FastDateFormat getDateInstance() and getDateTimeInstance() assume > Locale.getDefault() won't change > -- > > Key: LANG-368 > URL: https://issues.apache.org/jira/browse/LANG-368 > Project: Commons Lang > Issue Type: Bug >Reporter: Sebb > Attachments: FastDateFormat.patch, FastDateFormatTest.patch > > > The FastDateFormat getDateInstance() and getDateTimeInstance() methods > create the HashMap key from various items including the locale. > If the locale is null, then it is not made part of the key, but the stored > object is created using the current default locale. > If the Locale is changed subsequently, then the wrong locale is applied. > Patch for test case to follow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-368) FastDateFormat getDateInstance() and getDateTimeInstance() assume Locale.getDefault() won't change
[ https://issues.apache.org/jira/browse/LANG-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated LANG-368: -- Attachment: FastDateFormatTest.patch Patch to add failing unit tests of getDateInstance() and getDateTimeInstance() > FastDateFormat getDateInstance() and getDateTimeInstance() assume > Locale.getDefault() won't change > -- > > Key: LANG-368 > URL: https://issues.apache.org/jira/browse/LANG-368 > Project: Commons Lang > Issue Type: Bug >Reporter: Sebb > Attachments: FastDateFormatTest.patch > > > The FastDateFormat getDateInstance() and getDateTimeInstance() methods > create the HashMap key from various items including the locale. > If the locale is null, then it is not made part of the key, but the stored > object is created using the current default locale. > If the Locale is changed subsequently, then the wrong locale is applied. > Patch for test case to follow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (LANG-368) FastDateFormat getDateInstance() and getDateTimeInstance() assume Locale.getDefault() won't change
FastDateFormat getDateInstance() and getDateTimeInstance() assume Locale.getDefault() won't change -- Key: LANG-368 URL: https://issues.apache.org/jira/browse/LANG-368 Project: Commons Lang Issue Type: Bug Reporter: Sebb The FastDateFormat getDateInstance() and getDateTimeInstance() methods create the HashMap key from various items including the locale. If the locale is null, then it is not made part of the key, but the stored object is created using the current default locale. If the Locale is changed subsequently, then the wrong locale is applied. Patch for test case to follow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-367) FastDateFormat thread safety
[ https://issues.apache.org/jira/browse/LANG-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated LANG-367: -- Attachment: FastDateFormat.patch Make HashMaps final > FastDateFormat thread safety > > > Key: LANG-367 > URL: https://issues.apache.org/jira/browse/LANG-367 > Project: Commons Lang > Issue Type: Bug >Reporter: Sebb > Attachments: FastDateFormat.patch > > > FastDateFormat has several static HashMaps. These are currently not final, so > there is no guarantee that they will be visible to all threads. > Patch to follow. > Also, as far as I can make out, the class shares SimpleDateFormat instances > between threads. > It does not document why this is OK. > I'm guessing that it assumes that instances of the SimpleDateFormat class are > thread-safe provided that they have the same attributes, but this is not > documented. If this is the case, it's not clear that it is a valid assumption. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (LANG-367) FastDateFormat thread safety
FastDateFormat thread safety Key: LANG-367 URL: https://issues.apache.org/jira/browse/LANG-367 Project: Commons Lang Issue Type: Bug Reporter: Sebb Attachments: FastDateFormat.patch FastDateFormat has several static HashMaps. These are currently not final, so there is no guarantee that they will be visible to all threads. Patch to follow. Also, as far as I can make out, the class shares SimpleDateFormat instances between threads. It does not document why this is OK. I'm guessing that it assumes that instances of the SimpleDateFormat class are thread-safe provided that they have the same attributes, but this is not documented. If this is the case, it's not clear that it is a valid assumption. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (VFS-174) VFS is not Supported Network Attached Storage by using smb
[ https://issues.apache.org/jira/browse/VFS-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12538754 ] Sergey Vladimirov commented on VFS-174: --- Please, check if you are using correct user name and password, because root exception is: Caused by: jcifs.smb.SmbAuthException: Logon failure: unknown user name or bad password. at jcifs.smb.SmbSession.sessionSetup(SmbSession.java:281) > VFS is not Supported Network Attached Storage by using smb > -- > > Key: VFS-174 > URL: https://issues.apache.org/jira/browse/VFS-174 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 1.1 > Environment: Window,java >Reporter: vikas > > When I am not able to connect network Attached Storage by usng sbm . > I am trying this by using jars:jcifs1.2.9,jcifs1.2.10,jcifs1.2.17. > What is problem in this. > If there is any fix for this please gives yours coments on this > org.apache.commons.vfs.FileSystemException: Could not determine the type of > file "smb://vikas:[EMAIL PROTECTED]/vikas/vikas.txt". > at > org.apache.commons.vfs.provider.AbstractFileObject.attach(AbstractFileObject.java:1214) > at > org.apache.commons.vfs.provider.AbstractFileObject.exists(AbstractFileObject.java:391) > at > com.adeptia.indigo.services.transport.lanfile.LanFileSource.connect(LanFileSource.java:349) > at > com.adeptia.indigo.services.transport.lanfile.LanFileSource.testConnection(LanFileSource.java:366) > at com.adeptia.indigo.utils.IOUtils.testConnection(IOUtils.java:265) > at > org.apache.jsp.testConnection$jsp._jspService(testConnection$jsp.java:91) > at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) > at > org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:201) > at > org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:381) > at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:473) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) > at > org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:356) > at > org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567) > at org.mortbay.http.HttpContext.handle(HttpContext.java:1776) > at > org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:514) > at org.mortbay.http.HttpContext.handle(HttpContext.java:1726) > at org.mortbay.http.HttpServer.service(HttpServer.java:879) > at org.mortbay.http.HttpConnection.service(HttpConnection.java:790) > at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:952) > at org.mortbay.http.HttpConnection.handle(HttpConnection.java:807) > at > org.mortbay.http.SocketListener.handleConnection(SocketListener.java:196) > at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:289) > at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:487) > Caused by: jcifs.smb.SmbAuthException: Logon failure: unknown user name or > bad password. > at jcifs.smb.SmbSession.sessionSetup(SmbSession.java:281) > at jcifs.smb.SmbSession.send(SmbSession.java:233) > at jcifs.smb.SmbTree.treeConnect(SmbTree.java:154) > at jcifs.smb.SmbFile.doConnect(SmbFile.java:816) > at jcifs.smb.SmbFile.connect(SmbFile.java:854) > at jcifs.smb.SmbFile.connect0(SmbFile.java:793) > at jcifs.smb.SmbFile.queryPath(SmbFile.java:1248) > at jcifs.smb.SmbFile.exists(SmbFile.java:1330) > at jcifs.smb.SmbFile.isDirectory(SmbFile.java:1403) > at > org.apache.commons.vfs.provider.smb.SmbFileObject.createSmbFile(SmbFileObject.java:81) > at > org.apache.commons.vfs.provider.smb.SmbFileObject.createSmbFile(SmbFileObject.java:76) > at > org.apache.commons.vfs.provider.smb.SmbFileObject.doAttach(SmbFileObject.java:63) > at > org.apache.commons.vfs.provider.AbstractFileObject.attach(AbstractFileObject.java:1200) > Vikas -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COLLECTIONS-253) Generics version of PredicateUtils and the predicates it creates
[ https://issues.apache.org/jira/browse/COLLECTIONS-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12538742 ] Brian Egge commented on COLLECTIONS-253: I do like using the EasyMock library, but I'm not sure if there's enough of a need for it in the Collections project. It would be another build dependecy (obviously not a runtime dependency). The patch looks good, but we'd have to modify the ant and maven build script to include EasyMock. > Generics version of PredicateUtils and the predicates it creates > > > Key: COLLECTIONS-253 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-253 > Project: Commons Collections > Issue Type: Improvement > Components: Collection >Affects Versions: Generics > Environment: Mac OS X >Reporter: Edwin Tellman >Priority: Minor > Fix For: Generics > > Attachments: predicates.tgz, predicates.txt > > > I added generics to PredicateUtils and the predicates it creates > (AndPredicate, AllPredicate, etc.). I also made use of variable argument > arrays where it seemed appropriate. > I modified TestPredicateUtils to use JUnit4 and EasyMock. I created new test > classes for some of the predicates and migrated some of the existing tests > from TestPredicateUtils to test classes for specific predicates. This > allowed for the definition of some common tests and mock predicate creation > routines in a base class. > I added a unit test for the InvokerTransformer class. > This patch depends on COLLECTIONS-247 as it uses JUnit4 and EasyMock. > I believe there is some overlap between this patch and the patch attached to > COLLECTIONS-110 by Hendrik Maryns yesterday. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COLLECTIONS-243) Generic versions of Predicated, Syncronized and Unmodifiable classes
[ https://issues.apache.org/jira/browse/COLLECTIONS-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12538740 ] Brian Egge commented on COLLECTIONS-243: The Transformer interface makes since as a single item. I can create a transformer to convert Strings to Integers. These have nothing in common, and the Transformer seems to make sense. Where this doesn't seem to work so great is when you have a chain, or a collection of transformers. If you want to go from Double to String to BigDecimal, you could do this with two transformers. However, a class which contains a list of Transformer, expecting the output of one to feed into the input of the next will not work, with anything but . So, WRT ChainedTransformer, I'd be happy to leave it ungenerified. Another problem with Transformer I ran into is with classes like TransformedBag. This class implements Bag, and you must specify if the Bag is to add or types. Perhaps, it's best not to specify either. With the TransformedBag, you want you getters to return the type, but your adders to use the type. This breaks the Bag interface, if you try to specify a type for the Bag. It probably simply shouldn't try to specify a type for a Bag. If you have a Bag, then you expect to add & remove Strings. With a transformed Bag, you can add one type and get another type out - clearly defeating what you are trying to achieve with type safe generics. > Generic versions of Predicated, Syncronized and Unmodifiable classes > > > Key: COLLECTIONS-243 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-243 > Project: Commons Collections > Issue Type: Improvement > Components: Bag, Collection, List, Set >Affects Versions: Generics > Environment: OS X >Reporter: Edwin Tellman >Priority: Minor > Fix For: Generics > > Attachments: collections_06_03_11.patch > > > I added generics to some more classes and fixed some compilation problems. > The generic version of Transformer required the input and output types to be > identical. This seemed to me to reduce the usefulness of transformed > collections, as transforming one type into another seems like it would be a > fairly common operation. I'm not sure how to fix this, however, as it also > doesn't seem feasible to have a generic TransformedCollection with different > input and output types that implements Collection. Anyway, this patch > de-generifies TransformedCollection, which also fixes some compilation > problems. Please disregard this change if you disagree and have a better > solution. > The modified collection classes are: > Bags: PredicatedSortedBag, AbstractBagDecorator, SynchronizedBag, > UnmodifiableSortedBag, SynchronizedSortedBag, PredicatedBag > Lists: PredicatedList, SynchronizedList > Sets: PredicatedSortedSet, SynchronizedSortedSet, PredicatedSet, > UnmodifiableSortedSet, SynchronizedSet > Miscellaneous: PredicatedBuffer -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COLLECTIONS-251) Replace getInstance() and decorate() methods with get{ClassName}()
[
https://issues.apache.org/jira/browse/COLLECTIONS-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12538730
]
Brian Egge commented on COLLECTIONS-251:
It appears these methods exist in the current PredicateUtils class. I don't
see any need to depreciate the getInstance methods. Can this JIRA be closed?
> Replace getInstance() and decorate() methods with get{ClassName}()
> --
>
> Key: COLLECTIONS-251
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-251
> Project: Commons Collections
> Issue Type: Improvement
> Components: Bag, BidiMap, Buffer, Collection, Comparator, Core,
> Functor, Iterator, KeyValue, List, Map, Set
>Affects Versions: Generics
>Reporter: Stephen Kestle
> Fix For: Generics
>
>
> Commons Collections uses the singleton "getInstance()" pattern and extends it
> to allow parameters etc to be passed in. decorate() serves a similar purpose.
> I propose replacing both of these with getClassName() for the following
> reasons:
> # Static imports would mean that TruePredicate.getInstance() would be
> replaced with getTruePredicate(). getInstance() cannot be statically
> imported, because it is reduced to one class' getInstance(), where we are
> likely using many.
> # It gives subclasses a way to avoid compiler issues - COLLECTIONS-243
> compile problems are generally because the compiler can't choose between
> Collection and Set. Doing this change completely avoids this issue -
> even if there is a workaround, this makes life a lot easier (different
> compilers - eclipse - will allow things that the Sun one won't).
> ## Overridden and overloaded static methods are a really bad idea
> ## No confusion about what class is being instantiated
> ## As our methods become more useful in the generic sense, the compiler
> issues increase until you hit something that just won't work
> # Simple migration path - those using TruePredicate.getInstance() can switch
> to PredicateUtils.truePredicate() before updating to this version.
> # Allows a more consistent user environment. Following the current pattern
> means that most people will have MyTransformer.getInstance(), while using
> TransformerUtils.nopTransformer().
> Our work will be made a lot easier if we make this change.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COLLECTIONS-229) Remove deprecated classes from generics version
[ https://issues.apache.org/jira/browse/COLLECTIONS-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12538729 ] Brian Egge commented on COLLECTIONS-229: +1 for Stephen Smith's patches. Are there any active commiters willing to apply these changes? I'm happy to convert the files into a standard patch file. > Remove deprecated classes from generics version > --- > > Key: COLLECTIONS-229 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-229 > Project: Commons Collections > Issue Type: Task > Components: Core, Iterator >Reporter: Stephen Colebourne > Fix For: Generics > > Attachments: AbstractBidiMapDecorator.java, AbstractDualBidiMap.java, > AbstractOrderedBidiMapDecorator.java, AbstractSortedBidiMapDecorator.java, > TestAbstractOrderedBidiMapDecorator.java, UnmodifiableBidiMap.java, > UnmodifiableOrderedBidiMap.java, UnmodifiableSortedBidiMap.java > > > The generics version should have no deprecations -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COLLECTIONS-245) Genericise CollectionUtils and ListUtils.
[ https://issues.apache.org/jira/browse/COLLECTIONS-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12538728 ] Brian Egge commented on COLLECTIONS-245: I know Stephen Kestle is doing some work on the CollectionUtils. Are these patches more complete? Would it help if I downloaded them, applied them, and then reuploaded a patch file? > Genericise CollectionUtils and ListUtils. > - > > Key: COLLECTIONS-245 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-245 > Project: Commons Collections > Issue Type: Improvement > Components: Collection, List >Affects Versions: Generics > Environment: Commons Collections JSE5 branch. >Reporter: Stephen Smith > Fix For: Generics > > Attachments: AbstractCollectionDecorator.java, > BoundedCollection.java, CollectionUtils.java, ListUtils.java, > TestCollectionUtils.java, TestListUtils.java, > UnmodifiableBoundedCollection.java, UnmodifiableIterator.java > > > Attached are genericised versions of CollectionUtils and ListUtils, as well > as their test cases. Note that methods involving Transformers have been > ignored, as the current Transformer class signature is under > consideration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COLLECTIONS-233) Closure is an inaccurate name
[
https://issues.apache.org/jira/browse/COLLECTIONS-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12538725
]
Brian Egge commented on COLLECTIONS-233:
In some future version of Java, we may get Closures. It hasn't been voted into
7.0 yet. I think the Closures offered by the Collections is currently the
closest thing you can get in Java. True, it not a real closure like what you
get in Smalltalk or Ruby. Having learned to use Closures in Ruby, I found it
easy to pick up in the Collections framework. Having another name would make
the process more complex. If/when Java comes up with real closures, we could
depreciate the Closures interface, and give a good example of how to convert it
to a real one.
Introducing the Processor interface, would just create additional refactoring,
if the end goal is to use a built in Java mechanism instead.
I vote "won't fix" on this issue - at least not for now. Maybe if the 1.4
branch was in depreciated status, and there was a clear idea of if Closures are
going to be introduced into the Java languages, and if they are, what exactly
the usage is going to be. (As I understand there are two competing ways of
implementing closures).
> Closure is an inaccurate name
> -
>
> Key: COLLECTIONS-233
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-233
> Project: Commons Collections
> Issue Type: Improvement
> Components: Collection
>Reporter: Stephen Kestle
> Fix For: Generics
>
>
> The "Closure" in commons collections is not named well: for non-functional
> programmers it will induce a "what's that?", and for functional programmers
> it will confuse expectations.
>
> From http://en.wikipedia.org/wiki/Closure_(computer_science):
> A closure combines the code of a function with a special lexical environment
> bound to that function (scope).
>
> Java cannot pass functions, so the only way this can be done is with an
> (inner) class, as follows (also from wikipedia):
>
> class CalculationWindow extends JFrame {
> private JButton btnSave;
> ...
>
> public final calculateInSeparateThread(final URI uri) {
> // The expression "new Runnable() { ... }" is an anonymous class.
> Runnable runner = new Runnable() {
> void run() {
> // It can access final local variables:
> calculate(uri);
> // It can access private fields of the enclosing class:
> btnSave.setEnabled(true);
> }
> };
> new Thread(runner).start();
> }
> }
>
> Note how the Runnable accesses the btnSave variable in the function scope.
> This "special lexical environment" is NOT the same as passing a parameter
> through a constructor OR execute method. A Closure should NOT take a
> parameter for execute. It is not actually possible to have a "Closure"
> object, as that breaks the lexical environment.
>
> So, what to do?
>
> I would propose an interface called Processor. It is more intuitive and has
> many "real world" examples that can anchor the term so that it makes sense to
> the average programmer.
>
> For example, when applying for a passport, some documentation needs to be
> filled out, and then it will go through a process to get you a passport. You
> hand (or send) your forms to a clerk (Processor), and that's it. The
> Processor does not reply - the context that is passed in your form (your
> details) allows a message to be sent back at a later date.
>
> For backwards compatibility the interface would be
> public interface Processor extends Closure{}
> with the appropriate documentation. Closure would be deprecated with an
> appropriate explanation.
> However, it may be acceptable with the new version just to do a rename.
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (COLLECTIONS-274) Maven 2 pom file
Maven 2 pom file Key: COLLECTIONS-274 URL: https://issues.apache.org/jira/browse/COLLECTIONS-274 Project: Commons Collections Issue Type: Improvement Environment: Maven 2 Reporter: Brian Egge Fix For: Generics Attachments: pom.xml -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COLLECTIONS-274) Maven 2 pom file
[ https://issues.apache.org/jira/browse/COLLECTIONS-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Egge updated COLLECTIONS-274: --- Attachment: pom.xml > Maven 2 pom file > > > Key: COLLECTIONS-274 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-274 > Project: Commons Collections > Issue Type: Improvement > Environment: Maven 2 >Reporter: Brian Egge > Fix For: Generics > > Attachments: pom.xml > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COLLECTIONS-273) Generify functors
[ https://issues.apache.org/jira/browse/COLLECTIONS-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Egge updated COLLECTIONS-273: --- Attachment: functors.patch > Generify functors > - > > Key: COLLECTIONS-273 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-273 > Project: Commons Collections > Issue Type: Improvement >Affects Versions: Generics >Reporter: Brian Egge >Priority: Minor > Attachments: functors.patch > > > I generified most of the functors. I didn't touch the transformer classes, > as I need to think about those a bit more. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COLLECTIONS-273) Generify functors
Generify functors - Key: COLLECTIONS-273 URL: https://issues.apache.org/jira/browse/COLLECTIONS-273 Project: Commons Collections Issue Type: Improvement Affects Versions: Generics Reporter: Brian Egge Priority: Minor Attachments: functors.patch I generified most of the functors. I didn't touch the transformer classes, as I need to think about those a bit more. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COLLECTIONS-269) build.xml doesn't download emma
[ https://issues.apache.org/jira/browse/COLLECTIONS-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Egge updated COLLECTIONS-269: --- Attachment: junit.patch Allows Ant to download JUnit as well. > build.xml doesn't download emma > --- > > Key: COLLECTIONS-269 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-269 > Project: Commons Collections > Issue Type: Improvement >Affects Versions: Generics > Environment: clean checkout >Reporter: Brian Egge >Priority: Minor > Fix For: Generics > > Attachments: emma.patch, junit.patch > > > When downloading the project and running 'ant', it fails because emma isn't > available. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
